Aller au contenu

Vérificateur email

SPF, DKIM, DMARC et MX d'un domaine, lus et expliqués, y compris le budget de lookups SPF que la plupart des outils ne comptent jamais.

Les sélecteurs ne peuvent pas être découverts. Laissez vide pour essayer les plus courants, ou indiquez les vôtres pour en avoir le cœur net.

À propos de SPF, DKIM et DMARC

Trois enregistrements décident si vos emails sont crus. SPF liste qui a le droit d'écrire au nom de votre domaine, DKIM signe chaque message avec une clé publiée dans le DNS, et DMARC dit aux destinataires quoi faire quand aucun des deux ne correspond. Quand l'un manque ou est cassé, vos emails ne reviennent pas bruyamment en erreur : ils partent en indésirables, discrètement, et généralement chez les destinataires auxquels vous tenez le plus.

Ce que vérifie le serveur destinataireSPF et DKIM se portent chacun garant d'un domaine. DMARC vérifie que ce domaine est bien celui de l'adresse From que lit le destinataire.
  1. Le message quitte votre serveur
    Serveur d'envoimail.example.com 198.51.100.25
    Signature DKIM : domaine et sélecteurd=example.com; s=selector1
    Expéditeur de l'enveloppe (MAIL FROM), invisible pour le lecteurbounce@example.com
    Adresse From, affichée au lecteurnews@example.com
  2. Le serveur destinataire vérifie
    1. SPF

      L'adresse d'envoi figure-t-elle dans l'enregistrement SPF du domaine de l'enveloppe ?

      TXT example.comv=spf1 ip4:198.51.100.25 -all
    2. DKIM

      La signature se vérifie-t-elle avec la clé publique que le domaine signataire (d=) publie sous son sélecteur ?

      TXT selector1._domainkey.example.comv=DKIM1; p=MIIBIjANBg…
    3. DMARC

      SPF ou DKIM a-t-il réussi pour un domaine aligné sur le From ? Une seule réussite alignée suffit ; sinon, la politique du domaine s'applique.

      TXT _dmarc.example.comv=DMARC1; p=quarantine

      Aligné : le même domaine que le From ou, en mode relâché (celui par défaut), le même domaine parent : mail.example.com est aligné sur example.com. Une réussite pour un autre domaine, celui d'un prestataire par exemple, ne compte pas.

  3. Ensuite
    • DMARC réussitLe message passe aux filtres antispam habituels, puis arrive en boîte de réception.
    • Échec, p=noneDistribué comme s'il n'y avait pas de DMARC : l'échec n'apparaît que dans les rapports, si vous en demandez (rua).
    • Échec, p=quarantineClassé en indésirables.
    • Échec, p=rejectRefusé à la livraison : l'expéditeur reçoit un message d'erreur.
la vérification e-mail de github.com : MX, SPF avec son budget de 10 requêtes DNS, clés DKIM et politique DMARC, et ce qui demande attention.

Le chiffre à regarder en premier est le budget de lookups SPF. SPF autorise dix termes qui interrogent le DNS, et ils se comptent à travers chaque include : un enregistrement de deux mots peut en consommer une douzaine une fois suivis les include de votre prestataire. Au-delà de la limite, toute l'évaluation est une erreur permanente et les destinataires se comportent comme si vous n'aviez rien publié. C'est la panne qui survient sans que personne n'ait rien changé chez vous, le jour où un prestataire ajoute un include au sien. La deuxième chose à lire est la politique DMARC : p=none observe et ne protège rien, et c'est là que la plupart des domaines s'arrêtent. Quant à DKIM, un sélecteur ne se devine pas : un outil qui ne trouve aucune clé prouve seulement qu'il a mal deviné. Indiquez le vôtre pour obtenir une vraie réponse.

Questions fréquentes

Mon SPF est court. Comment peut-il dépasser dix lookups ?
Parce que la limite se compte à travers les include. Votre enregistrement contient peut-être trois include, mais chacun est un autre enregistrement avec ses propres include. Les grands prestataires coûtent couramment quatre à six lookups chacun. Le détail ci-dessus montre ce que chacun coûte réellement.
p=none, est-ce suffisant ?
C'est une première étape légitime : elle collecte les rapports sans toucher à la délivrabilité. Mais elle ne protège rien. N'importe qui peut écrire en se faisant passer pour votre domaine, et les destinataires n'y feront ni plus ni moins qu'avant. p=none est fait pour être temporaire.
L'outil n'a trouvé aucune clé DKIM. Est-ce grave ?
Probablement pas. Les sélecteurs DKIM sont des noms arbitraires qu'on ne peut pas lister : nous essayons les plus courants et nous le disons honnêtement quand aucun ne répond. Saisissez le vôtre, que votre prestataire d'emails vous affiche, et vous aurez une vraie réponse.
Pourquoi une clé de 1024 bits est-elle signalée ?
La RFC 8301 a porté la recommandation à 2048 bits en 2018, et plusieurs grands destinataires pondèrent désormais moins une signature de 1024 bits. Cela fonctionne encore, c'est donc un avertissement et non une erreur, mais cela mérite une rotation à la prochaine occasion.

Guides associés

Outils associés

Pour aller plus loin

Glossaire réseau : DNS inverse, TTL

Lancer un traceroute visuel vers cet hôte