Vérificateur DMARC :
votre politique bloque-t-elle quoi que ce soit ?
Saisissez un domaine — l’outil décode chaque balise et note ce que votre politique applique, pas seulement si un enregistrement existe. La plupart des domaines s’arrêtent à p=none, qui ne bloque rien : il demande seulement aux destinataires de signaler le courrier usurpé qu’ils livrent quand même.
Syntaxe parfaite, porte ouverte
Un enregistrement DMARC peut être syntaxiquement parfait et opérationnellement inutile. Chacun des quatre cas suivants passe les vérificateurs d’existence tout en laissant, dans les faits, une porte ouverte.
p=none laissé actif après le déploiement
Réglé sur « surveillance » pendant le déploiement de 2023 — et toujours en surveillance. p=none dit aux destinataires de ne rien faire : le courrier usurpé arrive en boîte de réception sous votre nom, pendant que votre tableau de bord affiche DMARC ✓.
p=none · ne bloque rienrua= pointant vers un domaine non autorisé
Votre rua= pointe vers un domaine de prestataire ou d’agence qui n’a jamais publié l’enregistrement d’autorisation. Les destinataires le vérifient — et jettent silencieusement chaque rapport. Aucun message de rejet, aucune erreur, aucune donnée. Jamais.
RFC 7489 §7.1La brèche du pct=
p=reject; pct=50 — le curseur de déploiement resté à mi-chemin. La moitié du courrier usurpé est rejetée, l’autre moitié livrée, tirée au sort à chaque message. Un attaquant n'a rien contre le fait de réessayer.
pct=50 · moitié appliquéesp=none sur vos sous-domaines
Un sp=none explicite, oublié depuis le déploiement, signifie que votre racine rejette l’usurpation pendant que invoices.yourdomain.com l’accepte. Les attaquants aussi lisent le DNS.
sp=none · sous-domaines non protégésreject, quarantine, none et les failles
La balise p= est une instruction adressée à tous les serveurs destinataires de la planète. Nous la notons comme une échelle de maturité, pas comme un simple oui/non.
« Le courrier qui échoue à l’alignement : refusez-le à la porte. » Protection totale — le sommet de l’échelle. Elle ne vaut que ce que valent le SPF et le DKIM qui l’alimentent, et n’est complète qu’à pct=100.
« Traitez les échecs avec suspicion » — en pratique, le dossier spam. Une vraie protection partielle, et le bon échelon intermédiaire, surtout monté progressivement avec pct=. Pas le sommet.
Surveillance : rien n’est bloqué, mais les rapports circulent, et vous apprenez qui envoie en votre nom. Les 90 premiers jours corrects de tout déploiement DMARC — et l’état permanent de bien trop de domaines.
Rien n’est bloqué et personne ne surveille. L’enregistrement n’existe que pour satisfaire les vérificateurs qui ne testent que sa présence. De la conformité de façade à l’état pur.
Les destinataires se rabattent sur leurs propres heuristiques ; l’exposition de votre domaine à l’usurpation dépend de qui reçoit le courrier. C’est aussi, de plus en plus, un problème de délivrabilité : les expéditeurs en masse vers Gmail/Yahoo doivent publier un DMARC.
Plusieurs enregistrements v=DMARC1 à _dmarc ne fusionnent pas — la découverte échoue et les destinataires considèrent que vous ne publiez rien. Même chose pour une liste de balises mal formée.
Où vont vos rapports DMARC
Le rapport DMARC repose sur un accord entre trois parties : vous, les destinataires, et quiconque lit les rapports. Quand rua= pointe vers un domaine différent (tableau de bord d’un prestataire, boîte d’une agence), la RFC 7489 §7.1 exige que ce domaine donne son consentement :
- Avant d’envoyer un rapport, le destinataire interroge yourdomain._report._dmarc.theirdomain à la recherche d’un enregistrement v=DMARC1.
- Pas d’enregistrement → pas de rapport. Silencieusement. Aucun message de rejet ne vous parvient, rien n’en garde la trace — vos rapports n’ont tout simplement jamais existé.
- Les vrais prestataires publient un enregistrement générique (*._report._dmarc.example.com) — un domaine de prestataire mal orthographié, un compte expiré ou la simple boîte mail d’une agence n’en auront pas.
- Nous résolvons jusqu’à 5 destinations rua=/ruf= par balise et lançons cette requête pour chacune — la plupart des vérificateurs ne le font jamais.
L’échelle de maturité
ce que rapporte chaque échelonCe que dig peut vous apprendre
L’enregistrement n’est qu’à un dig, et la vérification d’autorisation n’est qu’une requête DNS de plus une fois qu’on sait qu’il existe. Noter ce que la politique applique demande davantage qu’une ligne de commande.
Questions fréquentes sur le DMARC
Saisissez votre domaine ci-dessus. Nous récupérons l’enregistrement TXT à _dmarc.yourdomain, confirmons qu’il n’existe qu’un seul v=DMARC1 (deux signifie que les destinataires n’en voient aucun), et décodons chaque balise selon la RFC 7489 avec les valeurs par défaut explicitées (p=, sp=, pct=, adkim=/aspf=, rua=/ruf=, fo=). Nous notons ensuite le niveau d’application et vérifions que les destinations de rapports que nous notons peuvent bien recevoir des rapports. Gratuit, sans inscription.
Cela dit à chaque destinataire : « quand un courrier échoue au DMARC, ne fais rien — livre-le, mais envoie-moi un rapport. » Rien n’est mis en quarantaine, rien n’est rejeté. Une facture usurpée arrive dans la boîte de votre client exactement comme si vous n’aviez pas de DMARC. Ce que p=none vous apporte, c’est de la visibilité : les rapports agrégés nomment chaque serveur qui envoie sous votre domaine, légitime ou non. Cela en fait le bon premier échelon d’un déploiement, et un très mauvais endroit où s’installer durablement. Si votre enregistrement dit p=none depuis plus de 2 trimestres, vous ne « faites » pas de DMARC. Vous regardez, en haute définition, d’autres personnes usurper votre identité.
Une échelle, pas un saut. D’abord : p=none avec rua= pendant un trimestre. Lisez les rapports, repérez chaque expéditeur légitime (l’outil de facturation dont personne ne se souvenait), et corrigez leur alignement SPF/DKIM. Ensuite : p=quarantine; pct=10, puis montez pct à 50 puis 100 tant que les rapports restent propres. Enfin : p=reject. Si un sous-domaine traîne (une plateforme de newsletter en pleine migration), donnez-lui son propre enregistrement _dmarc.sub plutôt que de maintenir tout le domaine à none. Conditionnez chaque étape aux données des rapports — les rapports sont le filet de sécurité qui rend la rigueur sans risque.
rua= désigne le rapport agrégé : des résumés XML quotidiens de chaque destinataire — quelles adresses IP ont envoyé en votre nom, combien ont réussi ou échoué, sous quelle politique. C’est celui qui compte ; c’est lui qui vous permet de piloter l’échelle. ruf= désigne le rapport forensique : des copies d’échec message par message. La plupart des grands destinataires, Gmail et Microsoft compris, ne les envoient plus pour des raisons de confidentialité. Traitez ruf= comme un bonus venant de petits destinataires, pas comme une source de données fiable. Les deux n’acceptent que des URI mailto:, et les deux sont soumis au contrôle d’autorisation des destinations externes que cet outil effectue.
La cause classique est exactement ce que cet outil existe pour vérifier : votre rua= pointe vers un domaine qui n’est pas le vôtre, et ce domaine n’a jamais publié l’enregistrement d’autorisation. La RFC 7489 §7.1 oblige les destinataires à vérifier ce consentement d’abord : ils interrogent yourdomain._report._dmarc.destinationdomain et attendent une réponse v=DMARC1. Aucune réponse → le rapport est abandonné silencieusement, sans message de rejet ni erreur visible pour vous. Cela arrive quand le domaine du prestataire est mal orthographié, ou quand vous changez de prestataire sans changer l’enregistrement. Cela arrive aussi quand les rapports partent vers une boîte d’agence jamais configurée pour le rapport entre domaines. Nous lançons la requête pour chaque destination que nous notons et vous montrons l’enregistrement manquant exact.
L’alignement, c’est la façon dont DMARC relie le SPF/DKIM à la ligne From : que voit votre lecteur. Le mode relâché (par défaut, r) accepte une correspondance au niveau du domaine organisationnel — un courrier signé par news.yourdomain.com s’aligne avec yourdomain.com. Le mode strict (s) exige une correspondance exacte. Le mode relâché est le bon choix pour presque tout le monde ; le mode strict referme une brèche étroite (un sous-domaine compromis ou délégué se portant garant pour votre racine) au prix de casser tout expéditeur de sous-domaine que vous auriez oublié. Ne passez au mode strict qu’après qu’un trimestre de rapports propres montre un alignement exact et constant.
Il arrête l’usurpation de domaine exact chez les destinataires qui coopèrent — ce qui représente l’essentiel du volume de boîtes mail sur Internet. Trois failles subsistent. DMARC ne juge que l’alignement, il ne vaut donc que ce que valent le SPF et le DKIM qui le soutiennent. Un SPF en permerror ou une clé DKIM révoquée affaiblit reject en silence. Un pct<100 ou un sp= plus faible laisse des brèches délibérées. Et les domaines sosies (yourcompany-billing.com) sont hors du champ d’action, car aucun enregistrement DMARC vous appartenant ne peut parler pour un domaine que vous ne possédez pas. Vérifiez toute la chaîne : nos outils SPF et DKIM couvrent la première faille.
Continuer l'exploration
Les outils gratuits, c'est un début.
Uptimia veille sur la santé de vos sites.
Disponibilité, SSL, expiration de domaine, vitesse de page, transactions — surveillés depuis 171+ emplacements dans le monde. 30 jours gratuits.