Comment configurer DMARC : guide complet de configuration étape par étape (2026)

Les fournisseurs de messagerie ne considèrent plus la mise en place du protocole DMARC comme une mesure de sécurité « facultative ». Alors que Gmail, Yahoo et Microsoft imposent désormais des exigences d’authentification plus strictes, les entreprises qui n’ont pas mis en œuvre le protocole DMARC s’exposent à un rejet définitif de leurs messages, à une recrudescence des attaques par usurpation d’identité et à des problèmes de conformité.

Dans ce guide, vous apprendrez à configurer DMARC à partir de zéro, à valider vos paramètres SPF DKIM, à publier un enregistrement DMARC conforme et à passer progressivement du mode de surveillance à l'application complète. Nous aborderons également les dernières mises à jour de la norme RFC 9989, les erreurs de configuration courantes et des conseils pratiques de dépannage pour vous aider à déployer DMARC en toute confiance.

À la fin de ce guide de configuration DMARC, vous disposerez d'une feuille de route claire pour sécuriser votre domaine contre les attaques par usurpation d'identité, tout en garantissant que les e-mails légitimes continuent d'arriver dans la boîte de réception.

Conformité 2026 : l'application de la réglementation est désormais effective

Gmail et Yahoo (novembre 2025) : la mise en œuvre définitive du rejet 5xx est désormais effective pour les expéditeurs en masse (plus de 5 000 e-mails par jour). Les messages non conformes sont définitivement rejetés, et non simplement filtrés.

Microsoft Outlook (mai 2025) : application des protocoles SPF, DKIM et DMARC. Les e-mails non conformes risquent d'être mis en attente ou rejetés.

PCI DSS v4.0 (mars 2025) : mesures de lutte contre le phishing obligatoires pour toutes les entités traitant des données de cartes de paiement.

• CISA BOD 18-01 : Toutes les agences fédérales américaines doivent mettre en œuvre le protocole DMARC avec la politique « p=reject ».
• Consultez l'ensemble des exigences : Exigences DMARC mondiales et régionales

Qu'est-ce que le DMARC et comment fonctionne-t-il ?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) est un protocole d'authentification des e-mails qui permet aux propriétaires de domaines d'indiquer aux serveurs de messagerie destinataires comment traiter les messages qui échouent aux contrôles d'authentification SPF DKIM. En termes simples, il empêche des tiers d'usurper votre domaine et indique aux destinataires comment gérer les imposteurs.

DMARC s'appuie sur deux protocoles existants, SPF DKIM. Ensemble, ces trois protocoles constituent le fondement de la sécurité moderne des e-mails.

DMARC, SPF et DKIM : comment ils fonctionnent ensemble

SPF Sender Policy Framework) définit quels serveurs de messagerie sont autorisés à envoyer des e-mails depuis votre domaine. Il s'agit d'un enregistrement DNS qui précise : « Seules ces adresses IP peuvent envoyer des e-mails prétendant provenir de example.com. »

Le protocole DKIM (DomainKeys Identified Mail) applique une signature cryptographique à vos e-mails. Celle-ci atteste que le message provient bien de vous et qu’il n’a pas été modifié pendant son acheminement. La signature est vérifiée à l’aide d’une clé publique publiée dans votre DNS.

DMARC fait le lien entre ces éléments. Il stipule : « Voici ma politique. Si un e-mail prétend provenir de mon domaine, il doit respecter les règles SPF DKIM. En cas d’échec, voici ce que je souhaite que vous fassiez : rien (surveillance uniquement), quarantine transfert vers le dossier spam) ou rejet (blocage total). »

Pour en savoir plus sur les protocoles DMARC, SPF DKIM, consultez notre guide complet.

Que se passe-t-il lorsqu'un e-mail ne respecte pas les règles DMARC ?

Lorsqu'un destinataire reçoit un e-mail prétendant provenir de votre domaine, il le compare à votre politique DMARC. Le résultat dépend de votre politique :

• p=none (suivi) : l'e-mail est envoyé quel que soit le résultat. Vous recevez un rapport indiquant les éléments qui ont réussi et ceux qui ont échoué.
• quarantine: les e-mails jugés indésirables sont envoyés dans le dossier « spam » ou « courrier indésirable ». Les e-mails légitimes continuent d'arriver.
• p=reject : les e-mails non remis sont rejetés d'emblée. L'expéditeur reçoit un message de retour.

Avant de configurer DMARC : conditions préalables et inventaire des expéditeurs

De nombreuses entreprises se précipitent pour déployer DMARC et passent rapidement au paramètre « p=reject », pour finalement se rendre compte que des expéditeurs légitimes (CRM, ESP, service d'assistance, plateformes d'automatisation du marketing) sont bloqués. Cette section vous guide tout au long du processus d'audit afin d'éviter cette erreur coûteuse.

Étape 1 : Vérifiez que SPF bien publié pour votre domaine

Pour que DMARC puisse fonctionner, votre domaine doit disposer d'un SPF valide dans le DNS.

1. Utilisez notre SPF pour vous assurer que votre SPF existe bien.

2. Vérifiez qu'il n'existe qu'un seul enregistrement SPF pour votre domaine. La présence de deux SPF rend SPF inopérant, SPF les destinataires les ignoreront tous les deux.

3. L'entrée doit ressembler à ceci : v=spf1 include:sendgrid.net include:mailchimp.com ~all

Si SPF pas publié ou s'il existe deux enregistrements en conflit, corrigez ce problème avant de continuer. Utilisez dès maintenant notre outil gratuit pour créer votre SPF .

Étape 2 : Vérifier la limite de SPF

SPF un maximum de 10 requêtes DNS par évaluation de message. Chaque expéditeur tiers que vous autorisez (via la directive « include: ») utilise entre 1 et 3 de ces requêtes. Le dépassement de cette limite entraîne SPF pour certains expéditeurs.

1. Utilisez notre outil « SPF » pour vérifier le nombre de requêtes SPF votre SPF

2. Comptez le nombre de requêtes DNS nécessaires. Si ce nombre approche ou dépasse 10, un message d'erreur s'affichera.

3. Si vous dépassez la limite, optimisez votre enregistrement afin de regrouper les requêtes en remplaçant les instructions « include: » par des adresses IP explicites. Il s'agit d'un obstacle courant pour les grandes entreprises comptant de nombreux expéditeurs tiers.

Étape 3 : Vérifier que DKIM est configuré pour tous les expéditeurs

DKIM est une exigence imposée par Google, Yahoo et Microsoft aux expéditeurs de courriers en masse ; ce n'est pas facultatif.

1. Pour votre domaine principal : utilisez notre outil gratuit de vérification DKIM pour vous assurer que votre enregistrement DKIM est bien publié.

2. Pour chaque expéditeur tiers (Salesforce, HubSpot, Klaviyo, etc.) : vérifiez qu’il a activé la signature DKIM et publié sa clé publique sous forme d’enregistrement DNS. Pour cela, il faut généralement demander au fournisseur d’« activer le DKIM personnalisé pour votre domaine ».

3. Chaque expéditeur doit disposer d'un sélecteur DKIM unique (par exemple : k1._domainkey.example.com, sendgrid._domainkey.example.com).

Si DKIM n'est pas configuré, configurez-le dès maintenant avant de passer à l'application de DMARC. Utilisez notre outil gratuit pour générer un enregistrement DKIM pour votre domaine.

Étape 4 : Recenser tous les expéditeurs d'e-mails tiers

Dressez la liste de tous les services qui envoient des e-mails depuis votre domaine :

• ESP (SendGrid, Mailchimp, Klaviyo, etc.)
• CRM (Salesforce, HubSpot, Pipedrive, etc.)
• Systèmes d'assistance (Zendesk, Freshdesk, etc.)
• Automatisation du marketing (Marketo, Pardot, ActiveCampaign, etc.)
• Plateformes d'e-mails transactionnels (Auth0, Stripe, AWS SES, etc.)
• Serveurs ou applications internes envoyant des notifications
• Services de transfert ou gestionnaires de listes de diffusion

Pour chaque expéditeur, vérifiez :

1. Ils respectent SPF (inclus dans votre SPF )
2. Ils respectent les règles DKIM (la signature DKIM est activée pour votre domaine)
3. Ils sont configurés pour utiliser votre domaine dans l'en-tête « De : »

Utilisez notre outil d'analyse des rapports DMARC pour détecter les expéditeurs non autorisés.

Étape 5 : Vérifier si un enregistrement DMARC existe déjà

Utilisez notre outil de vérification DMARC pour vérifier si votre domaine dispose déjà d'un enregistrement DMARC.

• Si vous voyez « p=none » : votre domaine est en mode surveillance. Ce guide vous aide à passer en toute sécurité au mode d'application.
• Si vous remarquez des balises obsolètes (pct=, rf=, ri=) : celles-ci ne font plus partie de la norme RFC 9989 et doivent être supprimées lors de votre prochaine modification de la fiche.
• Si aucun enregistrement n'a été trouvé : vous partez de zéro. Passez à la section suivante.

Comment configurer DMARC : étape par étape

Étape 1 : Générer un enregistrement DMARC

Utilisez notre outil « DMARC Generator » pour créer votre enregistrement initial.

Champs obligatoires :

• Nom de domaine : votre nom de domaine (par exemple, example.com)
• Politique : Démarrer avec p=none (mode surveillance, pas d'application)
• Adresse de réception des rapports : adresse e-mail à laquelle vous souhaitez recevoir les rapports récapitulatifs (par exemple, [email protected])

Ajouts recommandés :

• np=reject : protège les sous-domaines inexistants contre l'usurpation d'identité (nouveauté de la RFC 9989, coût nul)
• Adresse rua : destination du rapport agrégé (essentiel pour le suivi)

Exemple d'enregistrement initial :

v=DMARC1 ; p=none ; np=reject ; rua=mailto:[email protected]

Cet enregistrement indique aux destinataires : « Surveillez les e-mails provenant de mon domaine et envoyez-moi des rapports quotidiens, mais ne bloquez encore rien. »

Étape 2 : Comprendre votre enregistrement DMARC avant sa publication

Un enregistrement DMARC est une chaîne de paires « balise-valeur » séparées par des points-virgules. Seules les balises v= et p= sont obligatoires ; toutes les autres sont facultatives, mais recommandées. Avant de publier votre enregistrement, assurez-vous de bien comprendre le rôle de chaque balise :

Étiquettes obligatoires

Étiquette	Description et règlement
v = (version)	• Valeur : Toujours v=DMARC1 • Doit être la première balise de l'enregistrement • Il n'y a qu'une seule valeur valide
p = (politique)	• Valeurs : none, quarantine, ou reject • Indique aux destinataires comment traiter les e-mails qui ne passent pas les contrôles DMARC • Consultez le tableau des garanties ci-dessous pour connaître les différences

Balises facultatives

np = (politiques de sous-domaines inexistantes)

• Valeurs : aucune, quarantine ou rejet
• Applique une politique aux sous-domaines qui ne disposent pas d'un enregistrement DMARC
• Protège contre l'usurpation de sous-domaines aléatoires (par exemple, random123.example.com)
• Recommandation : définissez « np=reject » pour tous les domaines. Cela ne coûte rien et permet de combler une faille d'usurpation d'identité.

rua= (adresse de référence pour les rapports globaux)

• Format : rua=mailto:[email protected]
• Il est possible d'indiquer plusieurs adresses séparées par des virgules : rua=mailto:[email protected],mailto:[email protected]
• Les rapports agrégés sont des résumés au format XML envoyés quotidiennement par les récepteurs
• C'est essentiel pour la surveillance. Sans cela, vous n'avez aucune visibilité sur votre flux de messagerie.

sp= (politique de sous-domaine)

• Valeurs : aucune, quarantine ou rejet
• Applique une politique aux sous-domaines disposant d'un enregistrement DMARC
• Si aucune valeur n'est spécifiée, la politique principale est appliquée (p=)
• À utiliser lorsque vous souhaitez appliquer des règles plus strictes aux sous-domaines (par exemple, mail.example.com)

fo = (options de signalement des défaillances)

• Valeurs : 0 (par défaut), 1, d, s ou des combinaisons (0:1:d:s)
• Détermine à quel moment les rapports d'analyse (de défaillance) sont envoyés
• fo=0 : ne générer des rapports que si tous les mécanismes d'authentification échouent
• fo=1 : Générer des rapports en cas d'échec d'un mécanisme d'authentification (sortie plus détaillée, utile pendant la phase de configuration)
• Généralement utilisé avec la balise « ruf= » (voir ci-dessous)
• Recommandation : utilisez la valeur fo=1 lors de la configuration initiale afin de détecter toutes les erreurs ; passez à fo=0 une fois que vous êtes sûr de votre alignement.

adkim= (mode d'alignement DKIM)

• Valeurs : r (assoupli, par défaut) ou s (strict)
• Condition assouplie : le domaine et le domaine signé par DKIM appartiennent à la même organisation (par exemple, mail.example.com et example.com correspondent).
• Strict : les domaines doivent correspondre exactement
• Recommandation : commencez par utiliser adkim=r (mode assoupli). Ne passez au mode strict qu’une fois que vous maîtrisez toutes les sources de signature.

aspf= (modeSPF )

• Valeurs : r (assoupli, par défaut) ou s (strict)
• Simplifié : lorsque le domaine et le domaine SPF correspondent au domaine de l'organisation
• Strict : les domaines doivent correspondre exactement
• Recommandation : commencez par utiliser « aspf=r ». Ne passez au mode « strict » qu’une fois que vous maîtrisez toutes les sources d’envoi.

t = (mode test)

• Valeurs : y (mode test activé) ou omis (mode test désactivé)
• Lorsque la valeur est définie sur t=y, cela indique aux récepteurs d'appliquer votre politique à un niveau inférieur
• quarantine; t = y se comporte comme si p = aucun pour les destinataires
• p = rejet ; t = y se comporte comme p =quarantine les destinataires
• Il s'agit du remplacement de la balise pct=, désormais obsolète.
• À utiliser lors du passage à une politique plus stricte : publier avec t=y, surveiller les rapports, puis supprimer t=y pour appliquer la politique

ruf= (adresse du rapport d'expertise)

• Format : ruf=mailto:[email protected]
• Envoie en temps réel des copies des messages dont l'authentification a échoué
• Remarque importante : Google, Microsoft et Yahoo n'envoient plus de rapports d'analyse (conformément à la norme RFC 9989). Vous pouvez inclure cette balise en toute sécurité, mais elle ne générera pas de rapports de la part des principaux destinataires.
• À inclure uniquement si vous disposez d'un système automatisé pour traiter les rapports d'expertise

Balises obsolètes et supprimées (RFC 9989)

Ces balises faisaient partie de la RFC 7489, mais ne figurent plus dans la norme. Ne les ajoutez pas aux nouveaux enregistrements. Si elles apparaissent dans des enregistrements existants, supprimez-les lors de votre prochaine modification du DNS.

pct=

• Servait à appliquer une règle à un pourcentage des messages ayant échoué
• A donné des résultats inégaux selon les récepteurs
• Remplacement : utiliser « t=y » pour un déploiement progressif à la place
• Si cette information figure toujours dans les anciens enregistrements, elle sera ignorée par les récepteurs conformes à la norme RFC 9989.

rf=

• La balise de format du rapport d'échec (qui n'a jamais pris qu'une seule valeur : afrf)
• Supprimé car les rapports modernes utilisent un mécanisme différent

ri=

• L'intervalle de rapport était-il
• Supprimé car les intervalles de déclaration sont désormais harmonisés

Étape 2 : Connectez-vous à votre fournisseur de services DNS

Connectez-vous à votre console de gestion DNS (GoDaddy, Cloudflare, Namecheap, cPanel, Route 53, etc.).

Étape 3 : Ajouter l'enregistrement DMARC via votre fournisseur DNS

Recherchez l'option permettant d'ajouter un nouvel enregistrement TXT, copiez-collez la valeur indiquée par l'outil, puis cliquez sur l'icône « Enregistrer ».

La procédure est la même chez tous les fournisseurs : ajoutez un nouvel enregistrement TXT, attribuez-lui le nom « _dmarc », collez votre enregistrement dans le champ « Valeur », puis enregistrez. Vous trouverez dans le tableau ci-dessous les chemins d'accès spécifiques à chaque fournisseur ainsi que les pièges les plus courants pour chacun d'entre eux.

Étape 5 : Attendre la propagation des enregistrements DNS

La propagation des modifications DNS peut prendre jusqu'à 48 heures à l'échelle mondiale, mais la plupart des fournisseurs DNS assurent cette propagation en 1 à 2 heures. Pour suivre la propagation en temps réel, vous pouvez utiliser notre outil de vérification de la propagation DNS. Il vous suffit de saisir votre nom de domaine et de rechercher l'enregistrement TXT _dmarc.

Étape 6 : Vérifiez que votre configuration DMARC est bien opérationnelle

Une fois la propagation DNS terminée, vérifiez votre enregistrement à l'aide de notre outil DMARC Checker.

1. Saisissez votre nom de domaine
2. Cliquez sur « Recherche »
3. Vous devriez voir s'afficher votre enregistrement avec toutes les balises analysées
4. Si l'outil de vérification affiche le message « Enregistrement DMARC détecté » pour votre politique, cela signifie que celle-ci est active.

Si vous constatez des erreurs ou si l'enregistrement n'apparaît toujours pas au bout de 48 heures, vérifiez que votre entrée DNS ne comporte pas d'erreurs de syntaxe ou de configuration.

Configuration de DMARC conformément à la norme RFC 9989 – Quels changements en 2026 ?

En mai 2026, l'IETF a publié la RFC 9989, qui remplace la RFC 7489 en tant que norme officielle DMARC. Vos enregistrements v=DMARC1 existants restent pleinement valides ; aucune migration d'urgence n'est donc nécessaire. Toutefois, trois changements concernent toute personne configurant DMARC aujourd'hui.

Ce que la RFC 9989 implique pour votre configuration DMARC

1. pct= est désormais obsolète

La balise « pct= » servait à appliquer une politique à un pourcentage de messages rejetés. Elle donnait des résultats incohérents d'un destinataire à l'autre et ne fait plus partie de la norme.

Action : Supprimez « pct= » de tous les nouveaux enregistrements. Si des enregistrements plus anciens contiennent cette mention, supprimez-la lors de votre prochaine modification du DNS. Les destinataires l'ignoreront, mais cela prête à confusion.

2. « np= » est une nouveauté

La balise `np=` (politique relative aux sous-domaines inexistants) vous permet de protéger les sous-domaines qui n'existent pas. Les pirates peuvent usurper des sous-domaines aléatoires (par exemple, random123.example.com) pour contourner les vérifications DMARC. La configuration `np=reject` comble cette faille sans aucun coût.

Action : cette option est facultative, mais vous pouvez choisir de l'ajouter à tous les nouveaux enregistrements.

3. « t=y » est la nouvelle approche pour mettre en œuvre les changements de politique

La balise `t=y` indique aux récepteurs d'appliquer votre politique à un niveau inférieur à celui déclaré. Cela vous permet de tester une politique plus stricte avant de vous engager à l'appliquer.

• quarantine; t = y se comporte comme si p = aucune (les destinataires ne quarantine pas quarantine; ils transmettent et signalent)
• p = rejet ; t = y se comporte commequarantine les destinataires quarantine de rejeter)

Action : lors du passage de p=none àquarantine p=reject, utilisez d'abord t=y. Surveillez les rapports pendant 1 à 2 semaines. Une fois que vous êtes sûr de votre choix, supprimez t=y pour que la règle s'applique.

Comment utiliser « t=y » pour un déploiement progressif

Voici le déroulement précis des opérations :

1. Situation actuelle :

v=DMARC1 ; p=none ; np=reject ; rua=mailto:[email protected]

2. Lorsque vous êtes prêt à tester quarantine, publiez :

v=DMARC1 ;quarantine; t=y ; np=rejet ;quarantine; rua=mailto:[email protected]

Les destinataires considèrent cela comme « p = none » : ils transmettent l'intégralité des données et établissent un rapport. Vous observez la situation pendant 1 à 2 semaines.

3. Vérifiez qu'aucun e-mail légitime n'a été affecté, puis supprimez « t=y » pour appliquer la modification :

v=DMARC1 ;quarantine; np=rejet ;quarantine; rua=mailto:[email protected]

4. Désormais, les e-mails indésirables sont redirigés vers le dossier « Spam », tandis que les e-mails légitimes ne sont pas affectés.

5. Lorsque vous êtes prêt à tester la politique de rejet, publiez :

v=DMARC1 ; p=reject ; t=y ; np=reject ; sp=reject ; rua=mailto:[email protected]

6. Les destinataires considèrent cela commequarantine. Vous devez observer la situation pendant 1 à 2 semaines.

7. Exécution finale : Supprimer t=y :

v=DMARC1 ; p=reject ; np=reject ; sp=reject ; rua=mailto:[email protected]

8. Le rejet total est désormais activé.

Si un problème survient à n'importe quelle étape : supprimez t=y, revenez au niveau de politique précédent, corrigez l'expéditeur défaillant, puis recommencez.

Comment faire évoluer votre politique DMARC en toute sécurité

La plupart des échecs liés à DMARC sont dus au fait que les organisations passent directement au paramètre « p=reject » sans avoir préalablement vérifié leur flux de messagerie. Les e-mails légitimes sont bloqués, les utilisateurs se plaignent et le propriétaire du domaine revient en arrière, pris de panique. Cette section vous explique la bonne approche à adopter : un déploiement en trois phases qui s'appuie sur des rapports agrégés pour renforcer la confiance avant chaque étape.

Remarque : la RFC 9989 stipule explicitement que les destinataires doivent traiter « p=reject » commequarantine les flux de messagerie indirects (transfert, listes de diffusion). Pour les domaines dont les utilisateurs participent à des listes de diffusion,quarantine la politique d'application permanente la plus sûre. Pour les domaines purement transactionnels ou exclusivement dédiés au marketing, ne comportant aucune boîte aux lettres utilisateur, « p=reject » est approprié.

Phase 1 : Surveillance (p = aucune)

Durée : 2 à 4 semaines minimum. Plus longue pour les environnements d'envoi complexes (10 expéditeurs tiers ou plus).

Voici à quoi ressemble votre dossier :

v=DMARC1 ; p=none ; np=reject ; rua=mailto:[email protected]

Ce qu'il faut faire :

1. Publier l'enregistrement ci-dessus

2. Attendez que les destinataires envoient leurs rapports agrégés (ce qui commence généralement dans un délai de 24 à 48 heures)

3. Utilisez notre outil d'analyse des rapports DMARC pour consulter les rapports quotidiens

4. Recherchez :

• Toutes les sources d'origine connues figurant dans les rapports
• Taux de réussite SPF DKIM pour chaque expéditeur
• Tout expéditeur inconnu que vous ne reconnaissez pas
• État de la conformité (vos expéditeurs sont-ils conformes ou non ?)

Quand avancer :

• Tous les expéditeurs légitimes sont conformes aux normes SPF DKIM
• Pas de sources inconnues dans les rapports
• Vous avez recueilli des données cohérentes pendant au moins deux semaines
• Vous avez corrigé tous les expéditeurs présentant des problèmes

Si vous découvrez les rapports DMARC, consultez notre guide intitulé « Comment lire les rapports DMARC » pour obtenir des explications simples et claires.

Phase 2 : Quarantine p =quarantine)

Durée : 1 à 2 semaines en mode test (t=y), puis en continu.

Étape A : Test avec t = y (simulation)

Publier :

v=DMARC1 ;quarantine; t=y ; np=rejet ;quarantine; rua=mailto:[email protected]

Lorsque t = y, les récepteurs appliquent la politique au niveau inférieur : quarantine comme si elle n'existait pas. Les e-mails en échec sont tout de même remis ; vous recevez simplement des rapports indiquant ce qui aurait dû être mis en quarantaine.

Surveillez la situation pendant 1 à 2 semaines. Consultez les rapports et surveillez votre boîte de réception. Recherchez :

• On continue de recevoir des e-mails légitimes
• Rapports d'échec indiquant quels expéditeurs seraient concernés
• Taux habituels de signalement de spam

Étape B : Appliquer (supprimer t=y)

Une fois que vous êtes sûr de vous, supprimez t=y :

v=DMARC1 ;quarantine; np=rejet ;quarantine; rua=mailto:[email protected]

Désormais, les e-mails en échec sont redirigés vers le dossier « Spam ». Les e-mails légitimes continuent d'arriver normalement.

Suivi continu :

• Examiner les rapports globaux chaque semaine
• Vérifier le dossier « Spam » pour repérer les e-mails légitimes
• Si des expéditeurs légitimes commencent à rencontrer des problèmes : repassez immédiatement à p=none, corrigez le problème d'alignement, puis recommencez la progression

Remarque concernant l'éligibilité au BIMI : si vous souhaitez utiliser le BIMI (Brand Indicators for Message Identification) pour afficher votre logo dans Gmail, vous devez avoirquarantine p=reject. Le paramètre p=none n'est pas éligible. Cela rend d'autant plus urgent de faire évoluer cette politique. Voici comment activer le BIMI pour votre domaine.

Phase 3 : Rejet (p = rejet)

Durée : 1 à 2 semaines avec t=y, puis en continu.

Étape A : Test avec t = y (simulation)

Publier :

v=DMARC1 ; p=reject ; t=y ; np=reject ; sp=reject ; rua=mailto:[email protected]

Lorsque t = y, les destinataires considèrent les messages rejetés comme étant quarantine. Les e-mails non livrables sont envoyés dans le dossier « spam », et non rejetés d'emblée. Surveillez la situation pendant 1 à 2 semaines.

Étape B : Appliquer (supprimer t=y)

v=DMARC1 ; p=reject ; np=reject ; sp=reject ; rua=mailto:[email protected]

Désormais, les e-mails qui ne parviennent pas à leur destinataire sont purement et simplement rejetés. L'expéditeur reçoit un message de rejet.

Recommandations politiques :

• Si votre domaine comporte des boîtes aux lettres humaines dont les utilisateurs figurent sur des listes de diffusion (NAR, MLS, listes d'associations, etc.), utilisez «quarantine politique d'application.
• Si votre domaine est exclusivement transactionnel (SaaS, paiements, fintech, e-mails marketing sans boîtes mail d'utilisateurs) : utilisez p=reject.

Dépannage de la configuration DMARC : problèmes courants et solutions

Problème n° 1 : « Aucun enregistrement DMARC trouvé » lors de la vérification

Pourquoi cela se produit-il ? La propagation DNS n'est pas encore terminée, ou vous avez saisi un nom d'hôte incorrect.

Comment y remédier ?

1. Attendez entre 24 et 72 heures après la publication
2. Vérifiez bien que le nom d'hôte est exactement _dmarc (et non _dmarc.votredomaine.com comme c'est le cas dans certains outils ; vérifiez auprès de votre fournisseur)
3. Utilisez notre outil de vérification de la propagation DNS pour vérifier l'état de la propagation
4. Réessayez notre outil de vérification DMARC

Problème n° 2 : SPF DKIM non alignés

Pourquoi cela se produit-il ? Le domaine figurant dans l'en-tête « De : » ne correspond pas au domaine authentifié par SPF DKIM.

Exemple d'échec :

• L'en-tête indique comme expéditeur [email protected]
• Le domaine SPF est mail.otherdomain.com
• Le domaine de signature DKIM est newsletter.anotherdomain.com
• Résultat : aucune correspondance. Échec de la validation DMARC.

Comment y remédier ?

1. Commencez par définir un alignement souple (adkim=r ; aspf=r) dans votre enregistrement. Cela permet les correspondances de sous-domaines.

2. Utilisez notre outil de vérification DKIM pour vérifier le domaine de signature de chaque expéditeur

3. Utilisez notre SPF pour vérifier que chaque expéditeur SPF

4. Pour chaque expéditeur dont l'envoi a échoué, demandez au fournisseur de configurer le domaine. Par exemple :

• « Veuillez activer la signature DKIM pour le domaine example.com (et non un sous-domaine) »
• « Veuillez utiliser example.com comme domaine dans le champ Return-Path/envelope-from »

5. Une fois que tous les expéditeurs ont été validés avec l'alignement « relaxed », vous pouvez passer à l'alignement « strict » (adkim=s ; aspf=s) si vous le souhaitez

Problème n° 3 : échec de l'authentification d'un expéditeur tiers

Pourquoi cela se produit-il ? Un ESP, un CRM ou une plateforme marketing envoie des e-mails depuis votre domaine, mais n'est pas configuré dans votre SPF et/ou n'a pas activé le protocole DKIM.

Comment y remédier ?

En cas de SPF :

1. Récupérez SPF de l'expéditeur dans sa documentation (par exemple, include:sendgrid.net)

2. Ajoutez-le à votre SPF : v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. Testez-le avec notre outil « SPF »

En cas d'échecs DKIM :

1. Demandez au fournisseur d'activer le DKIM personnalisé pour votre domaine

2. Publiez la clé publique DKIM qu'ils vous fournissent (généralement au format : selector._domainkey.votredomaine.com)

3. Testez votre configuration avec notre outil de vérification DKIM

Problème n° 4 : plusieurs SPF ou nombre de requêtes SPF la limite de 10

1. Présence de plusieurs SPF : la présence de deux enregistrements SPF sur un même domaine rend SPF inopérant, et les destinataires ignoreront les deux.

Comment y remédier : fusionnez vos SPF en un seul, car vous ne pouvez avoir qu'un seul enregistrement SPF par domaine.

Exemple :

• Ancien enregistrement 1 : v=spf1 include:sendgrid.net ~all
• Ancien enregistrement 2 : v=spf1 include:mailchimp.com ~all
• Nouvel enregistrement fusionné : v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. Plus de 10 requêtes DNS : chacune d'entre elles peut nécessiter entre 1 et 3 requêtes DNS. Si vous dépassez ce nombre de 10, SPF pour certains expéditeurs.

Comment y remédier : utilisez notre SPF hébergé SPF optimiser dynamiquement votre enregistrement. Cela permet de remplacer les instructions « include: » par des adresses IP explicites, ce qui réduit le nombre de requêtes de recherche.

Exemple :

• Avant (plus de 10 requêtes) : v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• Après optimisation : v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

Problème n° 5 : des e-mails légitimes finissent dans le dossier « Spam » après avoir été misquarantine

Pourquoi cela se produit : vous êtes passé à l'étape «quarantine vous être assuré que tous les expéditeurs légitimes avaient passé l'authentification.

Comment y remédier ?

1. Revenir immédiatement à p=none
2. Consultez vos rapports globaux pour identifier l'expéditeur qui présente des problèmes
3. Corriger leur authentification (alignementSPF DKIM)
4. Revenir àquarantine effectuer un test avec t=y et surveiller la situation pendant 1 à 2 semaines avant d'appliquer la mesure.

Problème n° 6 : erreurs de syntaxe dans les enregistrements DMARC

Pourquoi cela se produit-il ? Faute de frappe dans l'enregistrement, points-virgules manquants ou balises non prises en charge

Comment y remédier ?

1. Vérifiez-le à l'aide de notre outil de vérification DMARC, car celui-ci mettra en évidence les erreurs de syntaxe.
2. Utilisez notre générateur DMARC pour recréer l'enregistrement plutôt que de le modifier manuellement
3. Copiez l'enregistrement généré et collez-le chez votre fournisseur DNS

En conclusion

Une configuration correcte du protocole DMARC n'est plus une simple option. L'application systématique du rejet par Gmail, les exigences de Yahoo et de Microsoft, les recommandations de la norme PCI DSS v4.0 et la directive CISA BOD 18-01 font toutes du protocole DMARC une nécessité en matière de conformité.

La méthode la plus sûre et la plus fiable consiste à avancer progressivement, à effectuer des vérifications en continu et à appliquer les mesures de manière responsable. Mais si vous souhaitez une gestion DMARC plus rapide et plus simple, avec un traitement automatisé des rapports, un suivi de la conformité et une assistance continue, envisagez une plateforme DMARC hébergée telle que PowerDMARC, qui se charge de la configuration, de la mise à l'échelle et de l'application des mesures, afin que vous puissiez vous concentrer sur la sécurité. Commencez votre essai gratuit dès aujourd'hui ou réservez une démonstration pour sécuriser votre domaine dès maintenant.

Foire aux questions

Combien de temps prend la configuration DMARC ?

La configuration initiale des enregistrements DNS ne prend que quelques minutes. La propagation DNS peut prendre jusqu'à 72 heures (généralement 1 à 2 heures). La mise en œuvre complète (pour atteindre le niveau « p=reject » avec certitude) prend généralement entre 4 et 8 semaines, en fonction du nombre de sources d'envoi et de la rapidité avec laquelle les problèmes d'alignement sont résolus.

La configuration du protocole DMARC a-t-elle une incidence sur la délivrabilité des e-mails ?

Lorsque p = none, l'impact sur la délivrabilité est nul, car le mode de surveillance n'entraîne aucune mesure coercitive. Lorsquequarantine p = reject, seuls les e-mails non authentifiés et non conformes sont concernés. Les e-mails correctement authentifiés ne sont pas affectés et bénéficient souvent d'une meilleure délivrabilité. Le protocole DMARC peut améliorer le placement dans la boîte de réception à long terme en établissant la réputation du domaine auprès des fournisseurs de messagerie.

Comment configurer DMARC pour plusieurs domaines ?

Lorsque vous configurez DMARC pour plusieurs domaines, n’oubliez pas que chaque domaine doit disposer de son propre enregistrement TXT DMARC à l’adresse _dmarc.[domaine].

Exemple :

• Domaine 1 : enregistrement TXT de _dmarc.example.com
• Domaine 2 : enregistrement TXT de _dmarc.example.org

Pour les organisations qui gèrent un grand nombre de domaines, une plateforme DMARC hébergée permet de gérer tous les enregistrements à partir d'un seul tableau de bord, ce qui facilite la mise à l'échelle.

Qu'est-ce que l'alignement DMARC ?

L'alignement signifie que le domaine figurant dans l'en-tête « From: » doit correspondre au domaine authentifié par SPF DKIM. L'alignement assoupli (par défaut, adkim=r ; aspf=r) autorise les correspondances de domaine au niveau de l'organisation, tandis que l'alignement strict (adkim=s ; aspf=s) exige des correspondances exactes.

• À propos de
• Derniers messages

Maitham Al Lawati

Expert en cybersécurité, PDG de PowerDMARC

Maitham est un entrepreneur technologique, expert en cybersécurité, PDG et fondateur de PowerDMARC avec plus de 15 ans d'expérience dans l'industrie. Maitham est titulaire d'un Global MBA de l'Université de Manchester et de diverses certifications professionnelles, notamment CISSP, CISM, CRISC et ISC2 CCSP.

Derniers messages de Maitham Al Lawati (voir tous)

• Comment configurer DMARC : guide complet de configuration étape par étape (2026) - 20 juin 2026
• Comment lire les rapports DMARC : guide complet sur les indicateurs RUA et RUF - 10 juin 2026
• Qu'est-ce que le DMARC ? Définition, fonctionnement et importance - 28 avril 2026