DMARC (Domain-based Message Authentication, Reporting & Conformance) aide à protéger votre domaine contre l’usurpation d’identité et le phishing. Il peut aussi améliorer votre délivrabilité en prouvant aux fournisseurs d’email que vos emails sont légitimes.

Ce que vous allez apprendre

À la fin de ce guide, vous saurez publier un enregistrement DMARC dans votre configuration DNS, choisir une politique adaptée (quarantine ou reject) et gérer les rapports DMARC pour renforcer progressivement votre réputation d’expéditeur.

Pourquoi c’est important

DMARC réduit le risque que des attaquants usurpent votre domaine, ce qui protège votre marque et vos destinataires. Il aide aussi les fournisseurs d’email (Gmail, Outlook, Yahoo, Apple Mail, AOL, entre autres) à faire confiance à votre domaine. Lorsque SPF et DKIM sont correctement configurés, cela augmente souvent les chances que vos emails arrivent en boîte de réception.

Prérequis recommandés

Vous avez déjà configuré SPF et DKIM pour le domaine que vous utilisez pour vos envois.
Vous avez accès aux paramètres DNS de votre domaine (GoDaddy, Cloudflare, Namecheap, IONOS, etc.).
Vous pouvez attendre que les modifications DNS se propagent (généralement quelques heures, parfois jusqu’à 48 heures selon les paramètres DNS et le TTL).

Configurer DMARC étape par étape

Partie 1 : choisir la bonne politique DMARC (notre recommandation)

Choisissez toujours une politique DMARC au moins aussi stricte que p=quarantine, jamais p=none.
Beaucoup publient p=none simplement pour avoir un enregistrement DMARC. Pourtant, les systèmes antispam traitent souvent cette politique, qui revient à « ne rien faire », comme une absence totale de politique DMARC.
Comprenez bien la différence entre mise en quarantaine et rejet.
- Mise en quarantaine : demande au serveur destinataire de ne pas placer le message en boîte de réception (il est généralement classé comme spam ou courrier indésirable) et d’effectuer des vérifications supplémentaires.
- Rejet : demande au serveur destinataire de refuser le message au moment de la remise (le message est renvoyé et l’expéditeur décide de la suite à donner).
Dans les deux cas, l’email n’arrive pas dans la boîte de réception du prospect. En théorie, l’effet sur le score est donc identique.
N’utilisez p=reject que si une personne (un postmaster) gère les rapports DMARC et que vous disposez des outils adaptés.
Lorsque vous publiez votre enregistrement DMARC, vous définissez aussi une adresse email pour recevoir les rapports DMARC (via rua=). L’application de la politique (surtout avec p=reject) peut entraîner un volume important de rapports. Ces rapports sont généralement complexes (fichiers XML contenus dans des archives) et difficiles à exploiter sans outil ou tableau de bord pour postmaster. Si vous ne souhaitez pas gérer les rapports DMARC, utilisez p=quarantine plutôt que p=reject.

Partie 2 : publier votre enregistrement DMARC dans les DNS

Accédez à l’interface de votre hébergeur DNS.
Ouvrez la section de gestion des DNS du domaine que vous utilisez pour envoyer vos emails.
Créez un nouvel enregistrement DNS.
- Type : TXT
- Nom / hôte : _dmarc
- TTL : 3600 (1 heure), sauf si votre hébergeur exige une autre valeur.
Renseignez la valeur de votre enregistrement DMARC.
Pour appliquer une politique DMARC en toute sécurité, utilisez cet exemple en remplaçant l’adresse email par une adresse que vous gérez :
```
v=DMARC1; p=quarantine; rua=mailto:[email protected]
```
Cet enregistrement indique aux fournisseurs d’envoyer des rapports agrégés (récapitulatifs) à l’adresse définie dans rua.
Sauvegardez l’enregistrement et attendez la propagation des modifications DNS.
Vérifiez votre configuration avec un outil de vérification DMARC (par exemple : MXToolbox, dmarcian ou EasyDMARC).

Partie 3 : renforcer la protection en toute sécurité (si vous êtes prêt)

Examinez les rapports jusqu’à être sûr que vos sources d’envoi légitimes sont bien alignées.
Une politique DMARC ne fonctionne bien que si vos services d’envoi légitimes réussissent systématiquement les contrôles SPF/DKIM et sont correctement alignés.
Ne passez de quarantine à reject qu’une fois la gestion des rapports en place.
Si vous avez un postmaster et un outil de gestion des rapports DMARC capables de gérer leur volume et leur complexité, vous pouvez passer à p=reject pour une protection maximale. Sinon, restez sur p=quarantine.

Exemple concret

Voici un exemple de déploiement pour limiter les risques tout en renforçant la protection :

Semaines 1 et 2 : publiez p=quarantine et vérifiez que tous vos expéditeurs légitimes (Google Workspace/Microsoft 365, votre CRM, l’infrastructure d’envoi liée à lemlist, les outils de support, etc.) s’authentifient correctement.
Semaine 3 : conservez p=quarantine et, si vous le souhaitez, appliquez la politique à une partie des emails avec pct=50, tout en surveillant les résultats.
À partir de la semaine 4 : passez à pct=100. Adoptez p=reject uniquement si vous avez mis en place un suivi avec un postmaster et les outils nécessaires pour gérer les rapports DMARC.

Exemples d’enregistrements DMARC

Exemple	Description
`v=DMARC1; p=quarantine; rua=mailto:[email protected]`	Politique minimale recommandée. Les emails qui échouent aux contrôles restent hors de la boîte de réception pendant que vous suivez les rapports.
`v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=50`	Mise en quarantaine appliquée à une partie des emails (pour limiter les risques si vous n’êtes pas sûr que tous les expéditeurs sont alignés).
`v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100`	Protection maximale. À utiliser uniquement si vous avez mis en place un suivi avec un postmaster et des outils pour gérer les rapports DMARC.

Problèmes courants et solutions

Problème : vous avez publié votre enregistrement DMARC, mais les outils de vérification ne le trouvent pas.

Cause : la propagation DNS n’est pas terminée, le nom ou l’hôte est incorrect, ou l’enregistrement a été créé sur le mauvais domaine.
Solution : vérifiez que l’enregistrement porte exactement le nom _dmarc sur le bon domaine, puis patientez et testez à nouveau avec un outil de vérification DMARC.

Problème : les rapports DMARC signalent des échecs pour des emails légitimes.

Cause : SPF ou DKIM est mal configuré pour un service d’envoi, ou l’alignement des identifiants est incorrect.
Solution : repérez la source d’envoi dans le rapport (IP/service), puis vérifiez que ce service est bien couvert par SPF et/ou signe les emails avec DKIM pour votre domaine.

Problème : vous êtes passé à p=reject et certains emails légitimes n’arrivent plus à destination.

Cause : les expéditeurs légitimes n’étaient pas tous authentifiés et alignés avant l’application de la politique.
Solution : revenez temporairement à p=quarantine (éventuellement avec pct=) le temps de corriger SPF/DKIM pour les sources qui échouent aux contrôles, puis rétablissez progressivement une politique plus stricte.

Problème : vous êtes submergé par les rapports XML.

Cause : les rapports agrégés DMARC sont généralement envoyés au format XML (souvent dans des fichiers d’archive) et peuvent être difficiles à exploiter lorsqu’ils sont nombreux.
Solution : utilisez un outil d’analyse des rapports ou un tableau de bord dédié (par exemple : dmarcian, Postmark DMARC ou EasyDMARC). Si vous n’avez pas mis en place de suivi avec un postmaster, privilégiez p=quarantine plutôt que p=reject.

Les politiques DMARC en bref

Politique	Effet	Quand l’utiliser
p=quarantine	Empêche les emails qui échouent aux contrôles d’arriver en boîte de réception (ils sont généralement classés comme spams ou courriers indésirables) et permet des vérifications supplémentaires.	Recommandée par défaut pour la plupart des domaines (niveau de protection minimal).
p=reject	Refuse, au moment de la remise, les emails qui échouent aux contrôles (protection maximale).	Uniquement si vous avez mis en place un suivi avec un postmaster et des outils pour gérer le volume et la complexité des rapports DMARC.
p=none	Ne demande aucune action de filtrage ; sert uniquement à recevoir des rapports.	Déconseillée. De nombreux systèmes antispam la traitent comme une absence de politique DMARC, car elle revient à demander de « ne rien faire ».

Astuce : utilisez p=quarantine comme politique de base. Ne passez à p=reject que si vous êtes prêt à gérer les rapports DMARC (postmaster et outils).

Comprendre les balises DMARC

Balise	Description
v=	Version (`DMARC1`).
p=	Politique (none, quarantine ou reject).
rua=	Destinataire des rapports agrégés (adresse à laquelle les rapports XML périodiques sont envoyés).
ruf=	Destinataire des rapports d’échec (détails sur chaque échec individuel).
pct=	Pourcentage d’emails auxquels la politique s’applique. Par défaut : 100.
aspf= / adkim=	Mode d’alignement SPF/DKIM (strict ou souple).
sp=	Politique applicable aux sous-domaines.
fo= / rf= / ri=	Options, format et fréquence des rapports.

Faites le point

Avez-vous publié votre enregistrement DMARC avec au minimum p=quarantine (et non p=none) ?
Savez-vous où sont envoyés vos rapports rua= et pouvez-vous les lire dans un tableau de bord DMARC ?
Avant de passer à p=reject, avez-vous mis en place un suivi avec un postmaster (et les outils nécessaires) pour gérer le volume et la complexité des rapports DMARC ?
Avez-vous vérifié que chaque outil ou service que vous utilisez pour envoyer des emails est couvert par SPF et/ou DKIM et respecte l’alignement DMARC ?