Erreur d’email « 550 rejected » : ce que ça signifie réellement et comment débloquer

Ce que « 550 rejected » signifie vraiment (et ce que ce n’est pas)

Les codes d’état SMTP sont la version du monde du mail de « l’ordinateur dit non ». 550 est une défaillance permanente
au niveau SMTP : le serveur destinataire n’acceptera pas le message tel qu’il a été envoyé. « Permanente » signifie que le destinataire vous dit
« ne réessayez pas comme un robot ; corrigez quelque chose ».

Mais voici le piège : 550 est un sac. Le nombre seul est presque inutile. La partie importante est le
code d’état amélioré (comme 5.7.1) et, encore plus, le texte qui suit.
Les destinataires surchargent 550 pour tout, de « utilisateur introuvable » à « votre IP sent le spam » en passant par « votre HELO est absurde ».

550 vs 450/451 : pourquoi « permanent » compte opérationnellement

Si vous voyez 450 ou 451, il s’agit généralement d’une défaillance temporaire : greylisting, limitation de débit,
vérifications de politique temporaires, ou le destinataire ayant une mauvaise journée. Votre MTA doit réessayer.
Avec 550, réessayer vous rend généralement plus suspect : vous continuez de frapper un destinataire qui a déjà dit « non ».

Cela ne veut pas dire « ne jamais réessayer un 550 ». Certains destinataires envoient incorrectement 550 pour des blocages de politique temporaires.
Mais traitez 550 comme un incident : pause, inspection, et correction ciblée.

Ce que 550 n’est pas

• Pas nécessairement un problème avec votre fournisseur de boîte. C’est souvent votre domaine, votre IP, votre authentification, votre contenu ou votre comportement d’envoi.
• Pas une preuve que vous êtes « blacklisté partout ». Un seul destinataire qui vous rejette peut gâcher votre journée, mais c’est rarement universel.
• Pas toujours lié au spam. Cela peut être un utilisateur inconnu, un mail mal routé, un DNS cassé ou un relais mal configuré.

Une règle opérationnelle : ne laissez pas l’équipe commerciale définir la sévérité de l’incident sur des impressions.
La sévérité vient de l’étendue : quels domaines vous rejettent, quels flux de mail sont impactés (transactionnel vs marketing),
et si vous perdez des mails critiques pour l’activité.

Faits intéressants et un peu d’histoire (parce que le mail est ancien)

• SMTP précède le web. La spécification SMTP de base a été publiée en 1982. La plupart de vos problèmes « modernes » avec le mail sont des ajouts.
• Les codes d’état améliorés (comme 5.7.1) ont été introduits plus tard pour rendre les échecs moins ambigus. Beaucoup de systèmes les traitent encore comme décoratifs.
• SPF a commencé en réponse aux adresses expéditrices falsifiées au début des années 2000. Il aide, mais ce n’est pas un système d’identité ; c’est un indice « qui est autorisé à envoyer pour ce domaine ».
• DKIM est devenu courant pour protéger l’intégrité du message et fournir un domaine de signature stable même lors de la réexpédition.
• DMARC est la colle de politique et de reporting qui indique aux destinataires ce que vous voulez faire quand SPF/DKIM échouent et vous donne de la visibilité via des rapports.
• Le greylisting était une astuce anti-spam reposant sur le fait que les spammeurs ne réessayaient pas. Les vrais MTAs réessaient ; les bots souvent non. Certains l’utilisent encore.
• Les RBL (listes noires en temps réel) ont émergé parce que SMTP n’a pas de système de réputation intégré. L’Internet a externalisé la « confiance » vers des listes et boucles de retour.
• IPv6 a rendu la réputation plus difficile au départ car l’espace d’adresses est énorme ; le blocage naïf peut être inutile ou dévastateur.
• Les boîtes « postmaster » et « abuse » sont devenues des standards de fait parce que les opérateurs avaient besoin d’un humain à qui crier quand un serveur se comportait mal.

Le courrier électronique est le plus ancien système distribué encore critique que la plupart des entreprises gèrent. C’est aussi celui que les gens supposent « devrait juste fonctionner »,
ce qui est adorable, comme supposer qu’une imprimante devrait juste fonctionner.

Blague #1 : Le mail est le seul système où un protocole de 40 ans pilote encore l’économie mondiale, et nous sommes surpris qu’il ait des caprices à propos du DNS.

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

Premier : classer le rejet en 60 secondes

1. Récupérez la transcription SMTP exacte ou le texte du bounce. « 550 rejected » n’est pas suffisant. Il vous faut le code amélioré et le texte de politique.
2. Identifiez la famille du destinataire. Consommateur (Gmail, Microsoft) vs passerelle d’entreprise (Proofpoint, Mimecast) vs Postfix/Exim custom. Leurs modes d’échec diffèrent.
3. Vérifiez l’étendue : Est-ce un seul destinataire ? un seul domaine ? plusieurs domaines ? seulement de nouveaux destinataires ? seulement les pièces jointes ?

Second : décidez s’il s’agit d’identité, de réputation ou de routage

• Identité/authentification : SPF fail, DKIM fail, DMARC fail, problèmes d’alignement, rDNS/PTR manquant, HELO/EHLO incorrect, exigences TLS.
• Réputation/politique : réputation IP ou domaine, listing RBL, taux de plaintes, limitation de débit, filtrage de contenu, réputation d’URL.
• Routage/destinataire : utilisateur inconnu, relay denied, expéditeur non autorisé, politique destinataire (blocage d’expéditeurs externes), MX incorrect, port erroné, DNS cassé.

Troisième : choisissez le chemin le plus court pour débloquer

1. Si c’est routage/destinataire : corrigez l’adressage, le MX, le relais ou la politique destinataire ; vous pouvez généralement résoudre rapidement.
2. Si c’est authentification : corrigez SPF/DKIM/rDNS/HELO et réessayez avec un test contrôlé.
3. Si c’est réputation : arrêtez l’hémorragie (limitez le débit, bloquez les comptes compromis, mettez en pause le marketing), puis travaillez le delisting et le warm-up.

L’essentiel : ne commencez pas par tout changer. Vous perdrez la capacité d’attribuer la correction et vous gaspillerez du temps à vous disputer plus tard.
Faites un changement ciblé, testez, puis poursuivez.

Décoder le bounce : les mots qui comptent

Codes d’état améliorés courants que vous verrez avec 550

• 550 5.1.1 : adresse du destinataire rejetée (souvent « utilisateur inconnu »). Peut être une faute de frappe ou une boîte désactivée.
• 550 5.1.10 (varie selon le fournisseur) : destinataire introuvable ou invalide.
• 550 5.2.0 / 5.2.2 : boîte pleine ou limite de stockage/politique (parfois mal utilisée).
• 550 5.7.1 : livraison non autorisée / message refusé pour raison de politique. C’est le gros lot : authentification, réputation, contenu ou politique admin.
• 550 5.7.26 : authentification requise ou rejet lié à DMARC (commun avec les principaux fournisseurs).
• 550 5.7.0 : statut générique de sécurité/politique.

Modèles de texte de politique et ce qu’ils impliquent généralement

• « SPF fail » / « SPF softfail » : votre IP d’envoi n’est pas autorisée dans SPF, ou votre SPF est malformé/trop long.
• « DKIM signature invalid » : la signature est cassée (souvent réécriture d’en-têtes, mauvais sélecteur ou désaccord de clé).
• « DMARC policy reject » : SPF/DKIM ont échoué en alignement selon la politique DMARC ; le destinataire applique votre position publiée (ou la sienne).
• « blocked using … » : souvent une RBL ou une réputation interne. La liste nommée est importante.
• « reverse DNS required » : PTR manquant ou non correspondant ; certaines passerelles sont strictes.
• « HELO/EHLO rejected » : votre MTA s’identifie avec un nom d’hôte faux ou un littéral d’adresse IP que le destinataire n’aime pas.
• « Relay access denied » : vous essayez d’utiliser un serveur comme relais ouvert, ou votre client n’est pas authentifié/autorisé.
• « Message content rejected » : réputation d’URL, type de pièce jointe ou heuristiques de contenu (y compris « trop de liens » ou « ressemble à du phishing »).

Traitez le texte du bounce comme des lignes de log : bruyant mais rarement aléatoire. Votre meilleur mouvement est de capturer plusieurs bounces sur une courte fenêtre
et de rechercher des libellés cohérents. Si chaque rejet contient la même clause, cette clause est votre candidate cause racine.

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

Voici les vérifications que j’exécute dans la première heure. Chaque tâche inclut : une commande, ce que signifie la sortie et quelle décision prendre.
Exécutez-les depuis un hôte ayant accès au DNS et à Internet (ou au moins à votre résolveur).

Task 1: Extract the exact SMTP rejection from your logs (Postfix)

cr0x@server:~$ sudo grep -R "status=bounced" /var/log/mail.log | tail -n 3
Jan  3 01:10:12 mx1 postfix/smtp[22103]: 9C2D12A03F: to=<user@example.net>, relay=mx.example.net[203.0.113.10]:25, delay=1.2, delays=0.1/0/0.4/0.7, dsn=5.7.1, status=bounced (host mx.example.net[203.0.113.10] said: 550 5.7.1 Message rejected due to policy restrictions (in reply to end of DATA command))

Sens : Vous avez le code amélioré 5.7.1 et un rejet de politique après DATA. C’est généralement authentification, réputation ou contenu.

Décision : Ne perdez pas de temps sur « utilisateur inconnu ». Allez directement aux vérifications d’authentification/réputation/contenu.

Task 2: Verify the sending IP you actually used

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5      2140 Fri Jan  3 01:11:44  alerts@corp.example
                                         user@example.net

-- 1 Kbytes in 1 Request.

Sens : Une file existe ; vous devez voir quel transport et quelle IP source sont utilisés pour la sortie.

Décision : Confirmez le NAT sortant ou le comportement multi-homed ; la mauvaise IP d’egress peut casser SPF et les hypothèses de réputation.

Task 3: Check your outbound public IP from the mail host

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

Sens : C’est l’IP que la plupart des destinataires vont évaluer pour la réputation et les mécanismes SPF « ip4 ».

Décision : Utilisez cette IP lors de la validation SPF, rDNS et le statut RBL.

Task 4: Look up the recipient domain MX records (routing sanity)

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

Sens : Vous savez où vous livrez. Si c’est vide ou étrange, vous pourriez envoyer au mauvais endroit.

Décision : Si le MX est manquant ou pointe vers des hôtes inattendus, corrigez le DNS/les attentes du destinataire avant de toucher à l’authentification.

Task 5: Open an SMTP session to see the rejection stage

cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP
EHLO mx.corp.example
250-mx1.example.net
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP
MAIL FROM:<alerts@corp.example>
250 2.1.0 Ok
RCPT TO:<user@example.net>
550 5.7.1 Recipient address rejected: Access denied

Sens : Rejeté au RCPT TO : souvent politique destinataire, listes de blocage, réputation expéditeur, ou « expéditeur externe non autorisé ».

Décision : Si RCPT échoue, le contenu est moins probable. Concentrez-vous sur la politique, la réputation et les règles d’autorisation du destinataire.

Task 6: Check SPF for the envelope-from domain

cr0x@server:~$ dig +short TXT corp.example | grep -i spf
"v=spf1 ip4:198.51.100.25 include:spf.mailvendor.example -all"

Sens : SPF existe et autorise explicitement votre IP sortante.

Décision : Si votre IP d’envoi réelle ne correspond pas, mettez à jour SPF ou corrigez le routage d’egress. Si SPF manque, ajoutez-le maintenant.

Task 7: Validate SPF evaluation with a local tool (quick-and-dirty)

cr0x@server:~$ sudo apt-get -y install spfquery >/dev/null
cr0x@server:~$ spfquery -ip 198.51.100.25 -sender alerts@corp.example -helo mx.corp.example
pass

Sens : SPF passe pour cette combinaison sender/IP/HELO.

Décision : Si ceci retourne fail/softfail/permerror, traitez SPF comme suspect principal et corrigez avant toute autre chose.

Task 8: Check DKIM DNS selector record exists

cr0x@server:~$ dig +short TXT selector1._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt0..."

Sens : La clé publique DKIM est publiée pour selector1.

Décision : Si elle manque, vous obtiendrez DKIM=none ou fail ; publiez l’enregistrement ou corrigez le désalignement de sélecteur dans votre MTA/ESP.

Task 9: Confirm your outbound message is actually DKIM-signed

cr0x@server:~$ sudo apt-get -y install swaks >/dev/null
cr0x@server:~$ swaks --to user@example.net --from alerts@corp.example --server mx1.example.net --data "Subject: test

hello" --quit-after DATA
=== Trying mx1.example.net:25...
=== Connected to mx1.example.net.
<= 220 mx1.example.net ESMTP
=> EHLO mx.corp.example
<= 250-mx1.example.net
<= 250-STARTTLS
=> QUIT

Sens : Ce test n’a pas inclus votre chemin de signature de production ; swaks est utile pour sonder, mais la signature DKIM dépend de votre pipeline d’envoi.

Décision : Envoyez un vrai message via votre MTA et inspectez les en-têtes (tâche suivante). Ne « prouvez » pas DKIM avec un test qui le contourne.

Task 10: Inspect a sent message’s Authentication-Results and DKIM headers

cr0x@server:~$ sudo grep -R "DKIM-Signature" /var/log/mail.log | tail -n 2
Jan  3 01:14:02 mx1 opendkim[1402]: 9C2D12A03F: DKIM-Signature field added (s=selector1, d=corp.example)

Sens : Votre MTA ajoute des signatures DKIM pour d=corp.example.

Décision : Si vous voyez « no signature data » ou rien du tout, corrigez l’intégration opendkim/opendmarc ou votre table de signature.

Task 11: Check DMARC policy and alignment expectations

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

Sens : DMARC est strict : DKIM et SPF ont un alignement « strict » (s). Cela peut casser des flux légitimes comme les transferts, les réexpéditions et les envois tiers.

Décision : Si vous êtes bloqué et que vous avez récemment mis p=reject avec alignement strict, confirmez que tous les flux sont alignés ; assouplissez l’alignement seulement si vous comprenez le compromis.

Task 12: Verify reverse DNS (PTR) for your outbound IP

cr0x@server:~$ dig +short -x 198.51.100.25
mx.corp.example.

Sens : Le PTR existe et pointe vers mx.corp.example.

Décision : Si pas de PTR, ou si le PTR pointe vers quelque chose de générique, corrigez-le auprès de votre ISP/fournisseur cloud. Beaucoup de passerelles échouent sévèrement sans rDNS.

Task 13: Confirm forward DNS matches your PTR (not required everywhere, but helps)

cr0x@server:~$ dig +short A mx.corp.example
198.51.100.25

Sens : Le reverse DNS confirmé en avant (FCrDNS) est cohérent.

Décision : Si l’A record ne correspond pas à l’IP du PTR, attendez-vous à de la suspicion. Corrigez le nommage et l’appariement IP quand c’est possible.

Task 14: Check your HELO/EHLO name matches something real

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

Sens : Vous vous identifiez comme mx.corp.example.

Décision : Si le HELO est « localhost » ou un nom interne, corrigez-le. Certains destinataires rejettent immédiatement ; d’autres vous pénalisent.

Task 15: Check if your IP is on common RBLs (DNS-based check)

cr0x@server:~$ for rbl in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do \
ip=198.51.100.25; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); \
ans=$(dig +short ${rev}.${rbl} A); \
echo "$rbl: ${ans:-not-listed}"; \
done
zen.spamhaus.org: not-listed
bl.spamcop.net: not-listed
b.barracudacentral.org: 127.0.0.2

Sens : Listé sur une RBL (exemple : réponse de type Barracuda).

Décision : Arrêtez les envois en masse et investiguez compromis/contenu immédiatement ; puis poursuivez le delisting selon le processus de la liste. Être listé est un symptôme, pas la maladie.

Task 16: Detect outbound spikes (compromised account or script gone feral)

cr0x@server:~$ sudo pflogsumm -d today /var/log/mail.log | head -n 20
Postfix log summaries for: Fri Jan  3 2026

Grand Totals
------------
messages processed:                    18432
messages delivered:                    12010
messages deferred:                      5200
messages bounced:                       1222
rejected connections:                    410

Sens : Volume élevé + fortes déferrals/bounces + rejets : profil classique d’épidémie.

Décision : Traitez comme incident sécurité + délivrabilité. Verrouillez les identifiants, limitez le débit et séparez transactionnel et bulk.

Task 17: Check Postfix SASL auth usage (hunting compromised credentials)

cr0x@server:~$ sudo grep "sasl_username" /var/log/mail.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head
  8420 sasl_username=support@corp.example
  3011 sasl_username=noreply@corp.example
   188 sasl_username=dev@corp.example

Sens : Un compte domine les envois sortants.

Décision : Si l’expéditeur principal est inattendu, changez le mot de passe/le token, vérifiez les IP sources et ajoutez MFA/restrictions de soumission SMTP.

Task 18: Confirm submission vs relay separation (port 587 with auth)

cr0x@server:~$ sudo ss -lntp | grep -E ":25|:587"
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1010,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1010,fd=15))

Sens : SMTP (25) et submission (587) écoutent tous deux.

Décision : Assurez-vous que le port 25 n’autorise pas le relay non authentifié, et que le 587 impose auth/TLS. Les mauvaises configurations ici deviennent des « 550 rejected » ailleurs après listing.

Note opérationnelle : chaque commande ci‑dessus est conçue pour répondre à une décision. Si une vérification ne change pas votre prochain mouvement, c’est de la trivia.
La trivia est la façon dont vous brûlez le jour pendant que le mail part en fumée.

Trois mini-récits d’entreprise tirés du terrain

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

Une entreprise de taille moyenne a migré son envoi sortant depuis une ancienne VM vers une nouvelle instance cloud brillante. Même nom d’hôte, même config Postfix,
mêmes clés DKIM. Ils ont effectué le changement pendant une fenêtre calme et se sont envoyé un mail de célébration pour valider. Il est arrivé.
Ils ont clôturé la modification.

Lundi matin, les e-mails de facturation vers un gros client ont commencé à rebondir avec 550 5.7.1 rejected. En interne, tout « semblait correct ».
Les logs montraient des livraisons réussies vers des comptes Gmail personnels. L’équipe a supposé que la passerelle mail du client était en panne,
parce que bien sûr elle l’était. Ils ont ouvert un ticket chez le client et ont attendu.

Le client a répondu : « Vos mails échouent SPF. » Ça semblait impossible—l’enregistrement SPF n’avait pas changé. La mauvaise hypothèse était subtile :
ils supposaient que l’IP sortante était celle de l’instance. En réalité, le trafic sortant était NATé via une IP d’egress différente dans le réseau cloud.
SPF autorisait toujours l’ancienne IP, pas le NAT.

La correction a pris dix minutes : mettre à jour SPF avec l’IP d’egress réelle et ajouter un second include pour leur nouveau chemin de relais. Le déblocage a pris plus de temps :
le client avait déjà ajouté un bloc temporaire parce que les réessais répétés ressemblaient à un abus.

Le postmortem fut court et un peu embarrassant. La leçon était franche : mesurez toujours votre IP d’envoi réelle.
« Nous avons déplacé le serveur » n’est pas une modification d’email. « Nous avons changé l’identité IP que le monde voit » l’est.

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

Une autre société a décidé d’« optimiser la délivrabilité » en centralisant tout l’envoi sortant via un MTA à haute capacité.
La logique était propre : un endroit pour gérer DKIM, un endroit pour tuner TLS, une IP à réchauffer. Ils ont même acheté une IP « premium » auprès de leur fournisseur.
Quelqu’un a fait une diapositive. Il y avait des flèches.

Ça a fonctionné—jusqu’à ce que le marketing lance une campagne avec un nouveau domaine de tracking et un template HTML fortement compressé.
Le MTA centralisé a subitement porté les reçus transactionnels et la campagne. Les taux de plaintes ont augmenté.
Quelques destinataires d’entreprise ont commencé à rejeter par blocs de politique 550 ; puis les domaines de la famille Microsoft ont commencé à limiter ; puis les listings RBL ont démarré.

Le retour de bâton n’était pas que le marketing ait envoyé du mail. C’était que l’organisation avait concentré plusieurs profils de risque dans un même seau de réputation.
Les destinataires ne se soucient pas qu’un message soit une réinitialisation de mot de passe et l’autre un « One weird trick ». Ils voient la même IP, le même comportement,
et vous notent globalement.

La récupération a exigé la séparation des flux : IP distinctes et parfois domaines distincts pour bulk vs transactionnel, plus des limites de débit strictes et une hygiène de contenu.
Ils ont aussi dû reconstruire la confiance auprès des destinataires—lentement—car la réputation se rétablit à la vitesse d’un comportement propre et soutenu, pas à la vitesse de la panique.

L’optimisation est excellente. Unifier le rayon d’explosion ne l’est pas. Simplifiez les systèmes, mais pas au point de rendre la défaillance catastrophique.

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

Une entreprise proche du secteur de la santé avait une pratique ennuyeuse : chaque changement d’envoi comprenait un point de checklist pour envoyer des messages de test
à un petit ensemble de boîtes semences hébergées chez différents fournisseurs et domaines. Ils gardaient les en-têtes. Ils suivaient les résultats d’authentification. Personne n’a été promu pour ça.

Une nuit, leur fournisseur DNS a eu une panne partielle qui n’a pas mis les domaines hors service, mais a causé des échecs intermittents de recherche TXT dans certaines régions.
Les recherches SPF ont commencé à retourner des timeouts. Certains destinataires ont traité cela comme un permerror et ont rejeté avec 550 5.7.1.
D’autres ont accepté mais les ont dégradés. C’était confus et inconsistant.

Les tests semences se sont allumés en quelques minutes : DKIM passait, mais SPF était instable. L’on-call n’a pas deviné. Ils ont comparé les résolveurs, confirmé le problème DNS,
et basculé vers un fournisseur DNS secondaire qu’ils avaient mis en place des mois plus tôt parce que quelqu’un avait insisté que c’était une « bonne pratique ».

Le flux de mail s’est stabilisé avant que les clients ne s’en aperçoivent. La seule partie dramatique fut le fil de discussion où les gens demandaient comment ils l’avaient détecté si vite.
La réponse était profondément peu sexy : ils avaient une base et ils la surveillaient.

Blague #2 : Le meilleur outil de délivrabilité est un rappel de calendrier pour éviter les trucs créatifs le vendredi après-midi.

Erreurs courantes : symptôme → cause racine → correctif

1) « 550 5.7.1 rejected » seulement chez un gros client

Symptôme : Gmail fonctionne, petits domaines fonctionnent, une entreprise rejette tout.

Cause racine : Le client a une politique d’autorisation/deni, des règles de passerelle entrante strictes, ou exige TLS/alignement ; votre IP/domaine peut être bloqué localement.

Correctif : Obtenez le texte de rejet exact ; demandez au client la raison de politique ; fournissez vos IP d’envoi, le domaine envelope-from et le domaine DKIM d= ; implémentez rDNS et HELO cohérent ; demandez un allowlist seulement après que l’authentification est correcte.

2) « 550 5.1.1 user unknown » après une migration

Symptôme : Des adresses auparavant valides rebondissent comme inconnues.

Cause racine : Vous livrez au mauvais MX (cache DNS obsolète, domaine mal saisi, ou domaine destinataire a changé de locataire) ; votre ancienne route est morte.

Correctif : Vérifiez les enregistrements MX, confirmez que le domaine est correct, et validez que le destinataire existe via le processus de l’annuaire du destinataire (ne devinez pas). Arrêtez les tempêtes de réessai.

3) « 550 reverse DNS required »

Symptôme : Rejet immédiat tôt dans la conversation SMTP.

Cause racine : Pas d’enregistrement PTR, PTR générique, ou mismatch entre PTR et A record ; HELO ne correspond ni à l’un ni à l’autre.

Correctif : Configurez un PTR vers un nom d’hôte stable ; assurez-vous que ce nom résout vers la même IP ; configurez Postfix/votre MTA HELO en conséquence.

4) « 550 relay denied » quand les applications envoient du mail

Symptôme : Les applications ne peuvent pas envoyer ; les humains oui.

Cause racine : L’app se connecte au port 25 sans auth ; la soumission devrait se faire sur 587 avec SMTP AUTH et STARTTLS ; ou vos restrictions de relais sont correctes et l’app s’attend à un relais ouvert (ce qu’elle ne devrait pas faire).

Correctif : Pointez les applis vers le port de soumission 587, activez l’auth, restreignez par IP quand approprié, et confirmez que l’app utilise un envelope-from valide.

5) « 550 5.7.26 DMARC reject » sur du mail transféré

Symptôme : Le transfert casse ; la livraison directe fonctionne.

Cause racine : SPF échoue chez les forwarders (car le forwarding change l’IP d’envoi) et DKIM est absent ou cassé ; la politique DMARC est reject et l’alignement échoue.

Correctif : Assurez-vous que la signature DKIM survit au transit (ne réécrivez pas les en-têtes signés) ; envisagez d’utiliser ARC sur les forwarders que vous contrôlez ; pour les forwarders tiers, concentrez-vous sur l’alignement DKIM.

6) « 550 message content rejected » après avoir ajouté un nouveau tracker de liens

Symptôme : Seuls les templates marketing échouent ; le transactionnel fonctionne.

Cause racine : La réputation URL/domaine du domaine de tracking est mauvaise, ou le contenu déclenche des heuristiques de phishing ; parfois les pièces jointes sont bloquées.

Correctif : Supprimez ou remplacez les URL suspectes ; assurez-vous que le domaine de tracking a un DNS et une réputation corrects ; évitez les raccourcisseurs d’URL ; gardez le HTML simple ; séparez les flux/IP.

7) « 550 rejected » apparu juste après avoir durci SPF

Symptôme : Vous avez changé SPF en -all et maintenant ça rebondit.

Cause racine : Vous avez oublié un expéditeur légitime (helpdesk, CRM, paie, imprimantes, ancien serveur d’appli) ou dépassé les limites de recherche DNS causant un permerror.

Correctif : Inventoriez les expéditeurs, réduisez les includes, aplatissez SPF si nécessaire, et validez chaque flux. N’utilisez pas SPF comme arme contre votre propre parc.

8) 550 aléatoires avec « policy restrictions » chez de nombreux destinataires

Symptôme : Tout ne tombe pas ; il y a du bruit.

Cause racine : Dégradation de réputation plus scoring incohérent des destinataires ; ou problèmes DNS/TLS intermittents provoquant des refus chez certains destinataires.

Correctif : Vérifiez les pics de volume, comptes compromis, fiabilité DNS, erreurs de handshake TLS et santé de la file ; stabilisez ensuite le comportement et réchauffez progressivement.

La méta‑défaillance dans la plupart de ces cas : les équipes traitent les rejets d’e-mails comme « le problème de l’autre côté ».
Parfois c’est vrai. La plupart du temps, c’est chez vous, simplement exprimé par le serveur de quelqu’un d’autre.

Listes de contrôle / plan étape par étape pour se débloquer

Étape 0 : Arrêtez d’aggraver la situation

• Mettez immédiatement en pause les campagnes bulk/marketing si vous suspectez un problème de réputation.
• Limitez le débit sortant si vous voyez des pics ou des expéditeurs inconnus.
• Désactivez les comptes compromis ou faites tourner les identifiants avant de « travailler la délivrabilité ».
• Conservez les preuves : sauvegardez les messages de bounce, les transcriptions SMTP et les en-têtes.

Étape 1 : Identifiez le flux en échec

• Est‑ce transactionnel (réinitialisation de mot de passe, factures) ou bulk (newsletters) ?
• Est‑ce une seule adresse expéditrice, un seul domaine, ou tout l’envoi sortant ?
• Est‑ce un seul domaine destinataire ou plusieurs ?

Si vous ne pouvez pas séparer les flux, faites‑le maintenant. Ce n’est pas « agréable à avoir ». C’est le contrôle du rayon d’explosion.

Étape 2 : Corrigez les bases d’identité (le « faites‑ça avant de supplier pour un delisting »)

• Corrigez SPF pour les IP d’egress et les vendors réels.
• Activez la signature DKIM de manière cohérente pour le domaine From visible (ou un sous‑domaine aligné).
• Publiez DMARC avec une politique que vous pouvez supporter (commencez par p=none si vous êtes aveugle ; montez quand vous êtes aligné).
• Configurez rDNS/PTR et faites correspondre HELO/EHLO à un nom résoluble.
• Assurez‑vous que TLS fonctionne ; certains destinataires imposent STARTTLS et des suites modernes.

Étape 3 : Confirmez que votre comportement ne ressemble pas à un botnet

• Maintenez des taux d’envoi stables ; évitez des pics soudains de 10x.
• Utilisez des envelope-from et des domaines From cohérents ; ne faites pas tourner les identités pour « échapper aux blocs ». Ça crie abus.
• Mettez en place le traitement des rebonds et supprimez les adresses invalides.
• Faites fonctionner la désinscription pour les mails bulk. Oui, ça influence les rejets.

Étape 4 : Actions ciblées de déblocage

• Si une RBL vous liste : identifiez pourquoi (compromis, relais ouvert, schémas de plaintes), corrigez la cause, puis demandez le delisting.
• Si une entreprise vous bloque : fournissez aux admins leurs IP d’envoi, le domaine DKIM et des exemples ; demandez un allowlist temporaire uniquement après corrections.
• Si des providers grand public vous bloquent : concentrez‑vous sur l’authentification, la réputation et le contenu ; réchauffez lentement et surveillez les bounces/plaintes.

Étape 5 : Prouvez la correction avec des tests contrôlés

• Envoyez un e‑mail minimal en texte brut (sans liens, sans pièces jointes) au domaine en échec. S’il passe, le contenu est suspect.
• Envoyez un template transactionnel typique ; puis un template marketing.
• Comparez les en‑têtes et les résultats d’authentification entre les messages.

Étape 6 : Mettez en place une surveillance ennuyeuse pour ne pas répéter cela le trimestre prochain

• Alertez sur le taux de rebond, deferrals et rejets par domaine.
• Suivez les taux de réussite/échec d’authentification par flux (SPF/DKIM/DMARC).
• Gardez un inventaire des expéditeurs légitimes et des vendors.
• La réputation n’a pas besoin de panique quotidienne, mais elle a besoin d’une attention hebdomadaire.

Une citation pour vous garder honnête :

« L’espoir n’est pas une stratégie. » — maxime générale d’ingénierie des opérations (idée paraphrasée)

La délivrabilité n’est pas de la magie. C’est de l’opération : identité, hygiène et réputation, en changement continu.

FAQ

1) « 550 rejected » est‑il toujours de ma faute ?

Non. Parfois le destinataire applique une politique stricte (blocage d’expéditeurs externes, allowlist-only, passerelle mal configurée).
Mais supposez que c’est de votre faute jusqu’à preuve du contraire avec des vérifications d’authentification et un comportement propre. Cet état d’esprit résout les incidents plus vite.

2) Quelle est la différence entre 550 5.7.1 et 550 5.1.1 ?

5.1.1 est généralement « mauvais destinataire » (utilisateur inconnu). 5.7.1 est « politique/sécurité ».
Le premier est souvent un problème d’annuaire/données. Le second est identité/réputation/contenu/politique.

3) Si SPF passe, puis‑je ignorer DKIM et DMARC ?

Vous ne pouvez pas les ignorer si la livraison cohérente vous importe. SPF casse lors du forwarding et chez certains relais.
DKIM fournit un signal d’identité durable. DMARC lie le tout et donne aux destinataires une politique claire et à vous des rapports.

4) Pourquoi cela a‑t‑il commencé après notre migration vers un nouveau cloud provider ?

Nouvelle réputation d’IP, nouvelle identité egress/NAT, rDNS manquant, et différences TLS subtiles sont des déclencheurs courants.
Les IP cloud commencent souvent avec une réputation neutre au mieux. Réchauffez lentement et soignez l’authentification.

5) Puis‑je simplement changer d’IP pour contourner un bloc ?

Parfois ça marche brièvement. C’est aussi la façon dont vous habituez les destinataires à se méfier de tout votre domaine.
Corrigez la cause racine d’abord. Si vous devez faire tourner des IP pour la continuité, faites‑le en transparence et stabilisez immédiatement le comportement.

6) Et si nous sommes listés sur une RBL mais que nous n’envoyons pas de spam ?

Les RBL listent des comportements, pas votre auto‑image. Vous pouvez avoir une boîte compromise, un port de soumission exposé, une appli web vulnérable qui envoie du mail,
ou un vendor qui utilise mal votre domaine. Identifiez la source d’envoi et stoppez‑la. Puis demandez le delisting.

7) Nos emails sont rejetés seulement quand ils contiennent des pièces jointes. Pourquoi ?

Les pièces jointes déclenchent l’antivirus, des politiques de type de fichier et des limites de taille. Certaines passerelles rejettent certaines extensions ou des archives protégées par mot de passe.
Testez avec un e‑mail en texte brut ; puis remettez la pièce jointe. Si elle est nécessaire, utilisez des formats approuvés et envisagez des liens de téléchargement sécurisés (sur des domaines réputés).

8) Le rDNS compte vraiment en 2026 ?

Oui. Pas universellement, mais suffisamment pour que vous trébuchiez sur des passerelles d’entreprise et des piles de politique anciennes.
Un PTR manquant est une raison à faible effort de vous méfier, et les destinataires aiment les raisons à faible effort.

9) Pourquoi nous livrons vers Gmail mais pas vers des domaines hébergés par Microsoft ?

Différents modèles de scoring, tolérances différentes pour les signaux limites, et comportements de throttling distincts.
Traitez‑le comme un indice : comparez les résultats d’authentification, TLS et les patterns d’envoi. Souvent le filtrage Microsoft est moins indulgent face aux changements soudains de volume.

10) Combien de temps pour récupérer la réputation après un bloc ?

Si c’est une mauvaise config d’authentification simple, cela peut prendre de quelques minutes à quelques heures après correction. Si c’est une dégradation de réputation due à un abus ou un fort taux de plaintes,
comptez des jours à des semaines d’envois propres et réguliers. On ne négocie pas avec les algorithmes ; on les surpasse par la durée.

Conclusion : prochaines étapes à exécuter aujourd’hui

« 550 rejected » signifie que le destinataire vous dit qu’il ne fait pas confiance à ce message, à cet expéditeur ou à ce comportement. Votre chemin le plus rapide est
pas une errance aléatoire dans les paramètres. C’est un triage discipliné et des corrections ciblées.

1. Capturez le rejet exact (code amélioré + texte) et déterminez si c’est identité, réputation ou routage.
2. Validez les fondamentaux : vraie IP d’envoi, SPF pass, DKIM présent/valide, alignement DMARC, rDNS, HELO, TLS.
3. Arrêtez l’hémorragie : pause bulk, limitation de débit, chasse aux comptes compromis, nettoyage des listes.
4. Prouvez la correction avec des tests contrôlés isolant contenu vs politique vs destinataire.
5. Évitez la répétition en séparant les flux et en surveillant les patterns de rejet par domaine et les résultats d’authentification.

La délivrabilité n’est pas de la magie. C’est de l’opération : identité, hygiène et réputation, sous changement continu.
Traitez‑la comme de la production, et elle se comporte comme de la production. Traitez‑la comme un service public, et elle finira par vous facturer en incidents.