Vérificateur d'enregistrements SPF/DKIM/DMARC
Saisissez un domaine pour consulter en temps réel ses enregistrements SPF, DMARC et DKIM et diagnostiquer la configuration d'authentification contre l'usurpation d'e-mails.
Diagnostiquer les enregistrements DNS qui protègent de l'usurpation
Saisissez un domaine et cet outil interroge sur-le-champ ses enregistrements SPF, DKIM et DMARC, rapportant jusqu'où vont ses défenses contre le courrier usurpé. Il vous permet d'établir si votre domaine peut être usurpé par un tiers, et si le courrier que vous envoyez inspirera confiance à qui le reçoit.
**Les trois remplissent des rôles distincts, et aucun ne suffit à lui seul.** SPF déclare quels serveurs peuvent émettre au nom du domaine, et DKIM garantit par signature que le message n'a pas été altéré. **DMARC indique alors au destinataire ce qu'il convient de faire du courrier qui échoue à ces contrôles.** Là est le nœud : **SPF et DKIM en place mais sans DMARC, le sort d'un message usurpé ayant échoué aux contrôles reste entièrement à la discrétion de celui qui le reçoit.** Bien des domaines laissent DMARC à `p=none`, ce qui signifie « envoyez-moi les rapports mais ne rejetez rien » — une étape du chemin plutôt qu'une défense établie.
Comment s'en servir
- Saisissez le domaine à examiner Indiquez le seul domaine, sous la forme `example.com`.
- Parcourez le contenu du SPF **Regardez la liste des expéditeurs autorisés et le qualificatif final, `~all` ou `-all`.**
- Lisez la politique DMARC **À `p=none`, rien n'est encore rejeté.**
- Ajoutez les enregistrements manquants Le diagnostic vous donne de quoi décider ce qu'il faut ajouter à votre DNS.
Astuces pour en tirer le meilleur parti
- L'ordre habituel est SPF, puis DKIM, puis DMARC en dernier. Mettez d'abord en place SPF et DKIM, puis utilisez DMARC pour préciser les instructions aux destinataires.
- Ne commencez pas DMARC directement avec p=reject. Collectez d'abord des rapports avec p=none afin d'identifier toutes les sources d'envoi légitimes avant de durcir progressivement la politique.
- Un domaine comportant trop d'"include" SPF peut atteindre la limite de "10 requêtes DNS / 255 caractères" et provoquer des échecs de résolution ; pensez à nettoyer régulièrement les include inutiles.
- Cet outil ne teste que des sélecteurs DKIM courants : un résultat "non trouvé" peut simplement signifier qu'un sélecteur différent est réellement utilisé.
- De grands destinataires comme Gmail et Outlook exigent depuis 2024 SPF, DKIM et DMARC pour les envois en masse ; les domaines qui envoient des newsletters devraient vérifier cette configuration en priorité.
Dans quels cas s'en servir
Pour vérifier les défenses de votre propre domaine
**L'usurpation s'abat d'abord sur les domaines qui n'ont pris aucune mesure.**
Pour chercher pourquoi votre courrier passe pour indésirable
Un défaut de SPF ou de DKIM est la première chose à soupçonner quand les messages n'arrivent pas.
Pour vérifier après l'ajout d'un service d'envoi
**Dès que vous adoptez un nouveau service de distribution, vérifiez que vous ne l'avez pas oublié dans le SPF.**
Pour examiner le domaine d'un correspondant
Il vous fournit de quoi juger de l'authenticité d'un message reçu.
Vocabulaire de l'authentification du courrier
- SPF
- L'enregistrement DNS **énumérant les serveurs autorisés à émettre au nom du domaine.** Un `-all` final signifie que tout ce qui n'y figure pas doit être refusé.
- DKIM
- Une signature numérique apposée à l'envoi. **Elle permet au destinataire de confirmer par une clé publique que ni le corps ni les en-têtes n'ont été réécrits en chemin.**
- DMARC
- L'enregistrement **indiquant au destinataire ce qu'il faut faire du courrier qui échoue aux contrôles SPF et DKIM.**
- P=none
- Une politique DMARC signifiant **que les rapports sont souhaités mais que rien n'est rejeté ni mis à l'écart.** C'est le réglage des premiers temps de l'adoption.
- P=quarantine et p=reject
- Ils enjoignent au destinataire d'écarter le message comme indésirable, ou de le refuser purement et simplement. **Atteindre l'un des deux est le but de l'entreprise.**
- Sélecteur
- Le nom indiquant où, dans le DNS, la clé publique DKIM a été placée. On y renvoie sous la forme `selector._domainkey.example.com`.
Questions fréquentes
Anecdote — Comment sont nés les trois piliers de l'authentification anti-usurpation
SPF, DKIM et DMARC sont apparus à des époques différentes et pour des raisons différentes. SPF, le premier apparu (vers 2003), déclare quelles adresses IP sont autorisées à envoyer des e-mails au nom d'un domaine, et s'est répandu comme réponse aux spammeurs qui falsifiaient l'adresse d'expéditeur. SPF est toutefois fragile face au transfert d'e-mails : lorsqu'un message est transféré, l'IP d'origine change et l'authentification échoue.
DKIM (normalisé vers 2007) est venu compenser cette faiblesse. Plutôt que de juger sur l'adresse IP comme le fait SPF, il appose une signature numérique sur une partie du corps du message et des en-têtes, que le destinataire vérifie à l'aide d'une clé publique publiée dans le DNS ; ainsi, tant que la signature elle-même reste intacte, l'authentification reste valide même après un transfert.
Cependant, SPF et DKIM ne pouvaient que détecter un échec d'authentification ; que faire de ce message — le distribuer, le marquer comme spam ou le rejeter — restait entièrement à la discrétion du serveur destinataire. DMARC, normalisé en 2012, a unifié ces instructions destinées au destinataire. Il intègre aussi un mécanisme de rapports (rua=) qui renvoie les résultats d'authentification aux administrateurs du domaine expéditeur, permettant une surveillance continue d'un éventuel usage abusif du domaine.
Lorsqu'en 2024 Google et Yahoo ont rendu SPF, DKIM et DMARC de facto obligatoires pour les expéditeurs en masse (plus de 5 000 messages par jour), ces trois piliers sont passés du statut de connaissance réservée aux grandes entreprises à celui de base incontournable pour toute organisation envoyant des newsletters ou des notifications système.