SPF/DKIM passent mais en spam : signaux cachés à corriger

Playbook de diagnostic rapide (trouver le goulot rapidement)

Quand « SPF/DKIM passent mais c’est quand même du spam » arrive, les gens paniquent et commencent à errer au hasard dans le DNS.
Ne faites pas ça. Traitez ça comme un incident. Triez d’abord, corrigez ensuite.

1) Confirmez que le problème est le placement, pas l’acceptation

• Vérifiez si le message est accepté (250 OK) et où il aboutit : spam vs promotions vs boîte de réception reste une livraison, juste un mauvais placement.
• Si vous voyez des temporisations/blocages (4xx/5xx), vous avez une porte de réputation ou de politique, pas un simple « filtrage anti‑spam ». Différent playbook.

2) Récupérez un vrai message et lisez les en‑têtes comme un détective

• Authentification : SPF=pass, DKIM=pass, DMARC=pass est nécessaire, pas suffisante.
• Alignement : le « pass » DMARC ne signifie pas toujours ce que vous pensez si vous utilisez des sous‑domaines, plusieurs identités From, ou des émetteurs tiers.
• ARC : si le mail est transféré (listes de diffusion, systèmes de ticket), ARC peut faire la différence entre « passe » et « semble falsifié ».

3) Déterminez quel axe échoue : identité, infrastructure ou comportement

• Identité : désalignement, domaines From étranges, schémas Reply‑To cassés, sélecteurs DKIM incohérents.
• Infrastructure : rDNS, HELO, posture TLS, réputation IP/domaine, voisins sur IP partagée, modèles de rythme, timeouts.
• Comportement : hygiène de liste, taux de plaintes, engagement, pics de volume soudains, domaines « froids », empreintes de contenu.

4) Corrigez le levier le plus puissant en premier

• Des plaintes élevées et une mauvaise hygiène de liste noieront des SPF/DKIM parfaits.
• Un rDNS/HELO mauvais et un TLS douteux peuvent vous torpiller avant même que le contenu soit évalué.
• Un DMARC mal aligné peut vous faire passer pour un phishing malgré des signatures correctes.

Idée paraphrasée de Werner Vogels : « Tout échoue tout le temps ; concevez pour ça. » La délivrabilité est la même chose — supposez la méfiance, puis gagnez la confiance encore et encore.

Ce que SPF/DKIM/DMARC prouvent réellement (et ce qu’ils ne prouvent pas)

SPF : « cette IP est autorisée à envoyer pour ce domaine »

SPF vérifie l’expéditeur d’enveloppe (MAIL FROM / Return‑Path), pas l’en‑tête From visible par l’utilisateur.
SPF passant peut coexister avec un domaine From qui n’a rien à voir. C’est pourquoi DMARC existe.

DKIM : « ce domaine a signé ce contenu »

DKIM valide qu’un domaine signataire (la valeur d=) a signé des en‑têtes spécifiques et le corps.
DKIM ne dit rien sur l’accueil que vous recevrez chez les destinataires.

DMARC : « le From visible s’aligne sur SPF ou DKIM »

DMARC est l’enveloppe de politique. Il vérifie si le domaine que l’utilisateur voit dans From s’aligne (strictement ou relax) soit avec le domaine authentifié par SPF,
soit avec le domaine signataire DKIM.

Ce qu’ils ne prouvent pas

• Que vous avez une bonne réputation d’envoi.
• Que votre liste est opt‑in et peu sujette aux plaintes.
• Que votre contenu n’est pas spammy ou proche du phishing.
• Que votre infrastructure ressemble à un système mail légitime (cohérence rDNS/HELO/TLS).
• Que vos schémas d’envoi paraissent stables et humains.

L’authentification est comme un passeport. Elle prouve que vous êtes bien qui vous prétendez être.
Elle ne prouve pas que vous êtes amusant à inviter à une soirée. Les fournisseurs de boîtes de réception se soucient de la soirée.

Faits intéressants et contexte historique (8 points rapides)

1. SPF date du début des années 2000 et est né d’une époque où les expéditeurs d’enveloppe étaient fréquemment falsifiés et où l’on cherchait un « identifiant » pour l’e‑mail.
2. DKIM a été normalisé plus tard après la convergence de DomainKeys et Identified Internet Mail en un mécanisme unique.
3. DMARC est venu des opérateurs (gros fournisseurs de boîtes et expéditeurs) qui voulaient une couche de politique, pas seulement une preuve cryptographique.
4. L’alignement fut l’innovation clé : DMARC a rendu le domaine From visible par l’humain applicable.
5. Le transfert casse SPF volontairement parce que l’IP du forwarder n’est pas autorisée dans le SPF du domaine d’origine.
6. Les listes de diffusion cassent souvent DKIM en modifiant les sujets ou le corps (ajout de pied de page), invalidant les signatures.
7. Les systèmes de réputation précèdent DMARC : les fournisseurs ont longtemps utilisé des scores de comportement IP/domaine, même quand l’auth était faible.
8. TLS est devenu un signal de délivrabilité non pas par effet de mode, mais parce que le chiffrement opportuniste corrèle avec des expéditeurs légitimes.

Blague n°1 : La délivrabilité e‑mail est le seul sport où vous pouvez tout faire correctement et quand même perdre à cause du bouton « se désabonner » de quelqu’un d’autre.

Les signaux cachés qui déterminent boîte de réception vs spam

1) La réputation de domaine et la réputation IP sont séparées, et les deux comptent

Les fournisseurs vous notent sur plusieurs axes : l’IP d’envoi, le domaine visible en From, le domaine d= DKIM,
le domaine Return‑Path, et parfois les URL incluses. Vous pouvez avoir un domaine impeccable et une IP épouvantable (pools partagés),
ou une bonne IP et un domaine flambant neuf qui ressemble à un jetable.

Si vous êtes sur une infrastructure partagée, le comportement de votre voisin peut vous éclabousser. Si vous êtes sur vos propres IP,
le warm‑up et la cohérence comptent plus que la seule exactitude DNS.

2) Le « pass » DMARC ne garantit pas la santé de l’alignement de marque

L’alignement DMARC peut passer alors que votre message paraît suspect pour les couches contenu et UI. Exemple :
From: billing@yourbrand.com, mais Reply‑To est un domaine différent, les liens pointent vers un tiers,
et le corps ressemble à une réinitialisation de mot de passe. Techniquement valide. Pratiquement terrifiant.

3) Le nom HELO/EHLO, le rDNS et la cohérence sont des signaux de confiance

Une quantité surprenante de mail est notée avant que le corps soit entièrement évalué. Si votre salutation SMTP dit
localhost ou un nom de cloud aléatoire, et que votre rDNS ne correspond pas, vous avez introduit une friction.
Pas toujours fatal. Souvent cumulatif.

4) Posture TLS : le chiffrement n’est pas obligatoire partout, mais son absence est un signal

Le TLS opportuniste est la norme. L’absence totale de TLS, des suites obsolètes, ou des chaînes de certificats cassées peuvent vous pousser vers la catégorie « expéditeur bon marché ».
Ajoutez MTA‑STS et rapports TLS si vous êtes sérieux. Ce n’est pas du théâtre de sécurité ; ça réduit les risques de rétrogradation et de mauvais routage.

5) Le taux de plaintes bat toujours vos bonnes intentions

Vous pouvez jurer que vos destinataires se sont inscrits. Les fournisseurs de boîtes croient le comportement du destinataire, pas votre tableur.
Les plaintes sont du poison ; les rebonds sont des avertissements ; la non‑interaction est une mort lente.

6) Signaux d’engagement : les ouvertures sont moins fiables, mais l’interaction compte encore

Les fournisseurs modélisent si les destinataires lisent, répondent, déplacent dans des dossiers, suppriment sans lire, ou marquent comme spam.
« Mon PDG a ouvert » n’est pas une métrique. Segmentez par destinataires engagés.

7) Empreintes de contenu : templates, réputation des URL et structure « phishing »

Vous pouvez être spammé par votre propre design system. Templates réutilisés, phrases d’appel à l’action répétées,
raccourcisseurs d’URL, domaines de marque dépareillés et types de pièces jointes déclenchent des modèles.
Aussi : la réputation de vos domaines de liens compte. Si votre domaine de tracking est neuf ou abusé, vous héritez de cette odeur.

8) List‑Unsubscribe et en‑têtes de désabonnement sont des primitives de délivrabilité

Si les utilisateurs ne peuvent pas partir facilement, ils agiront brutalement. Les fournisseurs le remarquent.
Implémentez le désabonnement en un clic quand c’est possible, et faites‑le fonctionner. Pas « fonctionner la plupart du temps ».

9) Gestion des rebonds et listes de suppression : ennuyeux, essentiel

Si vous continuez à envoyer à des adresses mortes, vous ressemblez à un spammeur qui a acheté une liste. Parce que c’est ce que font les spammeurs.
Les hard bounces doivent être supprimés rapidement. Les soft bounces nécessitent une politique (fenêtre de réessai, puis suppression).

10) Schémas d’envoi : pics de volume, changements d’horaire et pénalités de « nouveau flux »

Les moteurs de délivrabilité adorent la prévisibilité. Les pics soudains, nouveaux types de messages, ou changement de fournisseur peuvent ressembler à une prise de contrôle de compte.
Faites chauffer les nouvelles IP, montez progressivement les nouveaux flux, et évitez d’envoyer massivement à des listes froides.

Blague n°2 : Votre serveur mail est comme un videur de boîte de nuit : il se fiche de la qualité de votre SPF, il regarde avec qui vous êtes arrivé.

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

Ce sont des contrôles de niveau opérateur. Exécutez‑les, capturez les sorties, prenez des décisions. Ne « sentez » pas la délivrabilité au pif.

Task 1: Inspecter l’enregistrement SPF et compter les requêtes DNS

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

Ce que cela signifie : SPF existe et utilise un include plus une IP directe. Bon début.
Décision : Si vous voyez de nombreux includes, aplatissez ou simplifiez. SPF a une limite de 10 requêtes DNS ; la dépasser génère permerror et douleur silencieuse.

Task 2: Évaluer SPF depuis une IP d’envoi spécifique

cr0x@server:~$ spfquery --ip 203.0.113.10 --sender bounce@example.com --helo mail.example.com
pass (sender SPF authorized)

Ce que cela signifie : Cette IP est autorisée pour le domaine d’enveloppe.
Décision : Si cela renvoie fail ou softfail, corrigez SPF avant toute autre chose. Si c’est permerror, vous avez probablement dépassé les requêtes ou une erreur de syntaxe.

Task 3: Vérifier que le sélecteur DKIM existe et est sain

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

Ce que cela signifie : Le sélecteur s1 publie une clé publique.
Décision : S’il n’y a pas d’enregistrement, DKIM échouera. Si l’enregistrement est scindé incorrectement sur plusieurs chaînes, certains validateurs échouent — publiez correctement.

Task 4: Vérifier la politique DMARC et le mode d’alignement

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

Ce que cela signifie : DMARC est configuré en quarantine avec alignement relax pour SPF et DKIM.
Décision : Si vous passez SPF/DKIM mais êtes toujours en spam, la politique DMARC n’est pas le levier. Utilisez‑la pour garantir que l’alignement ne rate pas pour certains flux.

Task 5: Vérifier le rDNS (PTR) pour votre IP d’envoi

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

Ce que cela signifie : PTR est défini.
Décision : Si PTR manque, est générique ou pointe vers des domaines non liés, corrigez‑le. Beaucoup de récepteurs considèrent l’absence de PTR comme un signal de faible confiance.

Task 6: Vérifier le forward‑confirmed reverse DNS (FCrDNS)

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

Ce que cela signifie : Le nom PTR résout vers la même IP.
Décision : Si l’avant et l’arrière ne correspondent pas, alignez‑les. C’est une hygiène de base et enlève une excuse facile de filtrage.

Task 7: Inspecter la bannière SMTP/nom HELO depuis l’extérieur

cr0x@server:~$ nc -v mail.example.com 25
Connection to mail.example.com 25 port [tcp/smtp] succeeded!
220 mail.example.com ESMTP Postfix

Ce que cela signifie : La bannière est un vrai nom d’hôte, pas localhost.
Décision : Si la bannière ou le HELO est bizarre, corrigez smtpd_banner et myhostname de Postfix. L’incohérence crie « VM compromise ».

Task 8: Vérifier STARTTLS et la chaîne de certificats

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Verification: OK
Server Temp Key: X25519, 253 bits

Ce que cela signifie : STARTTLS fonctionne, TLS moderne, certif valide.
Décision : Si la vérification échoue, corrigez la chaîne de certificats. Si TLS est absent, ajoutez‑le. Cela ne vous fera pas automatiquement arriver en boîte de réception, mais évite un détachement de confiance facile.

Task 9: Vérifier si vous êtes sur des listes noires DNS communes (signal, pas évangile)

cr0x@server:~$ for z in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do \
  q=$(echo 10.113.0.203 | awk -F. '{print $4"."$3"."$2"."$1}'); \
  echo -n "$z: "; dig +short ${q}.${z} A; done
zen.spamhaus.org:
bl.spamcop.net:
b.barracudacentral.org:

Ce que cela signifie : Pas de listing dans ces zones (sortie vide).
Décision : Si vous êtes listé, enquêtez : hôte compromis, mauvaises pratiques de liste, ou problème d’IP partagée. Le retrait est de la paperasserie ; la prévention est de l’ingénierie.

Task 10: Vérifier la file Postfix pour backlog (un backlog peut ressembler à du spam en rafale)

cr0x@server:~$ mailq | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A01234A*     2480 Mon Jan  4 10:12:01  bounce@example.com
                                         user1@gmail.com
                                         user2@outlook.com

Ce que cela signifie : Des messages sont en file (l’astérisque indique actif).
Décision : Si la file grossit pendant les envois, vous êtes peut‑être rate‑limited ou greylisté. La livraison lente peut regrouper les réessais et créer des schémas suspects. Ajustez la concurrence et les réessais avec soin, pas agressivement.

Task 11: Inspecter les codes de réponse SMTP dans les logs (êtes‑vous throttled ?)

cr0x@server:~$ grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 5
Jan  4 10:14:22 mail postfix/smtp[22101]: 3F2A01234A: to=<user1@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.26]:25, delay=12, delays=0.1/0.02/5/6.9, dsn=4.7.28, status=deferred (host gmail-smtp-in.l.google.com[142.250.27.26] said: 421-4.7.28 [203.0.113.10] Our system has detected an unusual rate of unsolicited mail...)
Jan  4 10:14:25 mail postfix/smtp[22102]: 9ADBC1234B: to=<user2@outlook.com>, relay=outlook-com.olc.protection.outlook.com[52.101.73.8]:25, delay=8.2, delays=0.1/0.01/3.3/4.8, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[52.101.73.8] said: 451 4.7.0 Temporary server error. Please try again later.)

Ce que cela signifie : Vous êtes throttlé / limité pour réputation (4.7.x).
Décision : Arrêtez d’« envoyer plus fort ». Réduisez le volume, segmentez vers des destinataires engagés, corrigez les plaintes, faites du warm‑up, et assurez‑vous de ne pas mélanger marketing et transactionnel sur la même IP/domaine.

Task 12: Vérifier l’alignement dans un en‑tête reçu réel (résultats SPF/DKIM/DMARC)

cr0x@server:~$ sed -n '1,80p' sample-headers.txt
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=abc123;
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Ce que cela signifie : L’alignement est OK : header.from correspond au domaine DKIM et SPF mailfrom est du même domaine organisationnel.
Décision : Si DMARC échoue ou montre un désalignement, corrigez votre stratégie de domaine From ou configurez le fournisseur pour signer avec votre domaine et utiliser un return‑path aligné.

Task 13: Vérifier la présence des en‑têtes List‑Unsubscribe (et qu’ils fonctionnent)

cr0x@server:~$ grep -i "^List-Unsubscribe" -n sample-headers.txt
42:List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>, <https://example.com/unsub?u=abcd>
43:List-Unsubscribe-Post: List-Unsubscribe=One-Click

Ce que cela signifie : Vous proposez mailto et désabonnement en un clic.
Décision : Si absent, implémentez‑le. Si présent mais votre endpoint est instable, corrigez d’abord la fiabilité — un désabonnement cassé génère des plaintes.

Task 14: Confirmer que votre domaine d’envoi n’est pas utilisé pour le tracking web sur un hôte « neuf »

cr0x@server:~$ dig +short CNAME click.example.com
tracking.vendor-mail.net.

Ce que cela signifie : Votre click tracking utilise un domaine fournisseur via CNAME.
Décision : Si ce domaine de tracking a une mauvaise réputation, il peut tirer votre mail vers le bas. Envisagez de désactiver le click tracking pour les flux sensibles ou de migrer vers un sous‑domaine de tracking stable avec une histoire cohérente.

Task 15: Rechercher les changements soudains de volume en analysant les logs

cr0x@server:~$ awk '{print $1" "$2" "$3}' /var/log/mail.log | sort | uniq -c | tail
  88 Jan  4 10:12
  91 Jan  4 10:13
  96 Jan  4 10:14
 420 Jan  4 10:15
 110 Jan  4 10:16

Ce que cela signifie : Il y a un pic à 10:15.
Décision : Si les pics corrèlent avec le placement en spam, lissez le rythme d’envoi, scindez les campagnes et montez progressivement. La délivrabilité déteste les fêtes surprises.

Trois micro‑histoires d’entreprise issues du terrain

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

Une entreprise SaaS de taille moyenne a migré les e‑mails transactionnels d’un fournisseur vers « Postfix en interne sur une IP propre ».
SPF et DKIM passaient tous les tests. DMARC rapportait un pass. Tout le monde a fait un high‑five et est passé à autre chose.

En 48 heures, les e‑mails de réinitialisation de mot de passe ont commencé à atterrir dans le spam pour une tranche non triviale d’utilisateurs.
Les tickets support affluaient avec la phrase classique : « Je ne reçois pas les e‑mails. » L’équipe d’ingénierie a vérifié : le mail était accepté (250),
pas de rebonds, pas de blocages. Donc c’est forcément une « erreur utilisateur », non ?

La fausse hypothèse était que des auths passantes et des logs propres équivalent à un placement en boîte de réception. Ce n’est pas vrai.
Ils étaient passés de l’espace IP déjà chauffé du fournisseur à une IP toute neuve sans historique, puis ont envoyé un gros pic pendant un pic d’inscriptions.
Pour les fournisseurs de boîtes, cela ressemblait moins à un « service fiable » et plus à « nouvel expéditeur qui essaie d’évoluer vite ».

La correction n’était pas DNS. Elle était opérationnelle : throttler les envois transactionnels (oui, ça fait mal), prioriser les destinataires engagés,
et faire un warm‑up intentionnel. Ils ont aussi séparé transactionnel et marketing sur des sous‑domaines et IPs différents
pour que l’un ne puisse pas empoisonner l’autre. Après quelques semaines de comportement stable, le placement est revenu.

Micro‑histoire 2 : L’optimisation qui a mal tourné

Une entreprise retail s’est voulue maligne. Elle voulait réduire le temps de traitement des rebonds et « améliorer le débit »,
alors elle a réglé son MTA pour réessayer les messages différés plus agressivement, augmenté la concurrence et raccourci les timers d’exponential backoff.
Sur le papier : livraison plus rapide. En réalité : un désastre en slow motion.

Les grands fournisseurs de boîtes ont réagi par plus de throttling. Leurs logs se sont remplis de déferrals 4.7.x.
La file a commencé à osciller : énormes rafales de réessais, puis plus de déferrals, puis des rafales encore plus grosses.
Ce qui ressemblait à des « réessais efficaces » paraissait aux récepteurs comme un expéditeur qui n’entend pas le message.

Le placement en spam s’est aggravé partout, y compris pour des messages qui avaient auparavant de bonnes performances.
Ce n’était pas le contenu. Ce n’était pas DKIM. C’était le comportement au niveau SMTP : le schéma de réessai de l’expéditeur était devenu bruyant et robotisé.

Le retour en arrière fut ennuyeux : restaurer des calendriers de réessai conservateurs, réduire la concurrence, et introduire du rate limiting par domaine.
Ils ont aussi commencé à considérer 4.7.x comme un signal pour ralentir, pas comme un défi à combattre.
L’ironie : la livraison est devenue plus rapide pour les destinataires importants, parce que les expéditeurs ont arrêté de déclencher des throttles.

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

Une entreprise du secteur santé avait des exigences strictes de délivrabilité pour les rappels de rendez‑vous.
Ils ont fait quelque chose d’assez terne : exécuter des jobs hebdomadaires d’hygiène de liste, traiter les rebonds en quelques heures,
et garder une liste de suppression qu’on ne pouvait outrepasser sans ticket et note d’audit.

Un trimestre, l’équipe marketing a importé une « liste de réactivation » issue d’un vieil export CRM.
Ce n’était pas malveillant. C’était juste obsolète. Le premier envoi a produit une vague de hard bounces et une hausse notable des plaintes.

Ici la pratique ennuyeuse les a sauvés : la suppression automatisée a démarré immédiatement, retirant les adresses mortes avant la seconde vague.
Leurs systèmes ont aussi signalé le pic de plaintes et mis les envois en pause en attente d’une revue. Les mails transactionnels ont continué sur une infrastructure séparée.

Les conséquences ont été mineures : une petite baisse temporaire du placement pour les messages marketing, mais aucun impact sur les rappels.
Pas de changements DNS d’urgence, pas de « flattening » SPF frénétique, pas de blâme au fournisseur. Juste de l’hygiène disciplinée et une séparation des responsabilités.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptôme : SPF/DKIM passent, DMARC passe, mais Gmail dit « des messages similaires ont été identifiés comme spam »

Cause racine : faible engagement et/ou plaintes, souvent liées à l’envoi à des listes froides ou au mélange de flux (transactionnel + marketing).

Correctif : segmentez vers les engagés, mettez en pause les segments froids, séparez marketing et transactionnel sur différents sous‑domaines/IPs, ajoutez list‑unsubscribe, et réduisez la fréquence.

2) Symptôme : Outlook/Hotmail place les mails en indésirables de façon intermittente

Cause racine : signaux d’infrastructure incohérents (mismatch rDNS/HELO, TLS instable, IPs variables), plus des patterns de contenu proches du phishing.

Correctif : stabilisez les IPs d’envoi, corrigez rDNS et EHLO, assurez‑vous que STARTTLS fonctionne constamment, alignez From/Reply‑To/links, et évitez les types de pièces jointes risqués.

3) Symptôme : les tests internes montrent inbox, les vrais utilisateurs voient spam

Cause racine : les tests seed ne sont pas représentatifs ; le comportement réel des utilisateurs façonne la réputation. Aussi, les boîtes grand public diffèrent selon l’historique utilisateur.

Correctif : instrumentez le taux de plaintes, le taux de rebonds et l’engagement par domaine ; testez avec des segments réels ; concentrez‑vous sur les destinataires ayant récemment opté‑in.

4) Symptôme : DMARC échoue uniquement pour les mails transférés

Cause racine : le transfert casse SPF ; DKIM casse quand des intermédiaires modifient le contenu ; ARC absent.

Correctif : assurez‑vous que DKIM survive (signez en ciblant des en‑têtes stables, évitez la réécriture), envisagez ARC sur les forwarders que vous contrôlez, et acceptez que certains forwardings soient dégradés.

5) Symptôme : DMARC passe mais la marque semble toujours suspecte

Cause racine : surface de marque désalignée (Reply‑To ou liens sur des domaines non liés ; tracking lourd ; raccourcisseurs d’URL).

Correctif : gardez From/Reply‑To/liens dans une famille de domaines cohérente ; minimisez les redirections ; utilisez un sous‑domaine de tracking stable avec de l’historique.

6) Symptôme : placement dégradé soudainement après changement d’ESP

Cause racine : nouveau flux d’IP/domaine sans réputation ; montée de volume trop rapide ; listes de suppression non migrées.

Correctif : montez progressivement le warm‑up, migrez les suppressions, commencez par des destinataires engagés, et évitez de changer les domaines From en même temps que l’infrastructure.

7) Symptôme : la délivrabilité allait bien, puis s’effondre après ajout d’un nouveau template

Cause racine : empreinte de contenu modifiée (phrases, schémas de liens, ou un domaine dans les URL avec mauvaise réputation).

Correctif : différenciez les templates, supprimez les phrases risquées, vérifiez les domaines d’URL, réduisez le déséquilibre image/texte, et évitez les pièces jointes sauf nécessité.

8) Symptôme : messages fortement retardés, puis arrivent en spam

Cause racine : throttling et tempêtes de réessais créent des schémas en rafales ; le backlog modifie le timing et la perception de réputation.

Correctif : implémentez du rate limiting par domaine, respectez les déferrals, réduisez la concurrence, et lissez l’envoi.

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

Plan étape par étape pour « auth passe mais spam » (faire dans cet ordre)

1. Choisissez un message représentatif qui est allé en spam et sauvegardez les en‑têtes complets.
   • Décision : si vous ne pouvez pas reproduire avec des en‑têtes réels, vous déboguez une impression plutôt que la réalité.
2. Confirmez l’alignement DMARC pour ce message (header.from vs DKIM d= et SPF mailfrom).
   • Décision : si désaligné, corrigez l’architecture d’identité avant toute autre chose.
3. Vérifiez l’hygiène d’infrastructure : PTR, FCrDNS, HELO, TLS.
   • Décision : corrigez les problèmes d’hygiène évidents ; ce sont des gains faciles qui réduisent la suspicion de base.
4. Vérifiez les throttlings/deferrals dans les logs (4.7.x est votre canari).
   • Décision : si throttlé, ralentissez et segmentez ; ne touchez pas aux réessais pour « gagner ».
5. Séparez les flux : transactionnel vs marketing vs notifications.
   • Décision : si vous les mélangez aujourd’hui, planifiez la séparation. C’est un des changements avec le ROI le plus élevé.
6. Auditez l’hygiène de liste : rebonds, plaintes, segments anciens, campagnes de réactivation.
   • Décision : si vous ne pouvez pas mesurer plaintes/rebonds rapidement, corrigez l’instrumentation avant de monter en charge.
7. Réduisez les « surfaces suspectes » : domaines dépareillés, tracking agressif, raccourcisseurs d’URL, pièces jointes.
   • Décision : simplifiez. Vous n’essayez pas de gagner un prix tech marketing ; vous essayez d’être délivré.
8. Warm‑up et stabilisez : volume cohérent, horaire prévisible, rampes progressives.
   • Décision : traitez le warm‑up comme un déploiement en production, pas comme une configuration ponctuelle.

Checklist opérationnelle (hebdomadaire)

• Revoir les tendances de rebonds et de plaintes par domaine destinataire.
• Confirmer que les suppressions sont appliquées en quelques heures, pas jours.
• Rouler les clés DKIM selon un calendrier contrôlé (et garder les anciens sélecteurs pendant la transition).
• Valider que rDNS et TLS restent corrects après changements d’infrastructure.
• Réviser les domaines les plus cliqués et les chaînes de redirection utilisées dans les templates.
• Vérifier la profondeur de la file et les déferrals ; ajuster les limites de taux, pas seulement la concurrence.

Checklist d’architecture (une fois, puis maintenir)

• Séparer les sous‑domaines d’envoi par flux (par ex., notify., billing., marketing.).
• Aligner d= DKIM avec le domaine From (ou un sous‑domaine organisationnel aligné) autant que possible.
• Utiliser une IP dédiée (ou au moins un pool dédié) pour les messages transactionnels critiques.
• Implémenter List‑Unsubscribe et désabonnement en un clic pour le bulk mail.
• Assurer l’automatisation et la fiabilité du traitement des rebonds.

FAQ

1) Si SPF et DKIM passent, pourquoi un fournisseur me classe-t-il quand même en spam ?

Parce que l’authentification ne prouve que l’identité et l’intégrité du message. Le placement est guidé par la réputation, le comportement, l’engagement, les plaintes et les patterns de contenu.
Passer SPF/DKIM signifie juste que vous êtes un expéditeur vérifié — pas forcément bienvenu.

2) DMARC est‑il requis pour la boîte de réception ?

Pas universellement, mais pratiquement oui si vous voulez une livraison cohérente et éviter l’usurpation. DMARC vous force aussi à nettoyer l’alignement,
ce qui supprime toute une catégorie de signaux « ça semble forgé ».

3) Quelle est l’amélioration la plus rapide si nous allons en spam ?

Arrêtez d’envoyer aux destinataires non engagés. Segmentez agressivement : ouvertures/clics/réponses récents (selon ce que vous pouvez mesurer fiablement),
inscriptions récentes et destinataires ayant interagi. La réputation récupère plus vite quand vous arrêtez d’agacer les gens.

4) Devons‑nous passer à une IP dédiée ?

Si vous envoyez suffisamment pour justifier le warm‑up et la maintenance, oui — surtout pour les flux transactionnels.
Si votre volume est faible ou variable, une IP dédiée peut être pire car vous ne construirez pas une réputation stable.

5) Le contenu compte‑t‑il vraiment si notre réputation est bonne ?

Oui. La réputation vous ouvre la porte ; le contenu décide si vous restez dans la pièce. La structure phishy, les URL risquées,
le tracking lourd et le formatage bizarre peuvent couler un mail par ailleurs réputé.

6) Nos mails sont transférés via des systèmes de ticketing puis échouent. Que faire ?

Le transfert casse SPF, et les modifications cassent DKIM. Si vous contrôlez le forwarder, envisagez d’implémenter ARC.
Sinon, concentrez‑vous sur la robustesse DKIM (signer des en‑têtes stables) et acceptez que certains transferts réduisent la confiance.

7) Nous avons ajouté plus de clés/sélecteurs DKIM. Cela peut‑il nuire ?

Pas en soi. Ce qui nuit, c’est la signature incohérente (parfois signée, parfois non), des enregistrements DNS cassés, ou des rotations de sélecteurs sans période de transition.
Gardez les anciens sélecteurs actifs tant que du mail en transit peut encore les référencer.

8) Devons‑nous utiliser « p=reject » sur DMARC pour améliorer la délivrabilité ?

L’application DMARC peut réduire l’usurpation et l’abus de marque, ce qui aide indirectement la réputation.
Mais cela ne corrigera pas une mauvaise hygiène de liste ou un taux de plaintes élevé. Ne considérez pas p=reject comme un bouton magique de délivrabilité.

9) Pourquoi les tests seed indiquent « inbox » mais les vrais utilisateurs voient le spam ?

Les comptes seed ne se comportent pas comme de vrais destinataires et n’ont pas le même historique. Les fournisseurs personnalisent le filtrage.
Le comportement réel de votre audience (suppressions, plaintes, manque de lectures) est le véritable révélateur.

10) Les listes noires DNS sont‑elles la raison de notre placement en spam ?

Parfois, mais rarement la seule explication pour les boîtes grand public. Les blocklists expliquent mieux les blocages durs que les placements subtils en spam.
Utilisez‑les comme signal d’investigation pour compromission ou mauvais comportements, pas comme métrique unique.

Conclusion : étapes suivantes qui font réellement la différence

Si SPF et DKIM passent mais que vous allez en spam, cessez de traiter la délivrabilité comme un puzzle DNS.
C’est un système de confiance. La confiance se gagne par une identité cohérente, une infrastructure propre et un comportement d’envoi respectueux.

Faites ceci ensuite, dans l’ordre :

1. Extrait un message spammé, sauvegardez les en‑têtes complets, et confirmez l’alignement DMARC et la cohérence des domaines (From/Reply‑To/liens).
2. Corrigez l’hygiène d’infrastructure : rDNS, FCrDNS, HELO et STARTTLS avec certificats valides.
3. Vérifiez les logs pour throttling (4.7.x). Si présent, ralentissez et segmentez immédiatement.
4. Séparez transactionnel et marketing par sous‑domaine et idéalement IP/pool.
5. Implémentez et testez le désabonnement en un clic ; renforcez le traitement des rebonds et supprimez vite les hard bounces.
6. Montez en température les nouvelles IPs/domaines comme vous déployeriez un nouveau cluster de base de données : progressivement, de façon observable, avec plans de rollback.

Les signaux cachés ne sont pas vraiment cachés. Ils ne figurent tout simplement pas dans votre zone DNS.
Ils sont dans vos logs, le comportement de votre audience, et la constance ennuyeuse de vos systèmes.