Mode d’emploi
- 1.Saisissez un domaine comme
example.com, ou collez une adresse e-mail : c’est la partie après le @ qui est vérifiée. - 2.Ajoutez un sélecteur DKIM si vous le connaissez (la valeur
s=de l’en-têteDKIM-Signatured’un e-mail) ; sinon, les sélecteurs des grands fournisseurs sont essayés. - 3.Cliquez sur Vérifier. Le verdict en haut résume SPF, DKIM et DMARC ; chaque section en dessous montre l’enregistrement, ce qu’il signifie et ce qu’il faut corriger.
- 4.Dépliez les includes sous SPF pour voir quel service consomme combien des 10 requêtes DNS, et survolez un domaine ou une plage d’adresses IP pour l’examiner dans un autre outil.
À quoi servent SPF, DKIM et DMARC
L’e-mail a été conçu sans aucune vérification de l’expéditeur : n’importe qui peut mettre votre domaine dans le champ De (From). Trois enregistrements DNS corrigent cela. SPF (un enregistrement TXT commençant par v=spf1) liste les serveurs autorisés à envoyer des e-mails pour le domaine. DKIM signe chaque message avec une clé dont la partie publique est publiée sur <selector>._domainkey.<domain>, ce qui permet aux destinataires de vérifier que le message n’a pas été modifié et provient bien du domaine. DMARC (un enregistrement TXT sur _dmarc.<domain>) rattache les deux à l’adresse que les gens voient réellement dans le champ De et indique aux destinataires quoi faire quand aucun des deux ne passe : rien (p=none), dossier spam (p=quarantine) ou refus (p=reject).
Un message passe DMARC quand SPF ou DKIM réussit pour un domaine qui correspond au domaine du champ De. Le transfert d’e-mails casse souvent SPF, d’où l’importance de DKIM : une signature survit au transfert, l’adresse du serveur d’envoi non. Gmail, Yahoo et Microsoft exigent désormais SPF, DKIM et un enregistrement DMARC de la part de tous ceux qui envoient des e-mails en masse.
La limite SPF de 10 requêtes DNS
Pour évaluer SPF, un serveur destinataire peut effectuer au maximum 10 requêtes DNS (RFC 7208). Chaque include, a, mx, ptr, exists et redirect en coûte une, y compris ceux qui figurent dans les enregistrements que vous incluez. ip4, ip6 et all ne coûtent rien. Au-delà de 10, le résultat est une erreur permanente (permerror) : SPF échoue pour chaque message, souvent sans que personne ne s’en aperçoive.
Chaque service d’e-mail que vous ajoutez (un CRM, un outil de newsletter, un logiciel de support) apporte généralement un include qui consomme à lui seul plusieurs requêtes, et les fournisseurs modifient les leurs au fil du temps. Supprimez les includes des services que vous n’utilisez plus, utilisez l’include plus restreint du fournisseur s’il en propose un, et envoyez les e-mails marketing depuis un sous-domaine doté de son propre enregistrement SPF. Les requêtes qui ne trouvent rien comptent aussi : au-delà de deux, c’est également une erreur.
Passer DMARC de none à reject sans risque
Commencez par p=none et une adresse rua. Les destinataires envoient alors chaque jour des rapports agrégés qui listent tous les serveurs ayant envoyé des e-mails au nom de votre domaine et indiquent si SPF et DKIM ont réussi. Un service d’analyse de rapports ou un parseur gratuit transforme le XML en liste lisible.
Corrigez chaque source légitime qui échoue : ajoutez-la à SPF, activez la signature DKIM dans ce service ou déplacez-la vers un sous-domaine. Quand les rapports ne montrent plus que vos propres e-mails, et qu’ils réussissent, passez à p=quarantine, éventuellement avec pct inférieur à 100 pour démarrer progressivement, puis, après quelques semaines sans incident, à p=reject. Continuez ensuite à lire les rapports : un nouvel outil qui envoie au nom de votre domaine y apparaîtra en premier.
Questions fréquentes
Comment corriger « SPF permerror: too many DNS lookups » ?
Comptez les requêtes : ce vérificateur additionne chaque include, a, mx, ptr, exists et redirect dans tous les enregistrements imbriqués. Supprimez les includes des services que vous n’utilisez plus, remplacez les includes de vos propres serveurs par des plages ip4/ip6, et déplacez les envois en masse vers un sous-domaine doté de son propre enregistrement SPF. Évitez les services d’« aplatissement SPF » (SPF flattening) s’ils ne maintiennent pas les adresses à jour, car les fournisseurs modifient leurs plages.
Pourquoi le vérificateur ne trouve-t-il pas ma clé DKIM ?
Les clés DKIM ne peuvent être recherchées que par sélecteur, et il n’existe aucun moyen de les lister. Sans sélecteur, nestoo essaie les noms qu’utilisent les grands fournisseurs (Google, Microsoft 365, Mailchimp, SendGrid, Zoho et d’autres). Ouvrez un e-mail du domaine, regardez l’en-tête DKIM-Signature et saisissez sa valeur s=, par exemple s=20230601, comme sélecteur.
p=none suffit-il ?
Non. p=none demande seulement des rapports ; les e-mails qui échouent à DMARC sont livrés comme avant, donc l’usurpation fonctionne toujours. C’est la bonne première étape. Passez à p=quarantine puis à p=reject dès que les rapports montrent que tous vos vrais e-mails réussissent.
SPF doit-il se terminer par ~all ou -all ?
Les deux protègent le domaine quand DMARC est en place, car c’est DMARC qui décide du sort des e-mails en échec. ~all (softfail) est le choix le plus courant et pardonne davantage si vous oubliez un expéditeur. -all est plus strict et convient une fois que vous êtes sûr que l’enregistrement est complet. N’utilisez jamais +all ni ?all.
Un domaine qui n’envoie aucun e-mail a-t-il besoin de ces enregistrements ?
Oui, sinon les spammeurs peuvent l’utiliser. Publiez v=spf1 -all, un enregistrement DMARC avec p=reject et, éventuellement, un MX nul (0 .) ainsi qu’une clé DKIM vide sur *._domainkey. Ensemble, ils indiquent à tout destinataire qu’aucun e-mail de ce domaine n’est authentique.