Erreurs à éviter en écrivant un SPF
La plupart des SPF cassés viennent d’une poignée d’erreurs. Chacune est donnée avec le message qu’elle provoque et la façon de l’éviter.
Un second enregistrement SPF
Pourquoi. Ajouter un fournisseur en créant un autre enregistrement v=spf1 donne à chaque destinataire l’erreur « permerror: multiple SPF records found ».
Correction. Ajoutez le nouvel include à l’enregistrement existant. Le générateur produit toujours un seul enregistrement qui contient tout.
Un expéditeur oublié
Pourquoi. Factures, formulaires du site ou support qui envoient avec votre adresse sans être listés obtiennent « spf=softfail » et finissent en indésirables une fois DMARC appliqué.
Correction. Cochez chaque service qui envoie avec votre adresse. Vos rapports DMARC listent tous les expéditeurs, y compris ceux que personne n’avait en tête.
Trop d’includes
Pourquoi. Au-delà de 10 requêtes DNS, SPF renvoie « permerror: too many DNS lookups » pour chaque message.
Correction. Retirez les anciens fournisseurs, utilisez des plages ip4 quand un fournisseur documente des adresses fixes, et déplacez les envois en nombre vers un sous-domaine qui a son propre SPF.
+all ou ?all « pour que ça passe »
Pourquoi. +all laisse n’importe quel serveur d’Internet envoyer au nom de votre domaine ; ?all ne dit rien. Les deux suppriment la protection pour laquelle SPF existe.
Correction. Terminez par ~all avec DMARC, ou -all sans. Corrigez plutôt les expéditeurs manquants.
a sur un hébergement mutualisé
Pourquoi. Le mécanisme a autorise l’adresse de votre site. Sur un hébergement mutualisé, des centaines d’autres sites partagent cette adresse, et tous peuvent alors envoyer en votre nom.
Correction. Ne cochez pas a, sauf si le serveur de votre site vous est réservé ; listez plutôt le service d’envoi qu’utilise votre site.