Rapports DMARC : comment les lire et détecter l’usurpation rapidement

Ce que sont réellement les rapports DMARC (et ce qu’ils ne sont pas)

Les rapports DMARC sont des boucles de rétroaction envoyées par les fournisseurs de boîtes aux lettres (et certains intermédiaires) au propriétaire du domaine qui publie un enregistrement DMARC. Ils vous indiquent, à grande échelle, comment les messages prétendant provenir de votre domaine se comportent face à SPF et DKIM, et si la politique DMARC serait respectée.

Deux types de rapports importent :

• Rapports agrégés (a.k.a. RUA) : résumés périodiques, généralement quotidiens, montrant des comptes de messages par IP source, résultats d’authentification et disposition appliquée. Ce sont ceux que vous utilisez pour la surveillance et la détection de tendances.
• Rapports forensiques/échec (a.k.a. RUF) : détails d’échec par message (ou échantillon). De nombreux fournisseurs les limitent ou ne les envoient pas pour des raisons de confidentialité et d’abus. Si vous les activez sans plan, vous finirez avec une boîte aux lettres pleine de données personnelles que vous ne vouliez pas posséder.

Ce que les rapports DMARC ne sont pas :

• Une garantie que l’usurpation est impossible. DMARC aide à prévenir l’usurpation directe chez les récepteurs conformes ; il n’empêche pas les domaines ressemblants, la fraude par nom d’affichage ou les fournisseurs compromis.
• Une vérité absolue sur « qui a envoyé le message ». Les rapports montrent ce que les récepteurs ont observé. Le transfert, les passerelles et les listes de diffusion déformeront la réalité à moins que vous ne compreniez l’alignement et la rupture d’authentification.
• Un remplacement des logs. Les rapports DMARC sont une vue côté récepteur. Vous avez toujours besoin de la télémétrie côté envoi pour boucler l’enquête.

Considérez les rapports DMARC comme des alertes de burn-rate SLO pour la confiance de la marque. Ils ne vont pas éteindre l’incendie, mais ils vous diront où est la fumée et à quelle vitesse elle se propage.

Faits intéressants et un peu d’histoire

• DMARC est apparu au début des années 2010 lorsque les grands fournisseurs de boîtes aux lettres ont essayé de réduire le phishing à l’échelle Internet sans casser l’écosystème de messagerie existant du jour au lendemain.
• SPF est antérieur à DMARC et a été conçu autour du domaine d’enveloppe SMTP (Return-Path), pas l’en-tête From visible par l’utilisateur. Ce décalage est la raison pour laquelle DMARC a nécessité l’« alignement ».
• DKIM est né de DomainKeys et Identified Internet Mail ; il a standardisé la signature cryptographique des en-têtes/corps du message, mais il ne définissait pas comment les récepteurs devaient traiter les échecs de manière uniforme. DMARC a ajouté la politique.
• La balise « pct » de DMARC existe parce que le monde fonctionne avec des déploiements progressifs. C’est le bouton de déploiement canari pour l’authentification des e-mails.
• « Relaxed » vs « strict » alignment revient essentiellement à « sous-domaines autorisés ou non », ce qui paraît simple jusqu’à ce que votre organisation ait 47 plateformes marketing et un ERP legacy qui croit être en 2003.
• Les rapports agrégés sont du XML par tradition, pas parce que quelqu’un aime ça. Le format est largement supporté et se compresse bien, ce qui comptait quand les rapports ont été mis à l’échelle pour la première fois.
• Les grands fournisseurs limitent ou omettent les rapports forensiques en raison du risque pour la vie privée ; certains n’envoient plus d’échantillons complets de message.
• ARC (Authenticated Received Chain) existe en grande partie parce que des flux légitimes comme les listes de diffusion cassent SPF/DKIM ; ARC offre un moyen pour les intermédiaires de préserver les résultats d’authentification en aval.

Une idée paraphrasée et utile, attribuée à Werner Vogels : Tout finit par tomber en panne ; concevez pour pouvoir récupérer rapidement et apprendre de l’échec.

Les bases DMARC importantes en production

DMARC, c’est politique + alignement + rapports

Un enregistrement DMARC vit à _dmarc.example.com dans le DNS. Il définit :

• La politique : ce que les récepteurs doivent faire quand DMARC échoue (p=none, p=quarantine, p=reject).
• L’alignement : si les passes SPF/DKIM doivent s’aligner avec le domaine From (relaxed/strict).
• Les points de rapport : où envoyer les rapports agrégés (rua) et/ou forensiques (ruf).

L’alignement est là où la plupart des organisations saignent

DMARC n’exige pas que SPF et DKIM passent tous les deux. Il exige soit SPF soit DKIM pour réussir et s’aligner avec le domaine From.

Réalité courante en production :

• SPF passe mais ne s’aligne pas parce que le fournisseur utilise son propre domaine de bounce (Return-Path), pas le vôtre.
• DKIM passe mais ne s’aligne pas parce que le fournisseur signe avec d=vendor.example au lieu de d=yourdomain.com.
• Les deux échouent après un transfert, car SPF casse sur les changements d’IP et DKIM casse sur les modifications d’en-têtes/corps.

La politique n’est pas un badge d’honneur

p=reject n’est pas un trophée. C’est un changement en production avec des conséquences pour les utilisateurs. Vous le méritez en instrumentant et stabilisant d’abord vos expéditeurs.

Vérité sèche : si vous ne pouvez pas nommer vos expéditeurs légitimes, vous n’êtes pas prêt à rejeter les expéditeurs inconnus.

Blague #1 : L’authentification des e-mails, c’est comme se brosser les dents : tout le monde reconnaît que c’est bon, et personne ne le fait jusqu’à ce que ça saigne.

Agrégés vs forensiques : choisir ce que vous pouvez gérer

Agrégés (RUA) : votre pouls quotidien

Les rapports agrégés arrivent en pièces jointes compressées (souvent ZIP ou GZIP) contenant du XML. Chaque rapport couvre une fenêtre temporelle et inclut plusieurs « enregistrements », chacun résumant le courrier qui partage :

• IP source (ou parfois une abstraction de bloc réseau)
• Domaine From (header From)
• Résultats d’authentification et statut d’alignement
• Comptes et disposition appliquée par le récepteur

Ils sont parfaits pour détecter :

• De nouvelles sources envoyant en tant que votre domaine
• Des pics soudains d’échecs DMARC suite à un changement légitime de plateforme
• Des récepteurs appliquant quarantine/reject de manière inattendue à cause d’un manque d’alignement

Forensiques (RUF) : fort signal, forte responsabilité

Les rapports d’échec peuvent contenir des en-têtes de message et parfois des portions du message. Cela peut inclure des données personnelles, du contenu interne ou des identifiants sensibles. Traitez-les comme des logs contenant des PII et appliquez des règles de conservation et de contrôle d’accès en conséquence.

Dans de nombreux environnements, la bonne décision est : n’activez pas RUF sauf si vous avez un cas d’usage spécifique et un processus de gestion sécurisé.

Comment lire un rapport agrégé comme un SRE

Commencez par la question : « Qu’est-ce qui a changé ? »

Le reporting DMARC concerne moins les événements isolés que les deltas. Vous chassez les nouvelles IP, les nouveaux expéditeurs et les nouveaux modes d’échec. Traitez-le comme une analyse de trafic :

• Baseline : sources connues, taux de réussite attendus, mix de récepteurs attendu.
• Détection de changement : nouvelles sources, chutes brutales d’alignement, ou anomalies spécifiques à un fournisseur.
• Attribution : mappez les IP aux fournisseurs/MTAs et décidez d’autoriser ou de bloquer.

Comprenez les trois domaines en jeu

Vous vous perdrez à moins de garder ces éléments séparés :

• Domaine Header From : ce que les utilisateurs voient ; ce que DMARC utilise pour la politique.
• Domaine SPF : le domaine d’enveloppe (Return-Path / MAIL FROM) vérifié par SPF.
• Domaine de signature DKIM : la valeur d= dans le DKIM-Signature.

DMARC demande : est-ce que SPF passe et s’aligne avec Header From ? Ou est-ce que DKIM passe et s’aligne avec Header From ? Si aucun ne s’aligne, DMARC échoue même si quelque chose a techniquement « passé ».

La disposition est un comportement du récepteur, pas votre intention

Les rapports DMARC incluent ce que le récepteur a fait : none/quarantine/reject. Cela est influencé par votre politique publiée, mais aussi par la politique locale et les heuristiques anti-spam. Si vous publiez p=none, les récepteurs peuvent quand même mettre à la poubelle les messages manifestement pourris. Inversement, même avec p=reject, certains récepteurs peuvent accepter le courrier s’ils font confiance à une chaîne de transfert ou à ARC.

Concentrez-vous d’abord sur « échoue mais aurait dû passer »

L’usurpation existe, certes. Mais votre victoire la plus rapide est de corriger votre courrier légitime qui échoue DMARC. Cet échec provoque des problèmes de délivrabilité, et il vous force à garder une politique laxiste parce que vous craignez de vous auto-saboter.

L’ordre opérationnel que je recommande :

1. Corriger les sources légitimes qui échouent DMARC (alignement, clés DKIM, problèmes de flattening SPF).
2. Passer à p=quarantine avec une montée progressive du pct.
3. Puis et seulement alors : p=reject (également en montée progressive), avec une surveillance qui alerte quand les échecs augmentent.

Tâches pratiques : commandes, sorties et décisions (12+)

Ci-dessous se trouvent les types de tâches que vous pouvez réellement exécuter sur une machine Linux ou dans un job CI qui récupère les rapports DMARC depuis une boîte aux lettres/un stockage type S3. Chaque tâche inclut : une commande, une sortie d’exemple, ce que cela signifie et la décision que vous en tirez.

Task 1 — Fetch your DMARC record and sanity-check the policy

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; adkim=r; aspf=r; pct=100"

Ce que cela signifie : DMARC est activé, en mode surveillance uniquement (p=none), alignement détendu, échantillonnage complet.

Décision : Si vous êtes déjà stable et toujours en p=none, planifiez une transition vers p=quarantine avec une montée progressive du pct. Si vous n’êtes pas stable, restez en p=none mais priorisez les corrections d’alignement.

Task 2 — Verify the reporting mailbox exists and is receiving mail

cr0x@server:~$ ls -lh /var/mail/dmarc-agg
-rw------- 1 dmarc dmarc 218M Jan  3 08:40 /var/mail/dmarc-agg

Ce que cela signifie : Les rapports arrivent et s’accumulent.

Décision : Si la boîte est énorme, vous ne traitez pas les rapports. Automatisez l’ingestion et définissez une rétention. Si elle est vide, votre adresse rua peut être erronée ou bloquée.

Task 3 — Identify attachment types (zip/gz) before parsing

cr0x@server:~$ file /srv/dmarc/inbox/*
/srv/dmarc/inbox/report-001.xml.gz: gzip compressed data, was "report.xml", last modified: Thu Jan  2 00:00:00 2026, from Unix
/srv/dmarc/inbox/report-002.zip: Zip archive data, at least v2.0 to extract, compression method=deflate

Ce que cela signifie : Vous avez des formats mixtes. Votre pipeline doit gérer les deux.

Décision : Normalisez en XML brut comme première étape (décompression), puis parsez.

Task 4 — Decompress and validate XML is present

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | head -n 8
<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>ExampleMailboxProvider</org_name>
    <email>noreply-dmarc@provider.example</email>
    <report_id>abc123</report_id>

Ce que cela signifie : C’est un rapport agrégé DMARC (XML de feedback).

Décision : Procédez au parsing. Si vous voyez du HTML ou un bounce, votre ingestion pointe vers la mauvaise boîte ou vous recevez des DSN.

Task 5 — Extract key fields quickly using xmllint and XPath

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | xmllint --xpath 'string(/feedback/report_metadata/org_name)' -
ExampleMailboxProvider

Ce que cela signifie : Ce rapport provient d’un récepteur spécifique. Les particularités selon le récepteur comptent.

Décision : Étiquetez les données ingérées par org_name pour repérer « n’échoue que chez Microsoft » vs « échoue partout ».

Task 6 — Pull the date range to correlate with incidents or deploys

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | xmllint --xpath 'concat(/feedback/report_metadata/date_range/begin, " ", /feedback/report_metadata/date_range/end)' -
1704153600 1704240000

Ce que cela signifie : Timestamps epoch pour la fenêtre du rapport (début/fin). C’est une tranche quotidienne approximative.

Décision : Convertissez en heure humaine dans vos outils et superposez aux timelines de déploiement. Si vous ne pouvez pas corréler, vous accuserez le mauvais changement.

Task 7 — Summarize sources (IP + count) to find new senders

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/row/source_ip/text() | //record/row/count/text()' - 2>/dev/null | \
tr ' ' '\n' | paste - - | head
192.0.2.10	1450
198.51.100.23	12
203.0.113.77	980

Ce que cela signifie : Trois IP d’envoi ont été observées, avec des comptes de messages.

Décision : Toute IP nouvelle avec un volume non négligeable doit être investiguée. Les IPs inconnues à faible volume peuvent toujours être du spearphishing, ne les ignorez pas — triez-les différemment.

Task 8 — Look specifically for DMARC failures at scale

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record[row/policy_evaluated/dkim="fail" and row/policy_evaluated/spf="fail"]/row/source_ip/text()' - 2>/dev/null | \
sort | uniq -c | sort -nr | head
3 198.51.100.23

Ce que cela signifie : Une IP source apparaît dans plusieurs enregistrements « les deux échouent ». C’est soit de l’usurpation, soit un expéditeur légitime complètement mal configuré.

Décision : Si l’IP n’est pas la vôtre ni celle d’un fournisseur connu, considérez-la comme usurpation. Si c’est un fournisseur connu, escaladez pour corriger immédiatement l’alignement DKIM/SPF.

Task 9 — Check SPF record size and lookup count risk

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | grep -E '^"v=spf1' -n
1:"v=spf1 include:_spf.mailvendor.example include:_spf.crmvendor.example include:_spf.payroll.example -all"

Ce que cela signifie : SPF utilise des includes (normal). Le risque est le nombre caché de requêtes DNS.

Décision : Si les rapports DMARC montrent permerror/temperror SPF, vous pourriez dépasser la limite de 10 lookups SPF. Commencez l’inventaire des includes et réduisez la complexité ; ne « rajoutez pas juste un include de plus ».

Task 10 — Query DKIM selectors that vendors commonly use

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Ce que cela signifie : Le sélecteur s1 existe. Si votre fournisseur signe avec s1 et que cela s’aligne, tout va bien.

Décision : Si les rapports DMARC montrent DKIM fail, vérifiez que le sélecteur existe, que la clé est correcte, et que le fournisseur signe vraiment avec votre domaine (d=example.com).

Task 11 — Confirm alignment settings (strict vs relaxed) and evaluate risk

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g' | tr ';' '\n' | sed 's/^ *//'
v=DMARC1
p=none
rua=mailto:dmarc-agg@example.com
ruf=mailto:dmarc-fail@example.com
adkim=r
aspf=r
pct=100

Ce que cela signifie : Alignement détendu pour SPF et DKIM. Les sous-domaines peuvent s’aligner selon les règles de domaine organisationnel.

Décision : Restez en relaxed pendant le déploiement sauf si vous avez une stratégie disciplinée pour les sous-domaines. L’alignement strict est un outil tranchant ; ne l’utilisez pas près des équipes marketing.

Task 12 — Identify top “disposition=quarantine/reject” and treat as deliverability incident

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/row/policy_evaluated/disposition/text()' - 2>/dev/null | \
sort | uniq -c | sort -nr
1200 none
230 quarantine
12 reject

Ce que cela signifie : Une partie est mise en quarantaine/rejetée. Cela peut être attendu (usurpation) ou auto-infligé.

Décision : Si quarantine/reject est non négligeable et corrèle à du trafic légitime, arrêtez et corrigez l’alignement avant d’augmenter l’application de la politique.

Task 13 — Extract “header_from” domains to detect subdomain abuse

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
xmllint --xpath '//record/identifiers/header_from/text()' - 2>/dev/null | \
tr ' ' '\n' | sort | uniq -c | sort -nr
2100 example.com
45 billing.example.com
7 security-update.example.com

Ce que cela signifie : Le courrier affirme provenir aussi de sous-domaines. Certains sont légitimes (mail départemental), d’autres sont de la créativité d’attaquants.

Décision : Si vous n’envoyez pas intentionnellement depuis un sous-domaine, ajoutez des enregistrements DMARC pour ces sous-domaines ou des politiques organisationnelles, et verrouillez la délégation DNS pour ces noms.

Task 14 — Reverse-lookup suspicious IPs (quick triage, not proof)

cr0x@server:~$ dig +short -x 198.51.100.23
mailout-23.somehost.example.

Ce que cela signifie : Le PTR suggère un fournisseur d’hébergement. Les attaquants comme les fournisseurs y habitent.

Décision : Utilisez cela comme piste, puis vérifiez avec l’inventaire des fournisseurs et les logs d’envoi. Ne faites pas confiance à un PTR pour mettre en liste blanche ; c’est comme confier la confiance à un inconnu parce qu’il a un joli hostname.

Task 15 — Spot SPF permerror/temperror in DMARC auth results

cr0x@server:~$ gunzip -c /srv/dmarc/inbox/report-001.xml.gz | \
grep -Eo '<spf>(permerror|temperror)</spf>' | sort | uniq -c
18 <spf>permerror</spf>

Ce que cela signifie : Les récepteurs n’ont pas pu évaluer correctement SPF (souvent trop de lookups DNS, enregistrements malformés ou problèmes DNS transitoires).

Décision : Traitez permerror comme un bug de configuration. Corrigez la complexité SPF et la fiabilité DNS avant de durcir la politique DMARC.

Task 16 — Confirm your inbound pipeline is not dropping reports (basic mail log check)

cr0x@server:~$ sudo grep -E "dmarc-agg@example.com|dmarc-fail@example.com" /var/log/mail.log | tail -n 5
Jan  3 08:40:12 mx1 postfix/lmtp[22091]: 9B2C312345: to=<dmarc-agg@example.com>, relay=local, delay=0.22, delays=0.05/0/0/0.17, dsn=2.0.0, status=sent (delivered to mailbox)
Jan  3 08:40:14 mx1 postfix/lmtp[22092]: 1A7D912346: to=<dmarc-agg@example.com>, relay=local, delay=0.18, delays=0.04/0/0/0.14, dsn=2.0.0, status=sent (delivered to mailbox)

Ce que cela signifie : Les rapports sont livrés localement ; votre problème de pipeline (le cas échéant) est post-livraison.

Décision : Si vous voyez des rebonds ou des rejets ici, corrigez d’abord le routage/les limites de mail. Un programme DMARC sans rapports entrants, c’est essentiellement de la surveillance sans piles de piles.

Playbook de diagnostic rapide

Quand quelqu’un vous signale « DMARC échoue » ou « On se fait usurper », vous avez besoin d’un chemin court vers la clarté. Voici l’ordre qui minimise le temps jusqu’à la vérité.

Première étape : confirmez s’il s’agit d’usurpation ou d’auto-dommage

1. Vérifiez la politique DMARC et les paramètres d’alignement dans le DNS. Si vous êtes en p=none, vous observez surtout, vous ne bloquez pas.
2. Depuis les rapports agrégés, listez les IP sources en échec par compte et disposition. Gros volume + SPF et DKIM qui échouent signifie généralement tentatives d’usurpation.
3. Mappez les IP en échec aux expéditeurs connus. Si une IP en échec est votre ESP/CRM, vous avez probablement un problème d’alignement, pas un attaquant.

Deuxième étape : isolez le mécanisme en échec (SPF vs DKIM vs alignement)

1. Si DKIM passe mais DMARC échoue, c’est généralement un alignement DKIM (mauvais d=) ou le domaine From est différent de ce que vous pensez (sous-domaine vs apex).
2. Si SPF passe mais DMARC échoue, c’est généralement un alignement SPF (domaine Return-Path différent) ou vous authentifiez un domaine différent du From visible.
3. Si les deux échouent, suspectez l’usurpation, la casse par transfert, ou un expéditeur totalement non configuré.

Troisième étape : décidez du chemin de mitigation

• Expéditeur légitime en échec : corrigez le domaine/selector DKIM et/ou configurez un domaine de bounce personnalisé pour l’alignement SPF ; puis re-vérifiez les rapports sur 24–48 heures.
• Expéditeur inconnu (probable usurpation) : continuez à collecter des preuves (mix de récepteurs, plages IP, volumes) et avancez la politique vers quarantine/reject une fois le trafic légitime nettoyé.
• Casse par transfert/listes de diffusion : évaluez le support ARC et envisagez d’utiliser DKIM comme mécanisme aligné principal plutôt que SPF.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait une configuration qui semblait propre : SPF, DKIM et DMARC. L’équipe sécurité était fière ; l’équipe IT était fatiguée ; le marketing était joyeusement ignorant des deux.

Ils ont supposé que leur plateforme CRM « gérait DKIM » parce qu’une case était cochée. Elle signait bien les mails — simplement pas avec le domaine de l’entreprise. Le d= DKIM était le domaine du fournisseur. SPF « passait » aussi, mais avec le Return-Path du fournisseur. Donc le mail s’authentifiait, mais ne s’alignait pas avec le From visible. DMARC échouait silencieusement parce que la politique était p=none.

Puis ils sont passés à p=quarantine en une seule fenêtre de changement parce que « nous monitorons depuis des mois ». Monitorer, oui. Lire les rapports, non. Une partie des e-mails légitimes du cycle client a commencé à atterrir dans le spam. Les ventes l’ont remarqué en premier, comme d’habitude, sous la forme d’un ralentissement mystérieux du pipeline.

La correction a été simple mais pénible : configurer le CRM pour signer DKIM avec d=example.com en utilisant un sélecteur qu’ils contrôlaient, et définir un domaine de bounce personnalisé pour que SPF s’aligne aussi. La leçon réelle : « l’authentification passe » n’est pas la même chose que « DMARC passe ». Cette hypothèse coûte cher.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait un enregistrement SPF qui ressemblait à un sapin de Noël : des includes pour chaque outil ayant jamais envoyé des e-mails pour leur compte. On leur avait dit que SPF a une limite de 10 lookups DNS, alors un ingénieur a « optimisé » en flattenant SPF en une longue liste d’IP générée la nuit.

Au départ, ça a fonctionné. Les lookups ont chuté. Le courrier passait. Tout le monde est passé à autre chose.

Puis le retour de bâton : un fournisseur a fait tourner ses IP d’envoi. Le job nocturne n’a pas récupéré le changement à cause d’une défaillance DNS transitoire durant la génération. Pendant la journée suivante, une tranche importante du courrier a échoué SPF chez les récepteurs. DKIM aurait dû les sauver, mais ce fournisseur ne signait pas avec un DKIM aligné. DMARC a échoué. La quarantaine a augmenté. Les tickets de support aussi.

Ils ont annulé la flattening et construit une approche plus sûre : limiter les includes en consolidant les fournisseurs, garder SPF simple, et pousser pour un DKIM aligné partout afin que SPF ne soit pas un point unique de défaillance de délivrabilité. L’optimisation, c’est bien. L’optimisation sans modélisation de défaillance, c’est de l’art de la performance.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise régulée gérait DMARC comme un programme ops, pas comme une case à cocher. Ils faisaient une revue hebdomadaire : sources principales, nouvelles sources, échecs par récepteur, et une courte liste de décisions « autoriser ou bloquer ». Ils maintenaient aussi un inventaire vivant de tous les systèmes autorisés à envoyer des mails au nom du domaine, avec propriétaire, but et mécanisme d’authentification.

Un lundi, le rapport montra une nouvelle plage IP envoyant un petit nombre de messages avec le Header From de l’entreprise, tous échouant SPF et DKIM. Le volume n’était pas énorme ; cela n’aurait pas déclenché les alarmes habituelles d’« incident e-mail ». Mais la nouvelle source se détachait parce que la baseline était propre et stable.

Ils ont contacté la sécurité avec des preuves : org du récepteur, IP source, header_from et comptes. La sécurité l’a corrélé à des signalements clients d’une campagne de phishing ciblée sur la paie. Parce que la politique DMARC était déjà p=reject, les récepteurs conformes refusaient les mails. Le rayon d’action de la campagne a été limité aux systèmes de la périphérie et aux captures d’écran transmises par des employés vigilants.

Pas d’héroïsme. Pas de salle de crise. Juste une surveillance ennuyeuse et un domaine déjà passé en application. C’est à quoi ressemble la « maturité opérationnelle » : moins d’histoires spectaculaires.

Blague #2 : Les rapports DMARC sont les seuls e-mails que vous recevrez jamais qui se plaignent d’autres e-mails envoyant des e-mails.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: DMARC fails, but SPF shows “pass” in reports

Cause racine : SPF passe pour le domaine d’enveloppe, mais il ne s’aligne pas avec le domaine Header From (domaine de bounce du fournisseur).

Correction : Configurez un Return-Path / domaine de bounce personnalisé sous votre domaine chez le fournisseur, ou reposez-vous sur un DKIM aligné. Vérifiez l’alignement dans les rapports avant de durcir la politique.

2) Symptom: DKIM passes, but DMARC still fails

Cause racine : Le domaine de signature DKIM (d=) ne s’aligne pas avec le domaine Header From (le fournisseur signe avec son propre domaine).

Correction : Configurez la signature DKIM avec votre domaine et publiez les enregistrements TXT du sélecteur requis. Confirmez en envoyant un mail de test et en vérifiant les en-têtes dans une boîte que vous contrôlez.

3) Symptom: Sudden spike in SPF permerror

Cause racine : SPF a dépassé la limite de lookups DNS à cause de trop d’includes/redirects, ou syntaxe SPF malformée.

Correction : Réduisez les includes, supprimez les fournisseurs obsolètes, et poussez l’alignement DKIM pour que SPF ne soit pas votre seul mécanisme aligné. Validez SPF avec un linter en CI.

4) Symptom: Everything works except when recipients are on a specific provider

Cause racine : Particularités d’application côté récepteur, politique locale, ou différences dans le traitement du forwarding/ARC.

Correction : Segmentez les rapports par org_name du récepteur. Pour le récepteur problématique, vérifiez si le transfert est courant et si votre mail est DKIM-aligné (plus résilient que SPF).

5) Symptom: DMARC failures only for mailing list traffic

Cause racine : Les listes de diffusion modifient les messages (cassant DKIM) et renvoient depuis leur propre infrastructure (cassant l’alignement SPF).

Correction : Préférez une signature DKIM qui survit aux modifications attendues quand c’est possible, et évaluez les récepteurs compatibles ARC. Opérationnellement, acceptez certains échecs pour les listes ou utilisez des stratégies de sous-domaine.

6) Symptom: You never receive DMARC reports

Cause racine : Adresse rua incorrecte, boîte qui rejette les grosses pièces jointes, MX manquant, ou le fournisseur exige une vérification pour les adresses de rapport externes.

Correction : Assurez-vous que la boîte existe, accepte les gros messages et est routable. Envisagez d’utiliser un sous-domaine dédié et une infrastructure de boîte pour les rapports DMARC.

7) Symptom: Reports show your own outbound IPs failing SPF

Cause racine : L’enregistrement SPF n’inclut pas les IPs réelles d’envoi (nouvel MTA, nouveau relais, ou trafic déplacé vers un cloud provider).

Correction : Mettez à jour les includes/IPs SPF, mais déployez aussi DKIM aligné pour qu’un manquement SPF ne devienne pas un incident de délivrabilité.

8) Symptom: Duplicate or inconsistent report counts across receivers

Cause racine : Les récepteurs échantillonnent différemment, agrègent différemment, ou attribuent les sources différemment (surtout avec les grandes infrastructures partagées).

Correction : Utilisez les rapports pour les tendances et la détection de nouvelles sources, pas pour une comptabilité exacte. Corrélez avec vos logs d’envoi pour des comptes précis.

Listes de contrôle / plan étape par étape

Étape par étape : construire un workflow de reporting DMARC qui ne s’effrite pas

1. Créez des adresses dédiées pour les rapports (agrégés et optionnellement d’échec) et mettez-les derrière un système de boîte aux lettres que vous contrôlez. Ne balancez pas les rapports dans la boîte perso de quelqu’un.
2. Automatisez l’ingestion : récupérez les pièces jointes, décompressez, stockez le XML brut, parsez en données structurées (tables ou JSON), et conservez les originaux pour une durée limitée.
3. Étiquetez chaque enregistrement avec org_name du récepteur, report_id, plage de dates, header_from, source_ip et résultats de politique.
4. Maintenez un inventaire des expéditeurs : chaque expéditeur légitime (MTAs, plateformes SaaS, systèmes de ticketing, outils de monitoring), propriétaire, et s’il utilise DKIM aligné ou SPF aligné.
5. Baseliner et alerter sur :
   • Nouvelles IP sources
   • Nouveaux header_from domaines/sous-domaines
   • Taux d’échec DMARC par récepteur
   • Toute augmentation des dispositions quarantine/reject
6. Corrigez l’alignement en premier, puis durcissez la politique. Si vous essayez d’appliquer avant d’être aligné, votre équipe délivrabilité inventera de nouveaux mots pour vous.
7. Déployez l’application progressivement : p=quarantine; pct=10 puis 25/50/100, puis envisagez p=reject avec un autre ramp.
8. Définissez rétention et contrôles d’accès pour les rapports, surtout si vous activez le reporting forensique. Traitez-les comme de la télémétrie sensible.
9. Faites une revue hebdomadaire avec sécurité + responsable messaging : principaux échecs, nouvelles sources, changements fournisseurs et décisions d’autorisation en attente.

Checklist opérationnelle : quand vous ajoutez un nouveau fournisseur d’envoi d’e-mails

• Confirmez si le fournisseur peut signer DKIM avec d=yourdomain. Sinon, réfléchissez bien avant de lui permettre d’envoyer en votre nom.
• Publiez les sélecteurs DKIM qu’ils fournissent, avec contrôle de changement et propriété.
• Configurez un domaine de bounce personnalisé (pour l’alignement SPF) si supporté.
• Envoyez des messages de test à plusieurs fournisseurs de boîtes et vérifiez que les en-têtes montrent un pass aligné.
• Surveillez les rapports DMARC pendant 48 heures après activation ; vérifiez les échecs d’alignement et les IP inattendues.
• Documentez l’expéditeur dans l’inventaire : propriétaire, but, domaines From attendus, sélecteurs et chemin d’escalade de support.

Checklist de gestion du changement : passer de p=none à l’application

• Listez toutes les sources légitimes connues des 30 derniers jours de rapports agrégés.
• Pour chaque source, assurez-vous qu’au moins un mécanisme aligné (préférablement DKIM) passe de manière cohérente.
• Confirmez que SPF respecte les limites de lookups et ne dépend pas de jobs de flattening fragiles.
• Commencez p=quarantine avec un pct faible et alertez sur les changements de taux de quarantaine.
• Ne passez à p=reject que lorsque la quarantaine est stable et que les échecs légitimes sont proches de zéro.

FAQ

1) Do I need both SPF and DKIM to pass for DMARC to pass?

Non. DMARC passe si soit SPF soit DKIM passe et s’aligne avec le domaine Header From. En pratique, visez un DKIM aligné partout, et considérez SPF comme utile mais plus fragile.

2) Why do DMARC reports show a “pass” for DKIM but “fail” for DMARC?

Parce que DKIM peut réussir cryptographiquement tout en échouant à l’alignement. Si la signature DKIM utilise d=vendor.com et que votre From est example.com, DMARC échoue.

3) Are DMARC aggregate reports real-time?

Non. Ce sont des résumés périodiques, généralement quotidiens. Utilisez-les pour les tendances et la détection de nouvelles sources, pas pour une réponse incident minute-par-minute.

4) Should we enable forensic (RUF) reports?

Seulement si vous pouvez gérer les implications de confidentialité et de conservation et que vous avez un besoin d’investigation spécifique. Beaucoup de fournisseurs ne les envoient pas, et ceux qui le font peuvent inclure du contenu sensible.

5) If we publish p=reject, will spoofing stop everywhere?

Cela réduira l’usurpation directe chez les récepteurs qui respectent DMARC. Les attaquants peuvent toujours utiliser des domaines ressemblants, des comptes compromis ou des canaux hors e-mail. DMARC est nécessaire, mais pas suffisant.

6) Why does forwarding break authentication?

SPF est vérifié contre l’IP d’envoi ; le transfert change l’IP d’envoi. DKIM peut casser si des intermédiaires modifient le message (en-têtes ou corps). ARC peut aider certains récepteurs à comprendre l’état d’authentification original.

7) What’s the fastest way to detect a new spoofing campaign in aggregate reports?

Cherchez de nouvelles IP sources envoyant votre Header From avec SPF et DKIM échouant tous les deux, surtout si les comptes augmentent rapidement ou apparaissent chez plusieurs orgs de récepteurs.

8) We have many subdomains. How should DMARC handle them?

Décidez si les sous-domaines sont autorisés à envoyer du courrier et publiez des enregistrements DMARC explicites pour eux quand c’est nécessaire. Si vous ignorez les sous-domaines, vous découvrirez tôt ou tard que quelqu’un d’autre « les utilise ».

9) Why are DMARC report counts different from our outbound logs?

Les récepteurs agrègent différemment, échantillonnent, et peuvent exclure certains mails. Vos logs sont la vérité côté expéditeur ; les rapports sont des observations côté récepteur. Utilisez les deux ; n’attendez pas une égalité parfaite.

10) Can I use DMARC reports to find every third-party vendor sending mail?

Vous pouvez en trouver beaucoup, surtout ceux qui envoient en volume et atteignent les grands récepteurs. Mais vous avez toujours besoin de discipline dans les achats/processus parce que certains mails n’atteignent jamais les récepteurs qui vous rapportent.

Conclusion : prochaines étapes sans perdre un trimestre

Les rapports DMARC ne sont pas un artefact de conformité. Ce sont un signal opérationnel. Si vous les traitez comme des logs — ingérer, parser, baseliner, alerter — vous détecterez l’usurpation et les mauvaises configurations tôt, quand la correction se limite à un e-mail au fournisseur plutôt qu’à un incident de marque.

À faire ensuite :

1. Vérifiez votre enregistrement DMARC et assurez-vous que les rapports agrégés arrivent réellement.
2. Construisez un inventaire des expéditeurs et mappez chaque IP source significative des rapports à un propriétaire.
3. Corrigez l’alignement pour les expéditeurs légitimes (DKIM aligné préféré), puis montez la politique de none → quarantine → reject par étapes pct.
4. Définissez des alertes pour les nouvelles sources et la hausse des taux d’échec, et faites une revue hebdomadaire avec la sécurité.

Si vous voulez que les e-mails restent ennuyeux — et vous le voulez — rendez aussi ennuyeux le reporting DMARC. L’ennui signifie que vous êtes aux commandes.