DMARC en échec : choisir une politique sans bloquer les e-mails légitimes

L’e-mail de votre PDG « n’est pas passé », le support a trois captures d’écran de messages de rebond qui ne correspondent pas, et le service Marketing jure qu’il « n’a rien changé ». Pendant ce temps, votre domaine est usurpé dans des campagnes de phishing et l’équipe sécurité veut p=reject pour hier.

C’est le piège DMARC : si vous appliquez la politique trop tôt, vous perdez du courrier légitime. Si vous n’appliquez rien, vous donnez un buffet libre aux usurpateurs. L’astuce n’est pas de choisir une politique. L’astuce est de la mériter.

Ce que DMARC fait vraiment (et ce qu’il ne fait pas)

DMARC est une couche de politique et de reporting construite au-dessus de SPF et DKIM. Il répond à une question : le destinataire doit-il faire confiance au domaine dans l’en-tête From visible qui est authentifié ? DMARC vérifie si SPF ou DKIM « réussit » et est aligné avec le domaine dans l’en-tête From. S’il existe une authentification alignée, DMARC réussit. Sinon, DMARC échoue et le récepteur applique votre politique demandée : none, quarantine ou reject.

Important : DMARC n’est pas un filtre anti-spam. Il ne note pas le contenu. Il n’empêche pas les comptes compromis d’envoyer des messages abusifs en utilisant une authentification valide. Il ne répare pas votre réputation. C’est plutôt une « protection de marque avec des réglages », et ces réglages peuvent vous faire mal si vous les tournez comme un DJ à 2 h du matin.

Faits intéressants et contexte historique (ce qui explique pourquoi c’est étrange)

• DMARC est né de la douleur : il a émergé vers 2012 comme réponse pragmatique à l’usurpation de domaine généralisée que SPF et DKIM seuls ne résolvaient pas.
• SPF précède DKIM : SPF s’est imposé au début des années 2000 quand les expéditeurs d’enveloppe falsifiés étaient partout et que SMTP s’en fichait.
• DKIM vient d’une collaboration industrielle : il a grandi à partir d’efforts des grands fournisseurs de boîtes aux lettres pour préserver l’intégrité des messages à travers les sauts.
• L’alignement est la nouvelle exigence : SPF ou DKIM passants ne suffisent pas ; DMARC exige que le domaine authentifié corresponde (ou soit proche) du domaine From visible.
• Le transfert casse SPF par conception : le transfert standard change l’IP d’envoi, donc SPF échoue souvent même quand l’expéditeur d’origine était légitime.
• Les rapports DMARC ont rendu l’e-mail observable : les rapports agrégés sont l’un des premiers flux de télémétrie largement utilisés pour l’authentification d’e-mails à l’échelle Internet.
• L’adoption des politiques s’est accélérée après la pression des grands fournisseurs : une fois que de grandes boîtes ont commencé à signaler visiblement les mails non authentifiés, les dirigeants se sont soudain intéressés.
• La politique de sous-domaine existe parce que les attaquants adorent les sous-domaines : la balise sp= est une admission tacite que « une politique pour tous » survit rarement à la réalité d’une entreprise.

Une citation que les opérationnels répètent pour une raison : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan. L’authentification des e-mails en est la meilleure démonstration.

Guide de diagnostic rapide

C’est la séquence « arrêter de deviner ». L’objectif est de trouver le goulot d’étranglement en quelques minutes, pas de produire un beau diagramme que personne ne lira.

Première étape : confirmer l’axe qui échoue (SPF, DKIM ou alignement)

1. Récupérez un vrai message en échec (de préférence depuis un fournisseur de boîtes, pas une capture d’écran).
2. Inspectez Authentication-Results et notez :
   • SPF pass/failed et le domaine utilisé.
   • DKIM pass/failed et le domaine de signature (d=).
   • DMARC pass/failed et le domaine « header.from ».
3. Si SPF ou DKIM passe mais DMARC échoue, vous avez un problème d’alignement, pas d’authentification.

Deuxième étape : identifier le système d’envoi qui a produit le courriel

1. Cherchez des indices dans les en-têtes : Received:, X-Mailer, en-têtes spécifiques aux fournisseurs.
2. Associez-le à un flux connu : Microsoft 365, Google Workspace, Salesforce/Marketo, Zendesk, Postfix sur site, système RH, plateforme de facturation, etc.
3. Si vous ne pouvez pas l’identifier rapidement, les rapports agrégés DMARC le feront — si vous les collectez.

Troisième étape : décider si vous pouvez le corriger via config ou si un changement de routage est nécessaire

• Corrigible par configuration : ajouter la signature DKIM, corriger le domaine From, ajouter un include SPF, corriger le sélecteur, publier l’enregistrement DMARC, définir le mode d’alignement.
• Nécessite un changement de routage : le tiers doit envoyer via votre relais autorisé, ou doit utiliser son propre domaine, ou doit supporter DKIM avec votre domaine.

Ne commencez pas par changer votre politique DMARC. Commencez par faire passer vos flux légitimes. La politique vient en dernier.

Choisir une politique DMARC sans casser le courrier

La politique DMARC n’est pas une posture morale. C’est de l’ingénierie du trafic. Votre objectif : arrêter l’usurpation tout en gardant la livraison des e-mails légitimes. La voie la plus sûre est l’application progressive avec télémétrie.

Ce que signifient réellement les trois politiques en pratique

p=none (surveillance)

Cela demande aux récepteurs de ne rien faire de spécial en cas d’échec. Ce n’est pas inutile — si vous avez le reporting en place, c’est votre phase de visibilité. Traitez p=none comme un mode lecture seule : vous mesurez l’ampleur, énumérez les expéditeurs et corrigez l’alignement. Si vous y restez indéfiniment, les attaquants vous remercieront pour leur trimestre.

p=quarantine (application douce)

Cela demande aux récepteurs de considérer les échecs comme suspects — généralement placement en dossier spam. Le comportement varie selon le fournisseur. Certains mettent en quarantaine agressivement, d’autres plus doucement, d’autres encore vous ignorent plus qu’ils ne l’admettent. La quarantaine est utile car elle met en évidence l’impact pour l’utilisateur sans perte aussi catastrophique que le reject. Elle est aussi dangereuse car les gens ne consultent pas toujours les spams, et les processus métiers n’aiment pas la livraison probabiliste.

p=reject (application stricte)

Cela demande aux récepteurs de rejeter purement et simplement le courrier en échec, idéalement au moment SMTP. C’est la posture la plus propre pour prévenir l’usurpation. Elle est aussi impitoyable : tout flux légitime en échec d’alignement devient une panne. Vous ne « testez pas » le reject. Vous le déployez comme une règle de pare-feu en production : avec inventaire, canaris et rollback.

Application progressive sans embraser la production

Utilisez le déploiement en pourcentage avec la balise pct=. Commencez à pct=10 ou pct=25 pour quarantine ou reject, selon votre confiance dans l’inventaire des expéditeurs.

Une progression typique sécurisée :

1. Base : p=none + rapports agrégés fonctionnels (rua=) pendant au moins 2–4 semaines.
2. Nettoyage : corriger ou éliminer les flux légitimes en échec ; déployer DKIM partout où c’est possible.
3. Application partielle : p=quarantine; pct=25, surveiller l’impact utilisateur et les sources inattendues.
4. Renforcement : p=quarantine; pct=100 ou passer à p=reject; pct=25 si tout est propre.
5. Objectif : p=reject; pct=100, plus sp=reject si vous contrôlez les sous-domaines.

Blague #1 : DMARC, c’est comme la ceinture de sécurité — tout le monde l’aime jusqu’à ce qu’elle bloqué pendant que vous attrapez votre café.

Que faire pour les sous-domaines (là où la complexité se reproduit)

Si votre organisation utilise des sous-domaines pour le marketing, les mails transactionnels ou des marques régionales, définissez une politique explicite pour les sous-domaines avec sp=. Sinon vous appliquerez accidentellement des règles sur des sous-domaines dont vous ignoriez l’existence.

• Conservateur : p=reject; sp=none pour protéger le parent tout en donnant de l’air aux sous-domaines.
• Sévère : p=reject; sp=reject une fois que vous savez que les expéditeurs de sous-domaines sont propres.

Quelle sévérité pour l’alignement ?

L’alignement DMARC peut être relaxé ou strict :

• Alignement relaxé (par défaut) : permet l’alignement au niveau du domaine organisationnel (par ex., mail.example.com aligne avec From example.com).
• Alignement strict : nécessite une correspondance exacte de domaine. C’est là où des configurations parfaitement légitimes se brisent.

Dans la plupart des entreprises, l’alignement strict vient plus tard — après avoir éliminé les comportements fournisseurs étranges et standardisé les domaines d’envoi. Commencez relaxé à moins d’une bonne raison de faire autrement.

Alignement et modes d’échec qui frappent en production

SPF : l’expéditeur d’enveloppe n’est pas le From

SPF authentifie le domaine dans l’expéditeur SMTP (Return-Path), pas l’en-tête From. DMARC vérifie ensuite si ce domaine authentifié par SPF s’aligne avec le domaine de l’en-tête From.

Schéma d’échec courant :

• Return-Path : bounces.vendor-mail.example.net (domaine du fournisseur)
• From : billing@example.com (votre domaine)
• SPF passe pour le domaine du fournisseur, mais ne s’aligne pas avec example.com → DMARC échoue sauf si DKIM est aligné.

DKIM : la signature existe, mais pas pour votre domaine

DKIM signe le contenu et le lie à un domaine via la balise d=. DMARC vérifie si ce domaine s’aligne avec le domaine de l’en-tête From. Si un fournisseur signe en tant que d=vendor.com tout en envoyant From votre domaine, DKIM peut réussir mais DMARC échoue quand même.

Transfert : SPF échoue, DKIM peut survivre

Le transfert classique casse SPF parce que l’IP du transitaire n’est pas listée dans votre enregistrement SPF. DKIM peut survivre au transfert si le message n’est pas modifié en transit. Beaucoup de systèmes le modifient (préfixe de sujet, insertion de pied de page), ce qui casse aussi DKIM. Ensuite DMARC échoue et vous avez la réunion « pourquoi ça marchait l’année dernière ? ».

Listes de diffusion : le destructeur DKIM

Les listes de diffusion ré-encapsulent ou modifient souvent les messages (préfixe de sujet, pied de page de liste), ce qui casse DKIM. SPF s’aligne rarement parce que le serveur de liste envoie. DMARC échoue. Les gestionnaires de listes modernes peuvent atténuer cela, mais vous ne contrôlez pas toutes les listes auxquelles vos utilisateurs s’abonnent.

Multiples fournisseurs : mort par mille « ajoutez cet include »

SPF a une limite stricte : 10 recherches DNS lors de l’évaluation. Chaque include: compte, plus les redirects et certains mécanismes. Dépassez-la et vous obtenez permerror. DMARC ne se soucie pas de la raison de l’échec SPF ; il voit juste l’échec. Vous pouvez finir par casser des mails en « autorisant » trop de choses.

Rapports DMARC : la différence entre contrôle et superstition

Les rapports agrégés (RUA) montrent qui envoie au nom de votre domaine, quelles authentifications ils passent et à quel volume. Ils ne sont pas parfaits. Ils sont retardés, échantillonnés par certains fournisseurs, et parfois difficiles à parser. Mais sans eux, vous changez la politique à l’aveugle.

Tâches pratiques : commandes, sorties, décisions

Ces tâches sont conçues pour un flux de travail SRE-ish : vérifier l’état, interpréter la sortie, prendre une décision, changer une chose à la fois.

Tâche 1 — Vérifier que votre enregistrement DMARC existe et est syntaxiquement sain

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

Ce que ça signifie : DMARC existe ; la politique est en surveillance ; les rapports vont vers vos boîtes ; l’alignement relaxé est réglé.

Décision : S’il n’y a pas d’enregistrement ou s’il est mal formé, corrigez cela avant de toucher à quoi que ce soit d’autre. Si vous êtes encore en p=none, vous êtes en mode inventaire.

Tâche 2 — Valider que le DNS retourne un seul enregistrement TXT DMARC

cr0x@server:~$ dig TXT _dmarc.example.com +noall +answer
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"

Ce que ça signifie : Un seul enregistrement. Bien.

Décision : Si vous voyez plusieurs réponses TXT, consolidez-les. Plusieurs enregistrements DMARC sont un comportement indéfini, et les fournisseurs de boîtes ont tendance à choisir le chaos.

Tâche 3 — Vérifier l’enregistrement SPF et compter les includes (risque de recherches)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org -all"

Ce que ça signifie : SPF autorise Google, Microsoft, Mailgun. Potentiellement correct, mais chaque include coûte des recherches.

Décision : Si vous avez plus d’une poignée d’includes, lancez un test de comptage de recherches (tâche suivante). Si vous êtes proche de 10, arrêtez d’ajouter des includes et changez de stratégie (alignement DKIM via fournisseurs, ou consolidation via un relais).

Tâche 4 — Détecter un permerror SPF dû à la limite de recherches DNS

cr0x@server:~$ spfquery -ip=203.0.113.10 -sender=bounce@example.com -helo=mx.example.com
pass (lookup_count=7)

Ce que ça signifie : L’évaluation SPF a passé et a utilisé 7 recherches DNS. Vous avez de la marge.

Décision : Si vous voyez permerror (lookup limit exceeded), vous devez réduire la complexité SPF. Ce n’est pas un travail « plus tard » ; c’est du travail « aujourd’hui » avant l’application.

Tâche 5 — Extraire l’en-tête d’un message en échec et lire Authentication-Results

cr0x@server:~$ sed -n '1,120p' failing-message.eml | egrep -i 'authentication-results|dmarc=|spf=|dkim=|from:|return-path'
Return-Path: <bounces@vendor.example.net>
From: "Billing" <billing@example.com>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@vendor.example.net designates 198.51.100.20 as permitted sender) smtp.mailfrom=bounces@vendor.example.net;
       dkim=none (message not signed);
       dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=example.com

Ce que ça signifie : SPF a passé pour le domaine du fournisseur, mais DMARC a échoué parce qu’il n’y a pas de DKIM et que SPF ne s’aligne pas avec example.com.

Décision : Vous avez besoin d’une signature DKIM avec d=example.com (préféré) ou de demander au fournisseur d’envoyer avec leur propre domaine (moins idéal pour la marque), ou de router via votre infrastructure.

Tâche 6 — Vérifier que l’enregistrement de clé publique DKIM existe pour un sélecteur

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

Ce que ça signifie : Le sélecteur s1 est publié. C’est nécessaire, pas suffisant.

Décision : S’il manque, DKIM échouera pour les mails signés avec ce sélecteur. Publiez-le ou corrigez-le avant l’application.

Tâche 7 — Vérifier qu’un message est réellement signé DKIM et aligné

cr0x@server:~$ grep -i '^DKIM-Signature:' -m 1 good-message.eml
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:message-id; bh=...; b=...

Ce que ça signifie : Le domaine de signature d=example.com s’aligne avec From example.com. Ce flux devrait passer DMARC même si SPF casse (transfert).

Décision : Si d=vendor.com, DKIM peut passer mais l’alignement DMARC peut échouer. Corrigez la configuration du fournisseur pour signer avec votre domaine.

Tâche 8 — Tester l’évaluation DMARC depuis un outil de style récepteur (OpenDMARC)

cr0x@server:~$ opendmarc-testmsg < failing-message.eml | sed -n '1,25p'
opendmarc-testmsg: EnvelopeFrom: bounces@vendor.example.net
opendmarc-testmsg: HeaderFrom: example.com
opendmarc-testmsg: SPF: pass
opendmarc-testmsg: DKIM: fail
opendmarc-testmsg: DMARC: fail (policy=quarantine)

Ce que ça signifie : La logique DMARC côté récepteur concorde avec ce que vous voyez en production.

Décision : Ne discutez pas avec la production. Corrigez DKIM ou l’alignement.

Tâche 9 — Inspecter les logs Postfix pour le comportement du milter DKIM (sur site)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Jan  3 10:12:11 mx1 postfix/cleanup[22190]: 9F3C42C10D: message-id=<20260103101210.9F3C42C10D@mx1.example.com>
Jan  3 10:12:11 mx1 opendkim[1187]: 9F3C42C10D: DKIM-Signature field added (s=s1, d=example.com)
Jan  3 10:12:11 mx1 postfix/qmgr[1120]: 9F3C42C10D: from=<billing@example.com>, size=28412, nrcpt=1 (queue active)

Ce que ça signifie : Votre MTA ajoute des signatures DKIM en utilisant le sélecteur et le domaine attendus.

Décision : Si vous ne voyez pas « DKIM-Signature field added », votre chemin de signature est cassé (milter en panne, mauvais socket, permissions de clé incorrectes).

Tâche 10 — Confirmer que votre boîte de rapport DMARC reçoit des rapports agrégés

cr0x@server:~$ sudo -u postfix mailq | head
Mail queue is empty

Ce que ça signifie : Pas directement lié à DMARC, mais cela vous indique que la boîte de rapport n’a pas d’arriéré dans la file du MTA. Si vous effectuez une livraison locale, cela compte.

Décision : Si la file grandit et que la destination est votre boîte rua, vous perdez des rapports et vous devenez aveugle. Corrigez la livraison des mails avant de changer la politique.

Tâche 11 — Extraire le XML d’un rapport agrégé DMARC et résumer les sources en échec principales

cr0x@server:~$ unzip -p rua-archive/aggregate-report-001.zip '*.xml' | grep -Eo '<source_ip>[^<]+' | head
<source_ip>192.0.2.55
<source_ip>198.51.100.20
<source_ip>203.0.113.99

Ce que ça signifie : Vous avez une liste rapide d’IP sources envoyant pour votre domaine.

Décision : Pour chaque IP principale, identifiez le système/fournisseur. Les IP inconnues sont soit du shadow IT soit de l’usurpation active. Les deux méritent de l’attention ; une seule mérite un ticket fournisseur.

Tâche 12 — Vérifier quels systèmes se connectent à votre MX entrant (repérage d’usurpation et relais)

cr0x@server:~$ sudo grep -h "connect from" /var/log/mail.log | awk '{print $NF}' | sed 's/[][]//g' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  412 203.0.113.77
  198 198.51.100.20
   76 192.0.2.55

Ce que ça signifie : Principales IP de connexion. Cela ne prouve pas l’usurpation, mais montre qui vous parle.

Décision : Si vous voyez des expéditeurs inattendus ou des pics importants, corrélez avec les échecs DMARC et les événements de sécurité. Vous pourriez être la cible de campagnes d’usurpation actives.

Tâche 13 — Vérifier que votre politique DMARC est bien celle que vous pensez (le cache DNS ment)

cr0x@server:~$ dig TXT _dmarc.example.com @8.8.8.8 +short
"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-rua@example.com; adkim=r; aspf=r"

Ce que ça signifie : Un résolveur public voit quarantine à 25 %. Bien pour un déploiement progressif.

Décision : Si des résolveurs différents ne sont pas d’accord, votre TTL ou la propagation DNS joue. Ne basculez pas sur reject tant que vous n’avez pas des résultats cohérents.

Tâche 14 — Inspecter SPF pour un flux fournisseur spécifique (s’aligne-t-il ?)

cr0x@server:~$ dig +short TXT vendor.example.net
"v=spf1 ip4:198.51.100.0/24 -all"

Ce que ça signifie : Le fournisseur autorise sa plage IP pour son propre domaine. Cela n’aide en rien à l’alignement avec votre domaine From.

Décision : Arrêtez d’essayer de « SPF-iser » des expéditeurs tiers mal alignés. Demandez la signature DKIM alignée avec votre domaine ou changez le From.

Tâche 15 — Vérifier que la rotation des sélecteurs DKIM n’a pas laissé de records morts (courant lors du « nettoyage »)

cr0x@server:~$ for s in s1 s2 s2024; do echo "== $s =="; dig +short TXT ${s}._domainkey.example.com; done
== s1 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2 ==
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."
== s2024 ==

Ce que ça signifie : Le sélecteur s2024 est manquant. Si un expéditeur l’utilise encore, DKIM échoue.

Décision : Soit republiez la clé temporairement, soit migrez l’expéditeur vers un sélecteur existant avant l’application. Supprimer d’anciens sélecteurs n’est pas de « l’hygiène » si ils sont encore en usage.

Tâche 16 — Confirmer la frontière du domaine organisationnel pour l’alignement relaxé (comportement des suffixes publics)

cr0x@server:~$ python3 - <<'PY'
import sys
from email.utils import parseaddr
print("example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com")
PY
example.co.uk aligns with sub.example.co.uk under relaxed mode, but not with example.com

Ce que ça signifie : L’alignement relaxé utilise la logique du domaine organisationnel (basée sur les règles de suffixe public). Les domaines avec codes pays peuvent surprendre.

Décision : Si vous opérez sous des domaines comme example.co.uk, vérifiez deux fois les configurations fournisseurs et les attentes ; l’alignement strict devient pénible rapidement.

Blague #2 : SPF, c’est le régime de la sécurité e-mail — simple sur le papier, détruit par « encore un include ».

Trois mini-récits d’entreprise (parce qu’on n’apprend jamais facilement)

Mini-récit 1 : La panne causée par une mauvaise hypothèse

L’entreprise avait une configuration apparemment propre : Microsoft 365 pour les employés, une grosse plateforme marketing et un relais sur site pour les imprimantes et des « systèmes spéciaux ». La sécurité voulait p=reject. L’admin e-mail a accepté, parce que les rapports DMARC montraient « majoritairement pass ».

L’hypothèse erronée était subtile : ils ont supposé que « majoritairement pass » signifiait « le reste est de l’usurpation ». Ce n’était pas le cas. Un outil RH régional envoyait des lettres d’offre avec From: hr@example.com mais routait via l’infrastructure du fournisseur sans DKIM aligné. SPF passait — juste pas pour le bon domaine. DMARC échouait. Sous p=none, le message arrivait encore. Sous p=reject, il rebondissait sévèrement.

Lundi matin, les candidats n’ont pas reçu d’offres. Les recruteurs ont escaladé. Le service juridique a demandé si l’entreprise avait « retiré » des offres. L’équipe sécurité a été blâmée parce qu’elle avait demandé le reject, et l’équipe e-mail a été blâmée parce qu’elle l’avait mis en œuvre. La direction a fait ce que fait la direction : programmé une réunion, puis une autre réunion à propos de la première réunion.

La correction fut simple : configurer le fournisseur RH pour signer DKIM avec d=example.com en utilisant un sélecteur délégué, puis réactiver l’application. La leçon était plus laide : le succès DMARC, c’est énumérer chaque expéditeur légitime. Toute hypothèse « inconnu = malveillant » est une politique qui finira par vous réveiller en pleine nuit.

Mini-récit 2 : L’optimisation qui a mal tourné

Une autre organisation a décidé de « simplifier le DNS ». Quelqu’un a remarqué que l’enregistrement SPF était devenu un petit roman. Ils ont supprimé ce qui ressemblait à des « anciens includes fournisseurs » et ont fusionné des sélecteurs DKIM parce que « nous n’avons pas besoin d’autant ». C’était bien intentionné. Ce n’était pas testé contre la réalité.

Deux semaines plus tard, les taux d’échec DMARC ont grimpé. Pas partout — seulement chez quelques fournisseurs de boîtes. L’équipe a perdu du temps à blâmer « des changements de fournisseur » et « la réputation ». La vérité : un « ancien include » couvrait encore un flux de mails transactionnels utilisé pour les réinitialisations de mot de passe d’une application legacy. Il envoyait rarement, donc il n’apparaissait pas sur les tableaux de bord quotidiens. Quand il envoyait, SPF échouait, et l’app legacy ne signait pas DKIM. Sous l’application accrue, les e-mails de réinitialisation disparaissaient silencieusement en quarantaine ou en rejet, selon le récepteur.

Pendant ce temps, la consolidation des sélecteurs DKIM a cassé une intégration fournisseur qui avait le sélecteur en dur. Ce fournisseur a continué à signer avec l’ancien sélecteur, qui n’existait plus dans le DNS. DKIM a échoué immédiatement. Les échecs DMARC ont explosé pour cet expéditeur.

L’équipe a restauré, puis a écrit une règle : aucun nettoyage SPF/DKIM sans cartographier chaque include et sélecteur vers un propriétaire, un système et un message de test. L’optimisation est superbe, mais l’authentification e-mail punit les idées brillantes. Elle préfère la paperasserie ennuyeuse et un DNS stable.

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

Une entreprise SaaS de taille moyenne orientait les rapports DMARC vers une boîte interne, puis vers un parseur qui produisait un inventaire hebdomadaire des expéditeurs. Rien de fancy. Pas de ML. Juste une liste de sources, taux de réussite et « nouveaux expéditeurs depuis la semaine dernière ». C’était le genre de processus que l’on qualifie de « travail occupé » jusqu’au jour où ça compte.

Un mardi, le rapport a signalé une nouvelle IP source envoyant un petit volume de mails utilisant From: finance@example.com. SPF échouait. DKIM était absent. DMARC échouait. Sous leur p=quarantine actuel, beaucoup atterrissaient en spam. Bien, mais insuffisant.

La sécurité a enquêté et a trouvé une campagne de phishing visant les clients. Parce que l’équipe avait de la télémétrie et une base de référence, ils n’ont pas perdu de temps à discuter de la réalité. Ils sont passés à p=reject; pct=25 pendant 24 heures, ont vérifié qu’aucun flux légitime n’était impacté, puis ont monté à 100% reject. Ils ont aussi défini sp=reject après avoir confirmé que les sous-domaines étaient propres.

Les clients ont signalé moins d’e-mails de phishing utilisant le nom de l’entreprise en quelques jours. La pratique ennuyeuse — reporting régulier et inventaire — a rendu l’application un changement contrôlé plutôt qu’un saut dans l’inconnu. Personne n’a été réveillé par une alerte. Les meilleures pannes sont celles qui n’arrivent jamais.

Erreurs courantes : symptôme → cause racine → correction

1) « SPF passe mais DMARC échoue »

Symptôme : Authentication-Results affiche spf=pass, DMARC échoue.

Cause racine : SPF a passé pour un domaine qui ne s’aligne pas avec le header From (courant avec des expéditeurs tiers).

Correction : Activer la signature DKIM alignée sur votre domaine From (meilleur), ou changer le domaine From vers celui du fournisseur, ou router l’expéditeur via votre infrastructure alignée.

2) « DKIM passe mais DMARC échoue »

Symptôme : dkim=pass mais DMARC échoue.

Cause racine : Le domaine de signature DKIM d= n’est pas aligné avec le header From ; le fournisseur signe avec son propre domaine.

Correction : Configurer le fournisseur pour signer avec votre domaine via un sélecteur délégué (publier leur sélecteur sous votre domaine), ou ajuster le domaine From.

3) « Tout fonctionnait jusqu’à ce qu’on mette p=reject »

Symptôme : Rejets immédiats pour certains mails métiers légitimes.

Cause racine : Expéditeurs légitimes inconnus, sélecteurs DKIM cassés, ou permerror SPF masqués sous p=none/quarantine.

Correction : Revenir en quarantaine avec pct=, corriger l’inventaire d’expéditeurs, puis réappliquer le reject de manière progressive.

4) « Les mails transférés commencent à rebondir après l’application DMARC »

Symptôme : Les utilisateurs qui transfèrent vers des boîtes perso se plaignent ; les livraisons via listes échouent.

Cause racine : Les forwarders cassent SPF ; les modifications de listes cassent DKIM ; DMARC échoue.

Correction : Assurez-vous que vos mails sortants sont signés DKIM alignés ; pour les listes, envisagez des atténuations spécifiques (par ex., réécriture du From) ou une liste blanche des comportements connus dans les systèmes en aval quand c’est possible.

5) « Permerror SPF apparaît aléatoirement »

Symptôme : Certains récepteurs affichent permerror SPF ou fail ; d’autres passent.

Cause racine : Limite de recherches DNS dépassée ; certains évaluateurs court-circuitent différemment, ou des timeouts DNS vous poussent dans des erreurs temporaires.

Correction : Réduisez les recherches DNS SPF en consolidant les expéditeurs, en supprimant les includes inutilisés, ou en utilisant l’alignement DKIM plutôt que de dépendre de SPF.

6) « Les rapports DMARC ont cessé d’arriver »

Symptôme : La boîte RUA est silencieuse ; les tableaux de bord ne se mettent plus à jour.

Cause racine : Boîte pleine, routage changé, adresse rua invalide, ou filtrage qui bloque les grosses pièces jointes zip.

Correction : Assurez-vous que la boîte de rapport accepte les messages volumineux, ne supprime pas automatiquement et que l’adresse rua est correcte et monitorée.

7) « Nous avons DMARC mais l’usurpation continue »

Symptôme : Des clients reçoivent du phishing utilisant votre marque malgré l’existence d’un enregistrement DMARC.

Cause racine : Vous êtes en p=none, ou les récepteurs n’appliquent pas uniformément, ou les attaquants utilisent des domaines ressemblants.

Correction : Passez à reject une fois que les flux légitimes passent ; ajoutez une politique pour les sous-domaines ; surveillez les domaines ressemblants séparément (DMARC ne vous protégera pas contre examp1e.com).

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

Plan étape par étape : atteindre p=reject en toute sécurité

1. Inventoriez les expéditeurs via les rapports agrégés DMARC pendant au moins 2–4 semaines. Attribuez un propriétaire à chaque source.
2. Classifiez les flux :
   • Courriel employés (M365/Workspace)
   • Transactionnel (app mails, factures, réinitialisation de mot de passe)
   • Marketing (plateformes de campagne)
   • Support/ticketing
   • Infrastructure (alertes, monitoring)
3. Standardisez les domaines From : décidez quels domaines peuvent apparaître en From pour chaque flux. Soyez strict. Les fournisseurs aiment les From créatifs.
4. Activez la signature DKIM alignée partout où c’est possible. Préférez DKIM pour les flux tiers car l’alignement est plus simple et la survie au transfert est meilleure.
5. Corrigez SPF mais gardez-le léger :
   • Supprimez les includes morts
   • Restez en dessous de 10 recherches
   • Utilisez -all quand vous êtes confiants ; ~all est une béquille, pas une stratégie
6. Publiez DMARC avec reporting : p=none + rua. Vérifiez que les rapports arrivent et sont parsés.
7. Définissez explicitement la politique de sous-domaines avec sp=. Ne laissez pas les sous-domaines hériter de l’application par accident.
8. Montez en quarantaine avec pct : commencez pct=25, puis 50, puis 100 lorsque les taux d’échec baissent et que le bruit support reste acceptable.
9. Montez en reject avec pct : commencez 10–25, surveillez les nouveaux échecs. Montez délibérément.
10. Verrouillez la gouvernance : tout nouveau fournisseur doit supporter DKIM aligné ou utiliser un domaine fournisseur ; « on ne peut pas » signifie « on ne vous onboardera pas ».
11. Gardez la surveillance : DMARC n’est pas une opération « régler et oublier ». Les fournisseurs font tourner les IP, les intégrations changent, quelqu’un rachète une société, et votre posture DMARC rencontre à nouveau la réalité.

Checklist : avant de changer la politique DMARC

• Avons-nous au moins une destination RUA fonctionnelle et reçoit-elle des rapports ?
• Avons-nous un inventaire actuel des expéditeurs avec des propriétaires ?
• Les flux majeurs passent-ils DMARC (pas seulement SPF ou DKIM) ?
• SPF est-il sous la limite de recherches DNS et stable ?
• Les sélecteurs DKIM sont-ils publiés pour tous les signataires actifs ?
• Avons-nous un plan de rollback (enregistrement précédent et connaissance du TTL) ?
• Avons-nous informé le support et la sécurité des impacts attendus ?

Checklist : quand un fournisseur « doit envoyer comme votre domaine »

• Le fournisseur peut-il DKIM-signer avec d=yourdomain en utilisant un sélecteur délégué ?
• Peuvent-ils supporter un Return-Path personnalisé aligné sur votre domaine (rarement la meilleure voie, mais parfois possible) ?
• Peuvent-ils envoyer via votre relais (soumission SMTP) pour que vous signiez vous-même le mail ?
• Ont-ils un DKIM par locataire et des schémas d’envoi stables ?
• Pouvent-ils fournir des messages de test et un contact technique qui comprend l’authentification ?

FAQ

1) Devons-nous passer directement à p=reject pour arrêter l’usurpation ?

Seulement si vous êtes sûr que vos flux légitimes passent déjà DMARC. Sinon vous échangez l’usurpation contre une perte de mails auto-infligée. Faites-le progressivement avec pct et de la télémétrie.

2) Est-ce que p=quarantine est « sûr » ?

Plus sûr que reject, pas sûr pour autant. Certains mails métiers critiques disparaîtront dans les dossiers spam, ce qui équivaut fonctionnellement à un mail perdu — juste avec plus de déni.

3) Pourquoi SPF passe mais DMARC échoue ?

Parce que SPF authentifiait le domaine d’enveloppe, et DMARC se soucie du domaine de l’en-tête From. Si ceux-ci ne s’alignent pas, SPF n’aide pas DMARC. La signature DKIM alignée est généralement la solution.

4) Le transfert casse notre e-mail. DMARC est-il incompatible avec le transfert ?

DMARC expose la fragilité du transfert. SPF casse sur le transfert ; DKIM peut survivre si le message n’est pas modifié. Pour vos flux sortants, signez DKIM aligné afin qu’au moins un mécanisme puisse passer.

5) Avons-nous besoin des rapports forensiques ruf= ?

Généralement non. Les rapports forensiques sont supportés de façon inégale et peuvent soulever des questions de confidentialité. Les rapports agrégés (RUA) sont l’outil opérationnel principal.

6) Quelle est la raison la plus fréquente pour laquelle DMARC « échoue soudainement » après des années ?

Un nouvel expéditeur ou un changement de routage. Déclencheurs courants : l’équipe marketing ajoute une plateforme, le support change de fournisseur, un outil SaaS commence à envoyer « de votre domaine », ou des sélecteurs DKIM sont mal tournés lors d’une rotation.

7) Avons-nous besoin d’alignement strict (adkim=s, aspf=s) ?

Pas au départ. L’alignement strict réduit l’ambiguïté, mais il élève la barre pour chaque expéditeur. Commencez relaxé, atteignez reject, puis envisagez strict là où cela ne casse pas le monde.

8) Et les sous-domaines : devons-nous définir sp=reject ?

Uniquement quand vous savez ce qui utilise les sous-domaines. Si vous avez beaucoup de sous-domaines gérés par des fournisseurs, commencez avec sp=none ou sp=quarantine et faites un inventaire.

9) Si nous utilisons Microsoft 365 ou Google Workspace, avons-nous encore besoin de DMARC ?

Oui. Ces plateformes peuvent authentifier vos mails sortants, mais DMARC est la façon pour le reste du monde de savoir quoi faire quand quelqu’un usurpe votre domaine.

10) Combien de temps devons-nous rester en p=none ?

Assez longtemps pour capturer les cycles métiers normaux : au moins deux semaines, souvent un mois. Les cycles de facturation trimestriels et les workflows rares sont où se cachent vos « expéditeurs inconnus ».

Conclusion : prochaines étapes exploitables

Si DMARC échoue, ne commencez pas par demander « quarantine ou reject ? » Commencez par demander « quel flux légitime échoue d’alignement ? » Corrigez cela, puis appliquez. La politique est la dernière étape, pas la première.

Prochaines étapes pratiques

1. Récupérez un message en échec et lisez Authentication-Results. Décidez si le problème est SPF, DKIM ou alignement.
2. Vérifiez les enregistrements DMARC et SPF dans le DNS depuis plusieurs résolveurs. Corrigez la syntaxe et éliminez les doublons.
3. Transformez les rapports DMARC en inventaire : chaque expéditeur, propriétaire et taux de réussite.
4. Forcez la signature DKIM alignée pour chaque expéditeur tiers qui doit utiliser votre domaine From.
5. Appliquez progressivement avec pct : quarantine d’abord, puis reject, avec plan de rollback et support prévenu.

Faites cela, et « DMARC en échec » devient un problème d’ingénierie solvable plutôt qu’un fil d’e-mails sans fin intitulé « URGENT ».