IP/Domaine d’e-mail sur liste noire : comment vérifier et se faire retirer correctement

Guide de diagnostic rapide

Si vous avez 20 minutes avant que le VP demande pourquoi les factures n’arrivent pas, ne commencez pas par « demander le retrait ». Commencez par trouver le goulot d’étranglement : est-ce une véritable mise en liste RBL, un blocage de réputation par un fournisseur, ou votre propre infrastructure qui fond ?

Première étape : confirmer l’étendue et les symptômes (10 minutes)

• Quel flux échoue ? Transactionnel, marketing, réinitialisations de mot de passe, tout ?
• Où ça échoue ? Au moment SMTP (rejets), après acceptation (dossier spam), ou sans jamais quitter votre système (file d’attente) ?
• Qu’est‑ce qui a changé ? Nouvelle IP, nouveau fournisseur, nouveau contenu, nouvelle liste, nouvelle authentification, nouveau taux d’envoi.

Deuxième étape : lire un vrai bounce bout à bout (5 minutes)

Choisissez une seule erreur et extrayez la réponse exacte du serveur distant et le code de statut étendu (comme 5.7.1). Le bounce est votre trace de pile. Deviner, c’est comment on finit par « corriger le SPF » pour une boîte compromise.

Troisième étape : décider si c’est un problème d’IP, de domaine ou de compte (5 minutes)

• Problème d’IP : Une IP sortante est rejetée ; d’autres IP fonctionnent ; les recherches RBL donnent un résultat ; la réponse SMTP mentionne « listed », « RBL » ou « policy ».
• Problème de domaine : Plusieurs IP échouent pour le même domaine ; l’alignement DMARC échoue ; avertissements de « réputation de domaine » ; les liens/domaines dans le contenu déclenchent des filtres.
• Problème de compte : Une seule boîte/utilisateur/service envoie un volume inhabituel ; les logs montrent des pics ; des destinataires signalent du spam ; vous voyez beaucoup d’échecs d’authentification.

Règle : ne demandez pas à être retiré tant que vous ne pouvez pas expliquer, en un paragraphe, ce qui a causé la mise en liste et ce que vous avez changé pour empêcher que ça se reproduise. Les équipes de retrait ne sont pas là pour faire votre analyse d’incident.

Ce que « listé » signifie réellement (et ce que ça ne signifie pas)

Les gens disent « nous sommes sur une blacklist » comme s’il existait un seul presse‑papier global dans le ciel. Ce n’est pas le cas. Il existe :

• Listes publiques basées sur DNS (RBL/DNSBL) qui publient des entrées IP/domaine que vous pouvez interroger via DNS.
• Systèmes de réputation privés des fournisseurs (Gmail, Microsoft, Yahoo, passerelles d’entreprise) qui n’ont pas besoin de vous lister publiquement pour vous limiter ou vous mettre en indésirables.
• Flux de réputation commerciaux intégrés dans des appliances et produits de sécurité e‑mail, parfois avec des scores opaques.
• Blocages de politique locaux chez un destinataire (« nous bloquons tous les nouveaux expéditeurs », « nous bloquons votre ASN », « nous n’acceptons que les fournisseurs allowlistés »).

Également : être listé n’est pas toujours de votre faute. Des IP partagées vous punissent pour vos voisins. Des passerelles NAT font paraître plusieurs locataires comme un seul expéditeur. Et parfois un fournisseur bloque un bloc entier parce que c’est un marécage d’abus et vous êtes la grenouille innocente.

Mais : si vous gérez votre propre SMTP sortant et que vous êtes listé, supposez que c’est votre faute tant que le contraire n’est pas prouvé. Cet état d’esprit raccourcit les incidents.

Blague n°1 : La réputation e‑mail ressemble à un score de crédit, sauf qu’elle peut chuter de 200 points parce que quelqu’un a cliqué « spam » en étant en colère et caféiné.

Faits intéressants et brève histoire

• Les listes basées sur DNS ont décollé à la fin des années 1990, parce que DNS était rapide, distribué et déjà omniprésent — parfait pour des requêtes « cette IP est‑elle malveillante ? ».
• Les premières listes étaient communautaires et souvent controversées car des décisions de politique (« open relay », « plages dial‑up ») se mêlaient à des signaux d’abus.
• L' »open relay » était autrefois la première raison pour laquelle les serveurs mail se faisaient lister ; aujourd’hui ce sont plus souvent des comptes compromis, du trafic de botnets ou une mauvaise hygiène de listes.
• Le contenu n’est pas le seul filtre : les systèmes modernes pèsent fortement les signaux d’engagement (ouvertures, réponses, suppressions sans lecture) et les taux de plaintes.
• Beaucoup de destinataires préfèrent des échecs temporaires (4xx) aux blocages définitifs (5xx) pour ralentir le spam sans donner un retour net aux attaquants.
• DMARC (2012) a changé la donne en permettant aux domaines de publier comment les destinataires doivent traiter les mails non authentifiés, ce qui a aussi amélioré la visibilité forensique.
• Certains blocages « type liste noire » sont purement basés sur le débit : envoyer trop vite depuis une nouvelle IP vous fait ressembler à un botnet, même si chaque e‑mail est légitime.
• Les spam traps existent et sont variés : les traps vierges ne se sont jamais abonnés ; les traps recyclés étaient autrefois de vrais utilisateurs — les atteindre crie « mauvaise acquisition ».
• IPv6 a rendu la réputation plus difficile car l’espace d’adresses est énorme ; les destinataires s’appuient davantage sur le domaine/l’authentification que sur l’historique d’une IP individuelle.

Vérifier la mise en liste : IP, domaine et blocages « non-listes noires »

Vous devez répondre à trois questions :

1. Quel identifiant exact est bloqué ? IP, nom d’hôte, nom HELO, expéditeur d’enveloppe, domaine From:, domaine DKIM d=, domaine URL, ou un mélange.
2. Qui bloque ? Une RBL, un fournisseur, une passerelle d’entreprise, ou votre propre upstream (smart host) refusant de relayer.
3. Est‑ce un rejet ferme, une temporisation, ou une mise silencieuse en indésirables ? Chacun nécessite une approche différente.

IP vs domaine : pourquoi la distinction compte

La réputation d’IP concerne la machine depuis laquelle vous envoyez. Elle est impactée par les patterns de volume, les hits sur spamtraps, et les taux de plainte liés à cette IP. Faire pivoter l’IP peut vous faire échapper à la douleur immédiate — au prix de ressembler à un spammeur qui fait tourner ses IP. Ce n’est pas un exploit flatteur.

La réputation de domaine concerne l’identité que vous revendiquez. Si votre domaine est toxique — à cause de phishing ressemblant, d’une mauvaise authentification ou d’années de spam — changer d’IP ne vous sauvera pas. Les destinataires ne sont pas des poissons rouges.

Vérifiez aussi votre reverse DNS et votre HELO

Nous sommes en 2026 et certains systèmes vous pénalisent encore pour la même raison qu’en 2006 : absence d’enregistrement PTR, HELO non correspondant, ou un nom d’hôte qui ressemble à une plage résidentielle dynamique. Ce n’est pas « juste », ce sont simplement les règles de la route.

Lire les rebonds comme un SRE

Les incidents de délivrabilité sont des incidents de littératie des logs. Un rebond n’est pas « l’e‑mail a échoué ». C’est une erreur structurée venant d’un système distant, souvent avec :

• Un code de réponse SMTP (550, 421, etc.)
• Un code de statut étendu (5.7.1, 4.7.0)
• Une chaîne lisible par un humain (« blocked using… », « policy reasons », « rate limit », « authentication required »)

Les échecs fermes (5xx) signifient « ne pas réessayer ; corrigez quelque chose. » Les échecs temporaires (4xx) signifient « essayez plus tard » mais en pratique peuvent vouloir dire « nous ne sommes pas sûrs que vous êtes légitime ; ralentissez et nettoyez. » Si vous réessayez agressivement, vous pouvez transformer un problème temporaire en crater permanent de réputation.

Pensez-y ainsi : le destinataire fait de la gestion d’incident sur vous. Il limite le voisin bruyant.

Causes profondes : suspects habituels et ceux qui se cachent

1) Boîte compromise ou clé API compromise

C’est le classique. Un utilisateur se fait hameçonner, un attaquant envoie une rafale de spam via votre infrastructure légitime, et votre IP/domaine est mis en cause. Recherchez :

• Pics de volume soudains
• Nouveaux pays/ASNs dans les logs d’authentification
• Sujets, URL ou pièces jointes inhabituels
• Explosion des plaintes et des rebonds en quelques minutes

2) Mauvaise hygiène de listes (adresses recyclées, listes achetées)

Si vous avez acheté une liste, vous n’avez pas acheté des prospects — vous avez acheté l’historique d’abus de quelqu’un d’autre. Les spam traps ne se préoccupent pas de votre intention. Ils se préoccupent du fait que vous leur avez envoyé du mail.

3) Désalignement d’authentification (SPF/DKIM/DMARC)

Vous pouvez avoir SPF et DKIM « passant » et malgré tout échouer DMARC parce que le domaine authentifié ne s’aligne pas avec le domaine visible From:. Les destinataires traitent de plus en plus le désalignement comme « ça sent l’usurpation ».

4) Erreurs d’infrastructure : rDNS, HELO, TLS et chaos opportuniste

Un PTR manquant ou un HELO générique peut déclencher des filtres politiques. L’absence de TLS n’est pas toujours fatale, mais c’est un signal parmi d’autres. Certains destinataires pénalisent les comportements SMTP bizarres : pipelining étrange, en‑têtes malformés, mauvais Message‑IDs.

5) Pics de débit/volume (légitimes mais suspects)

Envoyer 10× votre volume journalier habituel après des mois de silence n’est pas « un grand lancement ». C’est un pattern de botnet. Chauffez les nouvelles IP/domaines. Montez en charge progressivement. Mesurez les plaintes comme s’il s’agissait de SLOs de latence.

6) Contamination d’IP partagée

Si vous êtes sur une IP sortante partagée (commun avec certains niveaux d’ESP), un autre locataire peut vous faire throttler. La solution est souvent ennuyeuse : passer à une IP dédiée ou à un pool meilleur avec application stricte des règles.

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

Voici les tâches que j’exécute lors d’un incident de réputation e‑mail. Chaque item inclut : commande, sortie d’exemple et la décision qu’elle informe. Adaptez les chemins et noms de services à votre environnement (Postfix/Exim/Exchange/PowerMTA/etc.).

Tâche 1 : Identifier l’IP publique d’egress réellement utilisée pour le SMTP sortant

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 203.0.113.1 dev eth0 src 198.51.100.23 uid 0
    cache

Ce que ça signifie : Votre IP source probable est 198.51.100.23. Si vous êtes derrière un NAT, confirmez avec votre équipe firewall ; n’assumez pas.

Décision : Utilisez cette IP pour les vérifications RBL et la validation rDNS.

Tâche 2 : Confirmer que vos MX ne sont pas mal pointés (vérification de cohérence au niveau domaine)

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

Ce que ça signifie : Le routage du mail entrant semble normal. Cela ne résout pas les problèmes sortants, mais évite de courir après des fantômes causés par une zone DNS cassée.

Décision : Si les MX sont faux, corrigez le DNS d’abord ; les zones mal gérées cassent souvent aussi SPF/DKIM/DMARC.

Tâche 3 : Valider l’existence d’un enregistrement SPF et sa syntaxe

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

Ce que ça signifie : SPF autorise votre IP et un fournisseur. Le -all est strict (bien) si correct (dangereux) s’il est incomplet.

Décision : Si vos IP actuelles d’envoi ne sont pas couvertes, corrigez SPF avant le retrait ; sinon les destinataires continueront de rejeter.

Tâche 4 : Vérifier la politique DMARC et les attentes d’alignement

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"

Ce que ça signifie : Un alignement strict est exigé pour SPF et DKIM. Parfait contre l’usurpation, impitoyable pour des configurations de fournisseurs négligentes.

Décision : Si des fournisseurs envoient avec des domaines non alignés, corrigez leur configuration ou relaxez temporairement l’alignement — puis renforcez à nouveau.

Tâche 5 : Vérifier que DKIM est publié (sélecteur présent)

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

Ce que ça signifie : La clé publique DKIM est présente. C’est nécessaire mais pas suffisant ; le signing doit effectivement avoir lieu.

Décision : Si absent, publiez DKIM avant de demander à qui que ce soit de vous faire confiance à nouveau.

Tâche 6 : Confirmer le reverse DNS (PTR) pour l’IP sortante

cr0x@server:~$ dig +short -x 198.51.100.23
mailout1.example.com.

Ce que ça signifie : Le PTR existe et ressemble à un hôte mail, pas à un nom de pool aléatoire.

Décision : Si le PTR est absent ou générique, corrigez‑le avec votre ISP/fournisseur cloud. Beaucoup de destinataires se méfient des IP sans PTR raisonnable.

Tâche 7 : Vérifier que le DNS direct correspond au PTR (hygiène basique)

cr0x@server:~$ dig +short A mailout1.example.com
198.51.100.23

Ce que ça signifie : Le reverse DNS est confirmé en forward. Certains filtres traitent les mismatches comme un faible signal négatif.

Décision : Si ce n’est pas aligné, corrigez l’A ou le PTR ; ne laissez pas ça « à peu près ».

Tâche 8 : Tester la bannière SMTP, le nom HELO et TLS depuis l’extérieur

cr0x@server:~$ openssl s_client -starttls smtp -connect mailout1.example.com:25 -servername mailout1.example.com -crlf
CONNECTED(00000003)
220 mailout1.example.com ESMTP Postfix
...
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP

Ce que ça signifie : La bannière SMTP est sensée ; STARTTLS est proposé. Si vous voyez des erreurs de certificat, certains destinataires vous déclasseront.

Décision : Si TLS est cassé, corrigez la chaîne de certificats/nom d’hôte ; c’est un gain rapide et améliore les signaux de confiance.

Tâche 9 : Rechercher les pics de volume sortant et les principaux expéditeurs (exemple Postfix)

cr0x@server:~$ sudo pflogsumm -d yesterday /var/log/mail.log | sed -n '1,80p'
Postfix log summaries for yesterday

Grand Totals
------------
messages delivered: 12480
messages rejected: 3120
bytes delivered: 912m
hosts/domains: 438

Per-Sender message counts
-------------------------
  8200  alerts@example.com
  2100  marketing@example.com
   960  noreply@example.com

Ce que ça signifie : Un expéditeur (alerts@example.com) domine le volume. Cela peut être une vraie tempête d’alertes ou un compte compromis.

Décision : Enquêter sur les expéditeurs principaux et corréler avec des déploiements/incidents. Si compromis, désactivez les identifiants et purgez la file.

Tâche 10 : Inspecter la file d’envoi pour des patterns bloqués/rebondis

cr0x@server:~$ mailq | head -n 30
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5*    4210 Fri Jan  3 09:12:11  noreply@example.com
                                         user1@bigmail.example
                                         (host mx.bigmail.example[203.0.113.55] said: 421 4.7.0 Temporary rate limit)
F6G7H8I9J0     3988 Fri Jan  3 09:12:14  marketing@example.com
                                         user2@bigmail.example
                                         (host mx.bigmail.example[203.0.113.55] said: 550 5.7.1 IP listed in RBL)

Ce que ça signifie : Vous avez à la fois des limites temporaires de débit et des blocs fermes. C’est courant quand la réputation décline ; les fournisseurs commencent par des 4xx puis passent aux 5xx.

Décision : Ralentissez immédiatement l’envoi et priorisez la correction de la liste/auth. Pour les 4xx, appliquez du backoff ; pour les 5xx, arrêtez et remédiez.

Tâche 11 : Extraire la réponse SMTP distante exacte des logs (un message)

cr0x@server:~$ sudo grep -F "A1B2C3D4E5" /var/log/mail.log | tail -n 5
Jan  3 09:12:12 mailout1 postfix/smtp[22190]: A1B2C3D4E5: to=<user1@bigmail.example>, relay=mx.bigmail.example[203.0.113.55]:25, delay=1.2, delays=0.1/0/0.5/0.6, dsn=4.7.0, status=deferred (host mx.bigmail.example[203.0.113.55] said: 421 4.7.0 Temporary rate limit)

Ce que ça signifie : Le code étendu 4.7.0 et « Temporary rate limit » vous indiquent qu’il s’agit d’un throttling, pas d’une RBL. Ne déposez pas de demande de retrait pour ça.

Décision : Implémentez rate limiting/backoff et corrigez les signaux de réputation ; traitez cela comme une politique fournisseur, pas comme « une blacklist ».

Tâche 12 : Vérifier les comptes locaux compromis envoyant du mail (logs d’auth + submission)

cr0x@server:~$ sudo zgrep -h "sasl_username=" /var/log/mail.log* | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
12034 sales@example.com
  220 ops@example.com
   74 hr@example.com

Ce que ça signifie : Un utilisateur SASL est responsable de la plupart des soumissions authentifiées. Si ce n’est pas attendu, il est probablement compromis ou utilisé par une application.

Décision : Désactivez/réinitialisez ce compte, faites tourner mots de passe/clés API, ajoutez MFA, et examinez le contenu sortant. Puis purgez le spam en file.

Tâche 13 : Vérifier si votre IP est sur une DNSBL que vous pouvez interroger (exemple Spamhaus ZEN)

cr0x@server:~$ ip=198.51.100.23; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); dig +short ${rev}.zen.spamhaus.org
127.0.0.2

Ce que ça signifie : Une réponse de type loopback indique « listé » (la valeur précise donne un indice de catégorie). Pas de réponse signifie généralement « non listé ».

Décision : Si listé, stoppez les campagnes sortantes, remédiez à la cause, puis suivez la procédure de retrait de cette liste. Ne changez pas l’IP pour faire comme si rien ne s’était passé.

Tâche 14 : Vérifier que le nom HELO correspond à quelque chose de réel (et pas localhost)

cr0x@server:~$ postconf -n | grep -E '^myhostname|^smtp_helo_name'
myhostname = mailout1.example.com
smtp_helo_name = mailout1.example.com

Ce que ça signifie : Votre identité HELO est cohérente. Si le HELO est localhost ou une chaîne aléatoire, certains destinataires vous méfieront.

Décision : Corrigez HELO/myhostname vers un FQDN stable avec un DNS correspondant.

Tâche 15 : Vérifier les contrôles de débit sortant (éviter de transformer des 4xx en 5xx)

cr0x@server:~$ postconf -n | grep -E '^default_destination_rate_delay|^smtp_destination_concurrency_limit|^smtp_destination_rate_delay'
default_destination_rate_delay = 0s
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s

Ce que ça signifie : Vous ne cadencez pas les livraisons. Si un fournisseur vous limite, une concurrence à 20 peut être trop élevée.

Décision : Ajoutez des délais conservateurs et réduisez la concurrence par destination tant que la réputation se rétablit.

Tâche 16 : Détecter une croissance soudaine de la file (symptôme système)

cr0x@server:~$ postqueue -p | tail -n 1
-- 1247 Kbytes in 318 Requests.

Ce que ça signifie : 318 messages en file peut être normal ou alarmant selon la base. L’important est la tendance.

Décision : Si la file croît et que les erreurs distantes sont 4xx/5xx, suspendez les flux non essentiels et concentrez‑vous sur la remédiation. Ne « continuez pas simplement d’envoyer ».

Se faire retirer correctement (sans empirer)

Le retrait n’est pas du support client. C’est une porte de sécurité. Votre travail est de présenter une histoire crédible : « Voici ce qui s’est passé, voici ce que nous avons changé, et voici comment nous allons prévenir la récidive. » Si vous ne pouvez pas faire cela, vous demandez à un système de sécurité de se désactiver.

Étape 1 : Contenir l’incident

• Arrêter l’hémorragie : mettez en pause les flux marketing/bulk ; ne gardez que les mails transactionnels critiques si vous pouvez les segmenter proprement.
• Verrouiller les expéditeurs compromis : désactivez des comptes, faites tourner les identifiants, révoquez les tokens, imposez le MFA.
• Purger les entrées malveillantes de la file : ne continuez pas de retenter le spam ; cela prolonge le dommage et agace les destinataires.
• Conserver les preuves : logs, exemples de spam, horodatages des pics. Vous en aurez besoin pour les demandes de retrait et les postmortems internes.

Étape 2 : Corriger la cause racine avant de demander le pardon

Les « vraies corrections » que les équipes de retrait respectent :

• Corriger rDNS et HELO
• Corriger l’alignement SPF/DKIM/DMARC
• Mettre en place du rate limiting et du backoff
• Supprimer les sources de listes qui génèrent des traps/plaintes
• Sécuriser les boîtes compromises et les applications
• Segmenter le trafic : transactionnel vs marketing sur sous‑domaines/IP séparés

Étape 3 : Demander le retrait avec un récit d’incident serré

Quand vous soumettez une demande de retrait, incluez :

• Les IP(s) et domaines bloqués (exacts)
• Ce qui l’a déclenché (compromis, mauvaise config, hygiène de liste, IP partagée)
• Ce que vous avez changé (contrôles précis, dates, configuration)
• Signaux de preuve d’amélioration (volume réduit, authentification désormais passée, file nettoyée)
• Un e‑mail de contact qui atteint réellement un humain

Et ne mentez pas. Les opérateurs de listes noires ont des logs, des traps et de la télémétrie. Si vous prétendez « nous n’envoyons jamais de spam » alors que votre IP martèle 10k destinataires/minute, vous ne négociez pas — vous auditionnez pour un refus permanent.

Blague n°2 : Déposer une demande de retrait sans réparer le compromis, c’est comme repeindre votre voiture alors qu’elle est encore en feu.

Étape 4 : Préparez‑vous à un « non » ou à un « attendre »

Certaines listes expirent automatiquement les entrées après une période propre ; d’autres exigent une revue manuelle ; certaines ne délisteront jamais des plages résidentielles/dynamiques. « Non » n’est pas personnel. C’est une limite de politique. Si votre activité dépend de l’e‑mail, vous avez besoin d’une architecture d’envoi qui respecte ces limites.

Récupération de la réputation après retrait

Être retiré ne signifie pas être de nouveau digne de confiance. Cela signifie « pas activement signalé par cette liste ». Vous devez maintenant reconstruire la réputation, surtout auprès des gros fournisseurs de boîtes mail.

Chauffez les envois comme il faut

• Commencez par vos destinataires les plus engagés (ouvertures/réponses récentes, clients actifs).
• Augmentez le volume progressivement sur jours/semaines, pas sur des heures.
• Maintenez des taux de plainte bas en resserrant les critères de liste et en ajoutant une désinscription claire.
• Surveillez les temporisations (4xx) comme signaux d’alerte précoce ; elles précèdent souvent une nouvelle mise en liste.

Séparez les responsabilités : transactionnel vs marketing

Le mail transactionnel (réinitialisations, reçus) ne doit pas partager le sort des campagnes marketing. Utilisez des :

• Sous‑domaines (ex. mail.example.com vs news.example.com)
• Sélecteurs/cles DKIM distincts
• IP d’envoi distinctes (idéalement dédiées pour le transactionnel critique)

Surveillez comme un opérateur, pas comme un marketeur

Suivez :

• Les codes de réponse SMTP dans le temps (taux de rate limits vs blocs)
• La profondeur de la file et les taux de retry
• Les taux de passage/alignement d’authentification
• Les signaux de plainte (là où disponibles)
• La placement en dossier spam (les tests seed sont imparfaits, mais la tendance aide)

Une citation que je fais confiance en opérations est l’idée paraphrasée de W. Edwards Deming : on ne peut pas améliorer ce que l’on ne mesure pas (idée paraphrasée).

Trois mini‑histoires d’entreprise venant du terrain

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

Une société SaaS de taille moyenne gérait son propre Postfix pour le mail transactionnel et utilisait un ESP séparé pour le marketing. Un matin, les e‑mails de réinitialisation de mot de passe commencèrent à rebondir chez un grand fournisseur avec un rejet de type 550 5.7.1 mentionnant « policy ». L’équipe supposa, avec assurance, que « l’ESP nous avait mis sur liste ».

Cette hypothèse guida les six premières heures de travail : réunions avec l’équipe marketing, vérifications frénétiques du contenu des campagnes, et une demande à l’ESP de « réparer leur réputation IP ». Pendant ce temps, le système transactionnel continuait de réessayer, accumulant une file, et le support recevait des tickets en colère comme s’ils collectionnaient des Pokémon.

Quand quelqu’un tira enfin un seul bounce des logs transactionnels, le rejet faisait référence à la propre IP sortante de l’entreprise — pas au pool de l’ESP. Un rapide regard sur les logs de soumission montra un service interne envoyant des milliers d’e‑mails « facture prête » à des adresses qui n’existaient plus depuis des années. Une migration récente avait rejoué une ancienne file de jobs, ressuscitant une liste morte.

Ils corrigèrent le bug du job, purgèrent la file et ralentirent l’envoi. La mise en liste se dissipa d’elle‑même après une période propre, mais la leçon resta : ne devinez jamais quel système échoue. Confirmez d’abord le chemin d’envoi, puis diagnosez. On ne peut pas argumenter contre des logs. On peut seulement mal les lire.

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

Une équipe fintech voulait des livraisons plus rapides pour des alertes sensibles au temps. Ils réglèrent la concurrence Postfix et retirèrent les délais de rate parce que « la latence compte ». Ça marcha. Les messages arrivèrent plus vite — jusqu’à ce qu’une nouvelle intégration d’alerting commence à envoyer des rafales pendant des périodes de forte volatilité du marché.

Pour les fournisseurs récepteurs, le pattern ressemblait à un expéditeur compromis : pics soudains, contenu répété, forte concurrence. Le premier signe n’était pas une liste noire. C’étaient des temporisations : 421 4.7.0 rate limits. L’équipe interpréta cela comme de la « flakiness fournisseur » et augmenta encore la concurrence pour « pousser ».

C’est ainsi que l’on transforme un feu jaune en collision. Le fournisseur passa du throttling aux rejets fermes. Puis des listes secondaires commencèrent à marquer l’IP parce que les retries ressemblaient à une campagne spam persistante. L’optimisation — retirer le backoff — amplifia le mode de défaillance.

La correction fut ironiquement un pas en arrière : réintroduire un pacing par destination, plafonner la concurrence et implémenter une suppression d’alertes pour que le même destinataire ne soit pas bombardé. La livraison devint un peu plus lente aux moments de pointe mais beaucoup plus fiable globalement. L’entreprise apprit une vérité SRE : le débit sans boucles de contrôle n’est qu’une défaillance plus rapide.

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

Un fournisseur de santé avait une politique qui semblait ennuyeuse en revue de conception : mails transactionnels uniquement depuis un sous‑domaine et une IP dédiés, avec DMARC strict et identifiants séparés par application. C’était pénible. Les gens se plaignaient de « trop d’enregistrements DNS » et de « configurations fournisseurs supplémentaires ».

Puis la boîte d’un contractant fut compromise, et l’attaquant utilisa la plateforme corporate pour envoyer du phishing à des destinataires externes. Le domaine corporate prit un coup de réputation et certains mails utilisateurs commencèrent à atterrir dans les indésirables.

Mais les notifications patients critiques continuaient de passer parce qu’elles provenaient du domaine et de l’IP transactionnels isolés, avec une authentification propre et un volume contrôlé. Les destinataires les traitèrent comme une identité séparée avec une histoire séparée. L’impact support fut contenu. L’impact conformité fut contenu. L’impact leadership fut contenu — toujours le plus difficile.

Ils eurent quand même un incident et effectuèrent le nettoyage, mais la séparation des responsabilités empêcha une panne de délivrabilité de devenir une panne opérationnelle. La pratique ennuyeuse n’était pas glamour. Elle était efficace. C’est le boulot.

Erreurs courantes : symptôme → cause racine → correction

1) « Nous sommes listés partout »

Symptôme : Certains destinataires rebondissent, d’autres non ; l’équipe interne dit « tout est bloqué ».

Cause racine : Mélange de défaillances différentes : un fournisseur limite (4xx), un autre utilise une RBL spécifique (5xx), et certains mettent silencieusement en indésirables à cause de la réputation du domaine.

Correction : Catégorisez les échecs par destination et code. Construisez un tableau : fournisseur → chaîne d’erreur → IP/domaine impliqué → action (throttle/corriger auth/delist).

2) « SPF passe, donc l’authentification est OK »

Symptôme : Les destinataires marquent quand même le mail comme spam ou rejettent avec des erreurs de politique.

Cause racine : L’alignement DMARC échoue ; SPF passe pour un domaine différent (ex. domaine bounce du fournisseur), ou DKIM signe avec un d= non aligné.

Correction : Assurez‑vous que le domaine visible From: s’aligne avec SPF MAIL FROM ou DKIM d=. Faites respecter une identité cohérente sur les systèmes.

3) « Prenons juste une nouvelle IP »

Symptôme : L’équipe propose la rotation d’IP comme solution rapide.

Cause racine : Traiter un incident de réputation comme un problème DHCP. Les fournisseurs voient les changements d’IP soudains comme un comportement d’évasion, surtout si le domaine reste le même.

Correction : Changez d’IP uniquement dans le cadre d’une migration contrôlée avec warmup, et seulement après avoir arrêté l’abus et corrigé l’auth/hygiène.

4) « Nous avons demandé le retrait mais rien n’a changé »

Symptôme : Retiré d’une RBL ; la délivrabilité reste mauvaise.

Cause racine : Le vrai blocage est la réputation fournisseur, pas la RBL. Ou vous êtes listé sur plusieurs flux, ou la réputation du domaine est endommagée.

Correction : Vérifiez quelle entité vous rejette. Réduisez les plaintes, corrigez l’alignement, ralentissez et reconstruit l’engagement. Le retrait RBL est parfois nécessaire, rarement suffisant.

5) « Nous continuons de réessayer ; ça finira par passer »

Symptôme : La file grossit, tempêtes de retry, plus de blocs apparaissent.

Cause racine : Les retries agressifs contre des temporisations 4xx ressemblent à un comportement abusif et peuvent escalader les pénalités de réputation.

Correction : Implémentez un backoff exponentiel, réduisez la concurrence et mettez en pause les mails non critiques jusqu’à la stabilisation des temporisations.

6) « Un seul fournisseur nous bloque, donc c’est leur bug »

Symptôme : Gmail (ou Microsoft, ou Yahoo) rejette ; des domaines plus petits acceptent.

Cause racine : Les grands fournisseurs ont des modèles de réputation plus stricts et plus de télémétrie ; les domaines plus petits peuvent être moins filtrés (ou moins protégés).

Correction : Traitez les blocages des grands fournisseurs comme votre système d’alerte précoce. Corrigez vos signaux ; ne cherchez pas des destinataires plus laxistes.

7) « Nous avons nettoyé, mais nous avons été re‑listés »

Symptôme : Rétablissement bref suivi d’une nouvelle mise en liste.

Cause racine : La cause racine n’a pas été complètement éliminée (identifiants toujours actifs, source de liste toujours mauvaise, automatisation encore mal configurée), ou le warmup a été trop agressif.

Correction : Réaudit des expéditeurs, rotation de toutes les clés pertinentes, application de contrôles de débit, et recommencer le warmup avec uniquement des destinataires engagés.

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

Checklist A : Première heure de réponse (confinement)

1. Geler les envois bulk (marketing, digests, notifications basse priorité).
2. Confirmer les IP d’envoi utilisées pour le flux défaillant (n’assumez pas).
3. Extraire 3 vrais bounces de 3 destinations majeures ; enregistrez les codes SMTP et étendus.
4. Vérifier les comptes compromis via les principaux noms SASL ou tokens API.
5. Purger le spam en file (avec précaution ; ne supprimez pas de mails transactionnels légitimes sans sauvegardes).
6. Activer le throttling par destination ; réduire la concurrence.

Checklist B : Remédiation dans la journée (rendre le système digne de confiance)

1. Corriger rDNS et HELO vers des noms DNS stables et cohérents.
2. Confirmer que SPF couvre tous les expéditeurs et ne dépasse pas les limites de recherches DNS via trop d’includes.
3. Vérifier que DKIM signe réellement les messages sortants et s’aligne avec From: quand requis.
4. Revoir les paramètres DMARC et ajuster la configuration des fournisseurs.
5. Sécuriser l’authentification : MFA pour les boîtes, clés API scindées, least privilege pour la soumission SMTP.
6. Segmenter les flux : transactionnel vs marketing avec sous‑domaines/IP séparés si possible.

Checklist C : Exécution du retrait (quand vous êtes prêt)

1. Identifier les listes exactes qui affectent la délivrabilité (depuis les messages de bounce et les requêtes DNSBL).
2. Confirmer que vous n’émettez plus de trafic abusif (volume redevenu normal, comptes compromis fermés, file propre).
3. Rédiger une note d’incident concise : ce qui s’est passé, quand, ce qui a été changé, comment éviter la récidive.
4. Soumettre les demandes de retrait avec les identifiants corrects (IP, domaine, plages selon besoin).
5. Suivre les résultats par liste/fournisseur ; n’assumez pas qu’une approbation règle tout.

Checklist D : Récupération et prévention (la partie qui vous garde hors des listes)

1. Chauffer progressivement avec des destinataires engagés ; augmenter le volume avec garde‑fous.
2. Instrumenter les résultats SMTP (taux 4xx/5xx par domaine) et alerter sur les anomalies.
3. Mettre en place une hygiène de liste : double opt‑in si possible, suppression des bounces, respect rapide des désinscriptions.
4. Effectuer des audits d’auth réguliers (SPF/DKIM/DMARC dérivent à chaque ajout de fournisseur).
5. Documenter un runbook de délivrabilité de la même façon que votre runbook d’incident.

FAQ

1) Comment savoir si c’est une blacklist IP versus la réputation du domaine ?

Si les rebonds mentionnent explicitement votre IP (« listed », « RBL », ou affichent l’IP), c’est centré sur l’IP. Si plusieurs IP échouent pour le même From: domaine ou si DMARC échoue, c’est centré sur le domaine. Souvent c’est les deux.

2) Si je suis listé sur une RBL, est‑ce que tout le monde me bloque ?

Non. Les destinataires choisissent quelles listes utiliser (si tant est qu’ils en utilisent). Certains n’en utilisent aucune publiquement et s’appuient sur un scoring interne. Traitez les messages de bounce de chaque destination comme la source de vérité.

3) Dois‑je arrêter tout l’e‑mail pendant que je suis listé ?

Arrêtez immédiatement le bulk non critique. Pour le mail transactionnel critique, vous pouvez parfois continuer avec un throttling agressif et seulement vers des destinataires engagés — mais uniquement si vous avez bien contenu la source d’abus.

4) Puis‑je payer quelqu’un pour me retirer des blacklists ?

Certaines sociétés « aident », mais si elles ne corrigent pas la cause racine, elles vous vendent un retour rapide vers la mise en liste. Payez pour du travail d’ingénierie : authentification, segmentation, hygiène, monitoring.

5) Pourquoi ai‑je des erreurs 4xx « rate limit » au lieu d’un message clair de blacklist ?

Parce que les destinataires préfèrent ralentir les expéditeurs suspects sans donner aux spammeurs une réponse nette oui/non. Aussi, le throttling est réversible et moins coûteux que de renvoyer des millions de messages.

6) Un DMARC p=reject améliore‑t‑il la délivrabilité ?

Il peut améliorer la confiance sur le long terme en empêchant l’usurpation de votre domaine, mais il ne réparera pas miraculeusement un programme d’envoi défaillant. Si vos propres systèmes ne sont pas alignés, il cassera d’abord vos propres mails. Déployez par étapes.

7) Nous utilisons une IP partagée chez un ESP. Que pouvons‑nous faire ?

Demandez à changer de pool, réduisez les éléments qui génèrent des plaintes, et assurez‑vous que votre authentification s’aligne. Si l’e‑mail est critique, prévoyez un budget pour une IP dédiée et un plan de warmup. Les pools partagés conviennent… jusqu’à ce qu’ils ne conviennent plus.

8) Combien de temps prend la récupération de réputation ?

De « un jour » à « des semaines ». Si vous avez été compromis et que vous avez pulvérisé du spam, attendez une queue longue. La vitesse de récupération dépend surtout d’un comportement propre et constant, pas du nombre de formulaires remplis.

9) Quel est le dysfonctionnement technique le plus courant que je vois lors des demandes de retrait ?

L’authentification désalignée : SPF passe pour un domaine, DKIM signe un autre, From: montre un troisième. Les destinataires voient cela comme une confusion d’identité au mieux et de l’usurpation au pire.

10) Et si nous sommes bloqués à cause de la réputation du netblock de notre hébergeur ?

Ça arrive. Si votre ASN/plage est considéré comme à haute abuse, vous devrez peut‑être déplacer le mail sortant vers un fournisseur réputé, utiliser un relais avec une forte enforcement, ou migrer l’espace d’IP et le chauffer correctement.

Conclusion : prochaines étapes qui fonctionnent vraiment

Si vous ne retenez qu’une leçon opérationnelle : le retrait est la dernière étape, pas la première. Le chemin le plus rapide vers la restauration de la livraison est de l’ingénierie ennuyeuse et mesurable.

1. Extraites de vrais bounces et classez les échecs (RBL vs politique fournisseur vs throttling).
2. Contenez l’abus : stoppez le bulk, verrouillez les comptes compromis, purgez les entrées malveillantes de la file.
3. Corrigez l’identité et l’hygiène : rDNS/HELO, SPF/DKIM/DMARC alignés, TLS correct, rate limiting.
4. Demandez le retrait seulement quand c’est propre, avec un récit d’incident crédible.
5. Chauffez et surveillez comme vous surveillez la latence : tendances, alertes, garde‑fous.

Votre objectif n’est pas « être retiré ». Votre objectif est « être l’expéditeur que personne n’a besoin de lister ». C’est un problème de systèmes. Traitez‑le comme tel.