Alignement DMARC : ce que c’est et comment le configurer correctement

novembre 15, 2025 • février 3, 2026 • Lecture : 28 min • Views: 9

Cet article vous a aidé ?

Votre message « passe SPF » et « passe DKIM »… et pourtant DMARC échoue, les messages atterrissent dans les indésirables, ou pire : ils disparaissent dans le vide chez certains destinataires d’entreprise. Ce n’est pas de la malchance. C’est de l’alignement.

L’alignement DMARC est le videur qui vérifie les pièces d’identité à la porte. SPF et DKIM sont vos justificatifs. Si le nom sur la pièce ne correspond pas au nom sur le billet (From:), vous n’entrez pas — du moins pas de façon fiable, et certainement pas quand on active p=quarantine ou p=reject.

L’alignement DMARC en termes simples (et pourquoi vous devez vous en soucier)

DMARC ne concerne pas principalement le fait que SPF ou DKIM « fonctionnent ». Il s’agit de savoir si l’authentification obtenue concerne le domaine que l’utilisateur voit. Ce domaine visible par l’utilisateur est celui dans l’en‑tête RFC5322 From: (ce que les clients mail affichent comme expéditeur).

Alignement signifie : le domaine authentifié via SPF et/ou DKIM doit « correspondre » (selon des règles strictes ou relax) au domaine dans From:. DMARC réussit lorsque :

SPF passe et le domaine authentifié par SPF est aligné avec From:, ou
DKIM passe et le domaine de signature DKIM est aligné avec From:.

La plupart des incidents et problèmes de délivrabilité surviennent parce que quelqu’un a lu « SPF pass » dans un en‑tête et s’est arrêté là. C’est comme dire « le certificat SSL est valide » sans vérifier qu’il a été émis pour votre nom d’hôte.

Ce que l’alignement n’est pas

Ce n’est pas « SPF a‑t‑il passé ? » (SPF peut passer pour un domaine de rebond non lié.)
Ce n’est pas « DKIM a‑t‑il passé ? » (DKIM peut passer pour un domaine fournisseur.)
Ce n’est pas « DMARC existe ? » (Publier un enregistrement DMARC ne garantit pas que votre mail est aligné.)

Pourquoi c’est important en production

L’alignement est la façon dont les récepteurs distinguent « mail légitime de example.com » d’un « serveur quelconque qui peut passer SPF pour mailer.vendor.com tout en falsifiant From: example.com ». Sans alignement, SPF/DKIM sont utiles mais pas systématiquement liés à l’identité de la marque. Avec alignement + application, vous réduisez mesurablement l’usurpation et améliorez le signal vers la boîte de réception.

Faits intéressants et courte histoire

DMARC est apparu parce que SPF et DKIM résolvaient des problèmes différents mais laissaient un vide : aucun d’eux n’exigeait que le domaine authentifié corresponde au domaine expéditeur visible.
SPF vérifie l’identité « envelope‑from » (Return‑Path), pas le From: visible par l’utilisateur. Ce décalage est l’origine de nombreux incidents « mais SPF a passé ! ».
DKIM visait initialement l’intégrité du message et la responsabilité au niveau domaine, c’est pourquoi les signatures DKIM survivent à de nombreux sauts, mais pas à toutes les modifications.
DMARC a formalisé des boucles de rétroaction côté récepteur via des rapports agrégés (RUA) pour que les propriétaires de domaine découvrent des expéditeurs inconnus et des erreurs de configuration.
L’alignement relax existe parce qu’internet est désordonné : les organisations envoient régulièrement depuis des sous‑domaines, et une correspondance stricte bloquerait des usages légitimes.
Le transfert (forwarding) a cassé SPF bien avant DMARC ; le « pass via DKIM alignment » de DMARC donne un chemin survivable quand le transfert change l’IP d’envoi.
Le réglage « pct » de DMARC a été conçu pour un déploiement progressif afin que vous puissiez appliquer la politique sans transformer votre support en hotline.
ARC (Authenticated Received Chain) est arrivé plus tard pour aider à préserver les résultats d’authentification à travers des intermédiaires — utile, mais pas une excuse pour ignorer l’alignement.

Comment l’alignement fonctionne réellement (SPF vs DKIM)

Commencez par les identités : trois « from » que l’on confond

Le courriel a plusieurs identités qui se ressemblent jusqu’à ce qu’elles vous gâchent la journée :

RFC5322.From : le From: visible. DMARC utilise ceci comme référence.
RFC5321.MailFrom (envelope‑from) : utilisé pour les rebonds ; apparaît comme Return-Path: après livraison. SPF authentifie ce domaine.
DKIM d= : le domaine de signature dans la signature DKIM. DKIM authentifie ce domaine.

Condition de réussite DMARC (version opérationnelle)

DMARC se soucie du domaine dans From: et pose les questions :

SPF a‑t‑il passé pour un domaine MailFrom quelconque ?
Si oui, ce domaine MailFrom est‑il aligné avec le domaine From: ?
DKIM a‑t‑il passé pour une signature avec d= ?
Si oui, ce d= est‑il aligné avec le domaine From: ?

Si l’un des chemins SPF aligné ou DKIM aligné passe, DMARC passe. Si aucun n’est aligné, DMARC échoue, peu importe les mentions « pass » ailleurs.

Que signifie « aligner » en pratique

L’alignement compare des domaines, pas des adresses complètes. DMARC évalue généralement le domaine organisationnel (approximativement : domaine enregistrable) basé sur la Public Suffix List.

Exemples :

From: billing.example.com s’aligne (relax) avec mail.example.com parce qu’ils partagent example.com comme domaine organisationnel.
From: example.com ne s’aligne pas avec mail.vendor.com. C’est précisément le but.

Alignement SPF : pourquoi ça échoue plus souvent

L’alignement SPF utilise le domaine dans l’envelope‑from (MailFrom). Beaucoup d’expéditeurs SaaS utilisent leur propre domaine de rebond comme bounces.vendor.com. SPF peut passer pour cela, mais n’alignera pas avec From: example.com. Sauf si le fournisseur supporte un MailFrom personnalisé / return‑path brandé / domaine de rebond personnalisé.

De plus, SPF est évalué par rapport à l’IP de connexion. Les forwarders changent l’IP de connexion. SPF perd son argent de poche derrière le gymnase.

Alignement DKIM : généralement le cheval de trait

L’alignement DKIM utilise le domaine d= de DKIM. Si vous pouvez signer avec d=example.com (ou un sous‑domaine aligné), vous survivez aux transferts et à beaucoup de relais parce que DKIM porte sur la signature des en‑têtes et du corps, pas sur l’IP d’envoi.

Mais DKIM est fragile d’une autre manière : si des intermédiaires réécrivent le message (pieds de page, préfixes de sujet, changement d’encodage MIME), la signature peut se casser. Ce n’est pas théorique ; c’est mardi.

Une citation (idée paraphrasée) qui a sa place dans votre pipeline mail

Idée paraphrasée : l’espoir n’est pas une stratégie ; utilisez la télémétrie et l’automatisation pour rendre les échecs visibles et récupérables. — attribué à divers ingénieurs fiabilité, popularisé en culture SRE

Alignement strict vs relax (aspf/adkim)

L’alignement DMARC dispose de deux réglages :

aspf : mode d’alignement SPF
adkim : mode d’alignement DKIM

Alignement relax (r) : ce que ça permet réellement

Relax signifie que les sous‑domaines sont OK tant que le domaine organisationnel correspond. Donc From: example.com s’aligne avec MailFrom: bounce.example.com et avec DKIM d=mail.example.com (si le domaine org est example.com).

Conseil d’opinion : commencez par l’alignement relax à moins d’avoir une bonne raison d’être strict. Le strict n’est pas « plus sûr » s’il pousse les équipes à bricoler ou rend les fournisseurs impossibles à configurer correctement.

Alignement strict (s) : quand vous pouvez vous permettre d’être pointilleux

Strict signifie que les domaines doivent correspondre exactement. Si votre From: visible est example.com, alors MailFrom SPF doit être example.com (pas bounce.example.com), et DKIM d= doit être example.com (pas mail.example.com).

Strict est viable si :

vous contrôlez étroitement tous les expéditeurs sortants, et
vous ne dépendez pas d’un zoo de plates‑formes SaaS, et
vous êtes prêt à mettre en place des processus pour le maintenir.

Blague #1 : L’alignement strict, c’est comme un code vestimentaire dans une startup : ça semble ferme jusqu’à ce que vous réalisiez que votre CEO porte un sweat à capuche taché depuis 2017.

Sous‑domaines : alignement et héritage DMARC

La politique DMARC publiée sur _dmarc.example.com s’applique à example.com. Les sous‑domaines peuvent hériter sauf si vous publiez des enregistrements par sous‑domaine, et vous pouvez utiliser le tag sp= pour préciser la politique pour les sous‑domaines.

Opérationnellement, les sous‑domaines sont là où la « confusion d’alignement » devient « incident d’alignement ». Le marketing veut news.example.com, le produit veut notify.example.com, le support utilise support.example.com, et quelqu’un des RH branche un nouveau fournisseur d’enquêtes qui exige From: example.com parce que « marque ». Voilà comment on obtient des échecs DMARC à grande échelle.

Comment concevoir l’alignement pour de vrais expéditeurs (humains, apps, SaaS)

Décidez de la stratégie de domaine pour le `From`

Vous avez besoin d’une politique cohérente pour ce qui apparaît dans From:. Choisissez un des schémas suivants et engagez‑vous :

Schéma A : un domaine pour tout (From: example.com). Plus simple pour les utilisateurs ; plus difficile pour l’alignement car chaque expéditeur doit s’aligner parfaitement.
Schéma B : sous‑domaines fonctionnels (billing.example.com, news.example.com). Séparation plus claire et intégration des fournisseurs facilitée. Les utilisateurs le remarquent, mais ils remarquent aussi quand vos mails rebondissent.
Schéma C : domaine d’envoi dédié (mail.example.com) tout en gardant le domaine corporate example.com pour les humains. Fortement recommandé dans de nombreuses organisations car cela réduit l’impact en cas de problème.

Mon biais : Schéma B ou C. Si votre domaine est une cuisine partagée, ne stockez pas le poulet cru à côté du gâteau d’anniversaire.

Choisissez comment DMARC passera : « DKIM‑first » est généralement sensé

Pour les écosystèmes de sortie modernes, considérez l’alignement DKIM comme le chemin principal vers la réussite DMARC. Configurez SPF aussi, mais ne supposez pas qu’il survivra au forwarding, aux listes de diffusion et aux passerelles « utiles ».

Checklist d’intégration fournisseur (centrée sur l’alignement)

Quand une plateforme SaaS envoie en votre nom, vous avez besoin de ces capacités :

DKIM personnalisé avec d= sur votre domaine (ou sous‑domaine aligné).
MailFrom / return‑path personnalisé (optionnel mais précieux) pour obtenir aussi l’alignement SPF.
Support pour plusieurs sélecteurs DKIM afin de permettre la rotation sans interruption.
Documentation claire sur la réécriture des en‑têtes pour que DKIM survive.

Si un fournisseur ne peut pas faire du DKIM personnalisé, ne le laissez pas utiliser votre domaine From: principal. Donnez‑lui un sous‑domaine ou une surface de marque différente. DMARC est une politique. La politique peut dire « non ».

Comment l’alignement interagit avec les listes de diffusion et les forwarders

Les listes de diffusion modifient souvent les messages (ajout de pied de page, préfixes de sujet). Cela peut casser DKIM. Les forwarders cassent SPF. DMARC se trouve au milieu et dit : « apportez‑moi une authentification alignée ».

Les récepteurs peuvent utiliser ARC pour préserver les signaux d’authentification en amont, mais vous ne pouvez pas en dépendre. Votre levier contrôlable est : rendre DKIM robuste (choix de canonicalization, éviter le munging de contenu quand c’est possible) et minimiser la dépendance à SPF pour le passage DMARC.

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

Ce sont les tâches que j’exécute réellement lorsque je débogue l’alignement en production. Chacune inclut une commande, une sortie d’exemple, ce que cela signifie et la décision à prendre.

Task 1: Pull the DMARC record and sanity-check tags

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

Ce que cela signifie : DMARC existe, l’application est en quarantine, les deux alignements sont relax, déploiement complet.

Décision : Si vous voyez encore des échecs DMARC, le problème concerne l’alignement/l’authentification, pas « enregistrement manquant ». Si p=none, vous êtes en mode observation et vous devez planifier l’application.

Task 2: Check DMARC for a subdomain you think is “covered”

cr0x@server:~$ dig +short TXT _dmarc.news.example.com

Ce que cela signifie : Aucun enregistrement DMARC explicite au sous‑domaine.

Décision : Confirmez si vous comptez sur l’héritage et si sp= est défini au domaine organisationnel. Si le marketing envoie depuis news.example.com, vous voulez probablement un enregistrement explicite (ou au moins une politique sp= réfléchie).

Task 3: Check whether SPF is present for the From domain (not enough, but necessary)

cr0x@server:~$ dig +short TXT example.com | sed -n 's/.*"\(v=spf1[^"]*\)".*/\1/p'
v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

Ce que cela signifie : SPF autorise une IP spécifique et l’ensemble SPF de Google. La politique SPF finit par -all (échec dur).

Décision : Si vous utilisez des expéditeurs SaaS, assurez‑vous que leurs plages d’envoi sont incluses (directement ou via leur include). Mais aussi : planifiez l’alignement SPF en contrôlant MailFrom, pas seulement en publiant SPF.

Task 4: Count SPF DNS lookups (the hidden failure mode)

cr0x@server:~$ spfquery -debug -ip 203.0.113.10 -sender bounce@example.com -helo mx.example.com 2>&1 | tail -n 12
...
spfquery: using default zone: example.com
spfquery: found TXT record: v=spf1 ip4:203.0.113.10 include:_spf.google.com -all
spfquery: include:_spf.google.com
spfquery: result: pass

Ce que cela signifie : L’évaluation SPF pour cet expéditeur/IP passe.

Décision : Si vous voyez des erreurs de limite de lookup dans des en‑têtes réels (permerror), vous devez aplatir ou simplifier SPF. Un « pass » en labo n’est pas une preuve si la production contient plus d’includes que ce que vous avez testé.

Task 5: Fetch DKIM selector TXT records (vendor or internal)

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

Ce que cela signifie : La clé publique DKIM est publiée pour le sélecteur s1.

Décision : Si DKIM échoue chez les récepteurs, confirmez que le signataire utilise ce sélecteur et domaine. Si un fournisseur dit « nous signons », vérifiez le d= et s= réels dans les en‑têtes.

Task 6: Inspect a real message header for DMARC/SPF/DKIM and alignment hints

cr0x@server:~$ grep -E '^(From:|Return-Path:|Authentication-Results:|DKIM-Signature:)' -n sample.eml | sed -n '1,120p'
3:From: "Example Billing" <billing@example.com>
8:Return-Path: <bounce-123@mailer.vendor.com>
41:DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailer.vendor.com; s=dkim1; ...
72:Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-123@mailer.vendor.com designates 203.0.113.55 as permitted sender) smtp.mailfrom=bounce-123@mailer.vendor.com;
       dkim=pass header.i=@mailer.vendor.com header.s=dkim1 header.b=...;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Ce que cela signifie : SPF a passé pour mailer.vendor.com et DKIM a passé pour mailer.vendor.com, mais le From: est example.com. Aucun n’authentifie example.com. DMARC échoue à cause du désalignement.

Décision : Exigez que le fournisseur supporte DKIM personnalisé (signature avec d=example.com ou un sous‑domaine aligné) et de préférence MailFrom personnalisé. S’ils ne peuvent pas, changez le domaine visible From vers un sous‑domaine que le fournisseur peut aligner (par ex. billing.example.com) et publiez DMARC pour ce sous‑domaine.

Task 7: Validate that DKIM aligns with From (domain comparison)

cr0x@server:~$ python3 - <<'PY'
import re,sys
data=open("sample.eml","r",errors="ignore").read().splitlines()
from_dom=None
dkim_d=None
for line in data:
    if line.lower().startswith("from:"):
        m=re.search(r'@([A-Za-z0-9.-]+)', line)
        if m: from_dom=m.group(1).lower()
    if line.lower().startswith("dkim-signature:"):
        m=re.search(r'\bd=([A-Za-z0-9.-]+)', line)
        if m: dkim_d=m.group(1).lower()
print("from=",from_dom)
print("dkim d=",dkim_d)
PY
from= example.com
dkim d= mailer.vendor.com

Ce que cela signifie : Pas d’alignement ni strict ni relax (domaines organisationnels différents).

Décision : Corrigez le domaine de signature DKIM ou déplacez le domaine From pour correspondre à ce qui peut être authentifié.

Task 8: Check your MTA is actually signing DKIM for the right domain

cr0x@server:~$ sudo opendkim-testkey -d example.com -s s1 -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: key OK

Ce que cela signifie : Le sélecteur est présent et correspond à la clé privée configurée localement (au moins selon OpenDKIM).

Décision : Si cela échoue, corrigez le DNS ou le chemin de la clé locale avant de poursuivre DMARC. Pas de DKIM aligné, pas de réussite DMARC fiable en cas de forwarding.

Task 9: Confirm what Return-Path / MailFrom your outbound system uses

cr0x@server:~$ postconf -n | grep -E '^(myhostname|mydomain|myorigin|smtp_mail_name|sender_canonical_maps|smtp_generic_maps)'
myhostname = mx1.example.com
mydomain = example.com
myorigin = $mydomain

Ce que cela signifie : Identité Postfix de base. Cela ne garantit pas l’alignement MailFrom, mais indique les valeurs par défaut et si des maps de réécriture peuvent exister.

Décision : Si un relais ou une application définit envelope‑from différemment, suivez‑la. Aligner SPF implique souvent de contrôler cette identité d’enveloppe, pas seulement le DNS.

Task 10: Test SMTP submission and capture what the server adds

cr0x@server:~$ swaks --to you@recipient.test --from billing@example.com --server smtp.example.com --data <(printf 'Subject: test\n\nhello\n') --header "Date: $(date -R)"
=== Trying smtp.example.com:25...
=== Connected to smtp.example.com.
<** 250 2.0.0 Ok: queued as 9F2A8123

Ce que cela signifie : Message accepté pour livraison.

Décision : Récupérez les en‑têtes du message livré côté destinataire (ou votre boîte de test) et vérifiez d= DKIM, smtp.mailfrom SPF, et le résultat DMARC. « Queued » n’est pas « aligné ».

Task 11: Parse Authentication-Results for aligned identifiers quickly

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;
       spf=pass ... smtp.mailfrom=bounce-123@mailer.vendor.com;
       dkim=pass header.i=@mailer.vendor.com ...;
       dmarc=fail ... header.from=example.com

Ce que cela signifie : Cela montre les identités utilisées par le récepteur : smtp.mailfrom et header.i vs header.from.

Décision : Si smtp.mailfrom ou header.i ne sont pas dans la famille de vos domaines, l’alignement ne peut pas passer. Corrigez l’expéditeur, pas l’enregistrement DMARC.

Task 12: Verify organizational domain logic (public suffix pitfalls)

cr0x@server:~$ python3 - <<'PY'
from publicsuffix2 import get_sld
tests=["example.com","billing.example.com","example.co.uk","a.b.example.co.uk"]
for t in tests:
    print(t,"->",get_sld(t))
PY
example.com -> example.com
billing.example.com -> example.com
example.co.uk -> example.co.uk
a.b.example.co.uk -> example.co.uk

Ce que cela signifie : L’alignement relax de DMARC compare les domaines organisationnels, qui diffèrent pour des suffixes comme .co.uk.

Décision : Si votre organisation utilise des domaines code‑pays, soyez prudent en supposant ce que « relax » va matcher. Votre DNS et vos configurations fournisseurs doivent correspondre à la vraie frontière du domaine organisationnel.

Task 13: Check DMARC “sp=” behavior for subdomains

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

Ce que cela signifie : Le domaine racine est en reject ; les sous‑domaines par défaut passent en quarantine sauf s’ils sont surchargés.

Décision : Si vous migrez des expéditeurs vers des sous‑domaines pour réduire le risque, sp peut vous surprendre. Un DMARC explicite sur le sous‑domaine évite les réunions « pourquoi le marketing est en quarantaine ? ».

Task 14: Confirm the domain has a valid MX and isn’t mis-typed (yes, this happens)

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Ce que cela signifie : Le routage mail existe ; pas directement lié à l’alignement, mais un indicateur fréquent que le domaine est géré volontairement.

Décision : S’il n’y a pas de MX et que vous envoyez depuis ce domaine, certains récepteurs le traitent comme suspect. Pour un domaine d’envoi uniquement, vous pouvez quand même publier des MX ou au moins assurer une bonne hygiène générale.

Task 15: Check for multiple DMARC TXT records (receiver-dependent chaos)

cr0x@server:~$ dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com"
"v=DMARC1; p=reject; rua=mailto:security@example.com"

Ce que cela signifie : Deux enregistrements DMARC existent. C’est invalide ; les récepteurs peuvent en choisir un, ignorer les deux, ou se comporter de façon incohérente.

Décision : Corrigez le DNS immédiatement : publiez exactement un enregistrement DMARC par domaine. C’est un problème « arrêt du saignement » avant tout dépannage plus approfondi.

Guide de diagnostic rapide

Si vous avez 15 minutes avant qu’on n’escalade « panne email », ne vous éparpillez pas. Vérifiez ceci dans l’ordre.

Première étape : confirmez que l’échec est lié à l’alignement, pas à l’auth basique

Récupérez un en‑tête de message en échec dans une boîte destinataire (préférez Gmail ou Microsoft, ils sont verboses).
Trouvez Authentication-Results et lisez trois champs : header.from, smtp.mailfrom, et header.i (identité DKIM).
Si SPF/DKIM sont « pass » mais que les identités ne correspondent pas à header.from, c’est de l’alignement.

Deuxième étape : identifiez quel chemin doit être votre voie de réussite DMARC

Si le mail est transféré ou passe par des intermédiaires : priorisez l’alignement DKIM.
Si le mail va directement au destinataire avec des IP stables et un MailFrom contrôlé : l’alignement SPF peut être fiable.
Si les deux échouent : soit vous ne signez pas correctement, soit vous laissez des fournisseurs envoyer « à votre place » sans contrôles de domaine.

Troisième étape : repérez qui envoie le mail désaligné

Vérifiez le domaine du Return-Path : il révèle souvent le fournisseur.
Vérifiez le d= DKIM : il révèle le domaine du signataire.
Comparez avec votre liste d’expéditeurs autorisés. Si vous n’en avez pas, félicitations : vous venez de découvrir pourquoi les rapports DMARC existent.

Quatrième étape : choisissez la correction la moins risquée

Meilleure correction : configurez DKIM personnalisé pour votre domaine chez cet expéditeur.
Deuxième option : déplacez le From visible vers un sous‑domaine dédié que l’expéditeur peut aligner, et publiez DMARC pour ce sous‑domaine.
À éviter : assouplir la politique DMARC comme solution permanente. Réduire temporairement pct peut être raisonnable en incident ; les diminutions permanentes ramènent l’usurpation.

Blague #2 : Si vous « avez réparé DMARC » en mettant p=none, ce n’est pas une réparation ; c’est coller un post‑it sur le détecteur de fumée.

Erreurs courantes : symptôme → cause racine → correction

1) « SPF=pass, DKIM=pass, DMARC=fail »

Symptôme : Authentication-Results montre SPF pass et DKIM pass, mais DMARC fail.

Cause racine : SPF et DKIM ont authentifié des domaines différents du From: visible. Typique avec des fournisseurs SaaS qui utilisent leur propre Return-Path et d=.

Correction : Activez le DKIM personnalisé signant pour votre domaine ( d= aligné ). Éventuellement configurez MailFrom personnalisé pour obtenir aussi l’alignement SPF.

2) DMARC échoue seulement pour les mails transférés

Symptôme : Les destinataires directs reçoivent en inbox ; les destinataires par transfert voient quarantine/reject.

Cause racine : Les forwarders cassent SPF en changeant l’IP d’envoi ; DKIM peut manquer ou être cassé, laissant aucun chemin aligné.

Correction : Assurez‑vous que DKIM est activé et survit au transit habituel. Ne comptez pas uniquement sur SPF pour le passage DMARC si le forwarding est fréquent.

3) DKIM passe dans vos tests, échoue dans la réalité

Symptôme : Certains récepteurs affichent dkim=fail (bad signature), d’autres passent.

Cause racine : Les intermédiaires modifient le message (pieds de page, bannières « expéditeur externe », conversions MIME). Ou votre signataire inclut des en‑têtes volatils dans l’ensemble signé.

Correction : Ajustez la configuration DKIM : choisissez une canonicalization sensée, limitez les en‑têtes signés aux éléments stables, et éliminez les passerelles qui réécrivent après signature (ou signez après réécriture).

4) « On a mis aspf=s et tout a pété »

Symptôme : Pics d’échecs DMARC après passage à l’alignement strict.

Cause racine : Votre MailFrom est un sous‑domaine (ex. bounce.example.com) ou un fournisseur utilise un sous‑domaine de return‑path. Le strict exige une correspondance exacte.

Correction : Utilisez l’alignement relax (aspf=r) sauf si vous pouvez garantir un domaine exact MailFrom partout. Ou changez le From visible pour correspondre exactement à l’identité authentifiée.

5) Comportement DMARC aléatoire selon les récepteurs

Symptôme : Gmail dit DMARC pass, Microsoft dit fail, petits fournisseurs varient.

Cause racine : Plusieurs enregistrements TXT DMARC, incohérences de propagation DNS, ou interprétations différentes par les récepteurs face à des enregistrements cassés.

Correction : Assurez‑vous qu’un seul enregistrement TXT DMARC existe, validez le DNS, réduisez le TTL lors des changements et retestez.

6) Le mail d’un sous‑domaine se fait rejeter après application sur la racine

Symptôme : Les mails de news.example.com commencent à échouer quand vous appliquez DMARC sur example.com.

Cause racine : Le sous‑domaine hérite de la politique et l’expéditeur n’est pas aligné pour ce sous‑domaine. Ou sp=reject s’applique.

Correction : Publiez un DMARC explicite pour le sous‑domaine et configurez DKIM/SPF pour ce sous‑domaine ; ou ajustez sp délibérément.

7) DKIM s’aligne mais DMARC échoue encore

Symptôme : Vous voyez dkim=pass avec d=example.com, pourtant DMARC fail.

Cause racine : Le pass DKIM peut concerner une signature qui ne s’aligne pas (plusieurs signatures), ou le récepteur a choisi un autre résultat DKIM comme « meilleur » (nuance d’implémentation), ou le From visible utilise un domaine différent.

Correction : Inspectez soigneusement Authentication-Results pour savoir quelle signature a été évaluée et quel est le header.from. Assurez‑vous que la signature DKIM alignante est présente et valide chez le récepteur.

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

Plan de déploiement étape par étape qui évite les pannes auto‑infligées

Inventoriez les expéditeurs. Listez chaque système pouvant envoyer avec votre domaine dans From: : M365/Google Workspace, ticketing, CI/CD alerts, CRM, marketing, facturation, monitoring, humains avec clients SMTP.
Choisissez une architecture de domaine From. Privilégiez un domaine d’envoi dédié ou des sous‑domaines fonctionnels pour isoler les fournisseurs.
Activez DKIM partout où c’est possible. Si un expéditeur ne peut pas signer avec votre domaine, ne le laissez pas utiliser votre domaine From racine.
Publiez SPF avec précaution. Gardez‑le sous les limites de lookup DNS ; évitez les chaînes d’include incontrôlées.
Publiez DMARC avec p=none d’abord. Ajoutez rua pour collecter les rapports agrégés. Gardez l’alignement relax sauf si vous êtes sûr.
Examinez les rapports DMARC et corrigez les écarts d’alignement. C’est là que vous trouverez l’« expéditeur mystère » que le produit a oublié.
Passez à p=quarantine avec pct inférieur à 100 si nécessaire. Utilisez pct comme coupe‑circuit, pas comme mode de vie.
Passez à p=reject quand vous êtes confiant. L’usurpation cesse d’être un problème de marque et devient un problème côté récepteur.
Automatisez les contrôles continus. Expiration/rotation clés DKIM, dérive DNS, changements fournisseurs et acquisitions sont les endroits où l’alignement régresse silencieusement.

Checklist opérationnelle pour chaque nouvel expéditeur (imprimez‑la ou intégrez‑la dans votre processus d’achat)

Quel sera le domaine visible dans From: ?
La plateforme signera‑t‑elle DKIM avec d= sur notre domaine (ou un sous‑domaine aligné) ?
Pouvons‑nous définir un MailFrom / return‑path personnalisé dans notre domaine pour l’alignement SPF ?
Quels sélecteurs sont utilisés, et peut‑on faire la rotation des clés sans downtime ?
Réécrivent‑ils les messages après signature (pieds de page, tracking, modifications open/click) ?
Supportent‑ils des domaines séparés par environnement (prod vs staging) ?
Comment testerons‑nous avant mise en production (seed list, capture d’en‑têtes, validation DMARC) ?

Trois mini‑histoires d’entreprise tirées du terrain

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

L’entreprise venait de migrer les mails transactionnels vers un nouveau fournisseur flambant neuf. Le plan de migration était propre : mettre à jour SPF pour inclure le fournisseur, activer DKIM « parce que la case existe », puis durcir DMARC à p=reject après une semaine de calme.

Le deuxième jour, le support a commencé à recevoir des tickets : les réinitialisations de mot de passe n’arrivaient pas pour une partie des utilisateurs — principalement chez de gros fournisseurs de boîtes avec filtrage agressif. L’équipe d’ingénierie a fait son travail : vérifié les logs applicatifs, confirmé que les e‑mails étaient en file, confirmé que l’API du fournisseur renvoyait succès. Donc évidemment, « l’email est ok ».

Puis quelqu’un a regardé un en‑tête réel du destinataire. SPF a passé. DKIM a passé. DMARC a échoué. Le From: était example.com, mais le fournisseur signait avec d=vendor-mail.com et utilisait Return-Path sous vendor-bounce.com. L’équipe avait supposé que « pass » voulait dire « pass ». DMARC n’en a rien eu à faire.

La correction n’était pas héroïque : configurer DKIM personnalisé pour example.com chez le fournisseur, puis aligner le domaine de rebond sous un sous‑domaine contrôlé. La délivrabilité a été rétablie. Le gain culturel fut plus grand : le postmortem a ajouté une règle — aucune modification d’application de politique sans valider les identités d’alignement dans Authentication-Results chez au moins deux gros récepteurs.

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

Une autre organisation voulait « nettoyer le DNS ». Leur enregistrement SPF était devenu un monstre d’includes car chaque département avait onboardé des fournisseurs comme on collectionne des badges à une conf. Quelqu’un proposa d’aplatir SPF en développant les includes en une liste d’IP statiques. Moins de lookups DNS. Évaluation plus rapide. Tout le monde acquiesça.

Ils ont déployé l’enregistrement aplati et, pendant quelques jours, tout allait mieux. Puis les mails ont commencé à échouer de façon intermittente — surtout d’un fournisseur dont les IP d’envoi changent sans préavis. SPF a commencé à échouer pour ce trafic. DMARC a commencé à échouer aussi parce qu’ils s’appuyaient sur l’alignement SPF pour cet expéditeur ; DKIM n’était pas aligné (le fournisseur signait avec son propre domaine et personne n’avait mené ce combat).

L’« optimisation » avait remplacé des includes dynamiques (qui s’adaptent aux changements d’IP) par un instantané fragile. Le mode de panne n’était pas seulement SPF fail. Il a enchaîné sur le comportement d’application DMARC, transformant le changement d’IP d’un fournisseur en incident client.

La conception stable finale fut plus ennuyeuse : rétablir l’include du fournisseur, supprimer les includes obsolètes, séparer les expéditeurs en sous‑domaines avec alignement DKIM explicite, et suivre les comptes de lookup SPF via des tests en CI. La partie intelligente n’était pas l’astuce DNS. C’était de concevoir le chemin d’authentification pour qu’une dérive d’IP d’un fournisseur ne fasse pas s’effondrer DMARC.

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

Une équipe entreprise exécutait un job hebdomadaire simple : envoyer des messages de test depuis chaque expéditeur sanctionné vers quelques boîtes contrôlées, puis stocker les en‑têtes complets. Pas de tableaux de bord fancy au début — juste des fichiers dans un repo et l’habitude de regarder quand quelque chose changeait.

Un semaine, les tests ont signalé que les mails marketing arrivaient toujours, mais l’alignement DKIM avait basculé : le d= DKIM était désormais vendor.com au lieu de news.example.com. DMARC passait seulement parce que l’alignement SPF fonctionnait encore, et seulement pour les destinataires directs. Les destinataires transférés auraient échoué la prochaine fois que leur passerelle corporate routait via un nouveau saut.

Il s’est avéré que le fournisseur avait fait tourner son infrastructure et avait « aidé » en rétablissant un réglage durant une migration interne. Pas encore de panne. Juste une arme chargée sur la table.

L’équipe a ouvert un ticket, a obtenu la restauration du DKIM personnalisé, et ajouté une clause contractuelle : les changements affectant les identités d’envoi doivent être annoncés. La correction était banale. La sauvegarde était énorme. Voilà à quoi ressemble l’excellence opérationnelle quand personne n’applaudit.

FAQ

1) Si SPF passe, pourquoi DMARC échoue ?

Parce que SPF peut passer pour le domaine envelope‑from, et DMARC exige que ce domaine s’aligne avec le From: visible. Un pass SPF sans alignement est courant avec des expéditeurs tiers.

2) Dois‑je me reposer sur l’alignement SPF ou DKIM ?

Privilégiez l’alignement DKIM comme chemin principal DMARC, surtout si vos mails sont transférés, passent par des listes de diffusion, ou traversent plusieurs relais. Gardez SPF correct quand même ; il reste utile.

3) Que changent réellement « adkim » et « aspf » ?

Ils définissent l’alignement strict (s) ou relax (r) pour DKIM et SPF. Relax autorise l’alignement par sous‑domaine (même domaine organisationnel). Strict exige une correspondance exacte.

4) L’alignement strict est‑il toujours plus sûr ?

Non. Le strict n’est meilleur que si vous pouvez le maintenir sans exceptions. Si le strict force des fournisseurs à utiliser votre domaine From racine tout en authentifiant avec leurs propres domaines, vous obtenez des échecs — pas de la sécurité.

5) Pourquoi DMARC casse‑t‑il quand une liste ajoute un pied de page ?

Parce que les signatures DKIM couvrent des parties du corps et des en‑têtes du message. Si une liste modifie le corps, DKIM peut échouer. Si SPF échoue aussi à cause du forwarding, DMARC échoue.

6) Puis‑je corriger l’alignement en changeant seulement l’enregistrement DMARC ?

Rarement. La politique DMARC n’engendre pas l’alignement ; elle l’évalue. La plupart des corrections se font dans la configuration des expéditeurs : domaine de signature DKIM, domaine MailFrom, ou stratégie de domaine From visible.

7) Quelle est la façon la plus sûre de passer à `p=reject` ?

Exécutez p=none avec rapports agrégés, corrigez tous les expéditeurs connus, puis passez à p=quarantine en utilisant pct si nécessaire, puis p=reject. Ne sautez pas l’étape « corriger les expéditeurs ».

8) Ai‑je besoin d’un return‑path personnalisé si j’ai déjà l’alignement DKIM ?

Pas strictement, mais cela aide. Avoir SPF et DKIM alignés rend votre mail plus résilient face aux particularités des récepteurs et aux intermédiaires.

9) Comment les sous‑domaines affectent‑ils l’alignement ?

Avec l’alignement relax, les sous‑domaines s’alignent s’ils partagent le même domaine organisationnel. Avec l’alignement strict, ils ne s’alignent pas. La politique DMARC peut aussi s’appliquer différemment aux sous‑domaines via sp ou des enregistrements subdomaines explicites.

10) Quelle est la preuve la plus rapide qu’un fournisseur ne peut pas satisfaire l’alignement DMARC ?

Envoyez un mail de test et inspectez les en‑têtes : si d= DKIM et smtp.mailfrom SPF sont des domaines du fournisseur et non modifiables, ils ne peuvent pas s’aligner avec votre From: à moins de supporter des identités personnalisées.

Conclusion : actions suivantes qui réduisent réellement le risque

L’alignement DMARC n’est pas une théorie abstraite sur le mail. C’est la différence mécanique entre « nous authentifions quelque chose » et « les récepteurs peuvent faire confiance au domaine que nos utilisateurs voient ». Si vous appliquez DMARC sans discipline d’alignement, vous construisez une machine à rejeter et appelez ça de la sécurité.

Faites ceci ensuite, dans l’ordre :

Choisissez votre stratégie de domaine From (racine vs sous‑domaines vs domaine d’envoi dédié). Faites‑en une décision de politique, pas une préférence par équipe.
Faites de l’alignement DKIM la valeur par défaut pour chaque expéditeur, surtout les fournisseurs.
Utilisez les rapports DMARC et l’inspection d’en‑têtes comme télémétrie, pas comme de la paperasserie.
Déployez l’application délibérément (none → quarantine → reject), en utilisant pct comme valve de sécurité — pas comme béquille permanente.
Opérationnalisez‑le : un test hebdomadaire avec en‑têtes archivés détecte la classe d’incidents « fournisseur a rétabli sa config » avant que les clients ne s’en aperçoivent.