Courriel : réputation d’envoi effondrée — quoi arrêter immédiatement (et correctifs)

Arrêtez immédiatement ces pratiques

1) Arrêtez de « tester » en envoyant à toute votre liste

Si la réputation chute, le volume amplifie les dégâts. Envoyer plus de mails alors que le taux de rebond et les plaintes augmentent apprend aux fournisseurs de boîtes que vous êtes un expéditeur dont il faut protéger les utilisateurs. Votre premier travail est d’arrêter d’alimenter l’incendie.

Remplacez les tests massifs par des échantillons contrôlés vers une liste de seed vérifiée et un petit sous-ensemble de vos destinataires les plus engagés (ouvertures/clics/réponses récents). Et si vous ne pouvez pas mesurer l’engagement, ce n’est pas une raison pour continuer à bombarder ; c’est une raison pour ralentir.

2) Arrêtez d’envoyer depuis de nouveaux domaines « pour régler le problème »

« Envoyons juste depuis un autre domaine » est de la dette de deliverabilité avec intérêts. Les fournisseurs corrèlent l’infrastructure, les URL, le contenu et le comportement. De plus, vous perdez la réputation positive que vous aviez. Corrigez le problème ; ne le rebaptisez pas.

3) Arrêtez d’ignorer les rebonds et de réessayer indéfiniment

Votre MTA réessaie joyeusement les réponses 4xx. C’est le comportement correct pour des erreurs temporaires, mais si vous recevez des tempfails liés à du throttling ou à la réputation, vous avez besoin d’un contrôle de débit et d’une stratégie de suppression — pas d’un optimisme infini.

4) Arrêtez d’envoyer des mails qui échouent l’authentification (ou qui « passent à moitié »)

SPF passé avec DKIM échoué n’est pas « acceptable ». DMARC passé sans alignement n’est pas « acceptable ». En 2026, les principaux fournisseurs appuient plus fortement sur les mails authentifiés et alignés. Vous n’avez pas besoin de perfection, mais arrêtez d’envoyer des mails non authentifiés ou mal alignés comme si c’était 2009.

5) Arrêtez de faire passer les mails marketing et transactionnels par la même identité

Mélanger une newsletter hebdomadaire et des réinitialisations de mot de passe sous le même domaine et la même IP, c’est comment vous apprenez accidentellement à Gmail que « vos codes de connexion ont le même ton que votre promo hivernale ». Séparez les flux : sous-domaines, sélecteurs DKIM distincts, pools d’IP séparés si vous êtes assez grand.

6) Arrêtez de changer cinq variables en même temps

Quand vous ajustez SPF, faites tourner DKIM, changez le domaine From, changez d’ESP et modifiez les templates le même jour, vous perdez la capacité d’attribuer la cause. Traitez la deliverabilité comme un incident : un changement, impact mesuré, option de rollback.

Petite blague #1 : La réputation e-mail, c’est comme un score de crédit : on peut la ruiner rapidement, et la contester en tapant au clavier n’aide pas.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Ceci est le chemin « obtenir un signal en 30 minutes ». Il ne résoudra pas tout, mais il trouvera rapidement le goulot d’étranglement et vous évitera de deviner.

Premier : déterminer le mode de défaillance (livraison vs placement vs acceptation)

• Défaillance de livraison : rebonds, délais, blocs, croissance de la file, erreurs SMTP.
• Défaillance de placement : accepté (250 OK) mais atterrit dans spam/promotions/quarantaine.
• Accepté mais non vu : règles côté utilisateur, quarantaine d’entreprise, journalisation ou problèmes de routage.

Test rapide : choisissez 10 messages récents, collectez les logs de transaction SMTP et classez-les. Ne vous fiez pas à « l’utilisateur dit qu’il ne l’a pas reçu. » Les utilisateurs disent aussi « je n’ai rien changé ».

Deuxième : vérifier l’authentification et l’alignement (SPF/DKIM/DMARC)

• Le domaine From: est-il aligné avec SPF (MAIL FROM / Return-Path) ou le domaine d= DKIM ?
• Les signatures DKIM sont-elles présentes et vérifient-elles ?
• Une politique DMARC existe-t-elle, et voyez-vous des échecs ?

La plupart des chutes soudaines de réputation sont corrélées à des régressions d’authentification après un changement de fournisseur, une modification DNS ou une modification de la chaîne d’outils de templates.

Troisième : examinez votre profil de rebonds et de plaintes

• Rebonds durs : utilisateur inconnu, domaine invalide. Ils doivent être supprimés rapidement.
• Rebonds doux / throttles : limitation de débit, « réessayez plus tard », tempfails liés à la réputation.
• Plaintes : utilisateurs qui marquent comme « spam ». Si vous ne recevez pas de retours de plainte via votre ESP, vous avez quand même des plaintes — vous ne recevez juste pas le mémo.

Quatrième : isoler les flux et réduire le volume

Le mail transactionnel doit être protégé comme une base de données. Si votre flux marketing provoque une montée des rebonds, coupez-le ou déplacez-le vers une identité d’envoi séparée. L’objectif est d’arrêter les dommages collatéraux.

Cinquième : valider l’identité de l’infrastructure (rDNS, HELO, TLS)

Beaucoup de blocs sont simplement des signaux « ça ressemble à une infrastructure malveillante » : enregistrements PTR manquants, HELO générique, ou TLS cassé. Ce sont des gains faciles.

Comment la réputation fonctionne réellement (les parties qu’on oublie)

La réputation est multidimensionnelle, pas un score unique

Les fournisseurs de boîtes ne conservent pas un seul numéro magique pour vous. Ils suivent la réputation selon :

• Réputation de domaine (le domaine From: que voient les utilisateurs)
• Réputation de sous-domaine (news.example.com vs example.com)
• Réputation d’IP (surtout pour les IP dédiées)
• Réputation d’URL (où pointent vos liens, y compris les redirections)
• Réputation de contenu et comportementale (templates, lignes d’objet, schémas d’engagement)
• Réputation au niveau du destinataire (comment vos mails se comportent pour un fournisseur spécifique)

Donc quand quelqu’un dit « notre domaine est grillé », votre première question est : quel domaine, quel flux, quel fournisseur, quelle fenêtre temporelle ?

Les fournisseurs optimisent les résultats utilisateurs, pas le confort des expéditeurs

L’objectif du filtrage est « les utilisateurs ne sont pas agacés et ne sont pas phishés ». Votre objectif est « mes mails business sont vus ». Ces objectifs se recoupent seulement si vous vous comportez bien. Si la qualité de votre liste se dégrade, aucun tour de DNS ne compensera totalement.

L’authentification est le minimum ; l’alignement est le vrai enjeu

SPF et DKIM sont des mécanismes d’authentification. DMARC est la couche politique et de rapport, et il introduit l’alignement : le domaine visible pour l’utilisateur doit correspondre au domaine authentifié. Beaucoup d’expéditeurs « passent SPF » via un domaine de rebond d’un ESP, mais échouent DMARC parce que le domaine From: n’est pas aligné.

La récupération de réputation ressemble au shaping du trafic après une panne

Si vous étiez limité en débit, vous ne « prouvez » pas que vous êtes bon en envoyant plus. Vous le prouvez en envoyant constamment, à des personnes qui veulent vos mails, avec des faibles taux de rebond et de plaintes. Le warm-up est une discipline opérationnelle, pas de l’optimisme marketing.

Une citation (idée paraphrasée) : Gene Kim insiste souvent sur le fait que les systèmes fiables viennent de pratiques disciplinées et répétables plutôt que d’actions héroïques. C’est aussi la deliverabilité.

Faits intéressants et contexte historique (ce qui explique les règles d’aujourd’hui)

1. SMTP a précédé le spam. Le protocole mail d’origine supposait un réseau de confiance ; l’authentification et les contrôles d’abus ont été ajoutés ensuite.
2. SPF et DKIM sont nés de douleurs différentes. SPF visait à valider les IP d’envoi ; DKIM visait l’intégrité du message et la responsabilité du domaine.
3. DMARC a rendu l’« alignement » courant. Avant DMARC, « passer quelque chose » suffisait ; DMARC a rendu le domaine visible responsable.
4. Les systèmes de réputation répondent à l’échelle. Quand les fournisseurs ont commencé à traiter des milliards de messages, la liste blanche manuelle est morte et le filtrage statistique a pris le relais.
5. Le greylisting fut autrefois à la mode. Les échecs temporaires pour forcer les réessais servaient à dissuader le spam. Aujourd’hui, ça punit surtout les expéditeurs mal configurés et les MTAs fragiles.
6. Les e-mails uniquement image sont devenus un trope spam. Les spammeurs utilisaient des images pour contourner les filtres de mots-clés ; les fournisseurs ont répliqué par de l’OCR et des heuristiques améliorées.
7. Les IP partagées créent un « risque de voisinage ». L’essor des ESP a normalisé l’infrastructure partagée, et un mauvais acteur peut tirer tout un pool vers le bas.
8. Les gros fournisseurs exigent de plus en plus l’alignement pour les envois en masse. Au fil du temps, la barre a monté de « un peu d’auth » à « auth alignée plus bonnes pratiques de liste ».
9. Les rebonds sont un signal de réputation, pas seulement un échec de livraison. Un taux élevé d’inconnus ressemble à de la récolte d’adresses ou à des données périmées, et les filtres réagissent en conséquence.

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

Voici les vérifications que vous pouvez exécuter aujourd’hui. Chaque tâche inclut : une commande, une sortie réaliste, ce que cela signifie, et la décision à prendre.

Task 1: Check if the mail queue is exploding (Postfix)

cr0x@server:~$ mailq | tail -n 20
-- 2150 Kbytes in 124 Requests.
AB12CD34EF     2190 Thu Jan  4 10:11:12  sender@example.com
                                         (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later (in reply to end of DATA command))
                                         user@gmail.com

Signification : Beaucoup de mails différés, avec des tempfails 421. C’est généralement du throttling, un problème de réputation, ou une limitation côté fournisseur.

Décision : Arrêter les envois massifs, implémenter une limitation de débit et se concentrer sur la réputation/l’authentification avant que la file ne devienne votre nouvel outil de surveillance.

Task 2: Inspect recent SMTP status codes for patterns

cr0x@server:~$ sudo grep -E "status=(bounced|deferred)" /var/log/mail.log | tail -n 15
Jan  4 10:11:12 mx1 postfix/smtp[22107]: AB12CD34EF: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.200.26]:25, delay=12, delays=0.2/0/2/9.8, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[74.125.200.26] said: 421-4.7.0 Temporary System Problem.  Try again later)
Jan  4 10:11:18 mx1 postfix/smtp[22111]: CD34EF56GH: to=<user@outlook.com>, relay=outlook-com.mail.protection.outlook.com[52.101.68.9]:25, delay=3.2, delays=0.1/0/0.7/2.4, dsn=5.7.1, status=bounced (host outlook-com.mail.protection.outlook.com[52.101.68.9] said: 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.)

Signification : Gmail tempfail ; Microsoft rejette avec un 5.7.1 et un refus basé sur l’IP.

Décision : Rémédiation séparée par fournisseur. Pour Microsoft, vous aurez besoin d’améliorer la réputation IP/domaine et probablement d’un workflow de désinscription ; pour Gmail, réduisez le volume et corrigez l’authentification/la qualité de liste.

Task 3: Verify your outbound IP address (what the world sees)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.10

Signification : C’est l’IP publique que les fournisseurs associent à vos connexions SMTP.

Décision : Utilisez cette IP pour les vérifications PTR, les vérifications de listes noires (en interne ou via le portail de votre fournisseur), et toute escalade auprès de votre ISP/ESP.

Task 4: Confirm reverse DNS (PTR) exists and matches your mail identity

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

Signification : Le PTR existe. Ensuite, assurez-vous d’un reverse DNS confirmé en avant (FCrDNS) : le nom d’hôte résout de nouveau vers la même IP.

Décision : Si le PTR est manquant ou générique (comme un nom d’instance cloud), corrigez-le avec votre ISP/fournisseur cloud. Un PTR manquant est une voie rapide vers le score « hôte suspect ».

Task 5: Verify forward DNS for the PTR hostname

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

Signification : FCrDNS passe. Bon.

Décision : Si ça ne correspond pas, corrigez le DNS pour que PTR et A soient cohérents.

Task 6: Check HELO/EHLO name your MTA presents

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

Signification : HELO correspond à un nom d’hôte réel et résolvable. Cela réduit l’aspect « botnet ».

Décision : Si vous voyez « localhost » ou un nom d’instance cloud aléatoire, corrigez-le. Ça compte plus qu’on ne le pense.

Task 7: Validate SPF record exists and isn’t a hand grenade

cr0x@server:~$ dig +short TXT example.com | sed -n '1,5p'
"v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"

Signification : SPF autorise votre IP et Microsoft 365, et finit par -all (fail dur). C’est correct si c’est exact.

Décision : Si SPF est manquant ou termine par ~all alors que vous essayez d’appliquer DMARC, resserrez-le. Si il inclut trop de fournisseurs que vous n’utilisez plus, supprimez-les.

Task 8: Check SPF DNS lookup count (the silent failure)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null 2>&1 || true
cr0x@server:~$ spfquery -ip 203.0.113.10 -sender bounce@example.com -helo mx1.mail.example.com -debug | tail -n 8
policy result: pass
mechanism: ip4:203.0.113.10
explanation: (none)
received-spf: pass (example.com: domain of bounce@example.com designates 203.0.113.10 as permitted sender)

Signification : SPF évalue en pass pour cette IP d’envoi et cet expéditeur d’enveloppe.

Décision : Si vous voyez permerror ou « too many DNS lookups », simplifiez SPF (aplanir les includes, retirer les services anciens). Un permerror SPF est souvent traité comme un échec en pratique.

Task 9: Confirm DKIM public key is published for the selector you’re using

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

Signification : La clé existe en DNS. Ensuite, assurez-vous que vos mails sortants signent effectivement avec ce sélecteur et que les signatures vérifient.

Décision : Si l’enregistrement manque, publiez-le. Si vous avez fait tourner les clés, assurez-vous que les anciens sélecteurs restent jusqu’à ce que tous les systèmes ne les utilisent plus.

Task 10: Verify DMARC record and policy

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

Signification : DMARC existe, avec un alignement strict pour SPF et DKIM. C’est une position ferme.

Décision : Si vous échouez l’alignement à cause d’un outil fournisseur, soit corrigez l’outil, soit assouplissez temporairement l’alignement. Un alignement strict mal configuré est de l’auto-sabotage déguisé en sécurité.

Task 11: Inspect a real message’s Authentication-Results (from headers)

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature|From:" -n sample.eml | head -n 30
12:From: "Example Support" <support@example.com>
45:DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed;
88:Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@bounce.example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@bounce.example.com;
       dkim=pass header.i=@example.com header.s=s1;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Signification : SPF et DKIM passent individuellement, mais DMARC échoue. Pourquoi ? SPF authentifie bounce.example.com (le domaine d’enveloppe), qui n’est pas aligné avec example.com. DKIM passe et est aligné (d=example.com), donc DMARC devrait passer — à moins que la signature DKIM n’ait pas couvert correctement l’en-tête From, ou que le fournisseur ait vu un résultat de signature différent de celui que vous avez capturé.

Décision : Re-prenez la capture depuis la boîte du destinataire avec tous les en-têtes, confirmez l’alignement DKIM et assurez-vous qu’aucun système intermédiaire ne modifie le message (pieds de page, réécritures) après la signature. Si vous avez un connecteur M365 ou une passerelle qui ajoute des clauses, cela peut casser DKIM.

Task 12: Check whether a gateway or disclaimer is breaking DKIM

cr0x@server:~$ sudo grep -R "disclaimer\|footer\|append" /etc/postfix /etc/opendkim /etc/mail 2>/dev/null | head
/etc/opendkim.conf:# OversignHeaders From

Signification : Peu trouvé localement. Cela suggère que la modification pourrait se produire en amont (par exemple, passerelle d’entreprise, tracker d’ESP, ou appliance de sécurité en aval).

Décision : Tracez le chemin du mail. Si quelque chose modifie le corps/en-têtes après la signature DKIM, corrigez l’ordre (signer en dernier) ou configurez l’« oversigning » de façon appropriée. Ou déplacez les modifications avant la signature.

Task 13: Measure bounce rate by reason (log sampling)

cr0x@server:~$ sudo awk '/status=bounced/ {print $0}' /var/log/mail.log | tail -n 500 | \
awk -F'said: ' '{print $2}' | sed 's/[()]//g' | cut -c1-80 | sort | uniq -c | sort -nr | head
  88 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your email administrator.
  41 550 5.1.1 <user@domain.com>: Recipient address rejected: User unknown
  19 554 5.7.1 Message rejected due to content restrictions

Signification : L’erreur principale est un blocage de réputation/IP chez Microsoft, pas un problème de contenu. La deuxième est des utilisateurs inconnus (hygiène de liste). La troisième est un rejet basé sur le contenu.

Décision : Prioriser : (1) remédiation réputation avec Microsoft, (2) supprimer immédiatement les utilisateurs inconnus, (3) revoir le contenu et les URL seulement après avoir arrêté l’hémorragie.

Task 14: Verify TLS support on outbound (signals legitimacy)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mail.example.com:25 -servername mx1.mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.mail.example.com
Verification: OK

Signification : STARTTLS fonctionne et le certificat valide. Cela aide le scoring de certains fournisseurs et évite des comportements étranges de downgrade.

Décision : Si TLS échoue, corrigez-le. Une quantité surprenante d’« on a l’air douteux » vient d’un TLS cassé ou de noms non correspondants.

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

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_recipient_restrictions|mynetworks|smtpd_client_restrictions"
mynetworks = 127.0.0.0/8 [::1]/128 10.0.0.0/8
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

Signification : Vous refusez le relais non authentifié vers des domaines non locaux. Bien.

Décision : Si vous voyez des règles permit avant reject_unauth_destination ou des mynetworks trop larges, corrigez maintenant. Un open relay détruira votre réputation plus vite que vous ne pouvez dire « incident review ».

Task 16: Rate-limit outbound to reduce tempfails and throttles

cr0x@server:~$ sudo postconf -e "default_destination_rate_delay = 1s"
cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 5"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf default_destination_rate_delay smtp_destination_concurrency_limit
default_destination_rate_delay = 1s
smtp_destination_concurrency_limit = 5

Signification : Vous ralentissez les livraisons par destination, ce qui réduit le throttling fournisseur et évite les comportements en rafale.

Décision : Restez conservateur pendant la récupération. Si la latence transactionnelle devient inacceptable, isolez un flux dédié (IP/sous-domaine séparé) plutôt que de pousser les réglages à fond.

Trois mini-histoires d’entreprise (anonymisées, plausibles et douloureusement familières)

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

Ils ont migré d’un ESP à un autre pendant un week-end. Le plan projet était propre : ajouter le nouvel ESP à SPF, publier de nouvelles clés DKIM, basculer l’API d’envoi, fini. Lundi matin, les e-mails de réinitialisation de mot de passe ont commencé à disparaître. Pas de rebonds. Juste… pas d’arrivée.

L’hypothèse erronée était que « SPF passé = deliverabilité ». Leur nouvel ESP utilisait un domaine return-path différent pour les rebonds, et bien que SPF passât pour ce domaine de rebond, l’alignement DMARC échouait pour le domaine From visible. Dans leur ancienne configuration, DKIM était aligné et stable. Dans la nouvelle, une passerelle de sécurité en aval a ajouté un pied de page après la signature de l’ESP, cassant DKIM à l’arrivée.

Ainsi, les utilisateurs voyaient « support@example.com », mais ni SPF aligné ni DKIM survivant d’une manière qui satisfasse DMARC. Certains fournisseurs ont mis en quarantaine ; d’autres ont silencieusement classé en spam. L’équipe a cherché les templates et les lignes d’objet parce que c’est ce que le marketing peut changer rapidement. Pendant ce temps, la vraie correction était : changer le comportement de la passerelle (pas de modifications post-signature), signer au dernier saut, et valider l’alignement avec de vrais en-têtes pris depuis les boîtes réceptrices.

L’action post-mortem qui a compté : chaque changement de chemin de mail nécessitait un test qui affirme un DMARC pass avec alignement pour chaque fournisseur majeur, pas juste « message accepté par le distant ». Ils ont commencé à traiter le mail comme du trafic de production plutôt que comme un service magique qui « marche tout seul ».

Mini-histoire 2 : L’optimisation qui a échoué

Une équipe growth voulait des campagnes plus rapides. Ils étaient convaincus que leur MTA était « trop lent », car les temps d’envoi s’étalaient sur des heures. Un ingénieur a augmenté les limites de concurrence et retiré les délais de rate. Les messages ont volé comme des confettis.

Pendant environ 30 minutes, ça a semblé bien. Puis les différés ont commencé : tempfails 421, « try again later », puis des blocs complets d’un fournisseur majeur. La file a gonflé. Les tempests de réessais ont démarré. Le système mail a passé la journée suivante à marteler les mêmes fournisseurs, prouvant à répétition qu’il ne savait pas se comporter poliment.

Dans la revue d’incident, l’optimisation a été reclassée comme « shaping de trafic agressif dans la mauvaise direction ». Les fournisseurs ne rejetaient pas parce que le contenu s’était soudainement détérioré ; ils rejetaient parce que le comportement de l’expéditeur ressemblait à un botnet : en rafale, implacable et ignorant la contre-pression.

Les correctifs ont été ennuyeux : baisser la concurrence, implémenter des limites par destination, et échelonner les campagnes. Mais la vraie correction a été organisationnelle : arrêter de traiter la deliverabilité comme du débit. Le mail n’est pas un protocole de transfert de données en vrac ; c’est un protocole de confiance avec SMTP comme transport.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une entreprise SaaS de taille moyenne avait séparé les mails transactionnels et marketing il y a des années. Pas à cause d’une crise — parce qu’un SRE a insisté sur le fait que « le blast radius existe ». Les mails transactionnels sortaient de mail.example.com sur un petit pool d’IP dédié, avec un DMARC strict et une pipeline de templates verrouillée. Le marketing passait par news.example.com via un pool partagé d’ESP.

Un trimestre, le marketing a acquis une liste partenaire (opt-in… soi-disant). Les taux de plainte ont augmenté. Le pool ESP a commencé à vaciller. Certains domaines ont limité. La deliverabilité marketing a chuté. Ennuyeux, mais tenable.

La partie importante : les mails de réinitialisation, factures et alertes ont continué d’arriver. Les métriques du flux transactionnel sont restées propres : faibles rebonds, volume stable, destinataires constants. Les fournisseurs ont continué à lui faire confiance parce qu’il se comportait de façon prévisible et que les utilisateurs y interagissaient positivement.

Le moment « sauvé » est arrivé pendant un cycle de facturation. Si les factures étaient passées en spam, ce serait un incident de revenu. Ils l’ont évité parce que quelqu’un avait fait l’architecture terne en avance : séparation, alignement, et un plan de warm-up mesuré pour tout changement. La production aime l’ennuyeux.

Petite blague #2 : Si votre plan de deliverabilité est « envoyer plus fort », félicitations — vous venez de réinventer la tempête de réessais, mais pour le marketing.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptôme : Gmail accepte (250 OK) mais les utilisateurs rapportent un placement en spam

• Cause racine : Faible engagement et/ou dégradation de la liste ; contenu promotionnel ; pics de volume incohérents ; signaux d’alignement manquants.
• Correctif : Réduire le volume, n’envoyer qu’aux engageurs récents, supprimer les inactifs, assurer que DKIM est aligné, et garder une cadence constante pendant 2–4 semaines.

2) Symptôme : Microsoft rebondit avec 550 5.7.1 mentionnant votre IP

• Cause racine : Dégâts de réputation IP (problèmes de voisinage sur un pool partagé ou comportement de rebonds/plaintes de votre côté). Parfois aussi PTR manquant ou TLS faible.
• Correctif : Confirmer PTR/HELO/TLS, réduire le débit, corriger l’hygiène, et engager la remédiation spécifique via votre fournisseur d’envoi. Si vous êtes sur une IP partagée, demandez un pool différent ou une IP dédiée avec warm-up.

3) Symptôme : les échecs DMARC ont grimpé juste après un changement DNS ou de fournisseur

• Cause racine : Désalignement entre le domaine From et les domaines authentifiés ; mauvais sélecteur DKIM ; passerelle modifiant les messages après signature ; permerror SPF dû aux limites de lookup.
• Correctif : Valider avec de vrais en-têtes, s’assurer que DKIM signe avec d= aligné au From, corriger SPF, et supprimer les modifications post-signature.

4) Symptôme : augmentation soudaine des rebonds « User unknown »

• Cause racine : Liste périmée, contacts importés, domaines mal tapés, ou validation d’inscription cassée.
• Correctif : Suppression immédiate des rebonds durs ; implémenter la validation d’adresse au capture ; mettre en quarantaine les vieux segments ; ne re-permissionner qu’aux utilisateurs engagés connus.

5) Symptôme : la file mail grossit, et la latence de livraison pour le transactionnel devient minutes/heures

• Cause racine : File partagée entre bulk et transactionnel ; throttling fournisseur provoquant un backlog global ; réessais trop agressifs saturant les connexions.
• Correctif : Séparer les flux (MTAs ou transports distincts), imposer des limites par destination, prioriser les files transactionnelles, et mettre en pause temporairement le bulk.

6) Symptôme : Tout « passe » mais un destinataire entreprise spécifique ne reçoit jamais les mails

• Cause racine : Quarantaine côté destinataire, filtrage personnalisé, ou votre domaine/URL est bloqué en interne ; parfois leur passerelle rejette silencieusement.
• Correctif : Obtenir du mail admin destinataire les logs pour l’ID message et l’horodatage. Fournir vos logs SMTP. Si nécessaire, changer les URL (domaines de tracking) et assurer des identifiants cohérents.

7) Symptôme : DKIM échoue parfois, pas toujours

• Cause racine : Modifications multi-sauts ; clés de signature mélangées entre serveurs ; système de template injectant des espaces dynamiques/retours à la ligne après la signature ; plusieurs signatures DKIM dont une casse tout.
• Correctif : Signer au dernier saut, standardiser la config de signature, garder la canonicalisation relaxed/relaxed, et tester avec des captures d’en-têtes complètes chez plusieurs fournisseurs.

8) Symptôme : la deliverabilité est correcte jusqu’à une campagne puis tout empire

• Cause racine : Identité partagée entre marketing et transactionnel ; les pics de volume entraînent les filtres à se méfier de votre flux global.
• Correctif : Scinder domaines/sous-domaines, sélecteurs DKIM séparés, et utiliser des IP distinctes si possible. Au minimum, séparez les domaines d’enveloppe et les patterns de trafic.

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

Phase 0 (aujourd’hui) : Stabiliser et arrêter l’hémorragie

1. Geler le bulk. Suspendre les envois marketing non essentiels opérationnellement.
2. Protéger le transactionnel. Si vous ne pouvez pas séparer immédiatement, au moins priorisez le mail transactionnel dans la file et réduisez le volume bulk à presque zéro.
3. Activer une suppression stricte. Rebonds durs supprimés immédiatement ; rebonds doux répétés supprimés après un seuil raisonnable.
4. Réduire la concurrence et ajouter un délai de débit. Comportez-vous poliment ; acceptez la contre-pression.
5. Choisir un échantillon de contrôle. Un petit groupe engagé plus une liste seed que vous possédez à travers les fournisseurs majeurs.

Phase 1 (24–72 heures) : Diagnostiquer avec des preuves, pas des impressions

1. Classer le mode de défaillance. Rebond vs accepté-mais-spam vs accepté-et-manquant.
2. Récupérer de vrais en-têtes. Confirmer les résultats SPF/DKIM/DMARC tels que vus par le fournisseur destinataire.
3. Vérifier les bases d’identité. PTR, HELO, validité du certificat TLS, IP d’envoi stables.
4. Quantifier les rebonds. Principaux codes SMTP et leur distribution par fournisseur/domaine.
5. Trouver le point d’inflexion. Qu’est-ce qui a changé au moment où la réputation a chuté ? DNS, fournisseur, pipeline de templates, acquisition de liste, paramètres de concurrence.

Phase 2 (1–3 semaines) : Réparer la confiance avec un warm-up contrôlé

1. Segmenter par engagement. Commencer par les personnes ayant interagi récemment. Si vous ne suivez pas l’engagement, commencez à le collecter maintenant et acceptez que la récupération prendra plus de temps.
2. Warm-up progressivement. Augmenter le volume lentement, garder une cadence régulière, et surveiller les différés/plaintes comme on surveille un CPU de base de données.
3. Garder le contenu stable. Ne faites pas d’A/B tests pendant un incident de réputation.
4. Stabiliser les URL. Éviter de faire tourner des raccourcisseurs ou domaines de tracking pendant la récupération. Les chaînes de redirection suspectes ne sont pas vos amies.
5. Séparer définitivement les flux. Transactionnel vs marketing, et idéalement notifications produit comme troisième flux.

Phase 3 (en continu) : Prévenir la prochaine chute

1. SLOs de deliverabilité. Suivre le taux de rebond, le taux de différé, des proxys de plainte, et des indicateurs de placement inbox par fournisseur.
2. Gestion des changements. Les modifications DNS et du pipeline mail nécessitent des tests et un rollback, comme toute config de production.
3. Gouvernance des listes. Définir les sources d’adresses autorisées. Pas de « liste partenaire » sans gates de qualité et règles de suppression.
4. Drills d’incident. Pratiquer le playbook de diagnostic rapide trimestriellement. Votre futur vous remerciera.

FAQ

1) Combien de temps pour récupérer la réputation d’expéditeur ?

De quelques jours à quelques semaines, selon la gravité et si vous corrigez le comportement sous-jacent. Les fixes d’authentification peuvent aider immédiatement, mais les améliorations d’engagement/hygiène de liste mettent du temps à produire des effets.

2) Devons-nous changer d’ESP pour régler la deliverabilité ?

Seulement si votre fournisseur actuel ne vous donne pas le contrôle ou la visibilité (ou si vous êtes coincé sur un pool partagé empoisonné). Changer sans corriger l’hygiène de liste et l’authentification déplace juste le problème et ajoute un risque de migration.

3) Une IP dédiée résout-elle les problèmes de réputation ?

Elle supprime le risque de voisinage, pas votre propre risque. Si votre liste est mauvaise, une IP dédiée vous donne un lieu privé pour brûler de la réputation. Vous aurez toujours besoin de warm-up et d’hygiène.

4) Faut-il mettre DMARC à p=reject pour prouver la légitimité ?

Pas pendant un bazar de configuration. N’appliquez DMARC que lorsque vous savez que vos expéditeurs légitimes passent l’alignement. Sinon vous rejetterez vos propres mails en appelant ça « sécurité ».

5) Pourquoi voit-on des tempfails 421 plutôt que des rebonds durs ?

Les fournisseurs limitent souvent plutôt que de bloquer immédiatement, surtout s’ils pensent que vous pouvez être légitime mais risqué pour le moment. Traitez ça comme de la contre-pression et réduisez le débit ; ne marteléz pas plus fort.

6) Quelle est la cause la plus commune d’un « ça s’est soudainement aggravé » ?

Des changements non suivis : mises à jour DNS, changements de routage ESP, ou passerelles qui commencent à réécrire des messages et cassent DKIM. Ensuite viennent les acquisitions/imports de liste qui font monter les utilisateurs inconnus et les plaintes.

7) Le tracking de liens peut-il nuire à la deliverabilité ?

Oui. Les domaines de tracking partagés peuvent hériter de problèmes de réputation, les chaînes de redirection paraissent phishantes, et des domaines non alignés réduisent la confiance. Gardez les domaines de tracking stables et alignés avec votre marque, et évitez les raccourcisseurs douteux.

8) Pourquoi le mail transactionnel souffre-t-il quand le marketing lance une campagne ?

Parce que vous les avez liés : même From, même IP, même identité DKIM, mêmes files. Séparez les flux pour qu’une équipe ne puisse pas accidentellement DDoS votre relation de confiance avec les fournisseurs.

9) Nos e-mails sont « acceptés ». Pourquoi les utilisateurs ne les voient-ils pas ?

L’acceptation n’est pas le placement en boîte de réception. Le mail peut être accepté puis filtré en spam, mis en quarantaine par un outil d’entreprise, ou routé dans un autre dossier par des règles utilisateur. Vous avez besoin d’une preuve d’en-têtes et des logs côté destinataire pour différencier.

10) Sur quels metrics alerter ?

Taille de file, taux de différé par fournisseur, taux de rebond dur, taux d’inconnus, et taux d’échecs d’authentification (les rapports agrégés DMARC aident). Alertez sur des changements de tendance, pas seulement des seuils absolus.

Prochaines étapes à exécuter cette semaine

1. Geler les envois bulk pendant 48 heures pendant que vous collectez des preuves : codes SMTP par fournisseur, comportement de la file, et vrais en-têtes depuis les destinataires.
2. Confirmer la correction d’identité : PTR/FCrDNS, HELO, TLS, IPs de sortie stables. Corrigez d’abord les signaux faciles.
3. Faire passer DMARC avec alignement pour votre domaine From principal. Validez avec des en-têtes capturés depuis des destinataires Gmail et Microsoft.
4. Implémenter la suppression dure immédiatement et mettre en quarantaine les segments douteux. Les rebonds inconnus sont une taxe réputationnelle que vous payez avec intérêts.
5. Séparer les flux transactionnel et marketing (sous-domaines et sélecteurs DKIM au minimum). Traitez cela comme un contrôle du blast radius.
6. Warm-up délibérément : volume quotidien constant, destinataires engagés d’abord, rampes lentes, et surveillance attentive des différés et plaintes.

Si vous ne faites qu’une chose : arrêtez les pics de volume et cessez d’envoyer à des personnes qui ne l’ont pas demandé. L’authentification vous ouvre la porte ; le comportement décide si vous pouvez rester.