Courriel : « 554 spam detected » — nettoyer la réputation sans perdre des semaines

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

SMTP 554 est une erreur permanente. En pratique, cela signifie que le serveur récepteur a jugé que votre message ne mérite pas d’être accepté — souvent pour des raisons de filtrage anti-spam, d’échecs d’authentification, de contrôles de politique, de réputation, de patterns de contenu ou d’anomalies de trafic. « Spam detected » est une formulation lisible par l’humain ; la raison sous-jacente peut aller d’une signature DKIM mal alignée à un hôte compromis envoyant vers des adresses invalides.

554 n’est pas une cause racine, c’est un verdict

Pensez à 554 comme à « HTTP 403 Forbidden ». Il vous dit que la requête a été refusée, pas si c’est vos identifiants, la réputation IP ou votre comportement qui a déclenché le refus. Certains fournisseurs détaillent plus dans le code étendu (comme 5.7.1) et la chaîne de texte. Beaucoup ne le font pas. Votre travail est de corréler leur rejet avec vos preuves : journaux, DNS, en-têtes, débits, rebonds et rapports utilisateurs.

Ce que ce n’est pas

• Ce n’est pas « la boîte du destinataire est pleine » (c’est généralement 552 ou un report 4xx).
• Ce n’est pas un pic transitoire de file que vous pouvez « réessayer à l’infini ». Retenter des 5xx comme si c’était des 4xx transforme un problème de délivrabilité en DDoS auto-infligé sur votre réputation.
• Ce n’est pas corrigé en achetant un nouveau domaine à chaque fois. Vous pouvez le faire, mais vos clients vous verront comme la boîte qui change l’ID d’appel chaque semaine.

Et une blague, parce qu’on va en avoir pour un moment : la délivrabilité, c’est comme s’hydrater — si vous attendez d’avoir soif, vous avez déjà foiré.

Mode opératoire de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Voici la séquence « j’ai 30 minutes pour arrêter l’hémorragie ». Ne faites pas d’improvisation. Ne commencez pas par « réécrire le template de mail ». Commencez par des preuves qui séparent identité, réputation et comportement.

Premier point : identifier ce qui est rejeté (périmètre)

• Est-ce un seul fournisseur (Gmail seulement, Microsoft seulement), ou tous ?
• Est-ce un seul flux (marketing en masse) ou tout (transactionnel comme les resets) ?
• Est-ce une seule IP (nouveau nœud) ou tout le pool sortant ?
• Est-ce un seul domaine (domaine vanity récent) ou tous les domaines d’envoi ?

Décision : si c’est un fournisseur, concentrez-vous sur la politique et les signaux de réputation de ce fournisseur. Si c’est tout le monde, supposez que votre authentification ou votre hôte d’envoi se comporte mal.

Deuxième point : vérifier l’alignement d’authentification (SPF, DKIM, DMARC)

• Confirmez que le domaine visible dans le From: est aligné avec l’identité SPF ou DKIM (DMARC). Le désalignement est la façon la plus rapide de passer pour un usurpateur.
• Confirmez que le DNS est correct, public et pas obsolète à cause d’un split-horizon.

Décision : si l’alignement échoue, corrigez le DNS et la signature avant toute autre action. Chauffer une identité cassée n’enseigne qu’aux filtres à vous méfier plus vite.

Troisième point : vérifier les signaux de réputation & l’hygiène des listes

• Recherchez des pics de volume, des pics de rebonds et des motifs de destinataires spammy (comptes role, listes récoltées, domaines aléatoires).
• Vérifiez les hits sur les blocklists et si votre IP a un reverse DNS propre et un HELO/EHLO stable.

Décision : si les rebonds sont élevés ou si vous êtes sur une blocklist majeure, suspendez le trafic en masse et isolez le mail transactionnel sur le chemin le plus propre possible.

Quatrième point : ensuite seulement, regardez le contenu

Le contenu peut compter, surtout pour les templates ressemblant au phishing, les raccourcisseurs d’URL et les MIME étranges. Mais le contenu n’est généralement pas la première dominos. Traitez-le comme un multiplicateur, pas comme la racine.

Faits intéressants & historique : pourquoi les fournisseurs de boîtes mail agissent ainsi

• Fait 1 : SMTP a précédé les contrôles modernes contre les abus ; au début le courriel partait du principe d’un réseau bienveillant. L’anti-spam a été greffé plus tard sous forme de moteurs de politique et de systèmes de réputation.
• Fait 2 : Les premières blocklists basées sur DNS sont apparues fin des années 1990 en réaction aux relais ouverts — des systèmes qui relaiaient le courrier pour n’importe qui.
• Fait 3 : SPF a gagné en adoption au début des années 2000 pour dire « ces IP peuvent envoyer pour mon domaine », mais il n’authentifiait jamais le contenu du message — seulement le chemin de l’enveloppe.
• Fait 4 : L’idée majeure de DKIM était la signature cryptographique au niveau domaine afin que les fournisseurs puissent construire une réputation sur une identité stable même lorsque les IP changent.
• Fait 5 : DMARC (vers 2012) a forcé l’industrie à se soucier de l’alignement — pas seulement « SPF passé quelque part », mais « SPF/DKIM passés pour le même domaine visible par les utilisateurs ».
• Fait 6 : Beaucoup de fournisseurs considèrent les signalements de spam comme des signaux plus forts que les rebonds. Un clic « Signaler comme spam » peut compenser des dizaines de livraisons.
• Fait 7 : Gmail et Microsoft utilisent des modèles comportementaux massifs : patterns d’envoi, engagement, taux de plainte et réputation à travers domaines et plages IP liées.
• Fait 8 : La délivrabilité IPv6 reste inégale ; certains récepteurs sont plus stricts car l’abus est plus facile à scaler quand l’espace d’adresses est quasi infini.

Les véritables modes de défaillance derrière le 554

1) L’authentification est techniquement « présente » mais opérationnellement cassée

Les incidents les plus douloureux sont ceux où SPF existe, DKIM existe, DMARC existe… et vous échouez quand même l’alignement à cause d’un petit mismatch : mauvais sélecteur, mauvaise canonicalisation, rotation de clé oubliée, chemin de forwarding, ou un fournisseur tiers qui envoie en votre nom sans être autorisé.

2) La réputation s’est effondrée à cause du comportement de trafic, pas du contenu

Les fournisseurs détestent les surprises. Une nouvelle IP qui passe de 0 à 50k/jour ressemble à un botnet. Une IP stable qui commence soudainement à atteindre beaucoup de destinataires invalides ressemble à de l’achat de listes. Un hôte qui retry agressivement des 5xx donne l’impression que vous ne respectez pas la politique ou que vous êtes cassé.

3) Backscatter et rétorsion dus à des rebonds mal configurés

Si votre système génère des avis de non-distribution (NDR) vers des expéditeurs usurpés, vous envoyez du spam involontairement. Les récepteurs le remarquent. Ils ne sont pas contents.

4) Mismatch d’identité d’infrastructure (PTR, HELO, posture TLS)

Les serveurs mail sont jugés comme des voyageurs suspects : nom, papiers et histoire doivent correspondre. Si votre PTR indique une chose, votre HELO une autre, et votre certificat ressemble à un bricolage amateur, vous subirez plus de scrutation.

5) Compromis : une machine, un identifiant, un script « utile »

Classique : un serveur web est compromis, l’attaquant envoie du mail via localhost ou des identifiants SMTP volés, et votre domaine devient la newsletter la moins amusante du monde. Vous verrez des pics, des destinations étranges et des rejets furieux. Traitez cela d’abord comme un incident de sécurité.

Deuxième blague (et dernière, selon les règles) : rien n’augmente votre aura « spammy » comme envoyer 30 000 réinitialisations de mot de passe que personne n’a demandées.

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

Ci-dessous des tâches pratiques à lancer sur un hôte MTA Linux typique (exemples Postfix, mais la plupart des concepts s’appliquent). Chaque tâche inclut : commande, ce que signifie la sortie, et la décision à prendre.

Task 1: Confirm the exact rejection text and enhanced status code

cr0x@server:~$ sudo grep -E "status=bounced|status=deferred" /var/log/mail.log | tail -n 20
Jan 03 10:14:12 mx1 postfix/smtp[21844]: 3A1B012345: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0.0/0.4/0.7, dsn=5.7.1, status=bounced (host gmail-smtp-in.l.google.com[142.250.102.26] said: 554 5.7.1 Message rejected as spam (in reply to end of DATA command))

Sens : C’est un échec ferme (5.7.1 politique/spam). Le « end of DATA » indique qu’il a accepté l’enveloppe SMTP puis rejeté après évaluation du contenu/politique.

Décision : Arrêtez les réessais pour ces destinataires ; basculez vers les contrôles d’authentification/réputation et isolez les flux.

Task 2: Count rejections by destination domain (find scope fast)

cr0x@server:~$ sudo awk -F'to=<' '/status=bounced|status=deferred/ {print $2}' /var/log/mail.log | awk -F'>' '{print $1}' | awk -F'@' '{print $2}' | sort | uniq -c | sort -nr | head
  412 gmail.com
  133 outlook.com
   58 yahoo.com
   21 icloud.com
    9 example-corp.com

Sens : Une concentration sur de gros fournisseurs suggère des problèmes d’authentification/réputation. Si c’était surtout un domaine d’entreprise, vous auriez peut-être une politique gateway spécifique.

Décision : Priorisez la remédiation pour Gmail/Microsoft et validez les signaux d’identité globaux.

Task 3: Check outbound volume trend (is this a spike?)

cr0x@server:~$ sudo grep "postfix/qmgr" /var/log/mail.log | awk '{print $1,$2,$3}' | uniq -c | tail -n 5
   98 Jan 03 10:10:01
  101 Jan 03 10:11:01
  544 Jan 03 10:12:01
  610 Jan 03 10:13:01
  588 Jan 03 10:14:01

Sens : Un saut soudain de ~100/min à ~600/min est un risque pour la réputation, surtout sur une IP neuve.

Décision : Limitez le débit maintenant ; si vous devez livrer du mail critique, isolez-le dans une voie plus lente avec des listes propres.

Task 4: Verify the public IP you’re actually sending from

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

Sens : Confirme l’IP de sortie NAT. Beaucoup d’équipes déboguent une mauvaise adresse parce que l’egress cloud diffère de l’IP de l’instance.

Décision : Utilisez cette IP pour le reverse DNS, les vérifs blocklist et les outils postmaster des fournisseurs.

Task 5: Validate reverse DNS (PTR) matches your sending identity

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

Sens : Vous avez un PTR. Bien. Assurez-vous maintenant que le DNS direct pour ce nom pointe vers la même IP (tâche suivante).

Décision : Si le PTR est manquant ou générique, corrigez-le auprès de votre fournisseur. L’absence de PTR n’est pas toujours fatale, mais c’est un multiplicateur fréquent « spammy ».

Task 6: Confirm forward-confirmed reverse DNS (FCrDNS)

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

Sens : PTR et enregistrement A concordent. Cette cohérence réduit la suspicion et évite certains heuristiques côté récepteur.

Décision : Si ça ne concorde pas, alignez-les. Évitez un PTR vers un nom et un HELO vers un autre.

Task 7: Check your HELO/EHLO name (it should be real and resolvable)

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

Sens : Votre nom HELO est stable et correspond à l’identité DNS. Si HELO est « localhost » ou un nom interne aléatoire, certains récepteurs vous pénaliseront.

Décision : Définissez myhostname sur le nom PTR et assurez-vous qu’il se résout.

Task 8: Confirm SPF record for the visible From domain

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g'
v=spf1 ip4:203.0.113.45 include:_spf.mailvendor.example -all

Sens : SPF autorise explicitement votre IP d’envoi et votre fournisseur. Le -all est strict (bon si correct).

Décision : Si votre IP n’est pas autorisée, ajoutez-la (ou corrigez le routage pour envoyer depuis une infrastructure autorisée). Ne laissez pas SPF en ~all par peur — faites-le correctement.

Task 9: Check DKIM public key record exists (selector)

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

Sens : Le sélecteur DKIM s1 est publié. Si vous avez tourné les clés et oublié le DNS, vous aurez des échecs DKIM silencieux.

Décision : Si absent, publiez la clé correcte et assurez-vous que votre MTA signe avec le même sélecteur.

Task 10: Inspect a delivered message header for SPF/DKIM/DMARC results

cr0x@server:~$ grep -E "Authentication-Results|Received-SPF|DKIM-Signature" -n sample-headers.txt | head -n 20
12: Authentication-Results: mx.google.com;
13:        dkim=pass header.i=@example.com header.s=s1 header.b=abc123;
14:        spf=pass (google.com: domain of bounce@example.com designates 203.0.113.45 as permitted sender) smtp.mailfrom=bounce@example.com;
15:        dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
28: DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; c=relaxed/relaxed; ...

Sens : C’est le standard d’or : SPF pass, DKIM pass, DMARC pass. Si vous voyez dmarc=fail alors que SPF/DKIM passent, l’alignement est cassé (commun avec des envois tiers utilisant leur propre domaine de rebond).

Décision : Si DMARC échoue, corrigez l’alignement : assurez-vous que le d= de DKIM correspond au domaine From, ou que le domaine MAIL FROM SPF est aligné.

Task 11: Check DMARC policy and reporting addresses

cr0x@server:~$ dig +short TXT _dmarc.example.com | sed 's/"//g'
v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=s

Sens : L’alignement strict (adkim=s, aspf=s) est excellent si vous êtes cohérent. C’est douloureux si vous avez des systèmes legacy envoyant depuis des sous-domaines ou des fournisseurs non alignés.

Décision : Si vous échouez à cause d’un alignement strict, soit corrigez les expéditeurs pour qu’ils s’alignent, soit assouplissez temporairement en r pendant la migration. Ne laissez pas ça relaxé indéfiniment.

Task 12: Verify the TLS posture presented by your SMTP server

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.mail.example.com:25 -servername mx1.mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mx1.mail.example.com
issuer=CN = R3, O = Let's Encrypt, C = US
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar 10 23:59:59 2026 GMT

Sens : Un certificat valide avec un CN et des dates cohérentes. Certains récepteurs notent la qualité TLS. Plus important, un TLS cassé peut provoquer un downgrade ou des échecs étranges.

Décision : Si expiré ou non conforme, corrigez immédiatement — c’est de l’hygiène de réputation facile à régler.

Task 13: Detect backscatter (are you sending bounces to forged senders?)

cr0x@server:~$ sudo grep -E "postfix/bounce|postfix/local" /var/log/mail.log | grep -i "Undelivered Mail Returned to Sender" | tail -n 10
Jan 03 10:08:44 mx1 postfix/bounce[21201]: 9FEEA12345: sender non-delivery notification: 0ABCD12345
Jan 03 10:08:44 mx1 postfix/local[21202]: 0ABCD12345: to=<random.person@foreign-domain.tld>, relay=local, delay=0.1, dsn=2.0.0, status=sent (delivered to mailbox)

Sens : Vous générez des NDRs. La question clé : ces NDRs vont-ils à des expéditeurs légitimes ou à des adresses usurpées ? Si votre système a accepté du courrier qu’il n’aurait pas dû (open relay, pas de validation de destinataire), vous produirez du backscatter.

Décision : Si backscatter présent, renforcez la politique SMTP entrante et la validation des destinataires. Le backscatter peut déclencher des 554 ailleurs car vous devenez « ce serveur ».

Task 14: Check if your server is an open relay (the fastest way to ruin everything)

cr0x@server:~$ sudo postconf -n | grep -E 'smtpd_recipient_restrictions|mynetworks|smtpd_relay_restrictions'
mynetworks = 127.0.0.0/8 [::1]/128 10.10.0.0/16
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain

Sens : reject_unauth_destination est présent : bien. S’il manque, vous pourriez relayer le courrier pour des tiers.

Décision : Si les restrictions de relais sont incorrectes, corrigez immédiatement et faites tourner tout identifiant exposé. Supposez une compromission jusqu’à preuve du contraire.

Task 15: See the top sending accounts/apps (who is generating mail)

cr0x@server:~$ sudo grep "sasl_username=" /var/log/mail.log | awk -F"sasl_username=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  902 app-prod@example.com
  117 crm-sync@example.com
   44 legacy-batch@example.com

Sens : Un principal est responsable de la majorité du trafic. Si ce principal est compromis ou mal configuré, vous avez trouvé l’origine du feu.

Décision : Limitez ou suspendez le plus gros émetteur ; exigez rotation des identifiants et inspectez ses patterns d’envoi.

Task 16: Rate-limit Postfix outbound concurrency (stabilize behavior)

cr0x@server:~$ sudo postconf -e "default_destination_rate_delay = 2s"
cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 5"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf -n | grep -E "default_destination_rate_delay|smtp_destination_concurrency_limit"
default_destination_rate_delay = 2s
smtp_destination_concurrency_limit = 5

Sens : Vous avez réduit l’explosivité. Les fournisseurs considèrent souvent qu’un trafic plus lisse est moins suspect, et vous réduisez les dégâts collatéraux pendant la réparation de la réputation.

Décision : Maintenez les limites pendant la remédiation. Ensuite, augmentez prudemment selon les taux d’acceptation et de plainte.

Trois mini-récits d’entreprise (comment les équipes se font piéger)

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

Une entreprise SaaS de taille moyenne a transféré l’envoi sortant d’un prestataire géré vers « notre propre Postfix » pour économiser. L’hypothèse était simple et sincère : « Le mail, c’est juste SMTP ; s’il quitte notre serveur, c’est bon. » Ils ont mis à jour le DNS pour SPF. Ils ont même publié une clé DKIM. Puis les 554 sont arrivés — d’abord sur les resets, puis les factures, puis l’onboarding.

L’équipe on-call a chassé le contenu. Ils ont retiré des liens. Ils ont réécrit des sujets. Ils ont rendu les e-mails plus laids, ce qui est un exploit. Les rejets ont continué. Le vrai problème vivait dans la plomberie invisible : ils envoyaient avec From: example.com, mais leur domaine de rebond (enveloppe MAIL FROM) était un sous-domaine fournisseur utilisé par un système legacy. SPF passait pour le domaine de rebond, DKIM passait pour un domaine différent, et DMARC échouait l’alignement. Pour les gros fournisseurs, cela ressemblait à de l’usurpation de marque déguisée.

Une fois qu’ils ont extrait des en-têtes de quelques messages acceptés et les ont comparés au flux rejeté, le motif est apparu : la plateforme marketing était alignée ; le mailer applicatif ne l’était pas. Ils ont corrigé l’expéditeur d’enveloppe pour qu’il s’aligne avec le domaine From, re-signé DKIM avec le bon d=, et n’ont rendu DMARC strict qu’après vérification de tous les expéditeurs.

L’impact réputationnel n’a pas disparu instantanément, mais la fuite s’est arrêtée en un jour. La leçon : la délivrabilité n’est pas « le mail quitte le serveur ». C’est « le mail arrive avec une identité cohérente ».

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

Un retailer avait une réputation solide et une IP sortante stable et ennuyeuse. Puis est arrivé le Black Friday et quelqu’un a fait l’optimisation qui semblait sensée : augmenter la concurrence et supprimer les délais pour « vider la file plus vite ». Le MTA est passé d’un flux constant à une lance à incendie. Les campagnes se sont terminées plus vite. Tout le monde a applaudi.

En quelques heures, les domaines Microsoft ont commencé à répondre avec des 554 et variantes 5.7.1. Gmail a différé puis rejeté. Les tableaux de bord internes affichaient « envoyé avec succès » parce que l’application suivait seulement la remise au MTA. Les clients n’ont pas reçu les reçus. Le support s’est enflammé. Les finances l’ont remarqué avant l’ingénierie, ce qui est toujours une manière amusante de commencer la journée.

Le vrai dommage n’était pas seulement le volume : c’était la forme. Les fournisseurs ont vu un changement soudain de comportement : même expéditeur, même famille de contenu, mais débit et concurrence radicalement différents. Leurs modèles l’ont traité comme un expéditeur compromis essayant de tout balancer avant d’être arrêté. L’entreprise avait accidentellement simulé un attaquant.

Revenir en arrière sur la concurrence a aidé, mais la récupération de réputation a pris plus de temps parce que l’impulsion d’envoi a déclenché des pics de plaintes (« pourquoi je reçois autant de mails d’un coup ?»). La correction a été sans glamour : rétablir les limites de débit, segmenter le trafic par importance, et planifier les vagues marketing pour qu’elles se comportent comme un système mature, pas comme un stagiaire paniqué avec un mégaphone.

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

Une société de paiements utilisait deux chemins sortants : un pour le marketing et un pour les événements transactionnels. Ça semblait redondant. Ça coûtait un peu plus. Ça a aussi évité une catégorie entière d’incidents.

Un après-midi, une intégration CRM a importé une liste sale. Les rebonds ont grimpé, et en quelques heures l’IP marketing a commencé à être bloquée. Le flux transactionnel — réinitialisations, reçus, avis de rétrofacturation — continuait d’être délivré parce qu’il utilisait une IP différente, un expéditeur d’enveloppe distinct et une allowlist stricte des systèmes internes pouvant soumettre du mail.

Parce qu’ils étaient disciplinés, ils avaient aussi des rapports DMARC envoyés à une boîte surveillée et un petit script qui résumait les taux pass/failed. L’équipe a repéré une augmentation des mails mal alignés tôt et a mis en pause l’intégration avant que les boucles de rétroaction fournisseurs n’explosent. Ils ont nettoyé la liste, corrigé le chemin de soumission de l’intégration, et ont repris selon un calendrier de warmup.

Personne n’a écrit un postmortem viral. C’est le but. La pratique était ennuyeuse, correcte et silencieusement rentable.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: 554 only at Gmail, everything else mostly OK

Cause racine : Gmail est particulièrement sensible à la réputation de domaine, à l’engagement et à l’alignement. Souvent c’est un problème de warmup d’IP/domaine ou une mauvaise hygiène de liste.

Correction : Ralentissez les envois, segmentez vers les destinataires les plus engagés en premier, vérifiez l’alignement DMARC, retirez les adresses dormantes/non vérifiées et gardez le trafic transactionnel propre et stable.

2) Symptom: 554 starts right after moving to a new server/IP

Cause racine : Réputation IP froide. Les fournisseurs n’ont pas d’historique positif pour vous, et votre trafic ressemble à un expéditeur en masse ou à une machine compromise.

Correction : Chauffer : commencez par un faible volume, destinataires de qualité et engagés, montée progressive, identité stable (PTR/HELO/TLS), et évitez les pics soudains.

3) Symptom: SPF passes but DMARC fails in headers

Cause racine : Le SPF passe pour le domaine de l’enveloppe sender, pas aligné avec le domaine From ; ou DKIM signe avec un domaine différent.

Correction : Alignez les identités : faites correspondre le d= DKIM au domaine From, ou alignez le domaine MAIL FROM avec le domaine From et assurez-vous que SPF autorise l’IP d’envoi.

4) Symptom: Microsoft domains reject with 554/5.7.1 after a marketing blast

Cause racine : Taux de plainte et trafic en rafale. Microsoft est sensible aux changements soudains et au comportement « type campagne » depuis une infrastructure qui envoie normalement du transactionnel.

Correction : Séparez les flux. N’envoyez pas de marketing depuis l’infrastructure transactionnelle. Implémentez du throttling par domaine et surveillez les signaux de plainte/rebond.

5) Symptom: Many bounces to non-existent recipients, then blocks everywhere

Cause racine : Mauvaise hygiène de liste ou expéditeur compromis qui énumère des adresses. Un fort taux de destinataires invalides est un signal anti-spam puissant.

Correction : Arrêtez d’envoyer aux inconnus. Supprimez immédiatement les hard bounces. Exigez le double opt-in ou des adresses vérifiées pour le bulk. Enquêtez sur une compromission.

6) Symptom: Rejections say “HELO/EHLO” or “hostname” issues

Cause racine : Nom HELO non résolvable, PTR manquant ou mismatch entre HELO et reverse DNS.

Correction : Configurez myhostname sur un nom DNS avec un enregistrement A correspondant à l’IP d’envoi et assurez-vous que le PTR pointe en retour. Gardez-le stable.

7) Symptom: Suddenly you’re “sending spam” but you didn’t change email

Cause racine : Quelqu’un d’autre a changé de comportement : nouvelle intégration, boucle de retry, replay de file ou fuite d’identifiants.

Correction : Identifiez les principaux submitters, bloquez les comptes suspects, faites tourner les identifiants et analysez les journaux mail pour des patterns (destinations, débits, erreurs).

8) Symptom: “554 spam detected” after you enabled a new tracking or link shortener

Cause racine : Réputation d’URL. Certains domaines de redirection sont massivement abusés, et votre contenu hérite de cette mauvaise réputation.

Correction : Utilisez des domaines de tracking brandés avec un DNS/auth solides ; évitez les raccourcisseurs douteux ; assurez-vous que les domaines de landing ont une bonne réputation et TLS.

Listes de contrôle / plan étape par étape (retour en boîte)

Phase 0 : Stopper l’hémorragie (1–2 premières heures)

1. Séparez le mail critique du non-critique. Suspendez le marketing/bulk. Conservez le transactionnel seulement s’il est propre. Si vous ne pouvez pas séparer, coupez tout et utilisez temporairement un prestataire de confiance alternatif.
2. Limitez le débit sortant. Votre objectif est « prévisible, faible taux de plainte » pas « rapide ». Mettez en place des délais par destination et des limites de concurrence.
3. Arrêtez de réessayer les hard bounces. Traitez les 5xx comme terminaux. Retenter les 5xx fait de vous une machine qui n’apprend pas.
4. Confirmez que les signaux d’identité sont cohérents. PTR, HELO, certificat TLS, SPF, DKIM, alignement DMARC. Corrigez les cassures évidentes immédiatement.

Phase 1 : Trier les preuves (même jour)

1. Extraire un échantillon des journaux rejetés et grouper par fournisseur et chaîne de rejet.
2. Récupérer les en-têtes d’un message livré à chaque fournisseur majeur (les comptes seed aident). Comparez les résultats d’auth.
3. Calculer le taux de rebond et la liste des hard bounces. Si vous êtes au-dessus d’un faible pourcentage à un chiffre sur le bulk, assumez des problèmes de liste. Pour le transactionnel, les hard bounces doivent être rares.
4. Identifier les plus gros submitters et chemins applicatifs. Cherchez un seul coupable : job déchaîné, boucle, token compromis, ou fournisseur mal routant le mail.

Phase 2 : Réparer l’identité (1–3 jours, souvent plus vite)

1. Corriger SPF pour qu’il soit exact et minimal. N’autorisez que les vrais expéditeurs. Gardez les recherches DNS sous les limites en taillant les includes imbriqués.
2. Standardiser la signature DKIM. Un ou deux sélecteurs, rotation des clés selon un calendrier, assurer que tous les systèmes signent avec un d= aligné.
3. Utiliser DMARC intentionnellement. Si vous n’en avez pas, commencez par p=none pour le reporting et passez à quarantine/reject après que l’alignement soit validé. Si vous avez déjà p=reject, ne paniquez pas en détendant sauf si nécessaire.
4. Stabiliser l’identité d’infrastructure. rDNS, HELO, IPs de sortie cohérentes et TLS sain.

Phase 3 : Réparer la réputation (jours à semaines, mais vous pouvez accélérer)

1. Chauffez sérieusement. Commencez par des destinataires engagés. Augmentez progressivement le volume. Évitez les pics et les campagnes soudaines.
2. Nettoyez les listes agressivement. Supprimez immédiatement les hard bounces. Retirez les adresses dormantes des envois bulk. Préférez le double opt-in pour les nouvelles inscriptions.
3. Séparez définitivement les flux. Le mail transactionnel ne doit pas partager IP/domaine comportemental avec le marketing. Si vous devez partager un domaine, segmentez au moins par sous-domaine et clés de signature.
4. Instrumentez la délivrabilité comme la production. Suivez les taux d’acceptation, la distribution des raisons de rebond, les résultats par fournisseur et les délais de file. « On l’a envoyé » n’est pas un indicateur de succès.

Phase 4 : Prévenir la récurrence (continu)

1. Gestion du changement pour le courriel. Concurrence, politiques de retry, nouvelles intégrations, changements de templates — ce sont des changements de production. Revoyez-les.
2. Surveillance abus et compromission. Alertez sur anomalies de volume, nouveaux domaines de destination et pics de destinataires invalides.
3. Runbook de rotation de clés. La rotation DKIM doit être routinière, pas un générateur d’incident annuel.

Une citation fiabilité applicable

L’espoir n’est pas une stratégie — idée souvent paraphrasée dans les cercles d’ingénierie et d’exploitation. Appliquez-la aussi au courriel.

FAQ

1) Is “554 spam detected” always about content?

Non. Le contenu peut déclencher des filtres, mais la plupart des événements « soudain 554 » sont d’identité ou de comportement : échec d’alignement, IP froide, pics de rebonds ou trafic en rafale.

2) Should I switch to a new IP immediately?

Seulement si vous pouvez aussi corriger le comportement sous-jacent. Une nouvelle IP avec la même mauvaise liste, le même désalignement ou le même pattern de rafale sera brûlée à nouveau — souvent plus vite.

3) Can I “warm up” by sending to every address I have?

Ce n’est pas du warmup ; c’est de l’incendie de réputation. Le warmup fonctionne quand les destinataires sont réels, engagés et attendent vos mails. Commencez par la meilleure cohorte.

4) What’s the difference between SPF pass and DMARC pass?

SPF pass signifie que l’IP d’envoi est autorisée pour le domaine d’enveloppe sender. DMARC pass signifie que SPF ou DKIM a passé et s’aligne avec le domaine visible From.

5) Why do I see “in reply to end of DATA command” in the rejection?

Ça signifie que le récepteur a attendu de voir les en-têtes/le corps (et parfois exécuté des contrôles de contenu + réputation) avant de rejeter. Cela vous oriente vers la politique/réputation/contenu, pas la connectivité SMTP basique.

6) If I have DMARC p=reject, will that cause 554 rejections?

Ça peut — si vos messages échouent l’alignement. DMARC reject ne provoque pas le rejet en soi ; l’échec DMARC le fait. La correction est d’aligner les expéditeurs, pas de supprimer DMARC.

7) How do I protect transactional email when marketing gets blocked?

Séparez l’infrastructure et les identités. Au minimum : IPs et identifiants de soumission séparés. Préférez sous-domaines distincts et sélecteurs DKIM séparés. Gardez le volume transactionnel stable et propre.

8) Why do some recipients get mail while others bounce with 554?

Les filtres sont personnalisés. L’historique d’engagement, les règles utilisateur et les politiques locales varient. C’est pourquoi il vous faut une télémétrie au niveau domaine et des tests seed, pas des anecdotes.

9) Should I lower DKIM key size to “improve deliverability”?

Non. Utilisez une signature moderne et sécurisée (typiquement RSA 2048 bits quand supporté). La délivrabilité ne s’améliore pas en affaiblissant la crypto ; elle s’améliore en étant cohérent et digne de confiance.

10) How long does reputation recovery take?

Si le problème est une authentification cassée ou une erreur évidente, vous pouvez améliorer l’acceptation le jour même. Si vous avez brûlé la réputation avec de mauvaises listes ou des pics de volume, comptez des jours à semaines selon votre discipline.

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

Si vous regardez « 554 spam detected », votre victoire la plus rapide n’est ni un nouveau template ni une nouvelle ligne d’objet. C’est une identité cohérente plus un comportement prévisible :

1. Suivez le mode opératoire de diagnostic rapide : périmètre → alignement → réputation/comportement → contenu.
2. Corrigez l’alignement SPF/DKIM/DMARC pour que le domaine From soit authentifié comme les récepteurs l’attendent.
3. Stabilisez l’identité d’infrastructure : PTR, HELO, TLS, IPs de sortie cohérentes.
4. Limitez et segmentez le trafic. Suspendez le bulk pendant que vous protégez le transactionnel.
5. Nettoyez les listes comme si votre travail en dépendait — parce que c’est le cas.

Faites ça, et vous arrêterez de perdre des semaines à discuter avec des filtres mail. Il vous faudra quand même regagner la confiance, mais vous la regagnerez délibérément — pas en creusant accidentellement plus profond.