Objectif
Faire évoluer un domaine vers une politique DMARC p=reject sans bloquer les expéditeurs légitimes. La procédure s’appuie sur le standard DMARC actuel RFC 9989 publié en 2026, vérifie l’alignement SPF et surtout DKIM, exploite les rapports agrégés, teste les flux de mailing lists et de transfert, puis applique reject uniquement lorsque les échecs légitimes sont compris.
Prérequis
- Contrôle de la zone DNS du domaine et de ses sous-domaines d’envoi.
- Inventaire des services qui utilisent le domaine visible From:.
- SPF et DKIM déjà déployés ou plan de correction établi pour chaque source.
- Boîte ou service d’analyse pour les rapports DMARC agrégés rua.
- Accès aux en-têtes Authentication-Results de messages de test et aux journaux des plateformes d’envoi.
Procédure pas à pas
Inventorier toutes les sources utilisant le domaine From
Listez Exchange Online
- Chaque source légitime possède un propriétaire, un volume approximatif et une méthode d’authentification identifiée.
Vérifier qu’il n’existe qu’un SPF par domaine d’enveloppe
Résolvez le TXT SPF des domaines utilisés dans MAIL FROM. Il ne doit pas exister plusieurs enregistrements SPF concurrents. Vérifiez la limite de recherches DNS et retirez les includes obsolètes. SPF seul n’est pas suffisant pour DMARC reject, mais un SPF propre simplifie les rapports et protège les services qui conservent un alignement correct.
Resolve-DnsName -Type TXT <DOMAINE>nslookup -type=txt <DOMAINE>- Un seul record v=spf1 est publié par domaine concerné.
- Les sources légitimes sont autorisées sans includes historiques inutiles.
Activer DKIM aligné sur chaque plateforme d’envoi
Pour chaque service, activez la signature DKIM avec un domaine d= appartenant au domaine organisationnel ou au sous-domaine prévu. Dans Microsoft 365, utilisez les CNAME DKIM fournis pour le domaine personnalisé puis activez la signature. Pour les SaaS, évitez de vous contenter d’une signature DKIM du fournisseur si elle n’est pas alignée avec votre From.
- Chaque grande source d’envoi produit dkim=pass avec un domaine de signature aligné au From.
Publier DMARC en observation sans pct
Commencez avec p=none et demandez les rapports agrégés. Avec RFC 9989, le tag pct de l’ancien DMARC n’est plus utilisé. Utilisez un enregistrement simple, lisible et conforme. Si les rapports sont envoyés vers un domaine tiers, vérifiez le mécanisme d’autorisation du destinataire de rapports prévu par le standard.
TXT _dmarc.<DOMAINE> = "v=DMARC1; p=none; rua=mailto:dmarc-reports@<DOMAINE>; adkim=r; aspf=r"Resolve-DnsName -Type TXT _dmarc.<DOMAINE>- Un seul enregistrement DMARC est publié.
- Les rapports agrégés commencent à être reçus et analysés.
Analyser les rapports sur une période représentative
Laissez suffisamment de temps pour couvrir les envois quotidiens, hebdomadaires et mensuels. Classez les IP et domaines DKIM en trois catégories : légitimes alignés, légitimes non alignés, inconnus. Corrigez chaque source légitime avant enforcement. Les rapports agrégés sont maintenant spécifiés séparément par RFC 9990 ; utilisez un parseur capable de traiter le format actuel.
- Aucune source métier connue n’est laissée en DMARC fail sans décision explicite.
Tester les redirections, mailing lists et flux indirects
Envoyez des messages de test via les listes et mécanismes de transfert réellement utilisés. SPF peut échouer après redirection ; DKIM doit idéalement rester valide. Les mailing lists qui modifient le corps ou les en-têtes peuvent casser DKIM. RFC 9989 insiste sur le risque d’interopérabilité de p=reject pour ces flux : validez les usages de l’organisation avant enforcement global.
- Les flux indirects critiques sont connus et leur comportement DMARC est documenté.
Passer à p=quarantine comme étape d’enforcement
Après une période d’observation propre, passez à p=quarantine. N’utilisez pas pct pour n’appliquer la policy qu’à une fraction du trafic. Si vous avez besoin d’un vrai pilote, utilisez des sous-domaines dédiés ou une population d’envoi séparée. Surveillez les rapports et les plaintes de réception. Le tag t=y existe dans RFC 9989 pour signaler un contexte de test, mais ne doit pas remplacer une vraie analyse d’impact.
TXT _dmarc.<DOMAINE> = "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@<DOMAINE>; adkim=r; aspf=r"- Les messages légitimes continuent à être acceptés et authentifiés.
- Les fails restants sont compris.
Passer à p=reject uniquement lorsque DKIM est robuste
Une fois l’étape quarantine stable, publiez p=reject. Conservez rua afin de surveiller les nouvelles sources et les régressions. Si des sous-domaines doivent avoir un comportement différent, utilisez sp de façon explicite et documentée ; sinon la politique parente peut s’appliquer selon les règles de découverte DMARC. Les domaines qui envoient vers des mailing lists publiques doivent être évalués avec une prudence particulière.
TXT _dmarc.<DOMAINE> = "v=DMARC1; p=reject; rua=mailto:dmarc-reports@<DOMAINE>; adkim=r; aspf=r"- Le DNS retourne p=reject.
- Les flux légitimes passent DMARC grâce à SPF aligné ou, de préférence, DKIM aligné.
Contrôler les en-têtes et la délivrabilité après enforcement
Sur des messages reçus chez plusieurs grands opérateurs, contrôlez Authentication-Results : spf, dkim, dmarc et l’alignement des domaines. Sur Microsoft 365, utilisez également Message Trace et les outils de diagnostic d’authentification. Une réussite DNS ne suffit pas : la validation finale porte sur les messages réellement reçus.
Resolve-DnsName -Type TXT _dmarc.<DOMAINE>Resolve-DnsName -Type TXT <DOMAINE>- Les messages légitimes affichent dmarc=pass.
- Les nouveaux fails sont détectés via les rapports et la supervision.
Validation
La procédure est validée lorsque :
- Le domaine publie un seul record DMARC et n’utilise plus le tag pct pour un nouveau déploiement.
- Les principales sources d’envoi ont une signature DKIM valide et alignée.
- Les rapports agrégés n’identifient plus de source légitime inconnue ou non corrigée.
- Les flux indirects et mailing lists importants ont été testés avant p=reject.
- Des messages de production chez plusieurs destinataires retournent dmarc=pass après enforcement.
Retour arrière
- En cas de blocage légitime significatif, repasser temporairement à p=quarantine ou p=none pendant la correction de la source.
- Ne réintroduisez pas pct comme mécanisme de rollback ; utilisez une politique claire et une segmentation par sous-domaine ou plateforme si nécessaire.
- Conservez rua pendant le rollback afin de mesurer l’effet de la correction.
- Restaurer l’ancien SPF ou DKIM uniquement si la configuration précédente était valide et documentée ; sinon corriger la source fautive.
Dépannage / erreurs fréquentes
- spf=pass mais dmarc=fail : le domaine MAIL FROM n’est probablement pas aligné avec le From visible.
- dkim=pass mais dmarc=fail : vérifier le domaine d= de la signature et son alignement avec le From.
- Un SaaS légitime échoue : configurer un domaine d’enveloppe personnalisé ou DKIM personnalisé fourni par ce SaaS.
- Des mailing lists échouent en reject : évaluer leur réécriture From, la préservation DKIM et le besoin métier avant d’assouplir la politique globale.
- Rapports absents : vérifier rua, l’autorisation du domaine tiers de reporting et les filtres de la boîte de collecte.