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

> Ce que DMARC fait et ne fait pas, comment il s'appuie sur SPF et DKIM, l'alignement de domaine, l'enregistrement DNS et le choix d'une politique de traitement.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/dmarc

## 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](https://datatracker.ietf.org/doc/html/rfc7208) (Sender Policy Framework) et de [DKIM](https://datatracker.ietf.org/doc/html/rfc6376) (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](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc) pour le protocole de base, la [RFC 9990](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc) pour les rapports agrégés et la [RFC 9991](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc) 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](https://emailmarketing.net/fr/apprendre/authentification/reference-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](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc).

## 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)](https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf) 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](https://datatracker.ietf.org/doc/html/rfc7489), et il est désormais défini par la [RFC 9989](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc), 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 :

| Balise | Contenu |
|---|---|
| `v=` | La version. Elle n'a aujourd'hui qu'une valeur valide, `DMARC1`, et doit ouvrir l'enregistrement sous la forme `v=DMARC1;` |
| `p=` | Ce que vous demandez aux serveurs de réception de faire des emails qui échouent à DMARC. `none` leur demande de les traiter comme si DMARC n'avait pas échoué, `quarantine` de les livrer dans le dossier spam, et `reject` de les refuser. Faites de votre **premier** enregistrement `p=none;` et durcissez-le plus tard, sauf si le domaine est tout nouveau ou n'envoie aucun email. |
| `rua=` | La boîte aux lettres qui reçoit les **rapports agrégés**, par exemple `rua=mailto:dmarc-reports@example.com`. Les fournisseurs qui vérifient DMARC envoient généralement ces rapports une fois par jour. Chacun est un fichier XML de statistiques sur les emails qui ont utilisé votre domaine dans l'en-tête From, regroupées par adresse IP d'envoi, par résultat d'authentification et selon d'autres champs. Ce sont des logiciels qui les lisent, pas des personnes : donnez-leur une boîte aux lettres à part. |

## 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](https://bimigroup.org/), 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](https://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](https://emailmarketing.net/fr/apprendre/authentification/reference-de-la-norme-dmarc) (RFC 9989 et DMARCbis)
- [Déploiement de DMARC en détail](https://emailmarketing.net/fr/apprendre/authentification/deploiement-de-dmarc)
- [Rapports agrégés DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-dmarc) (RFC 9990)
- [Rapports d'échec DMARC](https://emailmarketing.net/fr/apprendre/authentification/rapports-d-echec-dmarc) (RFC 9991)
- [Fondamentaux de la délivrabilité des emails](https://emailmarketing.net/fr/apprendre/fondamentaux/fondamentaux-de-la-delivrabilite-email)