Deliverabilité des e-mails : messages dans les spams — solutions réelles (SPF/DKIM/DMARC bien configurés)

janvier 16, 2026 • février 3, 2026 • Lecture : 29 min • Views: 7

Cet article vous a aidé ?

Vous avez envoyé l’e-mail. Les logs SMTP indiquent “250 2.0.0 OK”. Votre application le marque « livré ». L’équipe commerciale jure pourtant que le client ne l’a jamais reçu. Et quand vous demandez une capture d’écran, elle est là—dans le dossier spam—posée entre une fausse facture et une promotion “Le PDG veut des cartes-cadeaux”.

Ce n’est pas un mystère. C’est un problème d’ingénierie avec un système de réputation. SPF/DKIM/DMARC sont le minimum syndical, mais la plupart des équipes les configurent comme une case à cocher puis s’étonnent que Gmail les traite de la même façon.

Méthode de diagnostic rapide

Si vous êtes d’astreinte et que votre PDG vient de transférer « pourquoi sommes-nous dans le spam ? » à tout le fil, ne commencez pas par réécrire votre enregistrement SPF de mémoire. Faites du triage comme un SRE : identifiez rapidement le goulet d’étranglement, puis affinez le diagnostic.

Première étape : confirmez ce que le destinataire a vu

Récupérez la source complète du message depuis la boîte du destinataire (les en-têtes importent plus que vos logs).
Trouvez les en-têtes Authentication-Results et Received. Ils vous indiquent les résultats SPF/DKIM/DMARC tels qu’évalués par le destinataire—le seul verdict qui compte.
Vérifiez quel domaine apparaît dans le From visible : et quel domaine figure dans le Return-Path (adresse de rebond). Le DMARC est une question d’alignement.

Deuxième étape : identifiez le mode d’échec

SPF : fail/softfail/permerror ? En général DNS, trop de recherches, ou IP d’envoi incorrecte.
DKIM : échec ? En général sélecteur non trouvé, canonicalisation cassée à cause de réécritures, ou mauvaise clé publiée.
DMARC : échec ? En général alignement (le domaine du From n’aligne pas avec le domaine authentifié par SPF ou DKIM), ou mauvaise configuration de politique/rapports.
Tout passe mais c’est quand même du spam ? Vous êtes alors sur la réputation/contenu/engagement, ou vous subissez du throttling/greylisting et vous arrivez “bizarre”.

Troisième étape : vérifiez votre identité et l’hygiène du transport

Reverse DNS (PTR) pour l’IP d’envoi doit exister et sembler cohérent.
Nom HELO/EHLO doit correspondre à un hostname valide qui se résout en avant et idéalement s’aligne avec le PTR.
TLS et chiffrement ne sont pas une magie pour la délivrabilité, mais une négociation STARTTLS cassée sent le manque de confiance.
Taux de rebonds et de plaintes sont votre « tension artérielle ». Si c’est élevé, aucun yoga DNS ne vous sauvera.

Puis : choisissez le chemin de correction le plus court

Si SPF est cassé : corrigez SPF sans provoquer de désalignement DMARC.
Si DKIM est cassé : corrigez la publication du sélecteur/clé, puis signez au dernier saut sortant.
Si l’alignement DMARC est cassé : décidez si l’alignement SPF ou DKIM sera votre voie principale ; concevez en conséquence.
Si tout authentifie : travaillez la réputation et l’hygiène des listes ; arrêtez d’envoyer massivement à des listes froides depuis un domaine récent.

Idée paraphrasée de Werner Vogels : « Tout échoue ; concevez des systèmes qui l’anticipent et se rétablissent rapidement. » La deliverabilité e-mail, c’est exactement ça, sauf que l’échec est silencieux et vos clients n’ouvrent pas de tickets—ils n’achètent tout simplement pas.

Comment les filtres décident réellement (au-delà de SPF/DKIM/DMARC)

SPF, DKIM et DMARC répondent à une question : « Ce message est-il plausiblement autorisé par le domaine du header From ? » Ils ne répondent pas : « Ce message est-il désiré ? »

Les fournisseurs modernes gèrent un système de scoring en couches. Une partie repose sur des règles. Beaucoup repose sur la réputation. Et une large part est du « feedback utilisateur sans le dire », comme quand les utilisateurs suppriment vos e-mails sans les lire ou les marquent comme spam. La vérité inconfortable : la deliverabilité est une fonctionnalité produit que vous gagnez et maintenez, pas un bout de configuration.

Les signaux qui comptent en pratique

Authentification + alignement : SPF/DKIM pass n’est pas suffisant ; l’alignement DMARC est le passeur pour de nombreuses boîtes de réception.
Consistance de l’infrastructure d’envoi : IP stables, HELO cohérent, domaines d’enveloppe expéditeur constants.
Taux de plainte : si les gens cliquent « spam », c’est fini pour un moment. Les fournisseurs ne négocient pas. Ils throttlent ou jettent.
Hygiène des listes : les listes vieillissent. Les pièges à spam existent. Les hard bounces ne sont pas une « tristesse temporaire », c’est une taxe sur la réputation.
Patrons de contenu : langage ressemblant au phishing, HTML cassé, raccourcisseurs de liens, texte d’affichage différent de la destination réelle, encodages bizarres.
Engagement : ouvertures et clics sont imparfaits, mais « lu vs supprimé » et « déplacé vers la boîte de réception » sont des signaux forts.

Deux réalités à intégrer :

Les destinataires font confiance aux domaines et aux IP, pas à vos bonnes intentions.
Les destinataires optimisent pour la sécurité des utilisateurs, pas pour votre taux de conversion.

Faits intéressants et brève histoire

Le SMTP est antérieur aux filtres anti-spam : les protocoles d’origine supposaient des utilisateurs coopératifs sur un réseau amical. L’internet en a décidé autrement.
SPF a commencé comme réponse aux expéditeurs d’enveloppe falsifiés : il vérifie par défaut le domaine du Return-Path (MAIL FROM), pas le From visible.
DKIM vient d’expérimentations de signature de domaine chez Yahoo et d’autres : il a été conçu pour survivre au transit et prouver qu’un domaine a pris la responsabilité du contenu.
DMARC est relativement jeune : il a standardisé l’exigence d’« alignement » que SPF et DKIM n’imposaient pas seuls.
« p=reject » n’est pas devenu omniprésent du jour au lendemain : les grandes marques sont passées de none → quarantine → reject sur des mois, car le désalignement casse des flux légitimes.
Les listes de diffusion cassent souvent DKIM : les pieds-de-page et les balises sujet modifient le contenu signé ; la canonicalisation aide, mais pas toujours.
SPF a une limite stricte de recherches DNS (10) : la dépasser provoque un permerror—l’authentification échoue même si votre IP est autorisée en esprit.
ARC existe parce que le transfert casse l’authentification : c’est un mécanisme de chaîne de garde pour « ceci a été validé quand je l’ai reçu ».
Les fournisseurs majeurs exigent de plus en plus l’authentification : avec le temps, « pas de SPF/DKIM/DMARC » est passé de « suspect » à « non livrable à grande échelle ».

SPF, DKIM, DMARC : bien faits (et alignés)

SPF : vos expéditeurs autorisés, avec des arêtes vives

SPF est un enregistrement TXT DNS qui indique quelles IPs (ou quels autres enregistrements SPF) sont autorisées à envoyer pour un domaine. Les destinataires l’évaluent contre le domaine de l’expéditeur d’enveloppe (Return-Path / MAIL FROM) ou, parfois, le domaine HELO.

Conseils opérationnels :

Gardez SPF simple. Moins d’includes, moins de recherches, moins de surprises.
N’utilisez pas « +all ». Ce n’est pas « permissif », c’est « s’il vous plaît usurpez-moi ».
Utilisez « ~all » seulement pendant une migration. Le softfail sert de roue d’apprentissage ; finissez par « -all ».
Possédez votre domaine de rebond (Return-Path). Si vous envoyez via un fournisseur mais voulez l’alignement DMARC, planifiez-le.

DKIM : responsabilité cryptographique, si vous ne la cassez pas

DKIM signe des parties du message (en-têtes et corps) avec une clé privée. La clé publique vit dans DNS sous un sélecteur. Les destinataires vérifient la signature. DKIM vous donne une identité stable même quand les IPs changent—à condition que la signature survive aux modifications intermédiaires.

Conseils opérationnels :

Signez au dernier saut sortant. Si un MTA intermédiaire réécrit le contenu après signature, vous venez de signer un faux.
Renouvelez les sélecteurs. Pas quotidiennement. Mais traitez les clés comme des identifiants avec un cycle de vie.
Signez les bons en-têtes : From, Date, Subject, Message-ID sont courants. Évitez de sur-signer des en-têtes fragiles susceptibles d’être réécrits.
Utilisez des clés 2048 bits lorsque c’est possible. Certains destinataires considèrent les clés plus courtes comme un signal plus faible.

DMARC : alignement, politique, et la partie qu’on ne peut pas simuler

DMARC lie le tout. Il indique aux destinataires : si SPF et/ou DKIM authentifient, s’alignent-ils avec le domaine du From visible ? Et que doit faire le destinataire si l’alignement échoue ?

Points clés que les équipes oublient souvent :

DMARC concerne le From visible : le domaine que voient les humains. C’est ce que les phishers usurpent.
L’alignement est tout : SPF peut passer pour un domaine tandis que le From est un autre. DMARC échouera quand même.
La politique n’est pas une enforcement à moins que vous le vouliez : « p=none » est de la télémétrie, pas une protection, et les fournisseurs peuvent le considérer comme « pas sérieux ».
Les sous-domaines comptent : décidez si vous utilisez l’alignement sur le domaine organisationnel et à quel degré vous voulez être strict (« adkim=s », « aspf=s »).

Blague #1 : SPF, c’est comme une liste d’invités. DKIM, c’est comme un bracelet. DMARC, c’est le videur qui vérifie si le bracelet correspond au nom sur le ticket.

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

Cette section est la partie que vous exécutez réellement. Chaque tâche inclut : une commande, à quoi ressemble une sortie réaliste, ce que cela signifie, et la décision à prendre.

Task 1: Pull the SPF TXT record and spot obvious footguns

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:198.51.100.10 include:_spf.vendor-mail.net ~all"

Ce que cela signifie : SPF existe. Il autorise une IPv4 et un include fournisseur. Il se termine par softfail (~all).

Décision : Si vous avez fini la migration, passez à -all. Si vous découvrez encore des expéditeurs, conservez ~all brièvement, mais planifiez une date de coupure.

Task 2: Check SPF lookup count (the 10-DNS-lookup trap)

cr0x@server:~$ spfquery -m example.com -ip 198.51.100.10 -sender bounce@example.com -helo mail.example.com
pass (mechanism 'ip4:198.51.100.10' matched)
dns-lookup-count=7

Ce que cela signifie : SPF passe pour cette IP et reste sous la limite des 10 recherches.

Décision : Si le nombre de recherches est proche de 10, aplatissez SPF (réduisez les includes imbriqués). S’il dépasse 10, corrigez-le en priorité ; un permerror tue la délivrabilité.

Task 3: Verify that your sending IP matches what the receiver sees

cr0x@server:~$ grep -E "postfix/smtp|status=sent" /var/log/mail.log | tail -n 2
Jan 03 10:12:08 mx1 postfix/smtp[21901]: 2F1C81234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0/0.4/0.7, dsn=2.0.0, status=sent (250 2.0.0 OK  1704276728 a1e2b3c4d5e6-200si1234567qkb.123 - gsmtp)
Jan 03 10:12:08 mx1 postfix/qmgr[1123]: 2F1C81234: removed

Ce que cela signifie : Vous avez délivré au MX de Gmail. Mais cela ne prouve pas l’IP source utilisée en externe (NAT et relays existent).

Décision : Confirmez l’IP d’egress depuis le serveur ou via les en-têtes chez le destinataire. Si vous envoyez via un smart host, SPF doit autoriser le smart host, pas le serveur applicatif.

Task 4: Confirm egress IP from the sending host

cr0x@server:~$ curl -s https://ifconfig.me
198.51.100.10

Ce que cela signifie : L’IP publique apparente de cet hôte est 198.51.100.10.

Décision : Assurez-vous que cette IP figure dans SPF et a un PTR. Si vous attendiez une IP différente, vous êtes peut‑être sur un pool NAT partagé—mauvais pour l’isolation de réputation.

Task 5: Check reverse DNS (PTR) for your sending IP

cr0x@server:~$ dig +short -x 198.51.100.10
mail.example.com.

Ce que cela signifie : Le PTR existe et pointe vers mail.example.com.

Décision : S’il n’y a pas de PTR, corrigez cela d’abord. Si le PTR pointe vers une valeur ISP par défaut comme static-10-100-51-198.isp.net, envisagez de le changer ; une identité non cohérente est un signal de manque de confiance.

Task 6: Check forward DNS for the PTR hostname (FCrDNS sanity)

cr0x@server:~$ dig +short A mail.example.com
198.51.100.10

Ce que cela signifie : Le forward résout vers la même IP. Beaucoup de destinataires apprécient cette cohérence.

Décision : Si le forward ne correspond pas, corrigez le DNS. Si vous ne pouvez pas (contraintes fournisseur cloud), utilisez leur mappage rDNS supporté ou déplacez l’envoi sortant ailleurs.

Task 7: Validate the DKIM public key exists for a selector

cr0x@server:~$ dig +short TXT s2026._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtYx...snip...QIDAQAB"

Ce que cela signifie : Le sélecteur s2026 est publié. Bien.

Décision : S’il manque, DKIM échouera. Si vous voyez plusieurs chaînes TXT à cause d’un fractionnement DNS, assurez-vous qu’elles se concatènent correctement (certains systèmes gèrent mal cela).

Task 8: Send a test message and inspect Authentication-Results

cr0x@server:~$ swaks --to you@outlook.com --from alerts@example.com --server mail.example.com --tls --header "Subject: auth test" --body "test"
=== Trying mail.example.com:25...
=== Connected to mail.example.com.
=== TLS started with cipher TLS_AES_256_GCM_SHA384
<** snip **>
<-  250 2.0.0 Ok: queued as 1234ABCD

Ce que cela signifie : Le message a été accepté par votre serveur pour livraison sortante. Maintenant récupérez les en-têtes reçus chez Outlook.

Décision : Récupérez la source du message dans la boîte et lisez les Authentication-Results. C’est là que se trouve le verdict réel.

Task 9: Parse headers locally (quick and dirty)

cr0x@server:~$ sed -n '1,80p' message.eml
Authentication-Results: mx.microsoft.com;
 spf=pass (sender IP is 198.51.100.10) smtp.mailfrom=example.com;
 dkim=pass (signature was verified) header.d=example.com;
 dmarc=pass action=none header.from=example.com
Received: from mail.example.com (mail.example.com [198.51.100.10])
 by NAM11-MW2-obe.outbound.protection.outlook.com with ESMTPS id 123...
From: alerts@example.com
Return-Path: <bounce@example.com>

Ce que cela signifie : SPF, DKIM, DMARC passent tous et s’alignent (header.from est example.com ; smtp.mailfrom est example.com ; DKIM d=example.com).

Décision : Si vous atterrissez encore en spam malgré tout-pass, arrêtez de bidouiller le DNS et commencez à investiguer la réputation, le contenu et l’engagement.

Task 10: Detect DMARC alignment failure (the common “everything passes but DMARC fails” trap)

cr0x@server:~$ grep -E "Authentication-Results|From:|Return-Path:" -n message.eml | head -n 20
1:Authentication-Results: mx.google.com;
2: spf=pass (google.com: domain of bounce@vendor-mail.net designates 203.0.113.44 as permitted sender) smtp.mailfrom=bounce@vendor-mail.net;
3: dkim=pass header.d=vendor-mail.net;
4: dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=example.com
12:From: Billing <billing@example.com>
13:Return-Path: <bounce@vendor-mail.net>

Ce que cela signifie : SPF et DKIM passent, mais pour vendor-mail.net. DMARC évalue l’alignement par rapport à example.com dans le From visible. L’alignement échoue ; DMARC échoue.

Décision : Configurez soit le fournisseur pour signer avec d=example.com (préférable), soit utilisez une fonctionnalité du fournisseur pour un domaine de rebond personnalisé sous example.com, ou changez le From pour un domaine que vous contrôlez et qui s’aligne avec l’identité authentifiée.

Task 11: Check your DMARC record

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=s; aspf=s; fo=1; pct=100"

Ce que cela signifie : DMARC existe, politique quarantine, alignement strict pour DKIM et SPF.

Décision : L’alignement strict va si vos systèmes sont disciplinés. Si vous avez beaucoup d’expéditeurs tiers et que vous stabilisez encore, envisagez de relâcher à adkim=r; aspf=r pendant que vous corrigez l’alignement. Ne le laissez pas laxiste indéfiniment.

Task 12: Confirm you publish a working MX and you’re not accidentally “parked”

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

Ce que cela signifie : Le domaine a des enregistrements MX ; ce n’est pas une zone morte.

Décision : Des MX manquants ou étranges peuvent affecter la perception et le traitement des rebonds. Assurez-vous au minimum de recevoir les rebonds.

Task 13: Check your SPF for multiple TXT records (silent breakage)

cr0x@server:~$ dig TXT example.com +noall +answer
example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.10 -all"
example.com. 3600 IN TXT "google-site-verification=abc123"

Ce que cela signifie : C’est correct : un seul enregistrement SPF plus un TXT non lié.

Décision : Si vous voyez deux enregistrements SPF (deux TXT commençant tous deux par v=spf1), l’évaluation SPF devient permerror. Fusionnez-les. N’ajoutez pas simplement un autre enregistrement.

Task 14: Confirm Postfix is presenting a sane HELO name

cr0x@server:~$ postconf -n | grep -E "myhostname|smtp_helo_name"
myhostname = mail.example.com
smtp_helo_name = mail.example.com

Ce que cela signifie : HELO est cohérent avec le hostname.

Décision : Si HELO est quelque chose comme localhost ou un nom interne, corrigez-le. Beaucoup de destinataires notent cela comme « comportement de botnet ».

Task 15: Make sure you’re not an open relay (yes, still happens)

cr0x@server:~$ swaks --server mail.example.com --to victim@external.com --from attacker@external.com --auth-user bogus --auth-password bogus
=== Trying mail.example.com:25...
<-  220 mail.example.com ESMTP Postfix
-> EHLO test
<-  250-mail.example.com
-> MAIL FROM:<attacker@external.com>
<-  554 5.7.1 <attacker@external.com>: Relay access denied

Ce que cela signifie : Relay refusé. Bien.

Décision : Si cela réussit sans authentification depuis l’internet, vous serez sur une liste noire avant le déjeuner. Restreignez le relay immédiatement.

Task 16: Spot greylisting/throttling in logs

cr0x@server:~$ grep -iE "deferred|throttl|try again|4\.7\." /var/log/mail.log | tail -n 5
Jan 03 10:18:22 mx1 postfix/smtp[22555]: 9ABCD1234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=120, delays=0.1/0/110/9.9, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[142.250.102.27] said: 421 4.7.0 Temporary System Problem. Try again later (in reply to end of DATA command))

Ce que cela signifie : Délai temporaire. Vous pouvez être throttlé ou atteindre des limites de réputation, surtout depuis des IPs/domains nouveaux.

Décision : Ralentissez l’envoi, chauffez les IPs, réduisez la concurrence et améliorez l’hygiène des listes. Traitez les schémas 4xx comme « le destinataire ne vous fait pas encore confiance », pas comme un simple « incident réseau ».

Transfert, listes de diffusion et ARC : où le bon courrier se perd

Le transfert d’e-mails est la maison hantée de la délivrabilité. Un message qui passe SPF et DKIM chez l’expéditeur peut échouer en aval après transfert parce que :

SPF échoue : le forwarder envoie depuis sa propre IP, qui n’est pas autorisée dans le SPF du domaine d’origine.
DKIM casse : le forwarder ou la liste modifie le corps ou les en-têtes (ajoute des pieds-de-page, change les limites MIME, réécrit le sujet).
DMARC échoue : l’alignement ne peut pas être satisfait si ni SPF ni DKIM ne valident plus pour le domaine du From.

ARC (Authenticated Received Chain) existe pour ajouter une « chaîne de garde ». Un forwarder peut indiquer : « Quand j’ai reçu ce message, SPF/DKIM/DMARC ont passé ». Les destinataires peuvent utiliser cela comme signal de confiance. Tous ne pèsent pas ARC de la même façon, mais cela aide dans le milieu désordonné où le transfert légitime est courant.

Ce que vous devez faire :

Si vous exploitez une infrastructure de transfert, envisagez d’implémenter la signature ARC.
Si vous dépendez de listes de diffusion, soyez réaliste : les politiques DMARC comme p=reject peuvent causer des problèmes de livraison aux listes sauf si la liste réécrit le From ou supporte des mitigations DMARC.
Pour les e-mails transactionnels, évitez d’envoyer via des chemins qui réécrivent le contenu après la signature DKIM. Signez en dernier.

Réputation : IP, domaine, contenu et signaux d’engagement

Une fois l’authentification correcte et alignée, la délivrabilité devient une lente accumulation de confiance.

Réputation IP : le voisinage compte

Une IP dédiée vous donne le contrôle de votre réputation. Une IP partagée vous fait hériter du comportement des inconnus. Parfois les inconnus sont corrects. Parfois ils improvisent une performance sur le thème « ignorer les liens de désinscription ».

Conseils pratiques :

Chauffez les nouvelles IPs : commencez à faible volume, montez progressivement, et priorisez les destinataires engagés.
Séparez les types de trafic : transactionnel et marketing ne devraient pas partager identité si vous pouvez l’éviter. Quand le marketing reçoit des plaintes, le transactionnel ne doit pas en pâtir.
Soyez cohérent : pics soudains, nouveaux hôtes d’envoi, et changement d’expéditeurs d’enveloppe ressemblent à une compromission.

Réputation de domaine : lente à gagner, rapide à perdre

La réputation du domaine suit votre domaine From, votre domaine de signature DKIM, et parfois vos domaines de lien. Si vous changez de domaine pour contourner les filtres, vous apprenez aux fournisseurs que vous vous comportez comme des spammeurs. Ils ne sont pas impressionnés par votre créativité.

Contenu : pas « évitez les mots spam », mais évitez les comportements spam

Les filtres ne recherchent pas seulement les mots-clés « argent gratuit ». Ils cherchent des patrons corrélés à l’abus :

Raccourcisseurs de liens et chaînes de redirection
Texte d’affichage qui ne correspond pas à la destination réelle du lien
E-mails fortement basés sur des images avec peu de texte
HTML malformé et structures MIME étranges
Pièces jointes venant d’identités inconnues (surtout exécutables, documents avec macros, ou archives inattendues)

Engagement : la partie que votre stack marketing vous cache souvent

Le « taux d’ouverture » est dégradé par les protections de vie privée et les proxys d’images. Mais les fournisseurs ont encore des signaux d’engagement que vous ne voyez pas : durée de lecture, comportement de réponse, déplacement depuis le spam vers la boîte de réception, et suppression sans lecture.

Implication pour l’ingénierie : arrêtez d’envoyer aux personnes qui ne s’engagent pas. Vous payez pour empoisonner votre propre réputation.

Blague #2 : Si vous continuez à écrire aux personnes qui n’ouvrent jamais, le fournisseur suppose que vous êtes soit un spammeur soit un optimiste. Aucun des deux n’est une catégorie protégée.

Trois mini-récits d’entreprise issus du terrain

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

L’entreprise : SaaS de taille moyenne, croissance stable, un seul flux sortant pour tout—réinitialisation de mot de passe, factures et newsletters hebdomadaires. Ils ont transféré les envois marketing vers un nouveau fournisseur pour « améliorer la délivrabilité ». Le plan de migration était, euphémiquement, une invitation calendrier.

La mauvaise hypothèse était simple : « Si SPF et DKIM passent, DMARC passera aussi. » Le fournisseur a fourni un include SPF et une signature DKIM pour vendor-mail.net. L’équipe a conservé le From visible comme billing@example.com, parce que la cohérence de marque est sacrée.

En quelques heures, des factures ont commencé à atterrir en spam pour un sous-ensemble de clients—principalement des clients entreprise avec un filtrage strict et une enforcement DMARC. Des tickets de support sont arrivés. Finance a monté le ton. L’SRE d’astreinte a regardé les logs Postfix et n’a vu que des 250, ce qui est l’équivalent e-mail de « ça marche sur ma machine ».

Le déclic est venu en récupérant les en-têtes bruts d’une boîte client. Authentication-Results montrait SPF=pass, DKIM=pass, DMARC=fail. La politique DMARC de example.com était p=quarantine avec alignement strict. SPF authentifiait vendor-mail.net (domaine Return-Path), DKIM authentifiait vendor-mail.net (d=), et aucun ne s’alignait avec le From example.com.

La correction n’était pas de « détendre DMARC parce que ça casse des choses ». La correction a été de configurer le fournisseur pour utiliser une signature DKIM personnalisée alignée sur example.com et un domaine de rebond personnalisé sous example.com afin que l’alignement SPF fonctionne aussi. Ils l’ont déployé émetteur par émetteur, vérifié l’alignement dans les en-têtes, puis augmenté le trafic. La délivrabilité est revenue. Finance a arrêté de faire les cent pas.

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

L’entreprise : plateforme B2C avec pics saisonniers. Ils géraient leur flotte MTA et voulaient réduire les coûts. Quelqu’un a remarqué que le trafic sortant était « en rafales » et a proposé de consolider sur moins de serveurs avec un nouveau NAT gateway. Super : moins d’instances, ops plus simples, facture réduite.

Le retour de bâton : la réputation IP s’est effondrée. Avant, le trafic sortant provenait de plusieurs IP statiques avec PTR stables. Après consolidation, les mails sortaient d’un pool NAT qui changeait lors d’événements d’échelle. SPF autorisait toujours le relais fournisseur, DKIM passait toujours, DMARC passait toujours. Et pourtant, la proportion de spams et les défaillances temporaires ont augmenté.

L’équipe a chassé le contenu, puis tenté de « chauffer » (sans contrôler quelles IP chauffaient). Ils ont ajouté des retries (ce qui augmentait le volume pendant les throttlings), et cela a empiré les défaillances. Boucle de rétroaction positive classique, sauf que le résultat est « tout le courrier arrive en retard et est suspect ».

La résolution a exigé d’admettre que l’optimisation était le problème. Ils ont ramené l’envoi sortant à un petit ensemble d’IP d’egress dédiées et stables avec PTR et HELO cohérents, et ils ont contrôlé la concurrence. Les coûts ont un peu augmenté. La délivrabilité et la latence se sont grandement améliorées. La leçon : l’e-mail est un système de réputation ; l’imprévisibilité coûte cher.

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

L’entreprise : éditeur logiciel pour entreprises. Plusieurs équipes envoyaient des e-mails : notifications produit, support, et marketing. Des années auparavant, quelqu’un amateur de « gouvernance » avait imposé un inventaire centralisé des identités e-mail : chaque expéditeur, chaque domaine, chaque fournisseur, chaque sélecteur DKIM, et les mécanismes SPF exacts requis. C’était dans le contrôle de version. Les gens grommelaient.

Puis une faille chez un fournisseur a fait la une et la sécurité a demandé : « Utilisons-nous ces expéditeurs ? » Ils l’étaient. Pire, ce fournisseur pouvait envoyer avec un From qui ressemblait appartenir à l’entreprise, parce que l’intégration avait été configurée lâchement pendant un projet précipité.

Parce qu’ils avaient l’inventaire, ils ont rapidement identifié quels flux utilisaient le fournisseur, quels domaines étaient affectés, et quelle était la posture d’authentification. Ils ont durci DMARC sur un sous-domaine utilisé uniquement pour le marketing tiers, appliqué un alignement strict pour les mails transactionnels, et renouvelé les sélecteurs DKIM quand nécessaire.

La délivrabilité n’a pas souffert pendant le changement car ils l’ont déployé prudemment, vérifié les en-têtes pour l’alignement, et évité les changements à risque lors des pics d’envoi. La pratique « ennuyeuse »—propriété documentée et changements DNS contrôlés—leur a permis d’agir vite sans tâtonner. Personne n’a écrit de postmortem héroïque. C’est le but.

Erreurs courantes : symptôme → cause racine → correction

1) « SPF passe, DKIM passe, DMARC échoue »

Symptôme : Authentication-Results montre spf=pass, dkim=pass, mais dmarc=fail.

Cause racine : Désalignement. SPF a authentifié le domaine du Return-Path (souvent un domaine fournisseur). DKIM a authentifié d=vendor. Le From est votre domaine.

Correction : Configurez un domaine de rebond personnalisé sous votre domaine pour l’alignement SPF et/ou la signature DKIM avec d=yourdomain. Vérifiez l’alignement dans les en-têtes.

2) « SPF permerror »

Symptôme : Résultat SPF permerror, ou les destinataires le traitent comme un échec.

Cause racine : Plus de 10 recherches DNS à cause d’includes imbriqués, redirections, ou macros ; ou plusieurs enregistrements SPF.

Correction : Aplatissez SPF. Supprimez les includes redondants. Fusionnez en un seul enregistrement SPF. Gardez le nombre de recherches confortablement en dessous de 10.

3) « DKIM échoue seulement chez certains fournisseurs »

Symptôme : DKIM passe chez un fournisseur mais échoue chez un autre, ou passe parfois.

Cause racine : Incohérences de propagation DNS, fractionnement TXT mal géré, ou modification intermédiaire après signature (pied-de-page de liste, gateway de sécurité, réécritures CRM).

Correction : Assurez-vous que le DNS renvoie une clé stable partout. Signez au dernier saut sortant. Évitez de réécrire les parties signées. Envisagez une canonicalisation relâchée, mais ne l’utilisez pas comme pansement pour des réécritures incontrôlées.

4) « Tout passe ; pourtant spam »

Symptôme : SPF/DKIM/DMARC passent et s’alignent, mais la boîte de réception est mauvaise.

Cause racine : Réputation ou engagement. Taux de plainte élevé, envoi à des listes obsolètes, ciblage médiocre, problèmes d’IP partagée, ou pics de volume soudains.

Correction : Améliorez l’hygiène des listes, réduisez le volume, chauffez correctement, segmentez transactionnel vs marketing, et arrêtez d’envoyer aux non-engagés. Corrigez le comportement business, pas seulement le DNS.

5) « Les messages disparaissent, pas de rebond »

Symptôme : Les logs de l’expéditeur montrent l’acceptation, mais les destinataires ne voient jamais le message (même pas en spam), et aucun NDR ne revient.

Cause racine : Filtrage silencieux chez le destinataire, souvent dû à de graves problèmes de réputation ou à des blocages politiques ; ou vous envoyez vers un puits (domaine avec faute de frappe, boîte invalide) avec un comportement non standard.

Correction : Utilisez des comptes tests seedés chez plusieurs fournisseurs pour récupérer les en-têtes et la position. Réduisez le volume, corrigez l’authentification/l’alignement, et traitez la réputation. Assurez-vous que les rebonds sont routés et traités correctement.

6) « Le mail transféré échoue DMARC »

Symptôme : Le mail envoyé à un forwarder (ou liste) est rejeté ou mis en spam en aval.

Cause racine : SPF casse sur le forward, DKIM casse sur modification ; DMARC échoue.

Correction : Pour votre propre infrastructure de transfert, implémentez ARC et évitez de casser DKIM. Pour les listes de diffusion, utilisez des comportements compatibles DMARC (réécriture du From ou autres mitigations) si vous les contrôlez.

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

Checklist A: Stabiliser l’authentification et l’alignement (le plan « arrêter l’hémorragie »)

Choisissez l’identité que vous voulez réellement : décidez des domaines From canoniques pour le transactionnel vs le marketing.
Inventoriez tous les expéditeurs : serveurs d’app, systèmes de ticketing, CRM, plateformes marketing, outils de monitoring.
Assurez un seul enregistrement SPF par domaine et gardez le nombre de recherches sous 10.
Assurez la signature DKIM pour chaque flux, de préférence avec d= correspondant à votre domaine From (ou sous-domaine aligné).
Déployez DMARC avec télémétrie d’abord : commencez par p=none juste le temps de collecter la réalité.
Corrigez les échecs d’alignement pour chaque expéditeur : domaines de rebond personnalisés, domaines DKIM personnalisés, ou ajustez les domaines From.
Passez à l’enforcement : p=quarantine, puis p=reject lorsque vous êtes confiants.
Verrouillez la stratégie de sous-domaines : séparez les sous-domaines pour marketing vs transactionnel, avec des politiques adaptées.

Checklist B: Hygiène du transport et de l’identité (le plan « ressembler à un vrai système mail »)

Définissez des IPs sortantes stables lorsque possible ; évitez les pools NAT pour l’identité mail principale.
Configurez le PTR pour correspondre à votre hostname mail ; assurez-vous que le DNS forward correspond à l’IP.
Réglez HELO/EHLO sur un hostname valide et gardez-le cohérent entre les MTAs.
Offrez STARTTLS correctement ; évitez les configs TLS cassées qui provoquent des fallback suspects.
Traitez les rebonds : gérez les DSNs, supprimez les hard bounces et enquêtez sur les pics.
Gardez les files de sortie saines ; de longs délais peuvent déclencher suspicion et plaintes utilisateur (« votre e-mail est arrivé deux jours plus tard »).

Checklist C: Réputation et gestion du volume (le plan « gagner la confiance »)

Segmentez le trafic : transactionnel sur sa propre identité et plage IP si possible.
Chauffez : montez le volume progressivement ; commencez par vos destinataires les plus engagés.
Hygiène de liste : supprimez les hard bounces immédiatement ; mettez en veille les non-engagés.
Désinscription qui marche : facilitez la désinscription ; une désinscription cassée alimente les plaintes.
Sanité du contenu : templates cohérents, peu de redirections de liens, MIME correct, et évitez les motifs de pièces jointes louches.
Mesurez la placement : boîtes seedées, capture d’en-têtes, suivez spam vs inbox chez les fournisseurs.

FAQ

1) Si SPF, DKIM et DMARC sont corrects, pourquoi suis-je encore en spam ?

Parce que l’authentification prouve l’identité, pas l’attrait. La mise en spam peut être due à la réputation (domaine/IP), au taux de plaintes, à l’hygiène des listes, aux pics de volume, et aux patrons de contenu.

2) Dois-je utiliser DMARC p=reject tout de suite ?

Non, sauf si vous connaissez déjà tous les expéditeurs légitimes et qu’ils s’alignent. Commencez par p=none brièvement pour voir qui envoie, corrigez l’alignement, puis passez à quarantine puis reject.

3) Qu’est-ce que l’alignement DMARC en pratique ?

Cela signifie que le domaine dans le header From visible correspond (ou est un sous-domaine correspondant selon la stricte exigence) au domaine authentifié par SPF (MAIL FROM) et/ou DKIM (d=).

4) SPF ou DKIM : lequel est plus important pour DMARC ?

DKIM est souvent plus fiable car il survit aux changements d’IP et peut résister à certains transferts. SPF est plus simple mais casse sur le transfert. En pratique, visez les deux et assurez-vous qu’au moins l’un s’aligne.

5) Pourquoi le transfert casse-t-il SPF ?

SPF vérifie si l’IP émettrice est autorisée pour le domaine de l’expéditeur d’enveloppe. Quand un forwarder relaie le courrier, l’IP d’envoi devient celle du forwarder, qui n’est généralement pas autorisée dans le SPF du domaine d’origine.

6) Quelle est la différence entre Return-Path et From ?

From est ce que voient et utilisent les utilisateurs pour répondre. Return-Path (expéditeur d’enveloppe) est où arrivent les rebonds. SPF authentifie par défaut le Return-Path ; DMARC évalue l’alignement avec le From.

7) Puis-je avoir plusieurs enregistrements SPF ?

Non. Un seul enregistrement SPF par domaine. Plusieurs TXT v=spf1 provoquent couramment un permerror, que les destinataires traitent comme un échec.

8) Ai-je besoin d’une IP dédiée ?

Si vous envoyez un volume significatif et tenez à la fiabilité, une IP dédiée (ou un pool bien contrôlé) en vaut généralement la peine. Les IP partagées peuvent convenir, jusqu’au jour où elles ne conviennent plus—et vous ne contrôlerez pas le « jusqu’à ».

9) Le marketing et le transactionnel doivent-ils partager le même domaine ?

Vous pouvez, mais c’est risqué. Des sous-domaines séparés (ou même des domaines séparés) vous permettent de protéger la délivrabilité transactionnelle des plaintes marketing et de la dégradation des listes.

10) Quel est le gain le plus rapide si nous sommes soudainement en spam ?

Récupérez les en-têtes des messages affectés et confirmez l’alignement. Si l’alignement est correct, réduisez immédiatement le volume, arrêtez d’envoyer aux destinataires obsolètes, et investiguez les défaillances temporaires et les signaux de plainte.

Conclusion : prochaines étapes qui font vraiment la différence

Si vos e-mails atterrissent en spam, traitez cela comme un incident : obtenez des preuves chez le destinataire, identifiez le mode d’échec, et corrigez le chemin le plus court. La plupart des équipes perdent des jours à peaufiner la syntaxe SPF alors que l’alignement DMARC échoue sous leurs yeux.

Prochaines étapes pratiques :

Collectez trois sources de messages réels depuis des boîtes affectées (Gmail, Outlook, et un domaine entreprise si possible). Comparez les Authentication-Results et l’alignement.
Rendez l’alignement explicite : décidez si les domaines de rebond alignés SPF et/ou les domaines de signature DKIM sont votre standard pour chaque expéditeur.
Stabilisez l’identité de l’infrastructure : PTR, DNS forward, HELO, et IPs sortantes cohérentes.
Séparez les risques : isolez les identités transactionnelles des identités marketing pour qu’une campagne ratée ne grille pas les réinitialisations de mot de passe.
Hygiène plutôt qu’héroïsme : arrêtez d’envoyer aux non-engagés, traitez les rebonds, et réduisez le taux de plainte. Le DNS ne sauvera pas une liste qui vous déteste.

La deliverabilité des e-mails est ennuyeuse quand elle est saine, et coûteuse quand elle ne l’est pas. Visez l’ennui.