Vous avez mis en place DMARC en mode p=none il y a quelques mois — peut-être à l’occasion d’un audit, peut-être parce que Google et Yahoo l’ont exigé en 2024. Les rapports arrivent, mais vous n’avez toujours pas franchi le pas vers reject. Et pour une bonne raison : vous ne savez pas exactement ce que vous allez bloquer.

Cette hésitation est rationnelle. Passer en reject sur un domaine actif avec des dizaines de services d’envoi, sans inventaire précis, peut effectivement casser des flux légitimes. Mais rester en p=none indéfiniment signifie que votre politique DMARC ne protège rien — elle ne fait que collecter des informations.

Ce guide vous donne un plan structuré pour migrer de none à reject en maîtrisant chaque étape, avec des points de contrôle clairs et une procédure de rollback si nécessaire.

Avant de commencer, vérifiez l’état actuel de votre domaine avec notre test sécurité email — il analyse vos enregistrements SPF, DKIM et DMARC en quelques secondes.

Pourquoi passer en DMARC reject

Ce que p=none fait réellement : rien

Un enregistrement DMARC avec p=none demande aux serveurs destinataires d’analyser l’authentification des emails de votre domaine et d’envoyer des rapports — mais de ne prendre aucune mesure. Un attaquant qui envoie un email depuis contact@votreentreprise.fr verra ses messages délivrés normalement. La victime reçoit un email qui semble provenir de vous, avec votre adresse dans le champ « De ».

p=none est une phase d’observation, pas une protection. Son seul intérêt est de vous donner les données nécessaires pour passer à une politique active. Une fois que vous avez ces données et que vous avez corrigé vos sources légitimes, continuer en p=none revient à laisser une porte ouverte en sachant qu’elle est ouverte.

Pourquoi la majorité des domaines français restent bloqués en none

Selon les données de Dmarcian et du Global Cyber Alliance, environ 70 % des domaines qui publient un enregistrement DMARC restent en p=none. Pour les domaines d’entreprises françaises, l’ANSSI estime que seulement 15 à 20 % disposent d’une politique active (quarantine ou reject).

Les raisons sont récurrentes : peur de bloquer les emails de services tiers, inventaire des sources d’envoi jamais finalisé, changement de priorité avant la phase quarantine, ou simplement méconnaissance de la procédure de migration progressive.

Ce que reject apporte concrètement

Avec p=reject, tout email qui échoue l’alignement DMARC — c’est-à-dire un email prétendant venir de votre domaine mais qui ne passe ni SPF aligné ni DKIM aligné — est rejeté par le serveur destinataire avant d’être remis à l’utilisateur. Aucune notification dans la boîte, aucune chance que l’email soit ouvert.

C’est la seule politique qui bloque réellement le spoofing de votre domaine. Un attaquant qui envoie une campagne de phishing en se faisant passer pour votre direction via noreply@votreentreprise.fr se heurte à un mur. Ses emails n’arrivent pas.

Pour des entreprises dont les noms de domaine sont connus — et donc des cibles de valeur pour le spoofing — cette protection n’est pas optionnelle.

Les prérequis avant de commencer

Vous ne pouvez pas migrer vers reject sur une infrastructure d’authentification défaillante. Avant de toucher à la politique DMARC, vérifiez ces trois points.

SPF est en place et couvre toutes vos sources

Votre record SPF doit lister tous les services autorisés à envoyer des emails pour votre domaine. Vérifiez qu’il existe (un seul record TXT v=spf1 à la racine de votre domaine), qu’il se termine par -all, et que vous n’avez pas dépassé la limite de 10 lookups DNS.

Vérification rapide :

dig TXT votredomaine.fr | grep "v=spf1"

DKIM est activé sur tous vos services d’envoi

Chaque service d’envoi doit signer les emails avec une clé DKIM dont la clé publique est publiée en DNS sous votre domaine. Si un service envoie des emails sans DKIM sous votre domaine, il devra soit être retiré du SPF soit avoir DKIM configuré avant la migration.

Vérification via Gmail : envoyez un email de test, ouvrez-le, cliquez sur le menu ⋮ → « Afficher l’original » et cherchez dkim=pass pour votre domaine.

DMARC est en p=none avec le tag rua actif

Votre record DMARC doit inclure le tag rua= pour recevoir des rapports agrégés. Sans rapports, vous naviguez à l’aveugle.

_dmarc.votredomaine.fr  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr; fo=1"

Si vous n’avez pas de tag rua=, ajoutez-le maintenant et attendez au moins 4 semaines de données avant de continuer. Consultez notre guide configurer SPF, DKIM et DMARC pour les détails de configuration.

Utilisez notre test sécurité email pour vérifier ces trois prérequis en une fois.

Les blocages les plus fréquents

Pas de DKIM sur OVH MXplan. Les offres MXplan historiques d’OVH ne proposent pas DKIM. Si vous utilisez encore ces offres, vous devrez soit migrer vers OVH Exchange/Pro, soit configurer un relais SMTP externe qui signe en DKIM.

Record SPF dépassant 10 lookups. Comptez vos includes récursifs — Google Workspace en consomme 4 à lui seul. Si vous approchez de la limite, remplacez les includes de services stables par leurs adresses IP directes (ip4:) ou utilisez un service de SPF flattening.

Adresse rua= non fonctionnelle. Si la boîte mail de destination des rapports a changé, vous recevez des rapports dans le vide depuis des semaines. Testez en vous envoyant un email à cette adresse.

Étape 1 : Inventorier toutes vos sources d’envoi

C’est l’étape qui conditionne le succès de toute la migration. La raison numéro un pour laquelle des emails légitimes se retrouvent bloqués après un passage en reject est un service d’envoi oublié lors de l’inventaire.

Les catégories à couvrir systématiquement

Messagerie principale. Microsoft 365 ou Google Workspace pour les emails internes et externes. OVH Exchange pour les PME françaises. C’est généralement la source la mieux configurée.

Outils marketing. Mailchimp, Brevo (ex-Sendinblue), HubSpot, ActiveCampaign, Klaviyo. Tous envoient des emails depuis votre domaine. La plupart proposent DKIM nativement — encore faut-il l’avoir activé.

Emails transactionnels. Les notifications générées par vos applications : confirmations de commande Stripe, reçus de paiement, notifications d’abonnement. Ces services utilisent souvent des relais SMTP comme SendGrid, Postmark, Amazon SES ou Mailjet. L’équipe dev peut les avoir configurés indépendamment.

Helpdesk et support. Zendesk, Freshdesk, Intercom, ou Zoho Desk envoient des réponses au nom de votre domaine support@.

CRM. Salesforce, Pipedrive, ou HubSpot (pour ceux qui ne l’ont pas cité côté marketing) peuvent envoyer des emails de séquences commerciales depuis votre domaine.

Applications RH et paie. Lucca, Payfit, BambooHR, ou les notifications automatiques de votre SIRH. Ces systèmes passent souvent sous le radar car ils sont gérés par les RH plutôt que par la DSI.

Applications internes legacy. Un ERP qui envoie des alertes, un outil de monitoring qui notifie par email, une application métier qui génère des rapports automatiques. Souvent configurés avec un SMTP direct depuis un serveur interne ou un compte applicatif.

Comment constituer cet inventaire

Consultez les rapports DMARC existants — ils listent toutes les IPs qui envoient des emails avec votre domaine dans le From, qu’elles soient légitimes ou non.
Interrogez les équipes : dev (applications internes, relais SMTP transactionnels), marketing (campagnes, newsletters), RH (notifications SIRH), support (helpdesk).
Vérifiez votre record SPF actuel : chaque include: correspond à un service déclaré — est-il encore actif ? En manque-t-il ?

Documentez chaque source : nom du service, adresses IP ou domaines utilisés, mécanisme SPF actuel, statut DKIM (actif ou non).

Étape 2 : Analyser les rapports DMARC

Ce que contiennent les rapports RUA

Les rapports agrégés (tag rua=) sont des fichiers XML envoyés quotidiennement par les grands fournisseurs de messagerie (Gmail, Microsoft, Yahoo, Orange, etc.) pour chaque domaine depuis lequel ils reçoivent des emails. Chaque rapport liste les sources d’envoi observées avec pour chacune :

L’adresse IP du serveur expéditeur
Le résultat du contrôle SPF et l’alignement SPF (pass/fail)
Le résultat du contrôle DKIM et l’alignement DKIM (pass/fail)
La disposition appliquée (none/quarantine/reject selon la politique)
Le nombre d’emails observés sur la période

Un enregistrement typique en XML ressemble à ceci :

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>147</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

Ici, 147 emails envoyés depuis une IP Google avec DKIM aligné mais SPF non aligné — résultat global : pass DMARC (un seul des deux suffit).

Outils pour lire les rapports sans configuration serveur

Les fichiers XML bruts ne sont pas pratiques à analyser à la main. Trois outils gratuits permettent de les visualiser :

Postmark DMARC (app.dmarc.postmarkapp.com) — envoyez votre adresse rua= à leur service, ils analysent et vous envoient un résumé hebdomadaire par email. Zéro configuration.

Dmarcian (dmarcian.com) — interface web complète avec cartographie des sources d’envoi. Offre gratuite pour les petits volumes.

DMARC Analyzer de MxToolBox — outil en ligne pour analyser un rapport XML à la fois, utile pour le diagnostic ponctuel.

Interpréter les résultats

Pour chaque source d’envoi dans vos rapports, vous cherchez à répondre à une question : est-ce légitime ou frauduleux ?

Sources légitimes bien configurées : adresses IP que vous reconnaissez (serveurs Google, Microsoft, Brevo, etc.) avec dkim=pass ou spf=pass et alignement correct. Ces sources ne posent aucun problème pour la migration.

Sources légitimes mal configurées : adresses IP que vous reconnaissez mais avec dkim=fail et spf=fail ou un alignement incorrect. Ce sont vos chantiers de correction avant de passer en quarantine.

Sources frauduleuses : adresses IP que vous ne reconnaissez pas, généralement avec dkim=fail et spf=fail. Ce sont les tentatives de spoofing que DMARC reject va bloquer.

Concentrez-vous sur les sources avec un volume significatif (plus de quelques emails par semaine). Les sources à faible volume et IP inconnue peuvent être des scanners ou des tentatives isolées — elles sont moins prioritaires pour la correction.

Étape 3 : Corriger l’alignement

Pour chaque source légitime qui échoue l’alignement dans vos rapports, vous avez deux options : corriger la configuration pour qu’elle passe, ou exclure ce service de l’envoi sous votre domaine.

Comprendre l’alignement

L’alignement DMARC vérifie que le domaine dans le champ « From » visible par l’utilisateur correspond au domaine authentifié par SPF ou DKIM.

Alignement SPF : le domaine du Return-Path (enveloppe de l’email) doit correspondre au domaine du From. En mode relaxé (défaut), les sous-domaines sont acceptés.
Alignement DKIM : le domaine du tag d= dans la signature DKIM doit correspondre au domaine du From.

Un email n’a besoin de passer qu’un seul alignement pour satisfaire DMARC. Si DKIM est aligné, l’échec SPF ne compte pas.

Corrections courantes par service

Microsoft 365. Si DKIM n’est pas activé pour votre domaine personnalisé, activez-le depuis Microsoft Defender → Stratégies → Email authentication settings → DKIM. Publiez les deux enregistrements CNAME fournis. Vérifiez que la signature apparaît dans les en-têtes des emails sortants.

Google Workspace. Activez DKIM depuis Admin Console → Apps → Google Workspace → Gmail → Authentifier les emails. Générez un enregistrement 2048 bits, publiez-le en DNS, attendez la propagation, puis démarrez l’authentification.

OVH MXplan (sans DKIM natif). Migrez vers OVH Exchange ou Pro, ou configurez un relais SMTP externe (Brevo, Mailjet) qui signe en DKIM. L’alignement SPF seul n’est pas une solution pérenne pour ce service car OVH utilise son propre Return-Path.

Mailchimp. Dans votre compte, allez dans Account → Domains. Ajoutez votre domaine et publiez l’enregistrement DKIM fourni. Mailchimp utilisera ensuite d=votredomaine.fr dans sa signature DKIM.

Brevo (Sendinblue). Paramètres → Expéditeurs & IP → Domaines → Ajoutez votre domaine → Publiez l’enregistrement TXT DKIM fourni → Vérifiez. Une fois validé, tous vos envois Brevo seront signés avec votre domaine.

HubSpot. Paramètres → Email → Authentification email → Connectez votre domaine. HubSpot génère un enregistrement DKIM à publier. Les emails de séquences et de marketing seront ensuite alignés.

Serveur applicatif interne (SMTP direct). Deux options : configurer un signer DKIM sur le serveur (OpenDKIM pour les serveurs Linux) ou router les emails via un relais SMTP comme Postmark ou SendGrid qui signe en DKIM et vous fournit un enregistrement DNS à publier.

Après chaque correction, attendez la propagation DNS (jusqu’à 24 heures, souvent moins) et vérifiez dans les nouveaux rapports DMARC que l’alignement est passé à pass pour cette source.

Étape 4 : La montée progressive

Ne passez jamais directement de p=none à p=reject. La montée progressive vous permet de détecter des problèmes sur une fraction du trafic avant de l’appliquer à l’ensemble.

Le calendrier recommandé

Semaines 1-4 : p=none avec rua actif

Phase d’observation. Inventoriez vos sources, analysez les rapports, corrigez les services mal alignés. Ne changez pas la politique avant d’avoir au moins 4 semaines de données et d’avoir corrigé toutes les sources légitimes avec un alignement fail.

v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr; fo=1

Semaines 5-6 : p=quarantine; pct=25

Appliquez la politique quarantine à 25 % du trafic suspect. Les 75 % restants continuent d’être traités selon p=none. Surveillez vos rapports quotidiennement. Si des emails légitimes atterrissent en spam, vous avez identifié une source non corrigée.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@votredomaine.fr; fo=1

Semaines 7-8 : p=quarantine; pct=50

Montez à 50 %. Deux semaines sans incident au-dessus de ce seuil vous donnent la confiance nécessaire pour la suite.

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@votredomaine.fr; fo=1

Semaines 9-10 : p=quarantine; pct=100

La totalité du trafic échouant l’alignement DMARC atterrit en spam. C’est le vrai test. Si vous passez 2 à 4 semaines à ce niveau sans faux positifs, vous êtes prêt pour reject.

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@votredomaine.fr; fo=1

Semaines 11-12 : p=reject

Le palier final. Les emails qui échouent l’alignement DMARC sont rejetés avant d’arriver dans les boîtes.

v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine.fr; fo=1

Continuez à surveiller les rapports DMARC après le passage en reject — ce n’est pas parce que la politique est active que la surveillance s’arrête.

Quand marquer une pause

Marquez une pause et repassez au palier précédent si :

Un volume significatif d’emails légitimes attendus n’arrive pas à destination
Vos rapports montrent une source avec un fort volume et un alignement fail que vous n’avez pas identifiée
Une équipe remonte un problème de délivrabilité depuis le changement de politique

Descendre d’un palier n’est pas un échec — c’est le fonctionnement normal d’une migration prudente.

Les pièges courants

Les sous-domaines non couverts

Le tag sp= (subdomain policy) contrôle la politique appliquée aux sous-domaines. Sans ce tag, les sous-domaines héritent de la politique principale dans certaines implémentations, mais le comportement varie selon les serveurs destinataires. Définissez-le explicitement :

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@votredomaine.fr

Si vous avez des sous-domaines avec leurs propres services d’envoi non encore corrigés (newsletter.votredomaine.fr, support.votredomaine.fr), publiez un record DMARC séparé sur ces sous-domaines avec une politique adaptée, qui écrasera l’héritage du domaine parent.

Le transfert d’emails

Quand un destinataire configure un transfert automatique (depuis une adresse pro vers un Gmail personnel, par exemple), l’IP du serveur de transfert n’est pas dans votre SPF, et le Forward-Path change. Si le serveur de transfert ne signe pas en DKIM, l’alignement échoue.

DKIM résiste mieux au transfert que SPF — à condition que le serveur intermédiaire ne modifie pas le contenu du message. Si des emails forwardés remontent dans vos rapports avec alignement fail, c’est normal. Ce n’est pas un problème de votre configuration.

Les listes de diffusion

Les listes de diffusion (Mailman, Listserv, GroupesIO) modifient généralement le contenu des messages — ajout d’un footer, modification de l’objet — ce qui invalide la signature DKIM. Ces emails échoueront DMARC. Si des listes de diffusion sont des flux légitimes pour votre organisation, soit le gestionnaire de la liste doit configurer ARC (Authenticated Received Chain), soit vous acceptez que ces emails soient bloqués.

Les applications RH et paie legacy

Lucca, Payfit, les SIRH maison, les applications de gestion des notes de frais — ces outils envoient souvent des emails depuis votre domaine sans en avertir la DSI. Interrogez explicitement les RH et la comptabilité. Une notification de fiche de paie rejetée n’est pas anodine.

Les alertes de monitoring

Nagios, Zabbix, Grafana, les scripts cron qui envoient des alertes par email — souvent configurés avec un SMTP direct sur le serveur, sans SPF ni DKIM. Identifiez ces flux et soit reconfigurez-les via un relais SMTP signé, soit utilisez une adresse d’envoi sur un sous-domaine dédié aux alertes avec sa propre configuration DMARC.

Que faire si des emails légitimes sont bloqués

Rollback d’urgence

Si vous détectez des blocages de flux légitimes après le passage en reject, agissez immédiatement.

Option 1 — Repasser en quarantine (recommandé) :

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@votredomaine.fr; fo=1

Les emails continuent d’arriver (en spam), ce qui permet au destinataire de les retrouver et à vous de diagnostiquer.

Option 2 — Suspendre la politique :

v=DMARC1; p=reject; pct=0; rua=mailto:dmarc@votredomaine.fr; fo=1

Le pct=0 applique la politique à 0 % du trafic — revient fonctionnellement à p=none sans modifier la politique déclarée.

La propagation DNS dépend du TTL de votre enregistrement. Si vous avez un TTL élevé (3600 ou plus), le changement peut mettre jusqu’à une heure à se propager. Gardez le TTL de votre enregistrement DMARC à 300 secondes pendant la phase de migration — vous pouvez le remonter une fois stable.

Identifier la source dans les rapports

Après le rollback, analysez les rapports DMARC reçus depuis le passage en reject. Cherchez une source avec :

Un volume qui correspond à la période de l’incident
Un alignement fail sur SPF et DKIM
Une adresse IP que vous reconnaissez (service interne ou prestataire)

Une fois la source identifiée, corrigez son alignement (voir Étape 3), vérifiez que les nouveaux rapports confirment le pass, et reprenez la montée progressive depuis le palier quarantine.

Communiquer avec les destinataires affectés

Si des partenaires ou clients vous signalent ne pas avoir reçu vos emails, demandez-leur de vérifier leur dossier spam (en cas de quarantine) ou les logs de leur serveur SMTP (en cas de reject). Un email rejeté par DMARC génère généralement une entrée dans les logs du serveur destinataire avec un message du type 550 5.7.1 Message rejected due to DMARC policy.

Informez-les du contexte — un retard lié à une migration de sécurité est généralement bien compris — et donnez-leur une estimation du retour à la normale.

La migration DMARC et la protection contre le phishing

Passer en reject protège vos destinataires contre le spoofing exact de votre domaine. C’est une protection réelle et nécessaire. Mais elle est ciblée : DMARC ne fait rien contre les domaines sosies (votre-entreprise.fr, votre-entreprise-fr.com), les comptes compromis qui envoient depuis votre domaine légitime, ou le phishing qui n’use pas de votre domaine du tout.

Ces attaques passent entièrement sous le radar de DMARC. C’est pourquoi la sécurité technique des emails et la formation des collaborateurs se complètent plutôt qu’elles ne se remplacent. Un employé capable de reconnaître un email de phishing — même techniquement impeccable — est une couche de défense que DMARC ne peut pas remplacer.

Votre configuration DMARC est en place ou en cours. Pour mesurer la résistance de vos équipes face aux attaques qui contournent la couche technique, notre service de simulation de phishing permet de tester et former vos collaborateurs avec des scénarios réalistes.

Thomas Ferreira est CISSP certifié et accompagne des équipes techniques dans la sécurisation de leur infrastructure email depuis 2015. Les recommandations de ce guide s’appuient sur la RFC 7489 (spécification DMARC), les recommandations de l’ANSSI et la documentation officielle de Google et Microsoft.