Qu'est-ce que DMARC ?

Ce guide fait partie de notre guide complet sur DMARC. Voir aussi : l’enregistrement DMARC et la politique DMARC.

DMARC - Domain-based Message Authentication, Reporting, and Conformance - est le protocole qui relie SPF et DKIM au sein d’un cadre unifié d’authentification des e-mails. Sans DMARC, SPF et DKIM fonctionnent indépendamment, et il n’existe aucun moyen standardisé d’indiquer aux serveurs destinataires quoi faire lorsque l’authentification échoue, ni de recevoir des rapports sur les résultats d’authentification à travers Internet.

RFC 7489 définit DMARC comme un mécanisme évolutif par lequel une organisation à l’origine d’un courrier peut exprimer des politiques et des préférences au niveau du domaine pour la validation, le traitement et le reporting des messages. Les serveurs de messagerie destinataires peuvent utiliser ces politiques pour améliorer leurs décisions de traitement du courrier.

DMARC résout trois problèmes que SPF et DKIM seuls ne peuvent pas résoudre :

1. Application des politiques - Il indique aux serveurs destinataires s’il faut rejeter, mettre en quarantaine ou accepter les messages qui échouent à l’authentification
2. Alignement - Il exige que le domaine authentifié par SPF ou DKIM corresponde au domaine de l’en-tête From visible, comblant l’écart où SPF ou DKIM pourraient réussir sur un domaine différent de celui que voit le destinataire
3. Reporting - Il fournit un mécanisme de reporting standardisé afin que les propriétaires de domaine puissent voir exactement qui envoie des e-mails en utilisant leur domaine - et si ces messages réussissent ou échouent à l’authentification

Comment fonctionne DMARC

L’évaluation DMARC a lieu après que SPF et DKIM ont déjà été vérifiés. Le déroulement est le suivant :

1. Le serveur destinataire vérifie SPF (l’IP émettrice est-elle autorisée par l’enregistrement SPF du domaine ?)
2. Le serveur destinataire vérifie DKIM (le message porte-t-il une signature DKIM valide ?)
3. Le serveur destinataire vérifie l’alignement DMARC (le domaine authentifié par SPF ou DKIM correspond-il au domaine de l’en-tête From ?)
4. Si ni SPF ni DKIM ne réussit avec alignement, le serveur destinataire applique la politique DMARC

L’idée clé est que DMARC n’effectue pas sa propre vérification d’authentification. Il évalue les résultats de SPF et DKIM et ajoute par-dessus la vérification d’alignement et l’application des politiques.

L’enregistrement DNS DMARC

Un enregistrement DMARC est un enregistrement DNS TXT publié sur _dmarc.yourdomain.com. Voici un exemple type :

_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=r; aspf=r; pct=100"

Balise	Signification	Valeurs
v=DMARC1	Version (obligatoire)	Toujours DMARC1
p=	Politique (obligatoire)	none, quarantine, reject
rua=	Destinataires des rapports agrégés	URI mailto:
ruf=	Destinataires des rapports forensiques	URI mailto:
adkim=	Mode d’alignement DKIM	r (relaxed) ou s (strict)
aspf=	Mode d’alignement SPF	r (relaxed) ou s (strict)
pct=	Pourcentage de messages auxquels appliquer la politique	1-100 (par défaut 100)
sp=	Politique pour les sous-domaines	none, quarantine, reject
fo=	Options de rapport forensique	0, 1, d, s

Vous pouvez vérifier l’enregistrement DMARC de n’importe quel domaine à l’aide du Vérificateur DMARC.

Politiques DMARC : none, quarantine, reject

La balise p= est l’élément le plus important d’un enregistrement DMARC. Elle indique aux serveurs destinataires quoi faire des messages qui échouent à la fois à l’alignement SPF et DKIM.

p=none (surveillance uniquement)

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

C’est le point de départ du déploiement de DMARC. Elle demande aux serveurs destinataires de ne prendre aucune mesure sur les messages en échec - de les livrer normalement. L’objectif de p=none est de collecter des rapports agrégés afin que vous puissiez voir :

• Quels services envoient des e-mails en votre nom
• Si ces services réussissent SPF et DKIM
• Si l’alignement est configuré correctement
• Si des expéditeurs non autorisés utilisent votre domaine

Utilisez p=none pendant au moins 2 à 4 semaines avant de passer à une politique plus stricte. Cela vous donne le temps d’identifier et de corriger les sources d’envoi légitimes qui ne sont pas correctement authentifiées.

p=quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25

La quarantaine demande aux serveurs destinataires de traiter les messages en échec comme suspects. En pratique, cela signifie généralement les acheminer vers le dossier spam ou courrier indésirable. La balise pct= vous permet d’appliquer la politique de quarantaine à seulement un pourcentage des messages en échec, permettant un déploiement progressif.

Une stratégie de déploiement courante est :

1. Commencer par p=quarantine; pct=10 - Appliquer la quarantaine à 10 % des messages en échec
2. Surveiller les rapports pour détecter les faux positifs
3. Augmenter à pct=25, puis pct=50, puis pct=100
4. Passer à p=reject une fois que vous êtes confiant

p=reject

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Le rejet demande aux serveurs destinataires de bloquer complètement les messages qui échouent à la fois à l’alignement SPF et DKIM. Le message n’est pas livré du tout - l’expéditeur reçoit un message de rebond.

p=reject offre la protection la plus forte contre l’usurpation de domaine, mais il doit être déployé avec précaution. Si une source d’envoi légitime n’est pas correctement authentifiée, ses messages seront rejetés. Une application forte est de plus en plus importante à mesure que les menaces de phishing par IA deviennent plus sophistiquées.

Guide détaillé : From Monitoring to Enforcement: Building a Scalable DMARC Strategy

Alignement DMARC : la pièce manquante

L’alignement est ce qui rend DMARC fondamentalement différent de l’exécution de SPF et DKIM indépendamment. Sans alignement, un attaquant pourrait configurer SPF et DKIM pour son propre domaine, puis utiliser ce domaine dans le Return-Path ou la signature DKIM tout en usurpant votre domaine dans l’en-tête From visible. Le destinataire verrait votre domaine, mais l’authentification vérifierait en réalité le domaine de l’attaquant.

DMARC comble cet écart en exigeant qu’au moins l’une des conditions suivantes soit vraie :

• Alignement SPF - Le domaine du Return-Path (expéditeur d’enveloppe) correspond au domaine de l’en-tête From
• Alignement DKIM - Le domaine de la signature DKIM (valeur d=) correspond au domaine de l’en-tête From

Alignement relaxed vs strict

DMARC prend en charge deux modes d’alignement pour chaque protocole :

Alignement relaxed (par défaut) : Le domaine organisationnel doit correspondre, mais les sous-domaines sont autorisés.

• From : user@example.com avec Return-Path : bounce@mail.example.com - Réussit l’alignement SPF relaxed
• From : user@example.com avec d=mail.example.com - Réussit l’alignement DKIM relaxed

Alignement strict : Les domaines doivent correspondre exactement.

• From : user@example.com avec Return-Path : bounce@mail.example.com - Échoue à l’alignement SPF strict
• From : user@example.com avec d=example.com - Réussit l’alignement DKIM strict

La plupart des organisations devraient commencer par l’alignement relaxed. L’alignement strict convient aux environnements à haute sécurité où le contrôle des sous-domaines est critique.

Guides détaillés :

• Are Your SPF and DKIM Identifiers Aligned?
• A Simple Explanation of DMARC Compliance Laws
• Fixing the SPF Alignment Failed Error

Reporting DMARC : une visibilité sur votre écosystème de messagerie

L’une des fonctionnalités les plus précieuses de DMARC est son mécanisme de reporting. Les rapports DMARC vous donnent une visibilité sur chaque e-mail envoyé en utilisant votre domaine - que vous l’ayez autorisé ou non.

Rapports agrégés (rua)

Les rapports agrégés sont des documents XML envoyés par les serveurs de messagerie destinataires (généralement quotidiennement) qui résument les résultats d’authentification pour votre domaine. Ils incluent :

• Les adresses IP sources qui ont envoyé des e-mails en utilisant votre domaine
• Le nombre de messages provenant de chaque source
• Les résultats réussite/échec SPF et DKIM pour chaque source
• Les résultats d’alignement DMARC
• La politique DMARC appliquée aux messages en échec

Les rapports agrégés sont l’outil principal pour :

• Découvrir les expéditeurs non autorisés utilisant votre domaine
• Identifier les services légitimes qui ne sont pas correctement authentifiés
• Surveiller l’efficacité de votre politique DMARC au fil du temps
• Préparer les mises à niveau de politique (de none à quarantine puis reject)

Les rapports agrégés bruts sont en XML et difficiles à lire manuellement. Un outil de reporting DMARC dédié comme DMARC Report analyse ces rapports en tableaux de bord lisibles par l’humain, vous montrant exactement quelles sources réussissent ou échouent à l’authentification. DMARC Report est le produit complémentaire de DuoCircle conçu spécifiquement à cet effet - il ingère vos rapports agrégés et fournit des analyses exploitables, des analyses de tendances et des alertes.

Guide détaillé : How to Utilize DMARC Reports to Resolve SPF Errors

Rapports forensiques (ruf)

Les rapports forensiques (également appelés rapports d’échec) sont envoyés en quasi-temps réel pour les messages individuels qui échouent à DMARC. Ils incluent des informations détaillées sur le message spécifique, y compris les en-têtes et parfois une partie du contenu du message.

Les rapports forensiques sont utiles pour :

• Enquêter sur des incidents d’usurpation spécifiques
• Déboguer les échecs d’authentification pour des messages individuels
• Identifier le point exact de défaillance dans la chaîne d’authentification

Note sur la confidentialité : De nombreux serveurs destinataires n’envoient pas de rapports forensiques en raison de préoccupations de confidentialité, et certains masquent les informations personnelles des rapports qu’ils envoient. Ne comptez pas sur les rapports forensiques comme unique source de données DMARC.

La balise fo= contrôle le moment où les rapports forensiques sont générés :

Valeur	Signification
fo=0	Rapport si SPF et DKIM échouent tous les deux (par défaut)
fo=1	Rapport si SPF ou DKIM échoue
fo=d	Rapport si DKIM échoue
fo=s	Rapport si SPF échoue

DMARC et anti-spam : des problèmes différents

Une idée reçue courante est que DMARC est un outil anti-spam. Ce n’est pas le cas. DMARC authentifie l’identité du domaine - il vous indique si l’expéditeur est bien celui qu’il prétend être. Il n’évalue pas le contenu du message pour détecter des caractéristiques de spam.

Un e-mail peut réussir DMARC et être néanmoins du spam (si l’expéditeur est authentifié mais envoie du contenu indésirable). Inversement, un e-mail légitime peut échouer à DMARC (si l’authentification est mal configurée). DMARC et les filtres anti-spam fonctionnent à des couches différentes et se complètent.

Guide détaillé : DMARC and Anti-Spam Aren’t the Same!

Déployer DMARC : une stratégie étape par étape

Le déploiement de DMARC devrait suivre une approche progressive pour éviter de perturber la livraison des e-mails légitimes.

Phase 1 : Préparation

1. Auditez vos sources d’envoi - Documentez chaque service, serveur et plateforme qui envoie des e-mails en utilisant votre domaine
2. Configurez SPF - Assurez-vous que votre enregistrement SPF inclut tous les expéditeurs autorisés
3. Configurez DKIM - Mettez en place la signature DKIM pour toutes les plateformes d’envoi
4. Vérifiez l’alignement - Confirmez que les domaines SPF et DKIM s’alignent avec le domaine de votre en-tête From

Phase 2 : Surveillance (p=none)

1. Publiez un enregistrement DMARC avec p=none et une adresse rua= pour les rapports agrégés
2. Mettez en place un processeur de rapports DMARC (comme DMARC Report) pour analyser les rapports entrants
3. Surveillez les rapports pendant 2 à 4 semaines
4. Identifiez et corrigez toute source légitime qui échoue à l’authentification ou à l’alignement

Phase 3 : Quarantaine

1. Passez à p=quarantine; pct=10 pour commencer à acheminer un petit pourcentage de messages en échec vers le spam
2. Surveillez les rapports pour détecter les faux positifs (courrier légitime mis en quarantaine)
3. Augmentez progressivement la valeur pct= à mesure que la confiance grandit
4. Une fois à pct=100 sans faux positifs, passez à la Phase 4

Phase 4 : Rejet

1. Passez à p=reject pour bloquer complètement les messages non authentifiés
2. Continuez à surveiller les rapports agrégés pour détecter tout nouveau service ou toute mauvaise configuration
3. Maintenez vos configurations SPF et DKIM à mesure que les services évoluent au fil du temps

Guides détaillés :

• From Monitoring to Enforcement: Building a Scalable DMARC Strategy
• How Should You Implement DMARC as an MSP or Enterprise?
• Spotting Spoofed Emails with DMARC: A Guide

Exigences de conformité DMARC

DMARC devient de plus en plus une exigence réglementaire et industrielle, et non plus seulement une bonne pratique. Il en va de même pour la conformité SPF, qui sous-tend l’application de DMARC.

Exigences de Google et Yahoo (2024+)

Depuis février 2024, Google et Yahoo exigent l’authentification DMARC pour les expéditeurs en masse (ceux qui envoient plus de 5 000 messages par jour à des adresses Gmail ou Yahoo). Les domaines sans DMARC peuvent voir leur délivrabilité réduite.

Guide détaillé : Major Email Service Providers Emphasize DMARC Deployment

PCI DSS 4.0

La norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS) version 4.0 rend DMARC obligatoire pour les organisations qui traitent des données de cartes de paiement, avec une application complète débutant en 2025.

Guide détaillé : DMARC to be Mandatory for PCI DSS Compliance by 2025

RGPD et protection des données

Les rapports agrégés DMARC offrent une visibilité sur le trafic e-mail qui peut aider les organisations à répondre aux exigences du RGPD en matière de protection des données et de notification de violation.

Guide détaillé : Implementing DMARC to Gain Visibility and Maintain GDPR Compliance

Exigences gouvernementales

Plusieurs gouvernements ont imposé ou fortement recommandé DMARC pour les domaines gouvernementaux, notamment le Royaume-Uni (via le NCSC), la Nouvelle-Zélande et les États-Unis (via BOD 18-01).

Guides détaillés :

• The New Zealand Government’s New DMARC Requirements
• Efficient DMARC Tools Needed After UK NCSC Changes

DORA (Digital Operational Resilience Act)

Le règlement DORA de l’UE recoupe les exigences DMARC pour les institutions financières.

Guide détaillé : The Point Where DORA and DMARC Intersect

Erreurs DMARC courantes et dépannage

Erreur permanente 554 5.7.5 dans DMARC

Cette erreur indique qu’un serveur destinataire a rejeté un message en fonction de la politique DMARC. Elle signifie généralement que SPF et DKIM ont tous deux échoué à s’aligner avec le domaine de l’en-tête From.

Guide détaillé : What is the 554 5.7.5 Permanent Error in DMARC and How to Fix It?

SPF réussit mais DMARC échoue

Cela se produit lorsque SPF authentifie le domaine de l’expéditeur d’enveloppe, mais que ce domaine ne correspond pas au domaine de l’en-tête From (échec d’alignement). La solution consiste à configurer l’expéditeur d’enveloppe pour qu’il utilise votre domaine, ou à mettre en place DKIM avec un domaine d= correspondant.

Guides détaillés :

• How SPF, DKIM, and DMARC Work Together During Authentication Failures
• How SPF and DMARC Work Together to Improve Email Security

Le courrier transféré échoue à DMARC

Le transfert d’e-mails casse SPF (l’IP du serveur de transfert n’est pas dans l’enregistrement SPF du domaine d’origine). Si DKIM n’est pas configuré ou si le serveur de transfert modifie le message (cassant la signature DKIM), DMARC échoue. La solution est de s’assurer que DKIM est correctement configuré, car les signatures DKIM survivent au transfert si le contenu du message n’est pas modifié.

La relation entre DMARC et SPF

DMARC dépend fortement du fait que SPF soit correctement configuré. Si votre enregistrement SPF comporte des erreurs - qu’il dépasse la limite de 10 recherches DNS, contienne des erreurs de syntaxe ou omette des expéditeurs autorisés - l’application de DMARC entraînera la mise en quarantaine ou le rejet du courrier en raison de ces échecs d’authentification. Apprenez à corriger SPF too many DNS lookups avant que cela ne casse DMARC. Consolidez vos includes avec un service d’aplatissement SPF pour rester sous la limite de 10 recherches.

Avant de déployer DMARC en mode d’application, vérifiez votre enregistrement SPF avec le Vérificateur SPF et assurez-vous que votre nombre de recherches DNS reste dans les limites à l’aide du Validateur SPF.

Pour les domaines dont les enregistrements SPF complexes approchent la limite de recherches, AutoSPF fournit un aplatissement SPF dynamique qui maintient automatiquement votre enregistrement dans les limites - un fondement essentiel pour une application DMARC fiable.

DMARC Report - le produit complémentaire de DuoCircle

DMARC Report est la plateforme dédiée de reporting et d’analyse DMARC de DuoCircle. Elle est conçue pour fonctionner aux côtés d’AutoSPF afin de fournir une gestion complète de l’authentification des e-mails :

• AutoSPF gère le volet SPF - aplatissement dynamique, gestion des recherches DNS et optimisation de l’enregistrement SPF
• DMARC Report gère le volet visibilité - analyse des rapports agrégés, identification des échecs d’authentification, suivi des tendances de conformité et alertes sur les problèmes

Ensemble, ils vous donnent un contrôle total sur votre posture d’authentification des e-mails. DMARC Report ingère vos rapports agrégés rua=, normalise les données et présente des tableaux de bord exploitables qui vous montrent exactement quels expéditeurs réussissent ou échouent à l’authentification pour votre domaine.

Outils de diagnostic

• Vérificateur DMARC - Validez votre enregistrement DMARC et vérifiez les problèmes de configuration courants
• Vérificateur d’authentification de domaine - Vérification combinée SPF, DKIM et DMARC en une seule recherche
• Vérificateur SPF - Vérifiez que SPF est correct avant d’appliquer DMARC
• Recherche DKIM - Vérifiez que les clés DKIM sont publiées et valides
• Validateur SPF - Évaluation SPF complète avec comptage des recherches

Prochaines étapes

1. Vérifiez votre statut DMARC actuel - Utilisez le Vérificateur DMARC pour voir si vous avez un enregistrement DMARC et quelle politique il spécifie
2. Commencez par p=none - Si vous n’avez pas déployé DMARC, commencez en mode surveillance pour collecter des données
3. Mettez en place le traitement des rapports - Pointez votre adresse rua= vers DMARC Report pour des tableaux de bord lisibles par l’humain
4. Corrigez les lacunes d’authentification - Utilisez les rapports agrégés pour identifier et corriger les services qui échouent à SPF ou DKIM
5. Progressez vers l’application - Passez par la quarantaine puis le rejet à mesure que votre couverture d’authentification mûrit
6. Maintenez en continu - L’infrastructure de messagerie change constamment. Surveillez les rapports et mettez à jour les configurations SPF/DKIM selon les besoins

Pour une comparaison complète des outils de gestion SPF, consultez PowerDMARC Alternatives, EasyDMARC Alternatives et DMARCLY Alternatives.