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.

Astuces

  • 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é.

Questions fréquentes

Ce n'est pas strictement obligatoire, mais ce n'est qu'en configurant les trois ensemble qu'on obtient une défense cohérente : prouver la légitimité de l'expéditeur (SPF/DKIM) et indiquer au destinataire comment réagir en cas d'échec (DMARC). N'en configurer qu'un seul a un effet limité ; il est donc recommandé de les mettre en place dans l'ordre.

Pas nécessairement. Le nom du sélecteur DKIM étant librement choisi par chaque service d'envoi, un résultat "non trouvé" signifie seulement que le domaine n'utilise pas l'un des noms courants testés par cet outil (default, google, etc.). Pour vérifier avec précision, consultez le panneau du service d'envoi ou l'en-tête DKIM-Signature d'un e-mail.

Ce n'est pas recommandé. Si vous n'avez pas encore identifié toutes les sources d'envoi légitimes (services de newsletter, systèmes internes, etc.), passer immédiatement à reject risque de bloquer aussi des e-mails légitimes. Il est plus sûr de commencer par p=none, de collecter des rapports pendant quelques semaines pour confirmer l'absence de problème, puis de durcir progressivement vers quarantine et reject.

À terme, -all (Fail, rejet explicite) est recommandé, mais pendant une période de transition où l'on n'a pas pleinement confiance dans la configuration SPF, ~all (SoftFail, traité comme suspect) est plus sûr : confirmez qu'aucun e-mail légitime n'est bloqué avant de passer à -all.

Non. La requête DNS pour le domaine saisi est effectuée à la volée, et les données des enregistrements obtenus ne sont pas conservées sur le serveur.
ツールくん

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.

→ Lire les anecdotes connexes

→ Voir toutes les anecdotes

Plus d'outils dans cette catégorie