DMARC : quarantaine vs rejet — quand basculer et comment le déployer en toute sécurité

novembre 21, 2025 • février 3, 2026 • Lecture : 30 min • Views: 8

Cet article vous a aidé ?

Votre CEO vient de transférer un e‑mail qui « ressemble à un message de la Finance » et demande si le virement est légitime.
Les en‑têtes indiquent que ce n’est pas vous. Vos utilisateurs ne savent pas le distinguer. Et votre domaine est sur le point de devenir le déguisement favori des attaquants.

DMARC est la solution adulte. Mais passer de p=none à p=reject n’est pas une simple case à cocher — c’est un changement en production qui peut interrompre silencieusement des mails légitimes.
Voici comment le faire comme un SRE : mesurable, réversible et ennuyeux dans le bon sens.

DMARC en production : le modèle mental qui évite les pannes auto‑infligées

DMARC n’est pas « un protocole d’authentification ». C’est une politique et une pipeline de rapports qui se place au‑dessus de SPF et DKIM.
Elle indique aux récepteurs quoi faire quand un message qui prétend venir de votre domaine échoue l’authentification et, surtout, échoue l’alignement.

L’alignement est la partie que les gens retiennent à moitié puis regrettent.
DMARC ne se soucie pas qu’un SPF ait réussi pour bounce.vendor-mail.example si le message prétend provenir de yourbrand.com.
Il ne compte pas qu’un DKIM ait réussi pour mailer.thirdparty.com si le From visible est yourbrand.com et qu’ils n’ont pas signé avec votre domaine (ou un domaine correctement aligné).

Voici le modèle opérationnel le plus clair :

L’identité dans l’en‑tête From est ce que voient les utilisateurs et ce que DMARC protège.
SPF authentifie l’expéditeur de l’enveloppe SMTP (Return‑Path / MAIL FROM), pas l’en‑tête From.
DKIM authentifie un domaine de signature (d=), pas l’en‑tête From.
DMARC exige qu’au moins SPF ou DKIM réussisse et soit aligné avec le domaine From.
Politique : p=none observe, p=quarantine incite, p=reject ferme la porte.

La vérité opérationnelle : DMARC n’est pas difficile, il est étendu. Votre domaine envoie probablement des e‑mails depuis des sources dont vous n’avez plus le souvenir :
systèmes de ticketing, outils RH, CRM, plateformes marketing, pages de statut, automatisations de sous‑traitants, imprimantes, scanners, et cette application bricolée en 2018 qui tourne encore « temporairement ».

Un déploiement DMARC bien mené est essentiellement une découverte d’actifs pour l’email sortant, avec des changements DNS à la fin.

Faits intéressants et bref historique (ce qui explique les bizarreries d’aujourd’hui)

SPF précède DMARC d’à peu près une décennie. SPF a commencé au début des années 2000 en réaction au spoofing massif, mais il n’a jamais authentifié ce que voient les utilisateurs dans le From.
DKIM est issu de la fusion de deux approches concurrentes. DomainKeys (Yahoo) et Identified Internet Mail (Cisco) ont convergé vers DKIM, d’où une terminologie parfois écrite par comité.
DMARC est né du constat « nous en avons marre de nous faire phishing nous‑mêmes ». Les gros fournisseurs de boîtes et grands expéditeurs l’ont poussé pour arrêter le spoofing de domaines directs, pas pour résoudre tous les problèmes de spam.
La fonctionnalité la plus puissante de DMARC est le reporting. Les rapports agrégés (RUA) transforment les récepteurs en sources de télémétrie. C’est rare dans l’univers de l’email, qui fonctionne souvent au feeling et au blâme.
Le renvoi de mail est plus ancien que la plupart de vos couches SaaS. L’écosystème d’origine supposait que le forwarding et le remailing étaient normaux. L’application stricte de DMARC peut entrer en conflit avec cet héritage.
ARC existe parce que « le forwarding casse SPF/DKIM » ne disparaissait pas. Authenticated Received Chain est un pansement pour préserver les résultats d’authentification à travers des intermédiaires.
Les grands récepteurs ont progressivement durci leur comportement. La conformité DMARC ne s’est pas imposée du jour au lendemain ; les fournisseurs ont graduellement renforcé l’application et les signaux UI sur des années, d’où des conseils anciens qui échouent aujourd’hui.
DMARC n’est pas uniquement pour le rejet. Beaucoup d’organisations à fort volume vivent en p=quarantine avec un pct progressif, car certains écosystèmes d’email ne deviennent jamais parfaitement déterministes.

Quarantaine vs rejet : ce qui change réellement sur le réseau

En théorie, la politique DMARC est un « choix du récepteur ». En pratique, les grands fournisseurs de boîtes interprètent votre politique comme un signal fort.
Vous leur dites : « Je contrôle mon domaine et je suis prêt à ce que vous l’appliquiez. »

Ce que signifie généralement la quarantaine

La quarantaine est une instruction « traiter comme suspect ». Le plus souvent : dossier spam, classification en indésirable, ou filtrage supplémentaire.
Certains récepteurs continueront de livrer en boîte de réception selon leur modèle propre.

Opérationnellement, la quarantaine est une piste de mise en scène :

Vous commencez à recevoir des plaintes d’utilisateurs (« mes factures vont dans les spams ») sans l’arrêt brutal d’un rejet total.
Vous pouvez découvrir des expéditeurs mal alignés qui « fonctionnaient » seulement parce que les récepteurs étaient indulgents.
Vous pouvez monter l’application avec pct pendant que vous corrigez l’alignement sous‑jacent.

Ce que signifie généralement le rejet

Le rejet est le refus de livraison par le récepteur lors du dialogue SMTP (idéal) ou l’abandon ultérieur (moins idéal).
Si votre mail légitime échoue DMARC sous une politique reject, vous obtenez souvent :

Des hard bounces pour les mails transactionnels.
Des non‑livraisons silencieuses selon le comportement du récepteur (rare, mais possible).
Des exercices de crise : « les e‑mails n’arrivent pas » est une panne métier, pas un ticket IT.

Le rejet est l’objectif pour des domaines à haute confiance (dirigeants, paie, finance, légal) et pour des marques fréquemment usurpées.
C’est aussi une promesse : vous dites aux récepteurs que votre posture d’authentification est assez mature pour que les messages échoués soient probablement hostiles.

Une règle opinionnée : n’allez pas en rejet tant que vous ne pouvez pas répondre, avec des preuves, « Quels systèmes envoient des mails en tant que notre domaine, et sont‑ils alignés ? »
Si votre réponse est « principalement Microsoft 365 », vous n’êtes pas prêt. « Principalement » est la façon dont les pannes arrivent.

Blague n°1 : DMARC, c’est comme mettre une serrure à la porte d’entrée — super idée — jusqu’à ce que vous vous rappeliez que votre colocataire utilise encore la fenêtre.

Préparation : prérequis avant de toucher à la politique DMARC

Le déploiement le plus sûr commence par un inventaire ennuyeux et finit par la politique. Entre les deux : des corrections d’alignement.
Voilà ce que vous devriez avoir en place avant d’augmenter l’application.

1) Vous possédez le DNS et pouvez le modifier de manière fiable

DMARC vit dans le DNS. Si votre workflow DNS c’est « quelqu’un d’un autre service clique », vous avez besoin d’un processus de changement :
contrôle de version, revue, et fenêtres de propagation prévisibles. Le mode d’échec est simple : TXT erroné, auth cassée, heures d’incertitude.

2) SPF n’est pas parfait, mais il est sain

SPF doit couvrir vos expéditeurs légitimes et éviter de dépasser la limite de 10 recherches DNS. Aussi : réduisez progressivement l’ambiguïté de ~all.
Le succès SPF ne suffit pas pour DMARC, mais le chaos SPF rend l’analyse DMARC pénible.

3) Le DKIM signe pour les plateformes d’envoi principales

DKIM est votre meilleur allié quand le mail est transféré ou relayé.
Si vous pouvez signer avec d=yourbrand.com (ou un sous‑domaine aligné), faites‑le.

4) Vous avez une boîte de réception pour les rapports et quelqu’un qui les lit

Les rapports agrégés DMARC sont en XML. Ils ne sont pas « lisibles par un humain », mais ce sont de l’or opérationnel.
Il vous faut une boîte pour les recevoir, un parseur/workflow (commercial ou interne), et une attente de type on‑call : quelqu’un vérifie quand vous changez la politique.

5) Vous comprenez votre tolérance au risque

La tolérance d’une banque n’est pas celle d’une agence créative. Décidez :

Quels domaines doivent aller en rejet rapidement (exécutifs, paiements) ?
Quels domaines peuvent rester en quarantaine plus longtemps (marketing lourd, beaucoup de tiers) ?
Avez‑vous besoin de politiques pour les sous‑domaines (sp=) ?

Tâches pratiques (avec commandes, sorties et décisions)

Ce sont des tâches réelles que vous pouvez exécuter depuis un shell. Elles ne corrigeront pas DMARC toutes seules, mais elles vous évitent de deviner.
Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie, et la décision à prendre.

Task 1: Inspecter l’enregistrement DMARC actuel

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

Sens : La politique actuelle est uniquement en surveillance (p=none). Alignement relaxé pour SPF et DKIM. Le reporting est configuré.

Décision : Si rua manque, arrêtez‑vous et ajoutez‑le avant l’application. Pas de télémétrie, pas de déploiement.

Task 2: Valider la syntaxe du record DMARC depuis le DNS

cr0x@server:~$ python3 - <<'PY'
import re, subprocess, shlex
domain="_dmarc.yourbrand.com"
out=subprocess.check_output(["dig","+short","TXT",domain],text=True).strip()
print(out)
if "v=DMARC1" not in out:
    raise SystemExit("Missing v=DMARC1")
if " p=" not in out and ";p=" not in out:
    raise SystemExit("Missing p=")
print("Looks like DMARC-ish TXT is present.")
PY
"v=DMARC1; p=none; rua=mailto:dmarc-rua@yourbrand.com; ruf=mailto:dmarc-ruf@yourbrand.com; fo=1; adkim=r; aspf=r; pct=100"
Looks like DMARC-ish TXT is present.

Sens : Vous avez au moins un enregistrement TXT ressemblant à DMARC renvoyé de manière cohérente.

Décision : Si plusieurs chaînes TXT apparaissent pour DMARC (plus d’un enregistrement), corrigez le DNS immédiatement ; les récepteurs peuvent se comporter de manière imprévisible.

Task 3: Inspecter l’enregistrement SPF actuel

cr0x@server:~$ dig +short TXT yourbrand.com | sed -n 's/^"//; s/"$//; /v=spf1/p'
v=spf1 include:spf.protection.outlook.com include:mailgun.org ip4:203.0.113.10 ~all

Sens : SPF existe et liste quelques fournisseurs plus une IP, avec un softfail en fin de ligne.

Décision : Si vous voyez plusieurs enregistrements SPF, consolidez. Si la chaîne d’includes est longue, vérifiez le nombre de recherches DNS ensuite.

Task 4: Compter les recherches DNS SPF (éviter le plafond des 10 lookups)

cr0x@server:~$ python3 - <<'PY'
import dns.resolver, re
domain="yourbrand.com"
visited=set()
def get_spf(d):
    txt=[]
    for r in dns.resolver.resolve(d,"TXT"):
        s="".join([b.decode() for b in r.strings])
        if s.startswith("v=spf1"):
            txt.append(s)
    return txt[0] if txt else None

lookups=0
def walk(d):
    global lookups
    if d in visited: return
    visited.add(d)
    spf=get_spf(d)
    if not spf: return
    for token in spf.split():
        if token.startswith("include:"):
            lookups += 1
            walk(token.split(":",1)[1])
        if token.startswith("redirect="):
            lookups += 1
            walk(token.split("=",1)[1])

walk(domain)
print("Estimated include/redirect lookups:", lookups)
print("Visited domains:", len(visited))
PY
Estimated include/redirect lookups: 2
Visited domains: 3

Sens : Vous êtes en dessous de la limite commune de 10 lookups SPF (ce script est approximatif ; l’évaluation réelle inclut d’autres mécanismes).

Décision : Si vous êtes proche ou au‑dessus de 10, simplifiez SPF avant de durcir DMARC. Sinon, vous « corrigez » le spoofing en cassant la livraison.

Task 5: Vérifier les enregistrements DKIM pour un expéditeur connu

cr0x@server:~$ dig +short TXT selector1._domainkey.yourbrand.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...snip..."

Sens : Une clé publique DKIM existe pour selector1. C’est nécessaire pour que les récepteurs valident les signatures DKIM de ce sélecteur.

Décision : Si vous ne connaissez pas les sélecteurs en usage, récupérez un en‑tête de message sortant récent et trouvez s= et d=.

Task 6: Vérifier l’alignement DMARC sur un message échantillon (depuis les en‑têtes)

cr0x@server:~$ awk 'BEGIN{RS="";FS="\n"} {for(i=1;i<=NF;i++) if($i ~ /Authentication-Results:/) print $i}' sample.eml
Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourbrand.com header.s=selector1 header.b=abc123;
       spf=pass (google.com: domain of bounce@mg.yourbrand.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@mg.yourbrand.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourbrand.com

Sens : DMARC passe parce qu’au moins SPF ou DKIM passe et s’aligne avec header.from=yourbrand.com. L’alignement DKIM est parfait ici.

Décision : Si DMARC échoue mais que SPF passe, il y a probablement SPF qui passe pour un autre domaine (désalignement). Corrigez l’alignement, pas « plus de SPF ».

Task 7: Localiser les sources en échec principales dans les XML RUA (vite fait)

cr0x@server:~$ ls -1 dmarc-rua/ | head
google.com!yourbrand.com!1735516800!1735603200.xml
outlook.com!yourbrand.com!1735516800!1735603200.xml

cr0x@server:~$ grep -RhoE '<source_ip>[^<]+' dmarc-rua/*.xml | sed 's/<source_ip>//' | sort | uniq -c | sort -nr | head
  482 203.0.113.10
  117 198.51.100.25
   41 192.0.2.77

Sens : Vous avez quelques IP principales qui génèrent le trafic vu par DMARC.

Décision : Identifiez chaque IP (votre MTA, un fournisseur, un mystère). Les IP inconnues à fort volume bloquent l’application.

Task 8: Mapper une IP suspecte à un fournisseur (whois + indice ASN)

cr0x@server:~$ whois 198.51.100.25 | egrep -i 'OrgName|org-name|descr|netname|origin|aut-num' | head
NetName:        EXAMPLE-NET
OrgName:        Example Email Services
OriginAS:       AS64500

Sens : Cette IP appartient probablement à un fournisseur ou du moins à un réseau identifiable.

Décision : Si ce n’est pas à vous, déterminez pourquoi elle envoie des mails se faisant passer pour vous. Soit vous l’autorisez et l’alignez, soit vous la bloquez par DMARC.

Task 9: Vérifier si vos sous‑domaines ont leurs propres enregistrements DMARC

cr0x@server:~$ for d in marketing.yourbrand.com status.yourbrand.com hr.yourbrand.com; do
  echo "== $d =="
  dig +short TXT _dmarc.$d
done
== marketing.yourbrand.com ==
"v=DMARC1; p=none; rua=mailto:dmarc-rua@yourbrand.com"
== status.yourbrand.com ==

== hr.yourbrand.com ==

Sens : Un sous‑domaine a sa propre politique ; les autres héritent du domaine organisationnel à moins qu’un sp= soit défini sur le parent.

Décision : Décidez si vous voulez une application différente pour les sous‑domaines. Si non, retirez les enregistrements DMARC égarés qui contredisent votre plan.

Task 10: Simuler un changement de politique en toute sécurité (utiliser pct=10 avec quarantaine)

cr0x@server:~$ cat <<'EOF'
_dmarc.yourbrand.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
EOF
_dmarc.yourbrand.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"

Sens : Ceci est l’enregistrement que vous proposez de publier : quarantaine, mais seulement pour 10% des mails échouant DMARC.

Décision : Si votre organisation ne tolère aucune mauvaise classification, maintenez pct bas plus longtemps et corrigez d’abord l’alignement. Si vous subissez du spoofing actif, montez plus vite.

Task 11: Vérifier la propagation DNS depuis plusieurs résolveurs

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "== resolver $r =="
  dig +short @$r TXT _dmarc.yourbrand.com
done
== resolver 1.1.1.1 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
== resolver 8.8.8.8 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"
== resolver 9.9.9.9 ==
"v=DMARC1; p=quarantine; pct=10; adkim=r; aspf=r; rua=mailto:dmarc-rua@yourbrand.com"

Sens : Le changement est visible depuis les grands résolveurs publics.

Décision : Si les résolveurs divergent pendant des heures, votre DNS met trop en cache ou vous avez publié plusieurs enregistrements. Ne montez pas la politique tant que le DNS n’est pas stable.

Task 12: Surveiller les logs mail pour des rebonds liés à DMARC (exemple Postfix)

cr0x@server:~$ sudo grep -E 'dmarc|policy|reject|quarantine' /var/log/mail.log | tail -n 20
Jan 04 10:21:16 mx1 postfix/smtp[18233]: host gmail-smtp-in.l.google.com[142.250.102.27] said: 550-5.7.26 Unauthenticated email from yourbrand.com is not accepted due to domain's DMARC policy. (in reply to end of DATA command)

Sens : Un récepteur a refusé une livraison explicitement à cause de votre politique DMARC. C’est soit un spoof bloqué (bon), soit un expéditeur légitime qui échoue à l’alignement (mauvais).

Décision : Récupérez le message en file, inspectez les en‑têtes, identifiez le système d’envoi réel, et corrigez l’alignement ou empêchez‑le d’utiliser votre domaine From.

Task 13: Confirmer qu’un tiers signe avec un DKIM aligné

cr0x@server:~$ grep -Eo 'dkim=[a-z]+|header.i=@[^;]+|header.s=[^;]+' sample-vendor.eml
dkim=pass
header.i=@vendor-mail.example
header.s=s1

Sens : DKIM a passé, mais la signature est de vendor-mail.example, pas de votre domaine. Cela ne s’alignera pas avec From yourbrand.com.

Décision : Configurez le DKIM personnalisé chez le fournisseur (préférable), ou migrez ce trafic vers un sous‑domaine que vous contrôlez (acceptable), ou changez le From pour un domaine qu’ils possèdent (souvent politiquement difficile, techniquement propre).

Task 14: Détecter le décalage « From domain » vs « envelope from » dans un message sortant

cr0x@server:~$ egrep -i '^(From:|Return-Path:)' sample.eml
Return-Path: <bounce@mg.yourbrand.com>
From: Billing <billing@yourbrand.com>

Sens : L’enveloppe est mg.yourbrand.com et le From visible est yourbrand.com. L’alignement SPF dépendra si l’alignement relaxé considère mg.yourbrand.com comme aligné (c’est le cas en relaxé, puisque c’est un sous‑domaine). En strict, ce serait un échec.

Décision : Si vous comptez passer en strict (aspf=s), l’enveloppe‑from doit correspondre exactement (ou vous devez compter sur l’alignement DKIM).

Task 15: Confirmer que votre enregistrement DMARC inclut une décision explicite pour les sous‑domaines

cr0x@server:~$ dig +short TXT _dmarc.yourbrand.com | tr -d '"' | tr ';' '\n' | sed 's/^ *//'
v=DMARC1
p=quarantine
pct=10
adkim=r
aspf=r
rua=mailto:dmarc-rua@yourbrand.com

Sens : Il n’y a pas de tag sp=. Les sous‑domaines héritent de p= par défaut, sauf s’ils publient leur propre DMARC.

Décision : Si vous avez beaucoup de sous‑domaines « sauvages », envisagez sp=none pendant que le parent passe en quarantaine/rejet. Ou faites l’inverse si les sous‑domaines sont abusés.

Task 16: Test rapide d’envoi depuis chaque système connu (minimal mais efficace)

cr0x@server:~$ swaks --to dmarc-test@externalmailbox.example --from noreply@yourbrand.com --server smtp.office365.com --auth-user noreply@yourbrand.com --auth-password 'REDACTED' --data "Subject: DMARC smoke test

hello"
=== Trying smtp.office365.com:587...
=== Connected to smtp.office365.com.
<** 220 ...
>** EHLO ...
<** 250-...
>** MAIL FROM:<noreply@yourbrand.com>
<** 250 2.1.0 Sender OK
>** RCPT TO:<dmarc-test@externalmailbox.example>
<** 250 2.1.5 Recipient OK
>** DATA
<** 354 Start mail input; end with <CRLF>.<CRLF>
>** .
<** 250 2.0.0 OK

Sens : Le message est accepté par votre système sortant. Le vrai contrôle se fait côté récepteur lorsque vous inspectez Authentication‑Results.

Décision : Faites‑le pour chaque plateforme (O365, Gmail, fournisseur marketing, ticketing). Si l’une ne peut pas produire de mail aligné, corrigez‑la avant le rejet.

Playbook de diagnostic rapide

Quand vous renforcez DMARC et que quelque chose casse, vous recevrez des rapports vagues : « les e‑mails n’arrivent pas ».
Votre travail est de transformer cela en un flux unique en échec et en une condition d’alignement qui échoue, rapidement.

Première étape : déterminer s’il s’agit d’un rejet, d’une quarantaine, ou autre

Demandez un bounce. S’il y a un message de rebond, lisez‑le. Si le rebond mentionne DMARC ou « unauthenticated », vous êtes dans la bonne zone.
Vérifiez la réponse SMTP du récepteur dans les logs. Vos logs MTA ont souvent le code d’état exact et le texte.
Vérifiez si l’utilisateur manque simplement le message (quarantaine). Si la politique est quarantaine, il peut atterrir dans les dossiers spam.

Deuxième étape : identifier quel expéditeur envoie réellement le message

Sortez le message du système expéditeur si possible (file d’attente, éléments envoyés archivés, logs applicatifs).
Extraites Return‑Path, From et DKIM d=.
Recoupez avec les rapports RUA pour trouver le volume et le taux d’échec pour cette IP source.

Troisième étape : décider si vous corrigez l’alignement SPF, DKIM, ou le domaine From

Si DKIM est présent et échoue : signature cassée (réécriture de contenu, clé invalide, mauvais sélecteur) ou mauvaise configuration fournisseur.
Si DKIM passe mais est non aligné : le fournisseur signe comme lui‑même ; il vous faut du DKIM personnalisé ou une stratégie de sous‑domaine.
Si SPF passe mais DMARC échoue : le domaine envelope‑from n’est pas aligné avec le From, ou le forwarding a cassé SPF et vous dépendiez de SPF.

Quatrième étape : contrôler le périmètre d’impact pendant la correction

Réduisez temporairement pct si nécessaire (surtout pendant la montée en quarantaine).
En cas d’urgence, repassez de reject à quarantine pendant que vous réparez — mais considérez cela comme un rollback, pas un mode permanent.
Communiquez clairement : quel expéditeur, quels flux, et délai estimé de restauration.

Listes de vérification / plan pas à pas : de none → quarantaine → rejet

Le déploiement DMARC le plus sûr est une migration contrôlée avec des portes mesurables. Voici le plan qui survit généralement à la réalité d’entreprise.

Phase 0 : Surveillance qui surveille réellement (1–4 semaines)

Publiez DMARC avec p=none, rua, et éventuellement ruf si vous pouvez traiter des données forensic sensibles. Beaucoup d’organisations sautent ruf.
Assurez‑vous que SPF existe et que DKIM est activé pour vos plateformes principales.
Mettez en place un workflow pour les rapports agrégés :
- Revue quotidienne durant la première semaine.
- Revue hebdomadaire ensuite jusqu’à stabilisation.
Créez un inventaire :
- Tous les expéditeurs légitimes.
- Les domaines qu’ils utilisent en From et envelope‑from.
- Le domaine DKIM avec lequel ils signent.
- Qui possède la configuration.

Porte pour avancer

Vous pouvez attribuer les 90–95% supérieurs du volume vu par DMARC à des systèmes connus.
Pour ces systèmes connus, vous avez un plan explicite pour corriger tout alignement en échec.
Vous avez au moins une « boîte externe » pour vérifier les en‑têtes.

Phase 1 : Quarantaine avec un pourcentage bas (1–3 semaines)

Configurez p=quarantine; pct=10 (ou 5 si vous êtes prudent).
Gardez l’alignement relaxé (aspf=r; adkim=r) sauf raison contraire.
Surveillez :
- Taux d’échec RUA par source.
- Tickets support mentionnant des e‑mails manquants ou des changements de dossiers spam.
- Logs de rebonds sortants.

Porte pour augmenter pct

Aucune source inconnue à fort volume n’échoue DMARC.
Tous les expéditeurs critiques métiers (transactionnel, facturation, auth, RH) passent DMARC de façon fiable.
L’impact utilisateur est gérable et compris (les faux positifs en quarantaine sont tracés jusqu’à un expéditeur et une correction).

Phase 2 : Quarantaine à 25 → 50 → 100 (2–6 semaines)

Montez à 25%, puis 50%, puis 100% avec plusieurs jours entre chaque étape.
Chaque étape doit comporter :
- Un ticket de changement avec instructions de rollback.
- Un propriétaire nommé surveillant RUA et logs mail.
- Une liste des expéditeurs sur watchlist (fournisseurs, applis legacy).

Phase 3 : Rejet avec montée de pct (1–4 semaines)

Passez à p=reject; pct=10, puis montez comme ci‑dessus.
Gardez la quarantaine comme étape de rollback (plus rapide que revenir à none).
Une fois stable en reject, envisagez :
- Alignement strict pour SPF/DKIM si votre écosystème le permet.
- Verrouiller le comportement des sous‑domaines avec sp=.

Ce qu’il ne faut pas faire

Ne passez pas de none à reject parce que « on a activé DKIM dans Microsoft 365 ». Vous avez plus d’expéditeurs que vous ne le croyez.
N’utilisez pas DMARC pour masquer « on ne sait pas qui envoie des mails ». DMARC vous forcera à savoir. C’est le but.
Ne définissez pas l’alignement strict tôt sauf si vous êtes sûr des envelope‑from et du DKIM des fournisseurs.

Trois mini‑histoires d’entreprise (anonymisées, douloureusement plausibles)

Mini‑histoire 1 : L’incident causé par une fausse hypothèse

Une fintech de taille moyenne a décidé qu’il était temps de passer à p=reject. Ils étaient en p=none depuis des mois, voyaient beaucoup de spoofing et subissaient la pression d’audits sécurité.
L’équipe e‑mail partait d’une hypothèse simple : « Tout le mail vient de Microsoft 365, plus la plateforme marketing que nous avons déjà signée en DKIM. »

Le lundi matin, ils ont basculé à reject à 100%. En une heure, les e‑mails d’onboarding client n’arrivaient plus chez plusieurs gros fournisseurs de boîtes grand public.
Les ventes ont dit « problème de délivrabilité ». Le support a appelé « le système mail est en panne ». L’ingénierie : « on n’a rien changé ».

La cause racine était un troisième système : un fournisseur d’identité envoyant des « magic links ». Il utilisait From: noreply@yourbrand.com mais signait DKIM avec le domaine du fournisseur.
SPF passait aussi — pour le domaine du fournisseur. Sous p=none, les récepteurs livraient quand même. Sous reject, DMARC échouait l’alignement et le message était refusé.

La correction n’a pas été héroïque. Ils ont activé le DKIM personnalisé du fournisseur pour yourbrand.com et ajusté l’enveloppe‑from vers un sous‑domaine aligné.
La partie difficile était organisationnelle : l’équipe identité gérait ce fournisseur, et l’équipe e‑mail n’avait pas été invitée au déploiement.

Leçon durable : vos plus grands risques DMARC ne viennent pas des systèmes que vous connaissez. Ils viennent de ceux achetés avec une carte et une deadline.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Un détaillant mondial avait un SPF compliqué : multiples includes, expéditeurs régionaux, quelques IP legacy.
Quelqu’un a tenté d’« optimiser » en aplatissant SPF en une longue liste d’IP pour éviter la limite de lookups et réduire la latence côté récepteur.

Ça a marché un temps. Puis un fournisseur a tourné ses IP sortantes. Comme le processus d’aplatissement était manuel et mal documenté, l’enregistrement SPF a pris du retard.
Certains récepteurs ont commencé à échouer SPF ; DMARC passait parfois grâce à DKIM, mais pas toujours — parce que quelques systèmes ne signaient pas DKIM de façon cohérente.

Quand l’équipe est passée en p=quarantine, ces cas marginaux sont allés en spam. Le plus ennuyeux : c’était intermittent, lié à l’IP sortante utilisée à l’instant T.

Ils sont revenus temporairement à p=none. Puis ont fait le travail peu sexy :
standardiser DKIM pour les expéditeurs transactionnels, automatiser les mises à jour SPF quand nécessaire, et arrêter de compter sur SPF comme seule méthode alignée.

Leçon d’optimisation : si vous « simplifiez » SPF d’une manière qui la rend moins maintenable, vous n’avez rien simplifié. Vous avez juste déplacé la douleur vers l’incident response.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société B2B a mené un déploiement DMARC lent. La sécurité voulait reject. Le marketing était nerveux. La finance était la plus bruyante.
Le responsable e‑mail a insisté pour un calendrier de changements et de petits ramp‑ups de pct avec plan de rollback et une watchlist explicite des expéditeurs.

Pendant le passage de quarantaine de 25% à 50%, les rapports agrégés ont montré une nouvelle IP source en échec, faible volume mais fort taux d’échec.
Ce n’était pas du spoofing. C’était un nouvel outil customer success envoyant des « résumés de réunion » en tant que from=yourbrand.com au nom du personnel.

Parce que le déploiement avait des portes, rien de catastrophique ne s’est produit. L’équipe a fait une pause à 50% et n’a pas continué.
Ils ont redirigé cet outil vers un sous‑domaine dédié, activé le DKIM personnalisé, et vérifié l’alignement avec des messages de test.

Deux semaines plus tard ils ont repris la montée, atteint le reject, et personne en dehors de l’équipe e‑mail ne l’a remarqué — mon type de succès préféré.

Citation (idée paraphrasée) de Gene Kranz : « “Failure isn’t an option” est moins un slogan qu’une discipline — préparez‑vous pour ne pas compter sur la chance. »

Erreurs courantes : symptômes → cause → correction

Voici les récidivistes. Vous pouvez les repérer via le pattern de plaintes.

1) Symptom : « Seuls certains destinataires ne reçoivent pas nos mails » après le passage en reject

Cause racine : chemins d’envoi mixtes. Un chemin s’aligne (DKIM ou SPF), un autre non (souvent un fournisseur ou un système régional).

Correction : Utilisez les rapports RUA pour segmenter par IP source et identifier le système en échec. Activez DKIM aligné pour cet expéditeur ou déplacez le From vers un sous‑domaine aligné.

2) Symptom : Les e‑mails atterrissent en spam juste après la quarantaine, mais DMARC passe dans vos tests

Cause racine : La quarantaine ne garantit pas une position spam uniquement pour les échecs DMARC ; elle modifie le score des récepteurs. Aussi, vos tests peuvent ne couvrir qu’un expéditeur.

Correction : Testez chaque chemin d’expédition majeur. Confirmez le passage DMARC et l’alignement dans Authentication‑Results. Si le passage est cohérent, regardez la réputation/contenu, pas la politique DMARC.

3) Symptom : DMARC échoue malgré SPF affichant « pass » dans les en‑têtes

Cause racine : SPF a passé pour un domaine différent du From visible (désalignement). Commun avec les fournisseurs qui utilisent leur propre domaine de rebond.

Correction : Configurez un return‑path / envelope‑from personnalisé sous votre domaine (sous‑domaine aligné) ou comptez sur un DKIM aligné.

4) Symptom : DKIM passe parfois et échoue d’autres fois pour le même système

Cause racine : modification du message en transit (pieds de page, disclaimers, réécriture de liens), plusieurs signataires DKIM avec config inconsistante, ou rotation de clé/sélecteur incomplète.

Correction : Signez après modification (au dernier saut que vous contrôlez), réduisez la réécriture en aval, et assurez‑vous que sélecteurs et clés sont déployés avant de changer de signeurs.

5) Symptom : Pics d’échec DMARC après activation de l’alignement strict

Cause racine : L’alignement strict exige une correspondance exacte. L’enveloppe‑from sur un sous‑domaine (par ex. mg.yourbrand.com) n’est plus alignée avec yourbrand.com pour SPF.

Correction : Gardez l’alignement relaxé sauf si vous avez de bonnes raisons. Si vous passez en strict, assurez‑vous que DKIM signe avec le domaine From exact, ou changez l’enveloppe‑from en conséquence.

6) Symptom : Certains mails transférés (surtout vers des comptes perso) commencent à échouer après le rejet

Cause racine : Les forwarders peuvent casser SPF et parfois DKIM. DMARC échoue alors chez le récepteur final.

Correction : Favorisez l’alignement DKIM pour les mails importants et envisagez des flux compatibles ARC. Pour les listes de diffusion, considérez la configuration qui respecte DMARC (peut impliquer la réécriture du From).

7) Symptom : Les rapports RUA sont vides ou de très faible volume

Cause racine : l’adresse rua n’est pas acceptée par les récepteurs (certains valident), mailbox problématique, faute de frappe DNS, ou vous avez très peu de trafic via des récepteurs qui envoient des rapports.

Correction : Vérifiez que rua est correct, que la boîte reçoit du courrier, et que le record DMARC est visible. Envisagez plusieurs boîtes RUA si utile opérationnellement.

8) Symptom : Vous publiez DMARC mais rien ne change

Cause racine : Vous testez avec du mail qui passe déjà DMARC, ou les récepteurs ignorent la politique à cause d’un record mal formé, de multiples TXT DMARC, ou du mauvais domaine.

Correction : Validez un seul record TXT DMARC à _dmarc.yourbrand.com et testez un message connu en échec (de manière éthique et contrôlée).

Blague n°2 : L’authentification email est le seul projet de sécurité où vous pouvez être « totalement conforme » et quand même perdre face à une newsletter transférée.

FAQ

1) Quand devrais‑je passer de quarantaine à rejet ?

Passez quand vos rapports agrégés montrent que les expéditeurs légitimes à fort volume passent DMARC de façon cohérente, et que les sources inconnues en échec sont de faible volume ou clairement malveillantes.
Concrètement : quand vous pouvez nommer chaque expéditeur significatif et qu’il y a un responsable pour chaque configuration.

2) Est‑il sûr d’aller directement de p=none à p=reject ?

Seulement si vous avez une surface d’envoi très petite et strictement contrôlée et que vous avez déjà validé l’alignement pour chaque expéditeur.
La plupart des organisations se croient petites et contrôlées. La plupart ont tort. Utilisez la quarantaine et les rampes pct sauf en cas de crise de spoofing active.

3) À quoi sert réellement pct ?

pct demande aux récepteurs d’appliquer la politique seulement à un pourcentage des messages qui échouent l’évaluation DMARC.
Ce n’est pas un algorithme d’échantillonnage garanti et les récepteurs l’implémentent différemment, mais c’est utile comme levier d’application graduelle.

4) Ai‑je besoin à la fois de SPF et DKIM pour DMARC ?

Strictement : non, DMARC peut passer avec SPF ou DKIM. Opérationnellement : oui, vous voulez les deux.
DKIM est particulièrement important car SPF est fragile face au forwarding et au relaying.

5) Dois‑je définir aspf=s et adkim=s (alignement strict) ?

Pas tôt. Commencez relax. L’alignement strict sert quand vous voulez réduire les abus marginaux et que vous contrôlez bien les fournisseurs et sous‑domaines.
L’alignement strict est aussi une excellente façon de découvrir des dépendances cachées à 2 h du matin.

6) Et les sous‑domaines — héritent‑ils de la politique du parent ?

Par défaut, les sous‑domaines utilisent la politique DMARC du domaine organisationnel sauf s’ils publient leur propre enregistrement DMARC.
Si vous définissez sp= sur le parent, vous pouvez définir une politique spécifique pour les sous‑domaines.

7) Pourquoi certains fournisseurs « supportent DMARC » mais échouent quand même l’alignement ?

Beaucoup de fournisseurs entendent par là « nous supportons SPF et DKIM pour notre propre domaine ». Ce n’est pas suffisant si vous voulez envoyer en tant que votre domaine.
Il vous faut généralement du DKIM personnalisé (signature avec votre domaine) et parfois un return‑path personnalisé sous votre domaine.

8) DMARC arrêtera‑t‑il tout le phishing utilisant ma marque ?

Il arrête le spoofing de domaine direct (l’attaquant utilise From: ceo@yourbrand.com en envoyant depuis ailleurs) chez les récepteurs qui appliquent DMARC.
Il ne stoppe pas les domaines ressemblants, le spoofing du nom d’affichage, ou les comptes légitimes compromis.

9) Quel est le plus grand risque opérationnel du rejet DMARC ?

Casser des mails légitimes provenant d’un système que vous ignoriez utiliser votre domaine From, ou d’un fournisseur incapable de s’aligner.
Cela impacte d’abord les e‑mails transactionnels, précisément ceux que vous ne pouvez pas vous permettre de perdre.

10) Si je subis du spoofing actif aujourd’hui, quel est le mouvement sûr le plus rapide ?

Passez rapidement à p=quarantine; pct=100 si vous avez un alignement basique pour vos plateformes principales, puis accélérez la remédiation et montez vers le rejet.
Si vous pouvez affirmer la cohérence de l’alignement DKIM pour votre mail cœur, vous pouvez aller plus vite vers le reject — mais faites‑le avec surveillance et personnel en poste.

Conclusion : prochaines étapes que vous pouvez exécuter cette semaine

DMARC quarantaine et rejet ne sont pas des positions philosophiques. Ce sont des modes d’application.
La quarantaine est la façon d’apprendre sans planter le business. Le rejet est la façon de capitaliser cet apprentissage et de rendre le spoofing nettement plus difficile.

Étapes pratiques :

Vérifiez vos enregistrements DNS DMARC/SPF/DKIM actuels et confirmez qu’il n’y a qu’un seul enregistrement DMARC.
Activez le reporting RUA s’il manque et commencez à collecter les rapports agrégés quotidiennement.
Construisez votre inventaire d’expéditeurs à partir des IP sources RUA et des en‑têtes Authentication‑Results.
Corrigez d’abord l’expéditeur légitime en échec le plus important (souvent un fournisseur avec DKIM non aligné).
Passez à p=quarantine; pct=10 avec un plan de rollback, puis montez délibérément.
Évoluez vers p=reject une fois que vos flux critiques connus passent DMARC de manière cohérente et que les sources inconnues ne vous appartiennent clairement pas.

La condition de réussite est silencieuse : moins de messages usurpés sont livrés, moins d’utilisateurs doivent deviner, et votre email cesse d’être une hallucination partagée entre expéditeurs et récepteurs.