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

Pourquoi SPF et DKIM ne suffisent pas

Beaucoup d’entreprises configurent SPF et DKIM et pensent que leur domaine est protégé. Ce n’est pas le cas. Les deux protocoles laissent une faille béante que les attaquants exploitent tous les jours.

SPF ne protège pas ce que l’utilisateur voit

SPF (RFC 7208) vérifie que l’adresse IP du serveur expéditeur est autorisée par le domaine de l’enveloppe (Return-Path). Le problème : le Return-Path est invisible pour l’utilisateur. Ce que l’utilisateur voit dans sa boîte de réception, c’est l’adresse du champ From — et SPF ne vérifie pas ce champ.

Concrètement, un attaquant peut envoyer un email avec :

• Return-Path : bounce@serveur-attaquant.com (son propre domaine, SPF valide)
• From : directeur.financier@votre-entreprise.fr (votre domaine, affiché au destinataire)

Le résultat : SPF passe, mais l’email usurpe votre identité. Le destinataire voit un message qui semble venir de votre entreprise.

DKIM ne dit pas quoi faire en cas d’échec

DKIM (RFC 6376) ajoute une signature cryptographique aux emails sortants et prouve qu’ils n’ont pas été modifiés en transit. Mais DKIM présente deux limites :

1. Le domaine de la signature (d=) peut différer du domaine From. Un attaquant peut signer avec son propre domaine tout en affichant votre domaine dans le champ From.
2. DKIM ne prescrit aucune action en cas d’échec. Si la signature est absente ou invalide, le serveur destinataire ne sait pas s’il doit livrer, mettre en spam ou rejeter l’email.

L’alignement manquant

Ni SPF ni DKIM ne vérifient la correspondance entre leurs identifiants techniques (Return-Path pour SPF, domaine d= pour DKIM) et le domaine From visible par l’utilisateur. Ce lien entre l’identité technique et l’identité visible, c’est précisément ce que DMARC apporte — avec en plus une instruction de politique et un mécanisme de reporting.

Comment fonctionne DMARC

Le processus DMARC se déroule en quatre étapes à chaque email reçu. Prenons un exemple : un serveur destinataire reçoit un email dont le champ From affiche ceo@example.fr.

Étape 1 : vérification SPF + alignement

Le serveur vérifie d’abord SPF : l’IP de l’expéditeur est-elle autorisée par l’enregistrement SPF du domaine du Return-Path ?

Ensuite, DMARC ajoute une vérification que SPF seul ne fait pas : l’alignement. Le domaine du Return-Path correspond-il au domaine du champ From (example.fr) ? Si le Return-Path est bounce@example.fr, l’alignement passe. Si le Return-Path est bounce@serveur-tiers.com, l’alignement échoue — même si SPF est valide pour serveur-tiers.com.

Étape 2 : vérification DKIM + alignement

Le serveur vérifie ensuite la signature DKIM : est-elle valide et non altérée ?

Puis, même logique d’alignement : le domaine de la signature DKIM (d=) correspond-il au domaine du champ From ? Si d=example.fr, l’alignement passe. Si d=autre-domaine.com, l’alignement échoue.

Étape 3 : verdict DMARC

La règle est la suivante :

• Si SPF passe ET son alignement passe → DMARC pass
• Si DKIM passe ET son alignement passe → DMARC pass
• Un seul des deux suffit. Il faut que SPF+alignement OU DKIM+alignement passe.
• Si les deux échouent → DMARC fail, et la politique s’applique.

Cette logique de “l’un ou l’autre” est importante. Un email transféré perdra souvent son alignement SPF (l’IP du serveur de transfert n’est pas dans le SPF d’origine), mais conservera sa signature DKIM. DMARC passera grâce à DKIM seul. C’est pour cette raison que configurer à la fois SPF et DKIM donne une meilleure résilience.

Étape 4 : application de la politique et reporting

En cas de DMARC fail, le serveur destinataire consulte l’enregistrement DMARC du domaine example.fr et applique la politique publiée :

• p=none → l’email est livré normalement (mais un rapport est envoyé)
• p=quarantine → l’email est placé dans le dossier spam
• p=reject → l’email est rejeté avant d’atteindre la boîte du destinataire

Que DMARC passe ou échoue, le serveur destinataire génère un rapport agrégé (envoyé à l’adresse spécifiée dans le tag rua=) qui documente le résultat. Ces rapports arrivent quotidiennement et constituent un journal de tout ce qui se passe avec votre domaine.

Les trois politiques DMARC

p=none — le mode observation

La politique p=none ne bloque rien. Les emails qui échouent à DMARC sont livrés normalement. Son seul effet : activer le reporting. Vous recevez des rapports quotidiens qui montrent quelles adresses IP envoient des emails avec votre domaine, et si ces emails passent ou échouent SPF et DKIM.

C’est le point de départ obligatoire. Ne passez jamais directement à p=reject sans avoir observé en p=none d’abord. La raison : la plupart des entreprises découvrent en lisant les rapports DMARC que des services légitimes envoient des emails pour leur domaine sans être correctement configurés — l’outil CRM, la plateforme de facturation, le prestataire de newsletter. Si vous passez à p=reject sans les avoir identifiés, vous bloquez vos propres emails.

p=quarantine — l’application souple

En mode p=quarantine, les emails qui échouent à DMARC sont envoyés dans le dossier spam du destinataire. L’email n’est pas bloqué — il est toujours livré, mais dans un endroit où le destinataire ira rarement le chercher.

C’est une étape intermédiaire qui permet de confirmer que vos services d’envoi sont tous correctement configurés. Si un email légitime finit en spam, vous le verrez dans les rapports et pourrez corriger avant de passer à p=reject.

p=reject — la protection réelle

p=reject est la seule politique qui protège votre domaine contre l’usurpation. Les emails qui échouent à DMARC sont rejetés par le serveur destinataire. Ils ne sont pas livrés en spam — ils ne sont pas livrés du tout. L’attaquant qui tente d’envoyer un email en usurpant votre domaine reçoit un bounce. Le destinataire ne voit jamais le message.

Le tag pct= : le déploiement progressif

Le tag pct= permet d’appliquer la politique à un pourcentage des emails échouant à DMARC. Par défaut, pct=100 (tous les emails sont soumis à la politique). Si vous écrivez pct=25, seuls 25 % des emails en échec DMARC seront traités selon la politique — les 75 % restants seront traités comme en p=none.

Ce mécanisme est utile pour tester p=quarantine ou p=reject progressivement :

p=quarantine; pct=25   → 25% en spam, 75% livrés normalement
p=quarantine; pct=50   → 50% en spam, 50% livrés normalement
p=quarantine; pct=100  → tous en spam
p=reject; pct=25       → 25% rejetés, 75% livrés normalement
p=reject; pct=100      → tous rejetés (protection complète)

L’alignement DMARC expliqué

L’alignement est le concept qui différencie DMARC de SPF et DKIM utilisés seuls. Sans alignement, un attaquant peut passer les vérifications techniques tout en usurpant votre identité visible.

Alignement strict vs. relaxé

DMARC propose deux modes d’alignement, contrôlés par les tags aspf= (pour SPF) et adkim= (pour DKIM) :

Alignement relaxé (aspf=r, adkim=r — c’est le mode par défaut) : le domaine organisationnel doit correspondre. Un sous-domaine est accepté.

Champ From	Return-Path / DKIM d=	Résultat
user@example.fr	bounce@example.fr	Aligné
user@example.fr	bounce@marketing.example.fr	Aligné (sous-domaine)
user@example.fr	bounce@autre-domaine.fr	Non aligné

Alignement strict (aspf=s, adkim=s) : le domaine doit correspondre exactement. Aucun sous-domaine n’est accepté.

Champ From	Return-Path / DKIM d=	Résultat
user@example.fr	bounce@example.fr	Aligné
user@example.fr	bounce@marketing.example.fr	Non aligné

Quel mode choisir ?

La majorité des entreprises doivent utiliser l’alignement relaxé (défaut). La raison est pratique : beaucoup de services d’envoi légitimes utilisent des sous-domaines. Votre outil de marketing envoie depuis em.example.fr, votre CRM depuis crm.example.fr, votre plateforme de facturation depuis invoices.example.fr. L’alignement relaxé accepte ces sous-domaines comme légitimes pour le domaine parent example.fr.

L’alignement strict est utile dans un cas précis : vous voulez empêcher un sous-domaine compromis de “valider” des emails pour le domaine parent. C’est une posture de sécurité plus agressive qui nécessite un contrôle fin de chaque sous-domaine.

Configurer DMARC étape par étape

Prérequis : SPF et DKIM doivent déjà être en place

DMARC ne fonctionne pas seul. Il s’appuie sur SPF et DKIM pour vérifier l’authentification. Avant de configurer DMARC, assurez-vous que :

• Un enregistrement SPF valide existe pour votre domaine et couvre tous vos serveurs d’envoi (Microsoft 365, Google Workspace, Mailchimp, Sendinblue, Salesforce, etc.)
• DKIM est activé et des signatures sont publiées pour chaque service qui envoie en votre nom

Si vous n’avez pas encore configuré ces deux protocoles, consultez notre guide SPF, DKIM, DMARC.

Étape 1 : créer l’enregistrement DNS

Ajoutez un enregistrement TXT à l’emplacement _dmarc.votre-domaine.fr dans votre zone DNS avec la valeur suivante :

v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr; ruf=mailto:dmarc-forensic@votre-domaine.fr

Les tags de cet enregistrement :

Tag	Valeur	Signification
v=DMARC1	Obligatoire	Version du protocole (toujours DMARC1)
p=none	Obligatoire	Politique pour le domaine principal
rua=	Recommandé	Adresse de réception des rapports agrégés
ruf=	Optionnel	Adresse de réception des rapports forensic
sp=	Optionnel	Politique pour les sous-domaines
pct=	Optionnel	Pourcentage d’emails soumis à la politique (défaut : 100)
aspf=	Optionnel	Mode d’alignement SPF : s (strict) ou r (relaxé, défaut)
adkim=	Optionnel	Mode d’alignement DKIM : s (strict) ou r (relaxé, défaut)

Étape 2 : observer les rapports (2 à 4 semaines)

Avec p=none, aucun email n’est bloqué. Vous recevez des rapports quotidiens. Pendant cette période, identifiez :

• Tous les services qui envoient des emails pour votre domaine : serveur email principal, CRM, outil marketing, plateforme de facturation, support client, notifications transactionnelles
• Les services dont le SPF ou DKIM est manquant ou mal configuré : un résultat “fail” dans le rapport pour une IP que vous reconnaissez = un service légitime à corriger
• Les adresses IP inconnues : des serveurs que vous ne reconnaissez pas qui envoient des emails avec votre domaine = spoofing potentiel ou service oublié

Étape 3 : corriger les services non conformes

Pour chaque service légitime qui échoue à SPF ou DKIM :

• Ajoutez son mécanisme include: dans votre enregistrement SPF
• Activez la signature DKIM dans la configuration du service et publiez la clé publique dans votre DNS
• Vérifiez l’alignement : le domaine From utilisé par le service doit correspondre à votre domaine (ou un sous-domaine en alignement relaxé)

Étape 4 : passer en quarantine progressivement

Quand les rapports montrent que tous vos services légitimes passent DMARC :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@votre-domaine.fr

Montez progressivement : pct=25 → pct=50 → pct=100. À chaque palier, surveillez les rapports pendant une à deux semaines. Si un email légitime finit en spam, vous le verrez et pourrez corriger avant d’aller plus loin.

Étape 5 : passer en reject

Quand p=quarantine; pct=100 est stable depuis au moins deux semaines et que les rapports ne montrent aucun faux positif :

v=DMARC1; p=reject; rua=mailto:dmarc@votre-domaine.fr

Votre domaine est protégé. Mais ne désactivez pas le reporting. Gardez le tag rua= actif. De nouveaux services d’envoi seront ajoutés (nouveau prestataire marketing, nouvel outil interne) et leurs emails échoueront à DMARC si vous ne les configurez pas. Les rapports vous alerteront.

Lire et comprendre les rapports DMARC

Rapports agrégés (rua)

Les rapports agrégés sont des fichiers XML envoyés quotidiennement par chaque fournisseur de messagerie qui traite vos emails (Gmail, Outlook, Yahoo, Orange, etc.). Chaque rapport couvre une période de 24 heures et contient :

• Le domaine vérifié
• La période couverte
• Pour chaque source d’email : l’adresse IP, le nombre de messages, les résultats SPF et DKIM, le résultat d’alignement, et la politique appliquée

Voici un extrait simplifié :

<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>1547</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Cette entrée dit : l’IP 198.51.100.42 a envoyé 1 547 emails pour votre domaine, SPF et DKIM sont passés, la politique none a été appliquée. Si cette IP est celle de votre serveur mail ou de votre fournisseur d’envoi, tout va bien.

Rapports forensic (ruf)

Les rapports forensic (aussi appelés “failure reports”) sont envoyés pour chaque email individuel qui échoue à DMARC. Ils contiennent des détails plus granulaires : en-têtes complets, adresse du destinataire, raison de l’échec. En pratique, peu de fournisseurs les envoient (Gmail ne les envoie pas, Microsoft les envoie en version expurgée), et leur utilité est limitée par rapport aux rapports agrégés.

Ce qu’il faut chercher dans les rapports

Quand vous analysez vos rapports DMARC, concentrez-vous sur :

1. IPs inconnues avec un volume élevé → probable tentative de spoofing ou envoi non autorisé
2. IPs légitimes avec SPF ou DKIM en fail → service d’envoi mal configuré, à corriger en priorité
3. IPs légitimes avec un échec d’alignement → le service envoie depuis un domaine qui ne correspond pas au champ From (vérifiez le Return-Path ou le d= DKIM)
4. Volume anormal → une hausse soudaine d’emails depuis des IPs inconnues peut indiquer une campagne d’usurpation active

Outils pour lire les rapports

Les fichiers XML bruts sont difficilement lisibles par un humain. Utilisez un outil dédié :

• DMARCian — interface complète avec analyse de tendances et identification des sources
• EasyDMARC — vue simplifiée avec alertes et recommandations
• Postmark DMARC Digests — rapports hebdomadaires gratuits par email
• Valimail — outil orienté grandes entreprises avec automatisation de la mise en conformité

DMARC et les sous-domaines

Le tag sp= : politique des sous-domaines

Par défaut, si votre enregistrement DMARC ne contient pas de tag sp=, les sous-domaines héritent de la politique du domaine parent. Si votre domaine principal est en p=reject, les sous-domaines sont aussi en reject.

Le tag sp= permet de définir une politique spécifique pour les sous-domaines :

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.fr

Dans cet exemple, le domaine example.fr est en reject, mais les sous-domaines (marketing.example.fr, support.example.fr) sont en quarantine.

Pourquoi les sous-domaines sont une cible

Les attaquants le savent : beaucoup d’entreprises protègent leur domaine principal mais oublient les sous-domaines. Un domaine en p=reject sans sp=reject explicite semble protégé, mais un sous-domaine non utilisé (old.example.fr, test.example.fr) peut être exploité pour du spoofing si aucun enregistrement SPF ou DKIM n’est publié pour ce sous-domaine.

Bonnes pratiques

• Ajoutez sp=reject à votre enregistrement DMARC pour couvrir tous les sous-domaines
• Les sous-domaines d’envoi actifs (marketing.example.fr) doivent avoir leur propre configuration SPF et DKIM
• Les sous-domaines non utilisés pour l’envoi d’email doivent avoir un enregistrement SPF vide (v=spf1 -all) qui rejette tout envoi

Statistiques d’adoption DMARC

Les nouvelles exigences de Google et Yahoo (2024)

Depuis février 2024, Google et Yahoo exigent que tout expéditeur envoyant plus de 5 000 emails par jour ait un enregistrement DMARC valide. Sans DMARC, vos emails finissent en spam ou sont rejetés par Gmail et Yahoo Mail — qui représentent à eux deux plus de 2 milliards de boîtes aux lettres dans le monde.

Cette exigence a accéléré l’adoption du protocole, mais beaucoup d’entreprises se sont contentées de publier un DMARC en p=none pour satisfaire la condition technique sans jamais activer la protection réelle.

L’état de l’adoption en France

Les grandes entreprises et les institutions financières ont largement adopté DMARC (plus de 80 % du CAC 40 ont un enregistrement publié). Mais le taux de p=reject reste faible : beaucoup de domaines restent en p=none ou p=quarantine, ce qui signifie que le spoofing est toujours techniquement possible.

Chez les PME françaises, la situation est plus préoccupante. La majorité n’ont aucun enregistrement DMARC, ou un enregistrement en p=none publié à la hâte pour satisfaire les nouvelles règles Gmail. Le domaine reste alors usurpable.

NIS2 et l’authentification email

La directive européenne NIS2, transposée en droit français, pousse les entreprises des secteurs critiques (énergie, santé, transport, infrastructure numérique, etc.) à renforcer leur posture de sécurité. L’authentification email — et notamment DMARC en mode reject — fait partie des mesures attendues dans le cadre de la sécurisation des communications. Les entreprises concernées qui n’ont pas de DMARC configuré s’exposent à des recommandations de mise en conformité de l’ANSSI.

Vers BIMI : l’étape après DMARC

Une fois DMARC en p=reject, votre domaine est éligible à BIMI (Brand Indicators for Message Identification). BIMI permet d’afficher votre logo d’entreprise à côté de vos emails dans les boîtes de réception compatibles (Gmail, Yahoo, Apple Mail). C’est un avantage de délivrabilité et de confiance — mais il exige un DMARC en p=reject minimum. Sans DMARC strict, pas de BIMI.

Comment nophi.sh vérifie votre DMARC

Notre test de sécurité email analyse la configuration DMARC de votre domaine en quelques secondes. L’outil vérifie :

• La présence de l’enregistrement : un enregistrement _dmarc.votre-domaine.fr existe-t-il ?
• Le niveau de politique : p=none, p=quarantine ou p=reject ?
• La configuration des rapports : un tag rua= est-il défini pour recevoir les rapports agrégés ?
• L’alignement : les modes aspf et adkim sont-ils configurés ?
• La politique des sous-domaines : un tag sp= protège-t-il les sous-domaines ?

L’outil attribue une note de A à F et fournit des recommandations spécifiques pour atteindre le niveau supérieur. Un domaine sans DMARC reçoit un F. Un domaine en p=none reçoit au mieux un C. Seul p=reject avec SPF et DKIM correctement configurés donne un A.

Testez votre domaine maintenant avec le vérificateur de sécurité email — résultat en 30 secondes, aucun compte requis.

Le protocole DMARC est défini par le RFC 7489. Les exigences Google pour les expéditeurs en masse sont documentées dans les Email sender guidelines de Google Workspace. Pour un guide complet de déploiement SPF + DKIM + DMARC, consultez notre guide de configuration.