DMARC (Domain-based Message Authentication, Reporting, and Conformance)

Pourquoi les propriétaires de domaines publient DMARC

N’importe qui peut inscrire votre domaine dans la ligne From que voient les destinataires. DMARC vous donne, à vous qui possédez ce domaine, le moyen de montrer aux serveurs de réception lesquels de ces emails vous avez autorisés. Pour cela, il confronte les résultats de SPF (Sender Policy Framework) et de DKIM (DomainKeys Identified Mail) au domaine de l’en-tête RFC5322.From, que l’on appelle aussi le « Friendly From ».

Pour un domaine qui envoie en volume, DMARC n’est plus facultatif. Google et Yahoo exigent tous deux des expéditeurs de gros volumes qu’ils publient un enregistrement DMARC avant d’envisager d’accepter et de livrer leurs emails.

Les sections qui suivent présentent les idées sur lesquelles repose DMARC et la forme générale d’une mise en place. Elles ne forment pas un guide pas à pas complet.

Quelle spécification s’applique

La RFC 7489 a décrit DMARC pour la première fois en 2015, sous la forme d’un document informatif (Informational). En mai 2026, son successeur, appelé DMARCbis, est devenu une Proposed Standard en trois parties : la RFC 9989 pour le protocole de base, la RFC 9990 pour les rapports agrégés et la RFC 9991 pour les rapports d’échec. Ensemble, elles rendent obsolètes la RFC 7489 et la RFC 9091.

Les notions de cette page valent sous les deux spécifications, et les quelques détails qui ont changé depuis la RFC 7489 sont signalés là où ils se présentent. Pour chaque balise de l’enregistrement, et pour le DNS Tree Walk qui remplace la Public Suffix List, voir la référence de la norme DMARC. Pour un déploiement approfondi, notamment la politique des sous-domaines, les nouvelles balises np et t et le traitement des rapports, voir Déploiement de DMARC en détail.

Les trois fonctions de DMARC

Un enregistrement DMARC permet au propriétaire d’un domaine :

• d’empêcher des tiers d’utiliser le domaine sans permission dans l’en-tête RFC5322.From, ce qui constitue l’usurpation d’identité (spoofing)
• de demander aux fournisseurs de messagerie des rapports sur les emails qui affichent le domaine dans cet en-tête
• de demander aux serveurs de réception de traiter d’une manière précise tout message qui affiche le domaine à cet endroit mais échoue à la vérification DMARC

Ce que DMARC ne résout pas

DMARC répond à une seule question : le propriétaire du domaine a-t-il autorisé cette utilisation du domaine From ? Un message qui réussit la vérification peut tout de même être du spam.

Deux procédés d’usurpation courants lui échappent aussi :

• Domaines sosies. Une politique DMARC sur « example.com » reste sans effet sur les emails venant d’une copie proche comme « ex4mple.com ». La copie est un autre domaine, avec son propre DNS.

• Attaques par nom d’affichage. L’attaquant envoie depuis un domaine qu’il contrôle et inscrit un nom de confiance dans le nom d’affichage, la partie que beaucoup d’applications de messagerie montrent en premier :

  From: "Your Bank Security Team" <alerts@unrelated-sender.example>

SPF et DKIM en bref

SPF vérifie le chemin qu’a suivi un message. Le propriétaire d’un domaine indique dans le DNS les serveurs et les réseaux autorisés à envoyer des emails dont l’adresse RFC5321.MailFrom, aussi appelée « Envelope From », utilise ce domaine. Les serveurs de messagerie s’appuient sur cette adresse lorsqu’ils se transmettent les emails. Elle aboutit dans l’en-tête Return-Path, et la plupart des destinataires ne la voient jamais.

DKIM vérifie le message lui-même. Le domaine qui prend la responsabilité d’un message ajoute un en-tête DKIM-Signature. Cet en-tête contient deux empreintes cryptographiques du message et les informations dont un serveur de réception a besoin pour les vérifier. Ajouter cet en-tête s’appelle signer le message, et le domaine qui y figure est le « domaine d= de DKIM ». Quand la vérification réussit, le serveur de réception sait que les parties signées du message n’ont pas changé depuis la signature.

Domaine organisationnel et alignement

DMARC ajoute deux termes qui lui sont propres :

• Domaine organisationnel (Organizational Domain) : le domaine enregistré qui porte la présence sur Internet d’une entreprise, d’une marque ou de toute autre organisation, par exemple « example.com ».
• Alignement de domaine (Domain Alignment) : deux domaines sont alignés lorsqu’ils ont le même domaine organisationnel. Ainsi, « billing.example.com » est aligné avec « sales.example.com », et aussi avec « example.com » lui-même. En revanche, « example.net » n’est pas aligné avec « sales.example.com », même quand une seule entreprise possède les deux.

C’est l’alignement souple, que les serveurs de réception appliquent par défaut. Le propriétaire d’un domaine peut demander à la place un alignement strict, dans lequel les deux domaines doivent être identiques.

Comment un message réussit DMARC

Le serveur de réception commence par chercher un enregistrement DMARC pour le domaine RFC5322.From. S’il en trouve un, le message réussit si au moins une de ces conditions est remplie :

• une signature DKIM est vérifiée, et son domaine d= est aligné avec le domaine From
• SPF réussit pour le domaine RFC5321.MailFrom, et ce domaine est aligné avec le domaine From

Une seule réussite alignée suffit : vous n’avez pas besoin des deux. Les Email Authentication Recommended Best Practices du Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) demandent pourtant aux expéditeurs d’obtenir une réussite alignée avec les deux. Si vous ne pouvez en assurer qu’une, choisissez DKIM. Les fournisseurs de messagerie lui accordent plus de poids qu’à SPF, dans DMARC comme lorsqu’ils décident qui peut rejoindre les feedback loops et les autres programmes destinés aux expéditeurs.

Publier l’enregistrement

Vous participez à DMARC en ajoutant un enregistrement TXT dans le DNS de votre domaine. Son format a d’abord été fixé par la RFC 7489, et il est désormais défini par la RFC 9989, sur la voie des normes. L’enregistrement est une liste de paires balise-valeur séparées par des points-virgules. Tout enregistrement doit contenir les deux premières balises ci-dessous, et la troisième est vivement recommandée :

Passer à une politique contraignante

Pour la plupart des domaines, p=none est le bon point de départ. Un domaine qui veut une protection forte contre l’usurpation d’identité, ou qui voudra peut-être afficher un jour son logo grâce à BIMI, passera ensuite à p=quarantine ou à p=reject. Chacune de ces politiques est dite contraignante (enforcement) : les emails qui utilisent le domaine sans autorisation n’atteignent plus la boîte de réception. Le M3AAWG va plus loin et voit dans la politique de surveillance un état transitoire, à quitter dès que possible.

Laissez les rapports agrégés décider du moment. Pour chaque source qui envoie avec votre domaine, ils montrent si elle s’authentifie avec DKIM, avec SPF ou avec les deux. Dès que toutes les sources légitimes y parviennent, durcissez la politique.

Le faire soi-même ou faire appel à un spécialiste

Un propriétaire de domaine qui dispose de compétences techniques suffisantes peut mener en interne tout le travail lié à DMARC. Beaucoup trouvent plus simple de faire appel à un prestataire externe. dmarcvendors.com tient une liste de prestataires de services DMARC, ainsi que des ressources pour se former à DMARC.

Voir aussi

• Référence de la norme DMARC (RFC 9989 et DMARCbis)
• Déploiement de DMARC en détail
• Rapports agrégés DMARC (RFC 9990)
• Rapports d’échec DMARC (RFC 9991)
• Fondamentaux de la délivrabilité des emails