DMARC et DKIM : qui écrit en votre nom ?
DMARC est un enregistrement publié dans le DNS de votre domaine. Il dit aux messageries de vos destinataires quoi faire d'un email qui se présente comme venant de vous sans pouvoir le prouver : le laisser passer, le classer en indésirables ou le refuser.
Il s'appuie sur deux autres mécanismes, SPF et DKIM, et il ne protège que si sa politique demande une action. C'est l'un des points que lit, au détail près, l'audit du nom de domaine et des emails.
SPF, DKIM et DMARC : trois réponses à trois questions
L'adresse d'expéditeur d'un email s'écrit librement, comme celle d'une lettre. Rien dans le protocole d'envoi n'empêche un tiers d'écrire à vos clients avec une adresse à votre nom. Les trois mécanismes permettent au destinataire de vérifier.
- SPF liste les serveurs autorisés à envoyer des emails pour votre domaine. Un message parti d'un autre serveur échoue.
- DKIM signe chaque message avec une clé que seul votre service d'envoi détient ; la clé publique qui permet de vérifier la signature est publiée dans votre DNS (RFC 6376). Un message modifié en route, ou signé par quelqu'un d'autre, échoue.
- DMARC relie les deux au nom de domaine que le destinataire voit dans le champ « De ». Il fixe la politique à appliquer quand ni SPF ni DKIM ne confirment ce nom, et il peut demander des rapports sur les envois faits à votre nom.
DMARC est décrit depuis mai 2026 par la RFC 9989, publiée par l'IETF comme norme et qui remplace la version de 2015. Les principes décrits ici n'ont pas changé.
None, quarantine, reject : ce que chaque politique demande
La politique est la balise « p » de l'enregistrement. Elle ne s'applique qu'aux messages qui échouent : vos emails légitimes, bien authentifiés, ne sont pas concernés.
- none : ne rien faire de particulier. Le message usurpé est traité comme les autres. La politique sert à recevoir des rapports avant de durcir, et ne protège de rien tant qu'elle reste en place.
- quarantine : traiter le message avec suspicion, en général le classer en indésirables. Le message usurpé arrive encore, mais ailleurs que dans la boîte de réception.
- reject : refuser le message. Le destinataire ne le reçoit pas.
Un enregistrement qui ne contient que « v=DMARC1 », sans politique ni adresse de rapport, est ignoré par les messageries. Il a l'air en place, et il ne produit rien.
Ce que Gmail, Yahoo et Outlook exigent des expéditeurs
Depuis février 2024, Google et Yahoo demandent à tout expéditeur au moins SPF ou DKIM. Ceux qui envoient plus de 5 000 messages par jour vers leurs boîtes doivent en plus publier SPF et DKIM, et un DMARC dont le domaine correspond à celui du champ « De ». Microsoft a posé des exigences comparables pour Outlook.com en mai 2025.
Ces exigences acceptent la politique none. Un domaine peut donc les remplir, voir ses emails délivrés, et ne rien demander contre l'usurpation. Être accepté par Gmail et être protégé sont deux questions différentes.
Ce que nous relevons sur les sites audités
10 %reçoivent des emails sur leur domaine sans SPF, ou sans DMARC valide
Ce pourcentage porte sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.
Ce que l'audit regarde
L'audit lit ce que votre domaine publie dans le DNS, dans cet ordre :
- Si le domaine reçoit des emails. Un domaine qui déclare des serveurs de messagerie est un domaine qu'on peut usurper de façon crédible.
- Si un enregistrement SPF est publié.
- Si l'enregistrement DMARC est absent, invalide ou présent. Un enregistrement réduit à « v=DMARC1 » compte comme absent, parce que les messageries l'ignorent.
- La politique demandée. None est noté comme une protection nulle, quarantine comme une protection partielle, reject comme une protection entière.
DKIM n'entre pas dans la note. Sa clé est publiée sous un nom choisi par le service d'envoi, le sélecteur, que l'on ne connaît pas depuis l'extérieur : ne pas la trouver ne prouve pas qu'elle manque.
Le même pilier lit la date d'expiration du domaine, qui compte pour la messagerie autant que pour le site, et la signature DNSSEC de sa zone, qui garantit que les réponses du DNS viennent bien de vous.
Ce qui se corrige simplement, ce qui demande un projet
Publier un SPF, puis un DMARC en none qui demande des rapports, est rapide pour celui qui gère votre DNS. Cela ne protège pas encore, mais les rapports arrivent : ils montrent quels services envoient des emails en votre nom.
Passer à quarantine puis à reject demande un inventaire. La lettre d'information, la facturation, le formulaire du site, l'outil de relation client envoient souvent sous votre domaine. Chacun doit être authentifié avant de durcir la politique, sinon vos propres emails sont classés en indésirables ou refusés.
Ce que cette vérification ne dit pas
Nous lisons les enregistrements que votre domaine publie. DKIM ne se vérifie pas sans connaître le sélecteur, et nous ne voyons pas les rapports DMARC, qui ne parviennent qu'à l'adresse que vous avez indiquée.
La délivrabilité réelle de vos emails dépend aussi de leur contenu et de la réputation de vos serveurs d'envoi. Le rapport dit ce qui est publié, pas ce que vos destinataires reçoivent.
À lire ensuite
DNSSEC : ce qu'il protège, et ses limites
DNSSEC signe les réponses DNS de votre domaine pour empêcher leur falsification. Ce qu'il couvre, ce qu'il ne chiffre pas, qui l'active, ce que l'audit lit.
Lire le guide →Expiration de domaine : ce qui s'arrête
Un nom de domaine qui expire coupe le site et la messagerie le même jour. Pourquoi un renouvellement échoue, et ce que l'audit lit dans le registre.
Lire le guide →