La politique DMARC est l’instruction que vous publiez dans votre DNS pour dire aux serveurs destinataires quoi faire d’un message qui échoue aux contrôles d’authentification : le laisser passer (p=none), le placer en spam (p=quarantine) ou le refuser (p=reject). Le bon choix n’est pas le plus strict d’emblée, mais le plus strict que vos flux d’emails légitimes supportent. Ce guide vous donne la méthode, la syntaxe et les pièges, avec un regard particulier sur l’emailing et la prospection à froid.

En bref

• Une politique DMARC indique aux serveurs destinataires comment traiter les emails qui échouent à SPF et DKIM avec alignement : aucune action, quarantaine ou rejet.
• Commencez par p=none avec des rapports (rua=), identifiez tous vos expéditeurs légitimes, puis passez à quarantine et enfin à reject.
• Ne durcissez qu’une fois vos flux légitimes alignés de manière stable sur plusieurs périodes de rapports.
• Pour un domaine d’envoi commercial, l’alignement SPF et DKIM compte autant que la politique elle-même : sans lui, même un p=none ne vous protège de rien.

Table des matières

• À quoi sert une politique DMARC
• SPF, DKIM et DMARC : qui fait quoi
• Les trois politiques : none, quarantine, reject
• Comment choisir : la montée en puissance par étapes
• Écrire l’enregistrement DMARC dans le DNS
• Lire les rapports DMARC
• Vérifier que la politique est bien publiée et appliquée
• DMARC et prospection à froid : ce qui change
• Notre point de vue
• Mettre en place l’infrastructure sans y passer vos semaines
• FAQ
• Sources

À quoi sert une politique DMARC

DMARC est un protocole d’authentification des emails qui aide à protéger les utilisateurs contre les messages falsifiés. Selon l’aide Google Workspace, il indique aux serveurs destinataires quoi faire des messages qui échouent aux contrôles SPF ou DKIM. Le dispositif d’assistance aux victimes de cybermalveillance précise qu’il aide les propriétaires de domaines à se protéger contre les usurpateurs, les expéditeurs de courrier indésirable et l’hameçonnage.

La RFC 7489, publiée en mars 2015, décrit DMARC comme un mécanisme par lequel une organisation expéditrice exprime ses politiques et préférences de domaine sur la validation, le traitement et le signalement des messages. Deux idées en ressortent :

1. Vous décidez : le propriétaire du domaine publie sa consigne, au lieu de laisser chaque destinataire deviner.
2. Vous êtes informé : les rapports vous montrent qui envoie des emails en utilisant votre domaine.

Pour une équipe commerciale, cela a deux conséquences concrètes. D’un côté, quelqu’un qui usurpe votre domaine pour envoyer du phishing abîme la confiance de vos prospects. De l’autre, un domaine bien authentifié envoie à la boîte de réception un signal de sérieux que les fournisseurs de messagerie sont en mesure de lire. Si vous voulez comprendre comment la réputation se construit autour de ce signal, notre article sur la réputation de domaine email détaille les mécanismes.

SPF, DKIM et DMARC : qui fait quoi

La confusion est fréquente, surtout à la question « quelle différence entre DKIM et DMARC ? ». La documentation de Microsoft la résume ainsi :

Le mot clé est alignement. Un message peut passer SPF avec le domaine d’un prestataire d’envoi et pourtant échouer à DMARC parce que ce domaine n’est pas celui de votre adresse « De ». C’est le cas le plus courant chez les équipes qui envoient via un outil tiers sans avoir configuré de domaine d’envoi personnalisé. Nous détaillons ce point dans l’alignement DMARC entre SPF, DKIM et domaine From, et, côté signature, dans l’article sur l’alignement DKIM. Pour une vue d’ensemble des trois protocoles, voyez le guide SPF, DKIM et DMARC.

Les modes d’alignement se règlent avec adkim et aspf : chacun peut être strict (s) ou relâché (r), selon Cloudflare. En relâché, un sous-domaine de votre domaine organisationnel est accepté. En strict, le domaine doit correspondre exactement. Le relâché convient à la plupart des cas et c’est le plus simple à tenir quand on envoie depuis des sous-domaines.

Les trois politiques : none, quarantine, reject

La balise p= fixe la politique de base. D’après l’aide Google Workspace :

p=none : observer sans risque

Avec p=none, rien ne change pour la remise : les messages en échec sont transmis au destinataire et consignés dans un rapport. Cette politique sert à recueillir des données sur les expéditeurs qui envoient au nom de votre domaine avant d’appliquer une règle plus stricte. Google recommande d’ailleurs de commencer par none, puis d’ajuster à mesure que l’authentification de vos messages est connue.

Attention à une idée reçue : p=none n’est pas une protection. Il ne bloque rien. C’est un instrument de mesure. Un domaine qui reste indéfiniment à none vous donne de la visibilité, mais n’empêche pas l’usurpation. Pour un domaine de prospection récent, la durée dépend du nombre de sources d’envoi : quelques semaines suffisent souvent si vous n’avez qu’un outil d’envoi et une messagerie.

p=quarantine : le palier de sécurité

Avec quarantine, les messages non authentifiés finissent en spam. C’est le premier palier qui a un effet réel, et c’est aussi celui qui révèle les oublis : une facturation envoyée par un logiciel que personne n’avait déclaré, une newsletter lancée depuis un autre outil, un CRM qui envoie en votre nom. Le paramètre pct= permet de n’appliquer la politique qu’à un pourcentage des messages en échec, ce qui rend la montée en charge progressive. La documentation Microsoft le présente comme paramètre optionnel.

p=reject : l’application complète

Avec reject, les serveurs destinataires refusent les messages qui échouent. C’est la protection maximale contre l’usurpation exacte de votre domaine. C’est aussi la politique qui ne pardonne pas : un expéditeur légitime mal aligné ne vous écrira plus. On y va donc en connaissance de cause, avec des rapports propres.

Comment choisir : la montée en puissance par étapes

La bonne méthode est progressive. DNSimple recommande de partir de p=none, de passer à p=quarantine, puis à p=reject après que les rapports montrent que les emails légitimes sont alignés. Voici comment l’appliquer.

1. Inventoriez vos expéditeurs. Messagerie d’entreprise, outil d’envoi de prospection, CRM, facturation, support, newsletter. Chaque source doit être connue.
2. Publiez p=none avec rua=. Vous recevez des rapports agrégés sans changer la remise.
3. Alignez les sources légitimes. Configurez SPF et DKIM pour que chacune s’aligne sur votre domaine.
4. Passez à quarantine, d’abord avec pct= bas. Surveillez la boîte de réception et les rapports.
5. Montez le pourcentage jusqu’à 100 %.
6. Passez à reject quand plus aucun flux légitime n’échoue.

Quand durcir ?

Pas de chiffre officiel universel. Un guide de pratique indique qu’un alignement d’au moins 95 % sur plusieurs périodes de rapports est un bon indicateur de préparation. Prenez-le comme un repère de prudence, pas comme une règle réglementaire. Les 5 % restants méritent d’être compris : s’agit-il d’usurpation ou d’un flux oublié ?

Une autre raison de ne pas se précipiter : les rapports arrivent avec du retard et le transfert d’emails peut modifier les résultats SPF, ce qui impose des points de contrôle réguliers pendant le déploiement. Le même guide conseille d’évaluer les flux de courrier indirects (listes de diffusion, redirections) avant de passer à une application stricte.

Écrire l’enregistrement DMARC dans le DNS

La configuration consiste à ajouter un enregistrement de type TXT sur le sous-domaine _dmarc de votre domaine, comme l’explique la documentation Microsoft. Les paramètres principaux sont :

• v=DMARC1 : la version, toujours en premier ;
• p= : la politique de base ;
• rua= : l’adresse qui reçoit les rapports agrégés ;
• pct= : le pourcentage de messages concernés (facultatif) ;
• adkim et aspf : les modes d’alignement DKIM et SPF (facultatifs).

Un exemple de départ pour le domaine exemple.fr :

Nom : _dmarc.exemple.fr
Type : TXT
Valeur : v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr

Puis, plus tard, un palier intermédiaire :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@exemple.fr; adkim=r; aspf=r

Une précision utile : les services d’hébergement ne configurent pas ces enregistrements à votre place. Cloudflare le rappelle : c’est au propriétaire du domaine de publier correctement SPF, DKIM et DMARC. Si vous gérez plusieurs domaines, faites-le domaine par domaine, y compris pour ceux que vous n’utilisez pas pour l’envoi.

Lire les rapports DMARC

Les rapports sont des fichiers, généralement du XML compressé, envoyés aux adresses indiquées dans l’enregistrement. Ils donnent une vue détaillée de qui envoie des emails avec votre domaine, et servent à valider que les sources légitimes passent les tests et à repérer les tentatives d’usurpation, selon Microsoft. Il en existe deux familles :

• Les rapports agrégés résument périodiquement les résultats positifs et négatifs ;
• Les rapports d’investigation donnent presque immédiatement les résultats d’échec.

En pratique, lire du XML brut n’est pas agréable. Redirigez rua= vers une boîte dédiée, et utilisez un outil de lecture de rapports si le volume augmente. Ce que vous cherchez : l’adresse IP source, le volume, le résultat SPF, le résultat DKIM et l’alignement. Une IP inconnue qui envoie en masse en usurpant votre domaine est un signal à traiter. Une IP connue mais mal alignée est un flux à corriger.

Vérifier que la politique est bien publiée et appliquée

Deux contrôles distincts :

1. La publication. Interrogez le DNS pour le TXT de _dmarc.votredomaine.fr et vérifiez qu’il commence bien par v=DMARC1 et qu’il n’y a qu’un seul enregistrement. Un outil de recherche DNS ou un vérificateur DMARC suffit. Un message « DMARC policy not enabled » signale en général qu’aucun enregistrement valide n’est trouvé.
2. L’application. Les serveurs de messagerie doivent vérifier et appliquer les enregistrements publiés pour qu’ils aient un effet, rappelle Cloudflare. Envoyez un message test vers plusieurs boîtes et inspectez les en-têtes : vous y lisez le résultat dmarc=pass ou dmarc=fail.

Ensuite, la surveillance dans le temps. Le Centre canadien pour la cybersécurité recommande, dans son guide d’août 2025, de vérifier périodiquement les règles DMARC afin de déterminer si des courriels importants sont bloqués. Gardez ce réflexe à chaque nouvel outil connecté à votre domaine.

DMARC et prospection à froid : ce qui change

Pour les équipes qui envoient des emails de prospection, DMARC se combine avec trois habitudes qui comptent autant que la politique.

Un domaine d’envoi dédié. Envoyer la prospection depuis votre domaine principal expose votre messagerie quotidienne à tout incident de réputation. Nous expliquons comment créer, chauffer et protéger un domaine de prospection dans un guide séparé. Sur ces domaines secondaires, vous pouvez publier DMARC dès le premier jour, avec p=none puis un durcissement rapide, car le nombre de sources est réduit.

Une base propre. L’authentification ne compense pas une liste mal qualifiée. Des adresses invalides génèrent des rebonds, et les rebonds dégradent la réputation. La vérification d’emails B2B et le traitement des emails catch-all sont les deux étapes à placer avant l’envoi.

Un suivi des listes noires. Si un domaine bien authentifié se retrouve tout de même listé, il faut savoir comprendre, vérifier et sortir d’une blacklist.

Les grands fournisseurs de messagerie ont par ailleurs durci leurs exigences d’authentification pour les expéditeurs en volume. Si vous prévoyez de monter en charge, le détail de notre recommandation est dans l’article DMARC policy : what to set before scaling outbound. Et si vous réchauffez des boîtes Gmail, la méthode de warm-up Gmail suppose que l’authentification soit déjà en place.

Notre point de vue

Nous voyons la même erreur chez les équipes qui lancent de la prospection : elles traitent DMARC comme une case à cocher, publient p=none et passent à autre chose. Or l’enregistrement n’est que la dernière couche. Ce qui fait la différence, c’est l’alignement de chaque source d’envoi et l’isolation de l’infrastructure.

C’est la raison pour laquelle PlusVibe a été conçu autour d’une infrastructure d’envoi isolée et d’un warm-up privé non partagé : notre approche vise à réduire les placements en spam et les taux de rebond, et à vous laisser un domaine dont vous maîtrisez chaque flux. Quand chaque client a ses propres serveurs et ses propres IP, les rapports DMARC racontent votre histoire, pas celle d’un voisin.

Notre conseil : un domaine d’envoi par usage, une politique qui monte par paliers, et un contrôle de la délivrabilité qui ne s’arrête pas le jour de la publication du DNS.

Yaro

Mettre en place l’infrastructure sans y passer vos semaines

Configurer SPF, DKIM et DMARC sur plusieurs domaines et plusieurs boîtes est un travail répétitif, et c’est là que les erreurs se glissent. PlusVibe propose le warm-up privé, la rotation des boîtes, la surveillance de la délivrabilité et des boîtes Google Workspace à partir de 4 $ par mois et par boîte, ou Microsoft 365 à partir de 4,5 $ par mois et par boîte. Les forfaits Personal (37 à 58 $ par mois), Business (77 à 220 $ par mois) et Agency (à partir de 497 $ par mois) sont détaillés sur la page des offres.

Si vous préférez déléguer, notre configuration d’emails clé en main est proposée à 1 500 $ par mois. Pour un contrôle rapide de votre base avant envoi, l’outil gratuit de vérification d’emails est un bon premier pas.

FAQ

C’est quoi DMARC ?

DMARC est un protocole d’authentification des emails qui permet au propriétaire d’un domaine de dire aux serveurs destinataires comment traiter les messages qui échouent aux contrôles SPF ou DKIM. Il produit aussi des rapports sur les envois effectués au nom du domaine. Il se publie sous forme d’enregistrement TXT dans le DNS.

Quelle politique DMARC choisir pour commencer ?

Commencez par p=none avec une adresse rua= pour recevoir les rapports. Google recommande ce point de départ, puis un ajustement à mesure que l’authentification de vos messages est connue. Passez à quarantine, puis à reject, quand vos flux légitimes sont alignés.

Quelle est la différence entre DKIM et DMARC ?

DKIM signe le message et permet de vérifier le domaine signataire. DMARC vérifie qu’au moins SPF ou DKIM réussit avec un domaine aligné sur l’adresse « De », puis applique la politique que vous avez choisie. DKIM est un contrôle, DMARC est la règle qui en tire les conséquences.

Qu’est-ce qu’un rapport DMARC et à quoi sert-il ?

C’est un fichier, généralement en XML compressé, envoyé à l’adresse rua= de votre enregistrement. Il liste les sources qui ont envoyé des emails avec votre domaine et leurs résultats SPF, DKIM et d’alignement. Il sert à valider vos expéditeurs légitimes et à repérer l’usurpation.

Comment vérifier mon DMARC ?

Vérifiez d’abord que l’enregistrement TXT _dmarc est publié et bien formé, avec un outil de recherche DNS. Envoyez ensuite un message test et lisez les en-têtes pour confirmer dmarc=pass. Relisez enfin vos rapports régulièrement pour détecter les flux légitimes bloqués.

Sources

• Configurer DMARC, aide Administrateur Google Workspace
• Guide de configuration de DMARC, Cybermalveillance.gouv.fr
• RFC 7489, DMARC
• Configurer DMARC dans Microsoft Defender pour Office 365
• Qu’est-ce qu’un enregistrement DNS DMARC ?, Cloudflare
• Que sont les normes DMARC, DKIM et SPF ?, Cloudflare
• Implement a Gradual DMARC Policy, DNSimple
• When to move from p=none to quarantine or reject
• How to safely transition your DMARC policy to quarantine or reject
• Guide rapide sur la configuration du courrier électronique, Centre canadien pour la cybersécurité

Recommandations

• Alignement DMARC : comprendre SPF, DKIM et le domaine From
• Politique DMARC : que définir avant de développer l’envoi