Questions DMARC,
avec réponses

DMARC (Domain-based Message Authentication, Reporting & Conformance) est un protocole d'authentification e-mail qui indique aux serveurs de messagerie destinataires quoi faire lorsque les contrôles SPF ou DKIM échouent. Il empêche les attaquants d'envoyer des e-mails qui semblent provenir de votre domaine, protégeant ainsi votre marque et vos destinataires contre le phishing et le spoofing. DMARC est défini dans la RFC 7489.

Oui. Si votre domaine envoie des e-mails - ou même s'il n'en envoie pas - vous avez besoin de DMARC. Sans lui, n'importe qui peut envoyer des e-mails en usurpant votre domaine. Google et Yahoo exigent désormais au moins p=none pour les domaines envoyant plus de 5 000 messages par jour. PCI DSS v4.0 exige DMARC pour les domaines destinés aux clients. Les domaines qui n'envoient pas d'e-mails devraient publier p=reject pour empêcher l'usurpation.

Commencez par vous assurer que SPF et DKIM sont configurés pour votre domaine. Publiez ensuite un enregistrement DNS TXT à _dmarc.votredomaine.com avec p=none et une adresse de rapport rua=. Surveillez les rapports agrégés pendant au moins 90 jours, corrigez l'authentification pour tous les expéditeurs légitimes, puis passez progressivement à p=quarantine et enfin p=reject. Utilisez notre vérificateur DMARC pour valider votre enregistrement.

La publication d'un enregistrement DMARC en p=none prend quelques minutes. Atteindre l'application complète en p=reject prend généralement 9 à 18 mois. Chaque phase (none, quarantine, reject) nécessite un minimum de 90 jours de surveillance pour identifier toutes les sources d'envoi légitimes et corriger leur authentification. Les organisations avec moins d'expéditeurs tiers peuvent avancer plus vite.

Un enregistrement DMARC est un enregistrement DNS TXT publié à _dmarc.votredomaine.com. Un enregistrement typique ressemble à : v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r. Les balises v= et p= sont obligatoires ; toutes les autres sont facultatives mais recommandées. Consultez notre page Qu'est-ce que DMARC pour une décomposition complète de chaque balise.

SPF vérifie que le serveur d'envoi est autorisé par l'enregistrement DNS du domaine - il contrôle l'expéditeur d'enveloppe (Return-Path). DKIM attache une signature cryptographique pour prouver que le message n'a pas été altéré en transit. DMARC les relie : il exige que SPF ou DKIM réussisse ET s'aligne avec le domaine visible de l'en-tête From, puis indique aux destinataires quoi faire lorsque l'authentification échoue. Utilisez notre vérificateur SPF et notre recherche DKIM pour tester vos enregistrements.

Non. Un domaine doit avoir exactement un enregistrement DMARC TXT à _dmarc.domain.com. Plusieurs enregistrements DMARC provoquent une erreur PermError et les destinataires les ignorent tous. Si vous devez envoyer des rapports à plusieurs adresses, listez-les séparées par des virgules dans la balise rua= : rua=mailto:dmarc@example.com,mailto:reports@example.com.

L'alignement DMARC signifie que le domaine dans l'en-tête visible From doit correspondre au domaine qui a réussi SPF ou DKIM. L'alignement relaxed (par défaut) permet la correspondance de sous-domaine - mail.exemple.com s'aligne avec exemple.com. L'alignement strict exige une correspondance exacte du domaine. L'alignement empêche les attaquants de réussir SPF avec leur propre domaine tout en usurpant le vôtre dans l'en-tête From.

La politique p=none demande aux serveurs destinataires de ne prendre aucune mesure d'application sur les messages qui échouent à DMARC. Les messages sont distribués normalement, quels que soient les résultats d'authentification. Le but est la surveillance : les destinataires envoient toujours des rapports agrégés, donnant au propriétaire du domaine une visibilité sur toutes les sources d'envoi. Commencez toujours avec p=none avant de passer à l'application.

La politique p=quarantine demande aux serveurs destinataires d'acheminer les messages en échec vers le dossier spam ou courrier indésirable. Le message existe toujours - les destinataires peuvent le retrouver - mais il est signalé comme suspect. C'est l'étape d'application intermédiaire entre p=none (surveillance) et p=reject (blocage complet). Consultez notre guide Politique DMARC pour la progression complète.

La politique p=reject demande aux serveurs destinataires de rejeter les messages en échec au niveau SMTP. Le destinataire ne voit jamais le message et le serveur d'envoi reçoit un rebond. C'est la protection DMARC la plus forte et l'objectif ultime pour chaque domaine. Atteindre p=reject nécessite une surveillance approfondie à travers les phases p=none et p=quarantine au préalable.

La balise pct= contrôle quel pourcentage des messages en échec reçoit la mesure d'application. À pct=25, seuls 25 % des messages en échec sont mis en quarantaine ou rejetés - le reste est traité comme p=none. Cela permet un déploiement graduel de l'application. Commencez à pct=10, augmentez à 25, 50, puis 100 sur plusieurs semaines. Si pct= est omis, sa valeur par défaut est 100.

Un rapport agrégé (RUA) est un fichier XML envoyé quotidiennement par les serveurs de messagerie destinataires, résumant les résultats d'authentification de tous les messages prétendant provenir de votre domaine. Il indique quelles adresses IP ont envoyé des e-mails, si SPF et DKIM ont réussi et quelle politique a été appliquée. Les rapports agrégés sont le fondement de la surveillance DMARC - ils fournissent les données nécessaires pour prendre des décisions d'application. DMARC Report convertit ces fichiers XML en tableaux de bord visuels.

Un rapport forensique (RUF) fournit des détails d'échec par message - l'e-mail spécifique qui a échoué à l'authentification, l'IP de l'expéditeur, l'incohérence From/Return-Path et quel mécanisme a échoué. Les rapports forensiques sont utiles pour enquêter sur des tentatives de spoofing actives, mais sont moins couramment pris en charge par les destinataires que les rapports agrégés. Certains destinataires n'envoient pas du tout de rapports RUF pour des raisons de confidentialité.

Les rapports agrégés DMARC bruts sont des fichiers XML difficiles à lire manuellement. Utilisez un analyseur de rapports DMARC comme DMARC Report pour convertir le XML en tableaux de bord visuels montrant le statut d'authentification des expéditeurs, les résultats d'alignement et les actions de politique. L'outil classe automatiquement les expéditeurs par fournisseur (Google Workspace, Microsoft 365, SendGrid, etc.) et met en évidence les échecs nécessitant une attention.

Raisons courantes : votre enregistrement DMARC n'inclut pas de balise rua=, l'adresse e-mail rua= comporte une faute de frappe, ou pas assez de volume d'e-mails a été envoyé pour déclencher des rapports (les destinataires regroupent généralement les rapports quotidiennement). Si rua= pointe vers un domaine différent de celui authentifié, vous avez besoin d'un enregistrement DNS de vérification externe. Prévoyez 24 à 72 heures après la publication de votre enregistrement DMARC pour que les rapports commencent à arriver. Utilisez notre vérificateur DMARC pour valider la syntaxe de votre enregistrement.

La plupart des destinataires envoient des rapports agrégés une fois toutes les 24 heures, généralement à minuit UTC. Certains grands destinataires comme Google et Microsoft peuvent envoyer plusieurs rapports par jour. Le volume de rapports que vous recevez dépend du nombre de destinataires différents qui traitent les e-mails de votre domaine. Les domaines populaires peuvent recevoir des centaines de rapports par jour de dizaines de destinataires.

Le parcours de p=none à p=reject prend généralement 9 à 18 mois. Chaque phase nécessite un minimum de 90 jours : p=none pour la surveillance et l'identification des expéditeurs, p=quarantine pour l'application intermédiaire et p=reject pour la protection complète. Les organisations avec moins d'expéditeurs tiers et une infrastructure e-mail plus simple peuvent avancer plus vite, mais précipiter l'application fait bloquer des e-mails légitimes.

Si un expéditeur légitime échoue à DMARC en p=quarantine, son e-mail va dans le spam. En p=reject, il est bloqué entièrement. Pour corriger cela : consultez les rapports agrégés pour identifier l'expéditeur en échec, configurez son include SPF ou sa signature DKIM et vérifiez que l'alignement réussit. L'utilisation de la balise pct= pour déployer progressivement l'application aide à détecter ces problèmes avant qu'ils n'affectent tous les e-mails.

La quarantaine offre une protection significative - les messages usurpés quittent la boîte de réception. Cependant, p=reject est l'objectif recommandé car il empêche entièrement la distribution. Certains cadres de conformité (PCI DSS v4.0, CISA BOD 18-01 pour les agences fédérales) exigent spécifiquement p=reject. De plus, p=reject est requis pour être éligible à BIMI, qui affiche le logo de votre marque dans les clients de messagerie compatibles.

Oui. Le transfert d'e-mails traditionnel peut casser l'alignement SPF car l'IP du serveur de transfert n'est pas dans l'enregistrement SPF du domaine d'origine. DKIM survit généralement au transfert car la signature est attachée au message lui-même. C'est pourquoi l'alignement DKIM est particulièrement important pour les domaines dont les destinataires transfèrent des e-mails. ARC (Authenticated Received Chain) est un protocole plus récent conçu pour résoudre ce problème, mais son adoption est encore en croissance.

DMARC est exigé par un nombre croissant de normes et d'organisations. Google et Yahoo exigent au moins p=none pour les expéditeurs de masse (5 000+ messages/jour). PCI DSS v4.0 exige DMARC pour les domaines utilisés dans les communications avec les clients (en vigueur depuis mars 2025). CISA BOD 18-01 impose p=reject pour les agences fédérales américaines. De nombreuses polices de cyber-assurance et processus d'approvisionnement exigent désormais l'application de DMARC.

Depuis février 2024, Google et Yahoo exigent de tous les expéditeurs de masse (5 000+ messages/jour vers les utilisateurs Gmail/Yahoo) une politique DMARC d'au moins p=none avec une adresse rua= valide. De plus, les expéditeurs doivent avoir des enregistrements SPF et DKIM correctement configurés, inclure des en-têtes de désabonnement en un clic dans les e-mails marketing et maintenir un taux de plaintes pour spam inférieur à 0,3 %. Les expéditeurs non conformes subissent un ralentissement de distribution et des rejets.

Oui. PCI DSS v4.0 (en vigueur depuis mars 2025) exige des organisations qui traitent des données de titulaires de cartes qu'elles mettent en œuvre DMARC sur les domaines utilisés dans les communications avec les clients. Plus précisément, l'exigence 5.4.1 stipule que les mécanismes anti-phishing doivent inclure l'authentification basée sur le domaine (DMARC, SPF, DKIM). La plupart des évaluateurs PCI attendent p=reject ou p=quarantine pour la conformité.

La Binding Operational Directive 18-01, émise par la Cybersecurity and Infrastructure Security Agency (CISA), exige de toutes les agences de la branche exécutive fédérale américaine qu'elles mettent en œuvre DMARC en p=reject. Cette directive a considérablement augmenté l'adoption de DMARC dans le secteur gouvernemental et est souvent citée comme référence de bonne pratique par d'autres organisations et industries.

DMARC soutient la conformité HIPAA en empêchant le spoofing des noms de domaine du secteur de la santé, réduisant le risque d'attaques de phishing pouvant conduire à l'exposition d'Informations de Santé Protégées (PHI). Bien que HIPAA ne nomme pas explicitement DMARC, la Security Rule exige des mesures de protection pour les PHI électroniques, et l'authentification e-mail est considérée comme une mesure raisonnable et appropriée. Notez que les rapports forensiques (RUF) peuvent contenir du contenu de message, de sorte que les organisations de santé devraient utiliser uniquement les rapports agrégés (RUA) ou s'assurer que les rapports forensiques sont traités conformément à HIPAA.