Rebonds d’e-mails : lire les codes de rebond comme un pro (et corriger la cause racine)

Un modèle mental opérationnel : qu’est-ce qu’un rebond réellement

Un « rebond » n’est pas une impression. C’est un serveur SMTP distant (ou une passerelle devant lui) qui vous dit qu’il n’a pas accepté votre message pour livraison. Parfois il refuse immédiatement pendant la conversation SMTP. Parfois il accepte le message puis génère une Delivery Status Notification (DSN) lorsqu’il ne peut pas le livrer localement.

Pour l’exploitation, la division la plus importante est :

• Rebond dur (typiquement 5xx) : échec permanent. Retenter est généralement vain et peut nuire à votre réputation.
• Rebond mou (typiquement 4xx) : échec temporaire. Retenter est attendu, mais des messages retardés répétés peuvent aussi poser un problème de réputation.

Puis vous posez la question suivante : à qui appartient le problème ?

• Problème du destinataire : boîte inexistante, boîte pleine, politiques bloquantes chez eux.
• Notre problème : DNS/authentification, réputation IP, TLS cassé, messages malformés, pics de volume, MX mal routé, MTA mal configuré.
• Problème réseau : timeouts, échecs de handshake, MTU bizarre, routage transitoire.

La plupart des équipes échouent ici car elles traitent tous les rebonds de la même façon. Ils ne le sont pas. « 550 5.1.1 user unknown » est un problème d’hygiène des données. « 421 4.7.0 try again later » est souvent un problème de volume/réputation/throttling. « 554 5.7.1 » est le braquage en plein jour de la délivrabilité : vous vous êtes fait bloquer.

Faits et historique qui aident vraiment à déboguer

1. SMTP est plus ancien que la plupart de vos infrastructures. Il remonte au début des années 1980 (RFC 821). Beaucoup de comportements existent parce que « c’était comme ça sur l’ARPANET », pas parce que c’est élégant.
2. Les codes d’état étendus (comme 5.7.1) ont été introduits plus tard pour rendre les classes d’erreur lisibles par machine (RFC 3463). Tous les serveurs ne les utilisent pas correctement.
3. Le « message de rebond » que vous recevez est souvent généré par votre propre MTA. Si le distant rejette pendant SMTP, votre serveur crée la DSN pour informer votre appli/utilisateur de ce qui s’est passé.
4. Le greylisting est devenu populaire au milieu des années 2000 comme tactique anti-spam : rejeter temporairement les premières tentatives de livraison (souvent avec un 4xx) pour filtrer les bots spam naïfs.
5. Les RBL (listes noires en temps réel) précèdent le métier de « deliverability engineering ». Elles ont commencé comme des listes maintenues par la communauté et ont évolué en un écosystème confus de signaux de réputation.
6. SPF existait avant DKIM (SPF début années 2000 ; DKIM standardisé plus tard). SPF authentifie l’IP d’envoi ; DKIM authentifie le contenu du message par signature.
7. DMARC est arrivé plus tard pour lier SPF et DKIM avec une politique et un mécanisme de rapport. Une politique DMARC stricte peut transformer « parfois livré » en « systématiquement rejeté ».
8. Les gros fournisseurs de boîtes n’ignorent pas le contenu. Ils utilisent des signaux comportementaux : taux de plaintes, taux de rebond, engagement, et schémas d’envoi. Voilà pourquoi « ça marchait hier » n’est pas une preuve.
9. Les textes de réponse SMTP ne sont pas normalisés. Les codes numériques sont le contrat ; le texte libre est un indice — souvent cryptique.

Anatomie d’un message de rebond (champs DSN à lire)

Quand vous recevez un e-mail de rebond (DSN), il contient généralement une partie structurée et une partie lisible par un humain. Si vous lisez uniquement la ligne d’objet, vous déboguez à l’aveugle.

Champs DSN clés

• Final-Recipient : à qui il essayait de livrer.
• Action : failed, delayed, delivered, relayed (la plupart des rebonds sont failed ou delayed).
• Status : code d’état étendu (comme 5.1.1, 4.7.0).
• Remote-MTA : le nom du serveur distant (parfois une passerelle, pas la boîte finale).
• Diagnostic-Code : inclut souvent la réponse SMTP brute.
• Reporting-MTA : votre système qui a généré la DSN.

Les opérateurs lisent ces champs comme un dump de crash : code d’état d’abord, texte de diagnostic ensuite, puis corrélation avec les logs via l’identifiant de transaction SMTP. Si vous ne pouvez pas relier les rebonds aux IDs de file et aux horodatages, vous perdrez des heures à vous disputer sur des captures d’écran.

Familles de codes de rebond : 2xx, 4xx, 5xx et ce qu’ils impliquent

2xx : succès (pas un rebond)

« 250 2.0.0 Ok » signifie accepté. Pas nécessairement lu. Pas nécessairement livré dans la boîte de réception. Mais accepté pour livraison, ce qui est la promesse SMTP.

4xx : échec temporaire (rebond mou / déféré)

4xx signifie « réessayez plus tard ». Votre MTA mettra en file et retentera. Mais vous devez décider si la cause racine est transitoire (indisponibilité distante) ou chronique (votre réputation provoquant du throttling).

• 421 : service non disponible / fermeture du canal de transmission. Souvent throttling ou refus temporaire.
• 450/451/452 : boîte indisponible / erreur locale / espace de stockage insuffisant. Pourrait être greylisting, politique, ou problème de capacité chez eux.

5xx : échec permanent (rebond dur)

5xx signifie « ne retentez pas cette livraison telle quelle ». Votre MTA peut encore retenter selon sa config, mais vous ne devriez généralement pas continuer à marteler un 550.

• 550 : boîte indisponible, utilisateur inconnu, rejet pour politique.
• 552 : quota de stockage dépassé (boîte pleine).
• 553 : nom de boîte non autorisé (syntaxe d’adresse invalide ou politique du destinataire).
• 554 : transaction échouée, souvent lié à la politique (spam, listes noires, contenu).

Règle opérateur : traitez les 5xx comme un problème de données ou de politique nécessitant un changement. Traitez les 4xx comme un signal de capacité ou de réputation nécessitant contrôle de débit et patience — sauf si cela persiste.

Codes d’état étendus (x.y.z) : le bon, le mauvais, le trompeur

Les codes d’état étendus vous donnent une seconde dimension. Le premier chiffre reste 2/4/5. Le deuxième chiffre est la classe (adressage, boîte, système de messagerie, réseau, sécurité/politique). Le troisième chiffre est la condition spécifique.

Codes étendus à fort signal que vous rencontrerez quotidiennement

• 5.1.1 — mauvaise adresse de destination (utilisateur inconnu). Généralement une adresse morte.
• 5.2.2 — boîte pleine. Pourrait être temporaire, mais la plupart des systèmes renvoient un 5xx quand même.
• 5.7.1 — livraison non autorisée / message refusé (politique). C’est là que vivent les blocages.
• 4.7.0 — échec temporaire de politique (throttling, greylisting, limitation de débit).
• 4.4.1 — connexion expirée (réseau ou problème distant).
• 5.3.0 — autre état du système de messagerie (souvent « message trop volumineux » ou échec général).

Voici le piège : certains fournisseurs collent « 5.7.1 » sur tout ce qu’ils n’aiment pas. Cela peut signifier « spam », « SPF manquant », « DKIM incorrect », « réputation IP », « votre HELO paraît suspect », ou « vous envoyez trop vite ». Il vous faut toujours des preuves.

Idée paraphrasée de Werner Vogels (fiabilité/ops) : « tout échoue, donc concevez pour l’échec ». Les rebonds sont la façon pour l’e-mail d’être honnête à ce sujet.

Playbook de diagnostic rapide (vérifications 1/2/3)

Ceci est l’exercice « vous êtes d’astreinte et quelqu’un vient de poster une capture d’écran de rebond ». L’objectif est d’identifier le goulot en moins de 10 minutes : adresse, auth, réputation, contenu ou capacité distante.

Premier : classer la panne en 30 secondes

1. Est-ce un 4xx ou un 5xx ? Si 5xx : arrêtez les tentatives pour cette classe de destinataires ; c’est probablement permanent ou lié à la politique. Si 4xx : cherchez throttling vs réseau.
2. Le code étendu est-il présent ? 5.1.1 (adresse), 5.2.2 (quota), 5.7.1 (politique), 4.7.0 (politique temporaire) sont les principaux.
3. Est-ce tous les destinataires ou un sous-ensemble ? Un seul domaine suggère une politique/réputation distante avec ce fournisseur ; tous les domaines suggèrent votre auth/DNS ou votre MTA sortant.

Second : valider rapidement votre identité (DNS/auth)

1. Vérifiez SPF pour le domaine MAIL FROM / Return-Path.
2. Vérifiez que DKIM signe et que l’enregistrement selector existe.
3. Vérifiez la politique DMARC et l’alignement (surtout après des changements de domaine).
4. Confirmez que le reverse DNS (PTR) correspond à vos attentes HELO/EHLO.

Troisième : vérifier réputation et comportement de débit

1. Recherchez « blocked », « blacklist », « spam », « policy », « too many connections » dans le texte de diagnostic.
2. Vérifiez la croissance de votre file de sortie et les motifs de retry. Une file différée en croissance est une alarme de fumée pour débit/réputation.
3. Identifiez si c’est une seule IP, un pool entier, ou un type de trafic spécifique (réinitialisations vs newsletters).

Quatrième : isoler le contenu et les problèmes de transport

1. Taille du message, pièces jointes, et terminaisons de ligne.
2. Échecs de handshake TLS et incompatibilités de chiffrements.
3. En-têtes mal formés (From, Message-ID, Date) ou frontières MIME bizarres.

Tâches pratiques : commandes, sorties attendues et décision

Voici des actions concrètes d’opérateur. Chaque tâche inclut : une commande, ce que signifie une sortie typique, et la décision à prendre.

Task 1: Find the bounce reason in Postfix logs by queue ID

cr0x@server:~$ sudo grep -E "^[A-Z][a-f0-9]{9,12}:" /var/log/mail.log | grep "status=bounced" | tail -n 3
A1B2C3D4E5: to=<user@example.com>, relay=none, delay=0.2, delays=0.1/0/0/0.1, dsn=5.1.1, status=bounced (host mx.example.com[203.0.113.10] said: 550 5.1.1 <user@example.com> User unknown (in reply to RCPT TO command))
F6E7D8C9B0: to=<billing@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, delay=12, delays=0.2/0.1/10/1.7, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Try again later, rate limited (in reply to end of DATA command))
0AA11BB22C: to=<alerts@other.tld>, relay=none, delay=0.1, delays=0.05/0/0/0.05, dsn=5.7.1, status=bounced (host mx.other.tld[192.0.2.55] said: 550 5.7.1 Message rejected as spam (in reply to end of DATA command))

Ce que cela signifie : 5.1.1 est une adresse morte ; 4.7.0 est un retry/throttle ; 5.7.1 est lié à la politique/contenu/réputation.

Décision : supprimer/nettoyer les destinataires invalides pour les 5.1.1 ; appliquer un contrôle de débit et un backoff pour les 4.7.0 ; lancer une enquête auth/réputation/contenu pour les 5.7.1.

Task 2: Inspect the current mail queue size and whether it’s deferred-heavy

cr0x@server:~$ mailq | tail -n 5
-- 1230 Kbytes in 184 Requests.

Ce que cela signifie : la taille de la file seule ne suffit pas, mais un pic soudain suggère des déférences distantes ou des problèmes locaux.

Décision : si la croissance de la file corrèle avec des déférences 4xx, limitez le débit sortant et enquêtez sur la réputation ; si vous voyez des erreurs locales, vérifiez le disque et la santé du MTA.

Task 3: Summarize DSN codes in logs (what’s dominant right now)

cr0x@server:~$ sudo grep -oE "dsn=[245]\.[0-9]\.[0-9]" /var/log/mail.log | sort | uniq -c | sort -nr | head
  412 dsn=4.7.0
  119 dsn=5.7.1
   88 dsn=5.1.1
   41 dsn=4.4.1

Ce que cela signifie : la domination de 4.7.0 pointe vers throttling/greylisting/déférences de politique. 5.7.1 signifie des blocages. 4.4.1 suggère des timeouts réseau.

Décision : priorisez le contrôle de débit et la réputation si 4.7.0 ; priorisez l’authentification/contenu/politique si 5.7.1 ; vérifiez la connectivité si 4.4.1 augmente.

Task 4: Check a domain’s MX records (are you even talking to the right servers?)

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

Ce que cela signifie : si le MX est incorrect ou pointe vers des hôtes morts, vous verrez des timeouts (4.4.1) ou des échecs de connexion.

Décision : si le MX a changé récemment, confirmez la propagation ; si le domaine destinataire est mal configuré, vous ne pouvez pas le réparer — stoppez les tempêtes de retry et notifiez-le.

Task 5: Verify your sending IP has reverse DNS (PTR) set

cr0x@server:~$ dig +short -x 198.51.100.10
mailout1.yourdomain.tld.

Ce que cela signifie : l’absence ou un PTR générique est une cause fréquente de rejets 5.7.1 pour les domaines stricts.

Décision : si PTR est manquant/mal apparié, corrigez le rDNS chez votre fournisseur et alignez HELO/EHLO sur un nom qui résout et correspond aux attentes de politique.

Task 6: Check SPF record for the envelope-from domain

cr0x@server:~$ dig +short TXT yourdomain.tld
"v=spf1 ip4:198.51.100.0/24 include:_spf.your-esp.tld -all"

Ce que cela signifie : SPF est présent. Le qualificatif compte : -all est un échec strict ; ~all est un softfail.

Décision : si vos IP d’envoi ne sont pas incluses, ajoutez-les. Si vous avez trop d’includes, vous pouvez atteindre les limites de lookup DNS et causer des échecs intermittents.

Task 7: Validate DKIM selector record exists in DNS

cr0x@server:~$ dig +short TXT s1._domainkey.yourdomain.tld
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt..."

Ce que cela signifie : le selector est publié. Si cette requête ne retourne rien, les récepteurs ne peuvent pas vérifier votre signature.

Décision : publiez le selector ou corrigez le mismatch domaine/selector dans la config de votre MTA/ESP.

Task 8: Check DMARC policy (and whether you accidentally set it to reject)

cr0x@server:~$ dig +short TXT _dmarc.yourdomain.tld
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.tld; adkim=s; aspf=s"

Ce que cela signifie : l’alignement strict (adkim=s, aspf=s) peut provoquer des rejets si votre domaine From n’est pas aligné avec SPF/DKIM.

Décision : si vous voyez des rebonds après un changement DMARC, confirmez l’alignement ; assouplissez temporairement l’alignement uniquement si vous comprenez le compromis lié à l’usurpation.

Task 9: Test an SMTP session manually to see the raw rejection point

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx.other.tld:25
CONNECTED(00000003)
220 mx.other.tld ESMTP
ehlo mailout1.yourdomain.tld
250-mx.other.tld
250-STARTTLS
250 SIZE 52428800
mail from:<sender@yourdomain.tld>
250 2.1.0 Ok
rcpt to:<alerts@other.tld>
550 5.7.1 Blocked due to policy

Ce que cela signifie : un rejet au RCPT TO est souvent au niveau destinataire/politique ; un rejet après DATA est plus sensible au contenu/réputation.

Décision : si bloqué avant DATA, concentrez-vous sur l’identité/la réputation ; si bloqué après DATA, inspectez le contenu, les en-têtes et le schéma d’envoi.

Task 10: Confirm your server presents the correct certificate chain for SMTP TLS

cr0x@server:~$ sudo postconf -n | grep -E "smtpd_tls_cert_file|smtpd_tls_key_file|smtpd_tls_CAfile"
smtpd_tls_cert_file = /etc/ssl/certs/mail.pem
smtpd_tls_key_file = /etc/ssl/private/mail.key
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Ce que cela signifie : vous savez quels fichiers sont en jeu. Les échecs TLS peuvent apparaître comme 4.4.1 timeouts ou erreurs de handshake dans les logs.

Décision : si vous avez récemment roulé des certificats et que des rebonds ont commencé, vérifiez les permissions, la complétude de la chaîne et les paramètres de chiffrement.

Task 11: Identify top recipient domains in your deferred queue (who’s throttling you?)

cr0x@server:~$ mailq | awk '/^[A-F0-9]/ {id=$1} /@/ {print $0}' | sed -n 's/.*@//p' | tr -d '>,' | sort | uniq -c | sort -nr | head
  98 gmail.com
  71 corp.tld
  40 outlook.com
  19 yahoo.com

Ce que cela signifie : quels domaines vous différent/mettent en file le plus en ce moment.

Décision : implémentez des throttles par domaine et des limites de connexion ; envisagez de séparer les types de trafic sur différentes IP si vous mélangez transactionnel et bulk.

Task 12: Check for “too many connections” and tune concurrency (without going feral)

cr0x@server:~$ sudo grep -iE "too many connections|rate limited|throttl" /var/log/mail.log | tail -n 5
Jan 03 10:11:22 mail postfix/smtp[23111]: F6E7D8C9B0: to=<billing@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Try again later, rate limited)
Jan 03 10:11:40 mail postfix/smtp[23112]: 9D8C7B6A5F: to=<ops@corp.tld>, relay=mx.corp.tld[198.51.100.25]:25, dsn=4.7.0, status=deferred (host mx.corp.tld[198.51.100.25] said: 421 4.7.0 Too many connections)

Ce que cela signifie : le côté distant vous dit de ralentir.

Décision : réduisez la concurrence vers ce domaine et augmentez le backoff ; ne « optimisez » pas en ouvrant plus de connexions. C’est comme ça que vous transformez un throttle temporaire en blocage.

Task 13: Confirm local disk isn’t the real reason you’re failing

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       40G   37G  1.2G  97% /

Ce que cela signifie : votre spool est presque plein. Postfix peut commencer à différer, et vos logs peuvent mentir par omission.

Décision : libérez de l’espace immédiatement et ajoutez de la supervision ; si vous êtes souvent proche du plein, vous aurez un comportement « système mail plein » qui ressemble à des problèmes distants.

Task 14: Inspect a specific queued message (check headers, size, and envelope)

cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_size:            48213            48159               54               54
sender: sender@yourdomain.tld
*** MESSAGE CONTENTS ***
Received: by mailout1.yourdomain.tld (Postfix, from userid 1001)
Date: Fri, 03 Jan 2026 10:10:05 +0000
From: "Your App" <noreply@yourdomain.tld>
To: user@example.com
Subject: Reset your password
Message-ID: <20260103101005.12345@mailout1.yourdomain.tld>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Ce que cela signifie : vous pouvez confirmer si les en-têtes sont cohérents et si le domaine expéditeur s’aligne avec votre setup d’auth.

Décision : si le contenu est malformé (Date/Message-ID manquants, MIME cassé), corrigez le générateur ; certains fournisseurs rejettent des messages malformés comme échecs de politique.

Blague 1 : L’e-mail est le seul système où vous pouvez tout faire correctement et vous faire quand même dire « essayez plus tard » par une machine qui ne s’explique pas.

Trois mini-histoires d’entreprise issues des tranchées des rebonds

Incident 1 : La mauvaise hypothèse (5.1.1 qui n’était pas « la faute du destinataire »)

Une entreprise a migré d’un CRM legacy vers une nouvelle plateforme client. Pendant la bascule, ils ont fait fonctionner les deux systèmes en parallèle. L’équipe e-mail a remarqué une hausse soudaine de rebonds 550 5.1.1 User unknown pour un domaine particulier. L’hypothèse immédiate fut la classique : « notre liste est obsolète. »

Ils ont fait ce que font les équipes sous pression : ils ont supprimé ces adresses. Des milliers. Des tickets support sont arrivés en quelques heures : des clients ne recevaient plus de liens de connexion, et ces clients étaient bien réels.

La vraie cause racine était dans un coin ennuyeux : le nouveau système mettait les e-mails en minuscules et enlevait bien les espaces, mais une couche intermédiaire ajoutait aussi un caractère Unicode caché copié depuis un outil interne d’administration. Visuellement, l’adresse semblait identique. Les serveurs SMTP ne s’intéressent pas à vos sentiments ; ils regardent les octets. Le système destinataire a traité cela comme un local-part différent et a répondu « user unknown ».

La correction n’était pas « nettoyez votre liste ». C’était normaliser et valider les adresses à l’ingestion, logger les octets bruts, et ajouter des tests qui comparent les formes normalisées UTF-8. Ils ont aussi mis à jour la logique de suppression pour exiger des échecs répétés et considérer comme suspectes les adresses « nouvellement en échec » pendant les migrations.

Par la suite, ils ont conservé une règle : si le taux de rebond augmente juste après un changement de pipeline de données, supposez que vous avez cassé les adresses jusqu’à preuve du contraire.

Incident 2 : L’optimisation qui s’est retournée contre eux (plus de débit, plus de blocages)

Une autre organisation gérait sa flotte Postfix et envoyait beaucoup d’e-mails légitimes : factures, reçus, notifications d’événements. Leur file commençait à s’accumuler aux heures de pointe. Quelqu’un eut l’idée raisonnable : « augmentez la concurrence et réduisez les intervalles de retry pour vider la file plus vite. »

Ils ont augmenté la concurrence par destination et réduit le backoff. La file s’est vidée. Pendant environ une journée. Puis les rebonds ont explosé : les déférences 421 4.7.0 sont devenues des blocages 550 5.7.1. Le texte diagnostic spécifique au fournisseur mentionnait « rate limited » puis « blocked due to policy ».

Ce qui s’est passé est classique : ils ont entraîné le récepteur à se méfier d’eux. Trop de connexions parallèles, trop de messages en peu de temps, et trop peu de patience. Même des e-mails conformes peuvent ressembler à un abus quand vous les envoyez comme un test de déni de service.

Le rollback fut douloureux car « annuler l’optimisation » n’a pas restauré instantanément la réputation. Ils ont dû implémenter du throttling adaptatif par domaine, segmenter le trafic bulk du transactionnel, et cesser de retenter agressivement sur 4xx. Avec le temps, les blocages se sont atténués.

Ils ont aussi appris une leçon valable pour le stockage et le réseau : la façon la plus rapide de casser un système partagé est d’optimiser le débit sans respecter les limites de l’autre côté.

Incident 3 : La pratique ennuyeuse qui a sauvé la mise (séparation du trafic et retries calmes)

Un SaaS d’entreprise appliquait une règle peu sexy : le mail transactionnel et le mail bulk ne partagent pas d’IP, ne partagent pas de domaines, et ne partagent pas le comportement de retry. Le marketing détestait cela car cela demandait plus de coordination. La finance détestait car cela coûtait plus d’IPs et de lignes vendor.

Puis un après-midi, le marketing a lancé une campagne qui a eu un taux de plaintes inattendu. Prédictiblement, le pool IP marketing a été throttlé et bloqué. Mais les réinitialisations de mot de passe et alertes de sécurité ont continué à passer. Pourquoi ? Ségrégation de la réputation IP et limitation stricte du débit côté transactionnel.

L’ingénieur d’astreinte a quand même été alerté, mais c’était un signal d’information, pas un incendie. Ils ont mis la campagne marketing en pause, nettoyé la liste, ajusté le ciblage, et attendu que la réputation remonte — sans la panne généralisée « personne ne peut se connecter ».

Ce n’était pas brillant. C’était ennuyeux. Et ça a marché parce que ça réduisait le blast radius. C’est un objectif de conception SRE, même quand le système est « juste de l’e-mail ».

Blague 2 : La façon la plus rapide de découvrir que vous n’avez pas de stratégie de délivrabilité, c’est d’envoyer un message « confirmez votre e-mail » qui n’arrive jamais.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: Lots of 550 5.1.1 “User unknown” right after a migration

Cause racine : bug de transformation d’adresse (espaces, Unicode, suppression du plus-addressing, faute de frappe de domaine) ou mauvais mapping de domaine destinataire.

Correction : valider à l’ingestion, normaliser avec soin, logger les octets bruts de l’adresse, et différer la suppression jusqu’à des échecs répétés sur plusieurs livraisons.

2) Symptom: 421 4.7.0 “Try again later” across one big provider

Cause racine : throttling dû à des pics de débit, mauvaise réputation, ou nouvelle IP chauffée trop rapidement.

Correction : limitation par domaine, montée en charge progressive, backoff plus long sur les déférences, et séparation des types de trafic (transactionnel vs bulk).

3) Symptom: 550 5.7.1 “Blocked” or “Message rejected” suddenly for many domains

Cause racine : échec d’authentification (SPF/DKIM/DMARC), rDNS manquant, ou IP listée suite à des plaintes ou un expéditeur compromis.

Correction : vérifier l’alignement SPF/DKIM/DMARC ; confirmer le PTR ; passer en revue les logs d’envoi pour des pics inhabituels ; révoquer des credentials ; isoler le trafic ; remédier à la réputation (et cesser d’envoyer massivement).

4) Symptom: 552 5.2.2 mailbox full bounces

Cause racine : quota destinataire dépassé. Pas votre infrastructure, mais vos retries peuvent les agacer.

Correction : traiter comme « temporaire mais lent » : supprimer les tentatives répétées pendant un certain temps, notifier l’utilisateur par d’autres canaux, et éviter les retries immédiats.

5) Symptom: 4.4.1 timeouts and connection errors to specific domains

Cause racine : problèmes de chemin réseau, préférence IPv6 cassée, MX erroné, blocs firewall, ou pannes distantes.

Correction : tester la connectivité depuis le MTA émetteur, vérifier la résolution DNS (A/AAAA), vérifier l’egress firewall, et privilégier IPv4 si votre chemin IPv6 est peu fiable.

6) Symptom: Bounces mention “TLS” or handshake failures

Cause racine : réglages TLS incompatibles, certificats intermédiaires manquants, dérive d’horloge, ou attentes SNI cassées chez certaines passerelles.

Correction : présenter une chaîne de certificats complète, maintenir OpenSSL à jour, surveiller les erreurs de handshake, et éviter un durcissement excessif des chiffrements sans tester les récepteurs réels.

7) Symptom: Only HTML-heavy messages bounce as spam; plaintext is fine

Cause racine : déclencheurs de contenu (patterns d’URL, domaines de lien non alignés, domaines de tracking, MIME cassé, ou messages « image-only »).

Correction : assurer une structure MIME valide, inclure une partie texte raisonnable, aligner les domaines visibles des liens avec les domaines authentifiés, et réduire les patterns de contenu risqués.

8) Symptom: “Message size exceeds fixed maximum message size”

Cause racine : pièce jointe ou encodage gonflant (overhead base64) dépassant les limites distantes.

Correction : réduire la taille des pièces jointes, utiliser des liens de téléchargement, et appliquer des limites de taille dans votre appli avant de mettre en file le mail.

Checklists / plan pas-à-pas

Checklist A: When bounces spike (incident response)

1. Stop the bleeding : pausez les envois bulk ; gardez le transactionnel en fonctionnement si possible.
2. Classify : principaux DSN (4.7.0 vs 5.7.1 vs 5.1.1) extraits des logs.
3. Scope : quels domaines, quelles IPs, quelle classe de trafic, quelle fenêtre de release/changement.
4. Identity : vérifiez SPF/DKIM/DMARC et rDNS. Corrigez d’abord les ruptures évidentes.
5. Rate behavior : réduisez la concurrence ; augmentez le backoff des retries ; implémentez des throttles par domaine.
6. Content sanity : confirmez en-têtes, MIME, taille du message. Comparez un échantillon « bon » et « mauvais ».
7. Queue health : surveillez la taille de la file et les comptes différés ; assurez-vous de l’espace disque et des processus MTA.
8. Remediate : nettoyez les destinataires invalides ; désactivez les expéditeurs compromis ; segmentez le trafic.
9. Verify recovery : surveillez la tendance des DSN à la baisse ; confirmez l’augmentation des taux d’acceptation (250).
10. Post-incident hardening : ajoutez des tableaux de bord pour les codes DSN, les taux de déférence, et l’efficacité des throttles par domaine.

Checklist B: Building a bounce-handling policy (so you don’t re-learn pain)

1. Define hard vs soft bounce logic : ne traitez pas tous les 5xx comme permanents sans nuance (quota est spécial), mais ne retentez pas indéfiniment un 5.1.1.
2. Set suppression thresholds : suppression immédiate pour 5.1.1 ; suppression basée sur le temps pour 4.7.0 ; gestion prudente pour 5.2.2.
3. Separate traffic classes : transactionnel vs bulk, idéalement IPs et domaines séparés.
4. Per-domain throttling : différents fournisseurs, différentes limites. Construisez une surface de configuration modifiable sans déploiement.
5. Feedback loop : les rebonds doivent mettre à jour vos données client, mais avec des garde-fous pendant les migrations et incidents.
6. Audit your From and Return-Path strategy : assurez-vous que l’alignement supporte DMARC.
7. Runbook everything : une capture de rebond doit se traduire par une série de vérifications prévisibles.

Checklist C: Pre-flight for new sending infrastructure (before you go live)

1. PTR/rDNS configuré et vérifié.
2. Le nom HELO/EHLO résout vers l’IP d’envoi.
3. SPF inclut toutes les IP sortantes ; ne dépasse pas les limites de lookup DNS.
4. DKIM activé ; selectors publiés ; plan de rotation existant.
5. Politique DMARC choisie intentionnellement ; alignement testé.
6. TLS sortant configuré ; certificats valides ; synchronisation horaire fonctionnelle.
7. Supervision de la file et des logs en place ; alertes sur les pics de différés.
8. Limites de débit et paramètres de concurrence conservateurs par défaut.
9. Séparation du trafic décidée, pas « plus tard ».

FAQ

1) What’s the difference between a bounce and a deferral?

Un rebond est une non-livraison définitive (typiquement 5xx). Une déférence est un refus temporaire (typiquement 4xx) que votre MTA retentera plus tard.

2) Is 5xx always a hard bounce I should suppress immediately?

Généralement oui, mais sans aveuglement. 5.1.1 est un fort signal de suppression immédiate. 5.2.2 (boîte pleine) est souvent mieux traité comme « reculez pendant des jours » plutôt que « supprimez l’utilisateur ».

3) Why do I see 4.7.0 for hours?

Parce que le récepteur vous throttle ou vous greyliste. Si cela persiste, traitez-le comme un problème de réputation/débit, pas comme un aléa transitoire.

4) The diagnostic text says “spam,” but the email is legitimate. Now what?

« Spam » est souvent une abréviation pour des échecs de politique/réputation. Vérifiez l’authentification (SPF/DKIM/DMARC), le rDNS, les schémas d’envoi, et la structure du contenu. Ensuite réduisez le volume et les retries pendant que la réputation se rétablit.

5) Can a bad SPF record cause bounces?

Oui. Avec l’application DMARC, les échecs SPF (surtout avec politique stricte) peuvent se transformer en rejets 5.7.1. Même sans DMARC, certains récepteurs utilisent SPF comme input de politique.

6) Why does it work for some recipients at a provider but not others?

Les fournisseurs exécutent plusieurs clusters et couches de politique. Un MX peut être plus strict, ou vous pouvez frapper des throttles par destinataire ou par domaine. C’est pourquoi il vous faut de la visibilité par domaine et par IP.

7) Should I “fix” bounces by switching IPs?

Seulement si vous savez pourquoi vous changez. L’IP hopping pour esquiver la réputation est un moyen rapide de brûler plusieurs IPs. Réparez la cause (auth, qualité de liste, volume) puis envisagez un warm-up contrôlé.

8) What’s the simplest metric that predicts deliverability trouble?

La montée des déférences 4.7.0 et la croissance des files différées vers les principaux fournisseurs. C’est le système d’alerte précoce avant les blocages 5.7.1.

9) What if the bounce message is missing the enhanced status code?

Revenez au code SMTP de base (4xx/5xx) et au texte diagnostic, puis confirmez dans les logs du MTA. Certains systèmes suppriment des détails ; vos logs ont généralement plus de vérité que l’e-mail DSN.

10) Do I need separate domains for transactional and marketing email?

Ce n’est pas strictement nécessaire, mais cela facilite l’alignement DMARC et l’isolation de réputation. Si vous conservez un seul domaine, vous acceptez un plus grand blast radius.

Étapes suivantes (ce qu’il faut changer lundi)

Si vous voulez moins d’incidents de rebonds et une récupération plus rapide quand ils surviennent, faites le travail ingrat :

1. Construisez un tableau de bord DSN qui suit 4.7.0, 5.7.1, 5.1.1 et 4.4.1 dans le temps, par domaine destinataire et par IP d’envoi.
2. Implémentez du throttling par domaine et cessez de traiter les serveurs distants comme des puits infinis. Respectez le « try again later ».
3. Renforcez l’identité : SPF inclut tous les expéditeurs, DKIM signe tout ce qui compte, la politique DMARC correspond à votre réalité, et PTR/rDNS n’est pas une réflexion après coup.
4. Séparez le trafic pour que les erreurs marketing n’empêchent pas les réinitialisations de mot de passe.
5. Rendez explicites les règles de suppression : immédiate pour 5.1.1, basée sur le temps pour 4xx, prudente pour les boîtes pleines, et protégée pendant les migrations.

Le courrier électronique n’est pas un transport fiable. C’est une trêve négociée entre votre MTA et les politiques de tout le monde. Lisez les codes, confirmez avec des preuves, et corrigez le système — pas la capture d’écran.