Vérificateur SPF

C'est un enregistrement TXT du domaine qui énumère les serveurs autorisés à envoyer du courrier avec celui-ci. Quand un message arrive, le serveur qui le reçoit regarde de quelle IP il provient et vérifie si elle figure dans cette liste. Si ce n'est pas le cas, le SPF échoue et le message perd en crédibilité : il peut aller en spam ou être rejeté, selon ce que dit votre DMARC.

La norme (RFC 7208) limite à dix les requêtes DNS que peut coûter l'évaluation d'un SPF, pour que personne n'utilise le courrier comme amplificateur d'attaques. Comptent include, a, mx, ptr, exists et redirect, y compris ceux à l'intérieur de chaque include. Pour réduire : retirez les fournisseurs que vous n'utilisez plus, remplacez a et mx par l'IP avec ip4 quand elle est fixe, et envoyez les newsletters depuis un sous-domaine avec son propre SPF. Aplatir l'enregistrement (remplacer les include par leurs IP) fonctionne jusqu'à ce que le fournisseur change d'IP sans prévenir.

Si vous avez déjà DMARC, ~all suffit : c'est DMARC qui décide quoi faire en cas d'échec, et ainsi vous ne perdez pas de courrier légitime si un jour vous envoyez depuis un service que vous avez oublié d'ajouter. -all a du sens quand vous savez avec certitude qui envoie pour vous. Ce qu'il ne faut jamais, c'est +all, qui autorise n'importe qui, ni ?all, qui ne protège rien.

Non. Si le domaine publie deux TXT commençant par v=spf1, le résultat est une erreur permanente et aucun des deux n'est valable. C'est une erreur très courante lors de l'ajout d'un nouveau service : au lieu de créer un autre enregistrement, ajoutez son include à celui que vous avez déjà.

Cela aide, mais ne suffit pas. Depuis février 2024, Gmail et Yahoo exigent SPF ou DKIM de quiconque leur envoie du courrier, et SPF, DKIM et DMARC de ceux qui envoient plus de 5 000 messages par jour. Ils regardent aussi la réputation de l'IP, le contenu et la réaction des destinataires. Pour voir tout cela ensemble, envoyez un message à notre test de messagerie.