Blocages de politique 550 5.7.1 — la voie réaliste de correction

Ce que signifie réellement 550 5.7.1 (et pourquoi c’est vague par intention)

Les codes d’état SMTP sont trompeusement simples. 550 est une défaillance permanente : le serveur distant dit
« ne réessayez pas, corrigez quelque chose ». Le statut enrichi 5.7.1 correspond généralement à
« livraison non autorisée, message refusé » — mais c’est une catégorie, pas un diagnostic.

Le détail clé : « politique » est une décision distante. Elle peut être déclenchée par votre posture d’authentification
(SPF/DKIM/DMARC), la réputation de votre IP ou de votre domaine, votre reverse DNS et identité HELO/EHLO, votre posture TLS,
votre contenu, vos schémas d’envoi, ou les règles internes du destinataire. Parfois c’est un mélange.

En termes opérationnels, 550 5.7.1 n’est pas un message d’erreur. C’est un différend contractuel.
Le système récepteur affirme : « Votre système ne satisfait pas notre seuil actuellement. »
Votre tâche est de déterminer quel seuil.

Un changement de perspective pratique : ne pensez plus « l’email est en panne ». Pensez « la délivrabilité échoue ».
Ce n’est pas de la pédanterie. La disponibilité, c’est votre serveur qui est en ligne. La délivrabilité, c’est la confiance des autres.
Outils différents. Corrections différentes. Délais différents.

Playbook de diagnostic rapide (trouver le goulot rapidement)

Quand une file s’accumule et que les dirigeants s’agitent, vous avez besoin d’un ordre d’opérations qui dissipe le bruit.
Voici le chemin le plus rapide que j’ai trouvé, évitant les deux pièges classiques : modifications DNS aléatoires et changements paniqués de relais.

Première étape : classer le rejet

• Où est-il rejeté ? Pendant le dialogue SMTP (RCPT TO / DATA) ou après acceptation (rebond ultérieur) ?
• Est-ce pour tous les destinataires ou pour un seul domaine ? « Seulement vers Microsoft » est différent de « vers tout le monde ».
• Est-ce pour tous les expéditeurs ou pour un seul domaine From ? Un DMARC non aligné ressemble souvent à « certaines marques échouent ».

Deuxième étape : vérifier l’identité et l’alignement (gains faciles)

• SPF : IP(s) sortantes autorisées et chaînes include non cassées.
• DKIM : signature valide, bon sélecteur, clés non expirées, signature des bons en-têtes.
• DMARC : alignement entre le From visible et les identités SPF/DKIM.

Troisième étape : vérifier les signaux de réputation (la partie lente)

• La réputation de l’IP sortante et les listes de blocage (RBL) que les destinataires utilisent réellement.
• La réputation du domaine (surtout si votre domaine a récemment servi au spam, comptes compromis ou comportements imitatifs).
• Drapeaux comportementaux : pics de volume soudains, nouvelle IP, taux de rebond élevé, faible engagement.

Quatrième étape : vérifier la présentation SMTP (rDNS/HELO/TLS)

• Le reverse DNS existe et correspond à votre nom annoncé (ou au moins a l’air intentionnel).
• HELO/EHLO est un FQDN réel avec un DNS direct correspondant.
• TLS est sensé ; les certificats ne sont pas expirés ; vous n’annoncez pas de suites de chiffrement étranges.

Cinquième étape : contenu et routage

• Triggers de contenu : raccourcisseurs d’URL, MIME malformé, absence de List-Unsubscribe pour le bulk, types de pièces jointes douteux.
• Routage : reliez-vous par inadvertance via un smart host ou un NAT cloud qui a changé l’IP sortante ?

Si vous suivez cet ordre, vous identifierez généralement le goulot dominant en 30–60 minutes et arrêterez l’hémorragie.
La partie longue — la récupération de réputation — peut prendre des jours, mais au moins vous saurez quelle dette vous payez.

Faits intéressants et contexte historique (pour que la bizarrerie ait du sens)

1. SMTP date d’avant le spam de plusieurs décennies. Le modèle original supposait des pairs majoritairement coopératifs ; l’authentification n’était pas une exigence première.
2. Les codes d’état enrichis (comme 5.7.1) ont été normalisés plus tard pour apporter plus de nuance que « 550 », mais les fournisseurs les surchargent encore.
3. SPF a commencé comme une idée « qui peut envoyer pour ce domaine » parce que la falsification de l’expéditeur d’enveloppe était bon marché et courante ; ce n’était jamais une solution anti-hameçonnage complète.
4. DKIM est né de la signature cryptographique au niveau du domaine pour mieux survivre au transfert que SPF ; il reste fragile quand des intermédiaires réécrivent le contenu.
5. La vraie puissance de DMARC est l’alignement et la politique. Il permet au propriétaire du domaine de dire « si ceci ne s’authentifie pas comme moi, rejetez ou quarantinez ».
6. Le reverse DNS est devenu un contrat social. Ce n’est pas une exigence protocolaire stricte, mais de nombreux récepteurs traitent un rDNS manquant comme « probable botnet ».
7. Les listes de blocage existaient avant les systèmes modernes de réputation. Les premiers opérateurs partageaient des listes parce que c’était plus rapide que de discuter avec chaque spammeur individuellement.
8. Les grands fournisseurs utilisent des moteurs de réputation propriétaires. Vous pouvez passer SPF/DKIM/DMARC et être quand même bloqué si votre trafic ressemble à de l’abus.
9. « Politique » signifie aussi choix de conformité locaux. Certaines organisations rejettent le mail provenant de plages IP résidentielles, de certaines géographies ou de faibles postures TLS indépendamment de l’authentification.

Collecter d’abord les preuves : quoi capturer avant de « réparer » quoi que ce soit

Quand l’email casse, les gens commencent à « essayer des choses ». C’est ainsi que vous vous retrouvez avec trois sélecteurs DKIM à moitié configurés,
un enregistrement SPF qui dépasse les limites de recherche DNS, et un problème de réputation que vous ne pouvez pas expliquer parce que vous avez changé cinq variables en même temps.

Capturez un petit paquet de preuves. Ce n’est pas de la bureaucratie ; c’est la manière d’éviter de répéter des pannes.

• Un message d’erreur complet incluant les en-têtes et la transcription SMTP (pas une capture d’écran).
• Les logs Postfix/Exim autour de la défaillance avec l’ID de file et la réponse distante.
• L’IP et le nom d’hôte d’envoi tels qu’observés de l’extérieur (pas ce que vous pensez qu’ils sont).
• Les enregistrements DNS actuels pour SPF, les sélecteurs DKIM, DMARC, MX, A/AAAA, PTR.
• Les changements d’envoi récents : nouvelle campagne marketing, nouvelle IP, nouveau relais, déploiement d’appli, changement NAT, ou remédiation d’un compte compromis.

Blague n°1 : Si votre « correctif » consiste à éditer des enregistrements DNS de mémoire à 2h du matin, félicitations — vous avez réinventé la roulette avec moins d’alcool.

Tâches pratiques avec commandes : quoi lancer, ce que ça signifie, ce que vous décidez

Ce sont des tâches exécutables depuis un hôte mail Linux ou une machine de dépannage avec accès réseau.
Chaque tâche inclut : commande, sortie d’exemple, ce que la sortie signifie, et la décision suivante.

Task 1: Find the exact remote rejection text and stage (Postfix)

cr0x@server:~$ sudo grep -E "status=bounced|status=deferred|5\.7\.1|policy" /var/log/mail.log | tail -n 8
Jan 04 10:11:22 mx1 postfix/smtp[18422]: 9C2E91A2C4: to=<user@recipient.example>, relay=mx.recipient.example[203.0.113.9]:25, delay=2.1, delays=0.1/0.02/0.6/1.4, dsn=5.7.1, status=bounced (host mx.recipient.example[203.0.113.9] said: 550 5.7.1 Message rejected due to policy (in reply to end of DATA command))
Jan 04 10:11:23 mx1 postfix/qmgr[913]: 9C2E91A2C4: removed

Signification : Rejet à la fin de DATA signifie que le distant a accepté l’enveloppe mais n’a pas aimé le contenu ou les résultats d’authentification après analyse.
S’il avait été rejeté à RCPT TO, il s’agirait plus probablement de réputation IP, RBL, ou politique du destinataire.

Décision : Si rejet à la fin de DATA, priorisez l’alignement d’authentification et les vérifications de contenu ; vérifiez quand même la réputation, mais commencez par ce que le distant a scanné.

Task 2: Inspect a queued message safely (Postfix)

cr0x@server:~$ sudo postcat -q 9C2E91A2C4 | sed -n '1,120p'
*** ENVELOPE RECORDS ***
message_size: 48231            1980             1               0               0
message_arrival_time: Sat Jan  4 10:11:20 2026
create_time: Sat Jan  4 10:11:20 2026
named_attribute: log_ident=mx1
sender: noreply@brand.example
*** MESSAGE CONTENTS ***
Received: from app1.internal (app1.internal [10.0.2.15])
        by mx1.brand.example (Postfix) with ESMTPSA id 9C2E91A2C4
        for <user@recipient.example>; Sat, 04 Jan 2026 10:11:20 +0000 (UTC)
From: "Brand Support" <noreply@brand.example>
To: <user@recipient.example>
Subject: Password reset
Date: Sat, 04 Jan 2026 10:11:20 +0000
Message-ID: <20260104101120.12345@app1.internal>
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Signification : Cela confirme le domaine From visible, le chemin de soumission (ESMTPSA depuis une appli interne),
et si les en-têtes semblent « normales ». Un Message-ID sur un domaine interne peut être un petit signal de confiance problématique pour certains filtres.

Décision : Si Message-ID ou d’autres en-têtes semblent étranges, corrigez la politique d’en-têtes de l’appli/MTA (domaine du Message-ID, Date, MIME). Puis retestez avant de changer le DNS.

Task 3: Verify which IP you actually send from (outbound NAT surprises are real)

cr0x@server:~$ ip route get 8.8.8.8 | sed -n '1p'
8.8.8.8 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000

Signification : L’IP source est 192.0.2.10 pour le trafic sortant typique. Si vous attendiez une IP différente, vous avez un problème de routage/NAT.

Décision : Si l’IP d’envoi a changé récemment, considérez la réputation comme suspecte et vérifiez rDNS et listes de blocage pour la nouvelle IP.

Task 4: Check forward DNS for your mail hostname (A/AAAA)

cr0x@server:~$ dig +short A mx1.brand.example
192.0.2.10

Signification : Le nom d’hôte résout. Beaucoup de récepteurs pénalisent les noms HELO qui ne résolvent pas.

Décision : Si vide, corrigez le DNS. Si ça résout sur la mauvaise IP, corrigez-le avant toute autre chose.

Task 5: Check reverse DNS (PTR) for the sending IP

cr0x@server:~$ dig +short -x 192.0.2.10
mx1.brand.example.

Signification : Le PTR existe et semble intentionnel.

Décision : Si le PTR est manquant ou générique (par défaut du fournisseur cloud), demandez la modification de rDNS à votre fournisseur. Beaucoup de blocages de politique tiennent discrètement à cela.

Task 6: Check HELO/EHLO identity your Postfix presents

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|smtp_helo_name'
mydomain = brand.example
myhostname = mx1.brand.example
smtp_helo_name = $myhostname

Signification : Vous présentez un FQDN stable. Bien.

Décision : Si smtp_helo_name est défini sur quelque chose de non qualifié (comme « mail ») ou interne, corrigez-le et redémarrez Postfix.

Task 7: Validate SPF record and detect DNS lookup explosion

cr0x@server:~$ dig +short TXT brand.example | sed -n '1,3p'
"v=spf1 ip4:192.0.2.10 include:spf.mailvendor.example -all"

Signification : SPF est présent. Mais cela ne vous dit pas si les includes dépassent la limite de 10 recherches DNS.

Décision : Si vous avez plusieurs includes, vous devez évaluer le nombre de recherches. Si vous dépassez, SPF peut renvoyer « permerror », ce qui peut déclencher des blocages de politique.

Task 8: Evaluate SPF from the outside using a local tool (auth results simulation)

cr0x@server:~$ python3 - <<'PY'
import sys, dns.resolver
domain="brand.example"
answers=dns.resolver.resolve(domain,'TXT')
for r in answers:
    for s in r.strings:
        t=s.decode()
        if t.startswith("v=spf1"):
            print(t)
PY
v=spf1 ip4:192.0.2.10 include:spf.mailvendor.example -all

Signification : Confirme la chaîne SPF que vous publiez. Ce n’est toujours pas une évaluation complète SPF, mais cela détecte rapidement « plusieurs enregistrements SPF » et les problèmes de format évidents.

Décision : Si vous voyez plus d’un enregistrement v=spf1, corrigez immédiatement. Les récepteurs peuvent le traiter comme un permerror SPF.

Task 9: Check DMARC record and policy posture

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

Signification : Vous avez un alignement strict (adkim=s, aspf=s) et une politique de rejet.
Excellent pour l’anti-phishing. Aussi impitoyable si vos systèmes ne sont pas parfaitement alignés.

Décision : Si vous obtenez des blocages de politique chez les principaux fournisseurs juste après avoir activé DMARC strict, confirmez que tous les expéditeurs légitimes signent DKIM avec un d= aligné ou que SPF s’aligne avec le domaine From.

Task 10: Verify DKIM public key exists for the selector you believe you use

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

Signification : Le sélecteur existe. L’absence de sélecteur est une panne très courante « nous avons fait pivoter les clés et oublié le DNS ».

Décision : Si manquant, publiez-le, attendez la propagation, puis retestez. Si présent, vérifiez que votre MTA utilise réellement ce sélecteur.

Task 11: Confirm DKIM signing configuration (OpenDKIM + Postfix example)

cr0x@server:~$ sudo egrep -n 'Domain|Selector|KeyFile|Socket' /etc/opendkim.conf | head
14:Domain                 brand.example
15:Selector               s2024
16:KeyFile                /etc/opendkim/keys/brand.example/s2024.private
23:Socket                 inet:8891@localhost

Signification : Montre quel domaine DKIM et quel sélecteur vous êtes configuré pour utiliser.

Décision : Si Domain/Selector ne correspondent pas au DNS, corrigez la configuration. Si KeyFile est mal placé ou permissions cassées, la signature DKIM échoue silencieusement et les récepteurs vous jugent louche.

Task 12: Check Authentication-Results on a delivered message (ground truth)

cr0x@server:~$ grep -i "Authentication-Results" -n /var/mail/test-inbox | tail -n 3
120:Authentication-Results: mx.google.example; spf=pass (google.example: domain of noreply@brand.example designates 192.0.2.10 as permitted sender) smtp.mailfrom=noreply@brand.example; dkim=pass header.i=@brand.example header.s=s2024; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=brand.example

Signification : C’est le verdict du récepteur. S’il indique SPF pass, DKIM pass, DMARC pass, vous pouvez arrêter de deviner et passer à réputation/contenu/limites de débit.

Décision : Si SPF/DKIM/DMARC échouent ici, corrigez l’alignement avant toute autre chose. Le passage local est sans intérêt ; l’évaluation du récepteur est ce qui compte.

Task 13: Check if your IP is listed on common DNSBLs (quick signal, not gospel)

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

Signification : Une sortie vide suggère « non listé » sur ceux-ci. Si vous obtenez une IP en retour, vous êtes listé.

Décision : Si listé sur une DNSBL utilisée par votre destinataire, corrigez la cause (compromis/relay ouvert) et demandez la délistage, ou changez d’IP sortante (puis réchauffez prudemment).

Task 14: Validate TLS posture from the outside (STARTTLS, cert chain)

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

Signification : Le certificat est valide et pas expiré.

Décision : Si expiré ou non conforme, corrigez les certificats. Certaines organisations appliquent des blocages de politique pour non-TLS ou TLS cassé, surtout en B2B.

Task 15: Ensure you are not an open relay (yes, still)

cr0x@server:~$ swaks --server mx1.brand.example --to victim@external.example --from attacker@external.example --data "Subject: test

hello"
=== Trying mx1.brand.example:25...
=== Connected to mx1.brand.example.
<-  220 mx1.brand.example ESMTP Postfix
 -> EHLO server
<-  250-mx1.brand.example
 -> MAIL FROM:<attacker@external.example>
<-  554 5.7.1 Relay access denied

Signification : Relais refusé pour un expéditeur externe non authentifié. Bien.

Décision : S’il accepte le relais, arrêtez tout. Vous allez devenir célèbre de la pire manière et les blocages 550 seront le moindre de vos soucis.

Task 16: Check outbound queue growth and retry behavior

cr0x@server:~$ mailq | tail -n 5
-- 2 Kbytes in 1 Request.

Signification : Petite file, c’est bon. Pendant un incident vous pourriez voir des centaines/milliers en file avec des reports répétés.

Décision : Si la file grossit, limitez le débit ou mettez en pause le flux en cause (campagne marketing, compte compromis) pour éviter d’empirer la réputation pendant que vous corrigez l’identité.

D’où viennent les blocages de politique : les véritables modes de défaillance

1) L’authentification passe… mais n’est pas alignée

C’est la variante la plus exaspérante car vos logs affichent fièrement « SPF=pass » et « DKIM=pass » quelque part,
et pourtant DMARC échoue et le récepteur vous considère comme usurpé. L’alignement est la différence entre
« un domaine s’est authentifié » et « le domaine From visible s’est authentifié ».

Causes typiques :

• Votre appli envoie From: brand.example mais l’expéditeur d’enveloppe est bounce@mailer.vendor.example et seul celui-ci passe SPF.
• DKIM signe avec d=vendor.example et non d=brand.example.
• DMARC configuré en alignement strict alors que des sous-domaines légitimes envoient du mail qui ne correspond pas exactement.

2) Spirale de mort de la réputation (volume et rebonds)

La réputation se nourrit de rétroaction. Si vous envoyez soudainement à une liste avec de nombreuses adresses invalides, vous générez des hard bounces.
Si votre contenu ressemble à du phishing, les destinataires l’ignorent ou le signalent. Si vous continuez à envoyer pendant que vous êtes bloqué, vous amplifiez le signal :
« cet expéditeur n’apprend pas ».

La récupération est possible, mais lente et ennuyeuse. C’est bien : cela signifie que les attaquants ne peuvent pas non plus « réinitialiser » instantanément.

3) Incohérence d’identité d’infrastructure (rDNS, HELO, IP dynamique)

Beaucoup de récepteurs traitent le mail provenant d’IP sans enregistrement PTR, ou avec un PTR qui crie « instance cloud générique », comme suspect.
Pas toujours un blocage dur, mais combiné à d’autres signaux faibles, cela devient le vote décisif.

Si vous envoyez depuis une plage d’un FAI résidentiel, attendez-vous à des rejets 5.7.1 constants de systèmes mail d’entreprise sérieux.

4) Blocages basés sur le contenu (oui, votre mail inoffensif peut sembler malveillant)

Les filtres sont impitoyables sur les motifs corrélant avec l’abus :
frontières MIME malformées, mail HTML-only avec texte minuscule et liens géants, URLs raccourcies, texte de lien non correspondant,
pièces jointes au format macro, et « domaine tout neuf + langage urgent + lien de connexion ».

Votre erreur « policy » peut être que le système distant refuse d’accepter votre message parce qu’il obtient un score au-dessus d’un seuil.
Vous n’obtenez pas le score. Vous obtenez le mur.

5) Transferts et listes de diffusion cassant SPF (et parfois DKIM)

SPF échoue lors du transfert parce que l’IP du serveur de transfert n’est pas autorisée dans votre enregistrement SPF.
DKIM peut survivre au transfert, mais casse si le forwarder réécrit le corps ou certains en-têtes.
DMARC échoue alors parce que ces deux mécanismes sont fragiles sous modification.

Si votre audience inclut universités, listes de diffusion, systèmes de ticketing et passerelles de sécurité,
cela peut représenter une part significative des rejets 5.7.1 « aléatoires ».

6) Throttling et portes de politique spécifiques aux fournisseurs

Les grands fournisseurs et les passerelles d’entreprise implémentent leurs propres barrières : limites de débit par IP, plafonds par domaine, contrôles de rafale, et suspicion « nouvel expéditeur ».
Parfois ils répondent avec des 4xx (déferrals). Parfois ils répondent avec des 5xx de politique qui signifient « allez-vous-en jusqu’à ce que la réputation s’améliore ».

C’est là que les opérateurs perdent des jours à se disputer avec le protocole. Ce n’est pas un problème de protocole. C’est un système anti-abus qui fait son travail.

Une citation qui ramène les équipes sur terre

Idée paraphrasée de Richard Cook (sécurité et fiabilité) : « le succès vient d’ajustements continus ; l’échec survient quand ces ajustements ne suivent plus. »

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

Mini-récit n°1 : L’incident causé par une fausse hypothèse (le NAT qui a volé le mail)

Une société SaaS de taille moyenne exécutait Postfix sur une paire de VM. Ils avaient SPF, DKIM, DMARC — tous au vert dans leurs tests.
Pourtant une partie des emails transactionnels vers un grand fournisseur de boîtes mail a commencé à échouer avec des blocages 550 5.7.1.
L’équipe a supposé « DKIM a cassé », car c’est le coupable habituel après un déploiement.

Ils ont fait pivoter les clés DKIM. Ils ont ajusté l’alignement DMARC. Ils ont ajouté encore un include à SPF.
La panne a continué. La file s’est énervée. Le support s’est fait plus insistant.

Le vrai problème était plus prosaïque : l’équipe réseau avait déplacé les VM mail derrière un egress NAT différent pendant une maintenance de pare-feu.
Le mail sortant quittait maintenant depuis une IP absente de SPF et sans rDNS configuré.
Leurs tests internes touchaient une boîte de test plus indulgente ; le grand fournisseur, non.

Une fois l’IP d’egress vraie identifiée (en vérifiant le routage et en comparant avec les logs du destinataire),
la correction a été simple : mettre à jour SPF pour la nouvelle IP, configurer un PTR approprié, et stabiliser le HELO.
La leçon est restée : pour l’email, « quelle IP utilisons-nous pour envoyer ? » n’est pas une question philosophique. C’est la première ligne de l’autopsie.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux (tuning de file et réputation)

Une équipe d’entreprise a décidé que leur débit sortant était « trop lent ». Le marketing voulait des lancements plus larges, plus rapides.
Quelqu’un a monté la concurrence et les taux de connexion de Postfix. Les graphiques étaient beaux. La latence a chuté.
Leur MTA avait l’air d’avoir bu trois expressos et d’avoir trouvé une nouvelle raison d’être.

Puis des blocages 550 5.7.1 ont commencé à apparaître de façon intermittente, surtout chez les plus grands fournisseurs et quelques passerelles d’entreprise strictes.
L’équipe a supposé « panne du fournisseur » parce que des tentatives de nouvelle livraison fonctionnaient parfois, et parce qu’il est réconfortant de blâmer quelqu’un d’autre.

Les fournisseurs n’étaient pas en panne. Les fournisseurs contrôlaient l’abus.
Le nouveau pattern de concurrence ressemblait à un expéditeur compromis : rafales, haut parallélisme, tentatives rapides vers de nombreux destinataires.
Quelques coquilles dans les uploads de listes ont créé des hard bounces, amplifiant le signal négatif.

Ils ont rétabli la concurrence, implémenté des limites de débit par domaine, et introduit un « mode warm-up » pour les envois massifs.
La délivrabilité s’est stabilisée. L’optimisation ne s’est pas seulement retournée contre eux ; elle a appris à l’équipe que le KPI principal pour l’email n’est pas le débit.
Le KPI est « messages acceptés et non marqués comme indésirables ».

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (rapports DMARC comme fumée précoce)

Une entreprise financière avait l’habitude, apparemment excessive, de revoir les rapports agrégés DMARC chaque semaine.
Pas avec un comité coûteux — juste une astreinte tournante et une courte note interne.
La plupart des semaines c’était ennuyeux : taux de passage, quelques sources inconnues, rien de dramatique.

Une semaine, ils ont remarqué une nouvelle source envoyant des mails prétendant être leur domaine, échouant à l’alignement, provenant d’un hébergeur au hasard.
Ce n’était pas leur infrastructure. Ce n’était pas un prestataire autorisé. C’était soit de l’usurpation soit un tiers compromis.
Aucun client ne s’était encore plaint. Aucune liste n’avait encore frappé. Mais la fumée était visible.

Ils ont resserré SPF, vérifié les sélecteurs DKIM pour tous les fournisseurs, et contacté l’hébergeur en fournissant des preuves.
Ils ont aussi préventivement assuré que leurs flux légitimes étaient parfaitement alignés et signés, pour ne pas être pris dans le rayon d’explosion.

Quand les campagnes de phishing ont monté et que les fournisseurs de boîtes sont devenus plus stricts pour cette marque, leur trafic légitime a continué de circuler.
La pratique n’était pas glamour, mais elle a transformé une panne soudaine en atténuation discrète.

Blague n°2 : La délivrabilité email est le seul domaine où faire tout correctement donne encore l’impression d’être jugé par un chat.

Erreurs courantes : symptôme → cause racine → correction spécifique

1) Symptom: 550 5.7.1 appears only for one big provider

Cause racine : Scorage de réputation spécifique au fournisseur, throttling, ou heuristiques de contenu ; parfois rDNS/TLS manquant que les petits récepteurs ignorent.

Correction : Vérifiez les Authentication-Results chez ce fournisseur, confirmez l’IP d’egress, corrigez rDNS/HELO/TLS, puis réduisez le débit et nettoyez les rebonds. Prévoyez un délai de récupération.

2) Symptom: SPF “pass” but DMARC fails

Cause racine : SPF passe pour un domaine différent (expéditeur d’enveloppe) que le domaine From visible ; l’alignement DMARC échoue.

Correction : Assurez-vous que le domaine expéditeur d’enveloppe s’aligne avec le From (ou configurez DKIM avec d=brand.example et alignez DMARC). Évitez l’alignement strict tant que toutes les sources ne sont pas conformes.

3) Symptom: Everything works until you rotate DKIM keys

Cause racine : Nouveau sélecteur non publié dans le DNS, latence de propagation DNS, ou permissions du fichier clé incorrectes provoquant un échec silencieux de signature.

Correction : Publiez le sélecteur d’abord, attendez le TTL, validez avec dig, puis basculez la signature. Surveillez les logs pour les erreurs de signature DKIM.

4) Symptom: Sudden spike in bounces and then policy blocks

Cause racine : Mauvaise hygiène des listes, compte compromis envoyant vers des adresses collectées, ou une mauvaise importation créant des destinataires invalides.

Correction : Arrêtez le flux, mettez en quarantaine l’expéditeur/l’appli, nettoyez les listes, implémentez des limites de débit sortant et le traitement des rebonds. Puis reprenez lentement.

5) Symptom: Policy blocks started after moving to a new cloud region

Cause racine : Nouvelle plage IP a mauvaise réputation ; rDNS manquant ; discordance HELO/PTR ; certains fournisseurs se méfient de certaines plages.

Correction : Configurez PTR et DNS direct correctement, réchauffez l’IP progressivement, et envisagez d’utiliser un relais réputé pendant le warm-up pour les mails critiques.

6) Symptom: Only forwarded recipients fail (universities, mailing lists, ticketing systems)

Cause racine : SPF casse lors du forwarding ; DKIM casse si le message est modifié ; DMARC échoue et les récepteurs appliquent la politique.

Correction : Préférez l’alignement DKIM ; assurez-vous que DKIM survive aux modifications courantes (la canonicalization simple peut être fragile). Envisagez le support ARC si vous opérez un service de transfert ; pour les expéditeurs, rendez DKIM robuste.

7) Symptom: “Relay access denied” internal users claim it’s 5.7.1 policy

Cause racine : Mauvaise configuration de soumission (clients n’authentifiant pas, mauvais port, restrictions de relais incorrectes) et non un blocage politique distant.

Correction : Corrigez le service de soumission sur 587 avec auth, vérifiez smtpd_recipient_restrictions, et assurez-vous que les clients utilisent STARTTLS + auth.

8) Symptom: Reject happens at end of DATA for HTML-heavy mail

Cause racine : Scorage de contenu : réputation des URL, MIME malformé, domaines de tracking, incohérence texte/HTML, absence de partie text/plain.

Correction : Validez le MIME, incluez multipart/alternative avec text/plain, enlevez les motifs d’URL risqués, corrigez le HTML cassé, évitez les raccourcisseurs, et alignez les domaines de tracking avec votre marque.

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

Étape par étape : Stabiliser l’incident (premières 2 heures)

1. Arrêtez d’empirer la situation. Mettez en pause les flux bulk et les expéditeurs suspects. Gardez les réinitialisations de mot de passe et reçus qui sont essentiels si vous pouvez les isoler.
2. Choisissez un domaine destinataire qui échoue et un exemple de message. Ne déboguez pas dix choses à la fois.
3. Capturez la transcription du bounce et l’ID de file, plus la réponse distante et l’étape (RCPT vs DATA).
4. Confirmez l’IP d’egress et vérifiez la cohérence PTR + HELO + enregistrement A.
5. Validez SPF/DKIM/DMARC du point de vue du récepteur en utilisant les Authentication-Results d’une livraison test ou d’une boîte ensemencée.
6. Vérifiez les indicateurs évidents de réputation : présence sur DNSBL et si l’IP est nouvelle/froide.
7. Faites un seul changement à la fois, documentez-le, et retestez. Les changements DNS comptent comme « changements lents ».

Étape par étape : Corriger l’identité et l’alignement (même jour)

1. SPF : enregistrement unique, IPs autorisées correctes, éviter les includes excessifs, définir -all seulement quand vous êtes sûr.
2. DKIM : signez tous les flux sortants avec un d= aligné pour le domaine From visible. Faites la rotation des clés avec chevauchement.
3. DMARC : commencez avec p=none pendant le déploiement si vous avez des expéditeurs inconnus ; passez à quarantine puis reject quand les taux de passage sont stables.
4. Expéditeur d’enveloppe : assurez-vous que le domaine de bounce est sous votre contrôle et s’aligne quand SPF est votre chemin principal.
5. En-têtes : corrigez le domaine du Message-ID, la Date, la structure MIME, et assurez-vous de ne pas produire de contenu malformé.

Étape par étape : Récupérer la réputation (jours à semaines)

1. Réduisez le volume et lissez les rafales. Les fournisseurs se méfient des expéditeurs en rafales.
2. Nettoyez les listes et supprimez les rebonds. Les taux élevés de hard-bounce sont des dommages auto-infligés.
3. Séparez les flux mail. Le transactionnel ne devrait pas partager la réputation avec le marketing expérimental.
4. Réchauffez les nouvelles IP lentement. Commencez par des destinataires engagés et augmentez progressivement le volume.
5. Surveillez les plaintes et signaux d’engagement quand disponibles (feedback loops, rapports utilisateurs).
6. Ne « corrigez » pas la réputation en changeant d’IP chaque semaine. Cela ressemble à de l’évasion. Certains systèmes s’en souviennent.

Checklist opérationnelle : Ce qu’il faut garder en place en permanence

• Diagramme de flux mail documenté : applis → soumission → MTA → relais (si présent) → IPs d’egress internet.
• Fragments de zone DNS en contrôle de version ou infrastructure-as-code pour SPF/DKIM/DMARC.
• Runbook de rotation des clés : publier le sélecteur, valider le DNS, basculer la signature, garder l’ancien sélecteur pendant la fenêtre de chevauchement.
• Limitation de débit sortant par domaine/fournisseur et valeurs de concurrence sensées.
• IPs/domaines séparés pour transactionnel vs marketing quand l’entreprise dépend de la livraison des reçus.
• Alerte sur pics de rebonds, croissance de file, et échecs d’authentification soudains.

FAQ

1) Is “550 5.7.1” always an SPF/DKIM/DMARC problem?

Non. C’est souvent corrélé aux échecs d’authentification, mais cela peut être la réputation, le rDNS/HELO mismatch, la politique TLS, ou le filtrage de contenu.
L’étape SMTP importe : rejet à RCPT pointe souvent vers IP/réputation ; rejet à la fin de DATA pointe souvent vers une évaluation de contenu/auth après scan.

2) We pass SPF, DKIM, and DMARC, but still get 550 5.7.1. Now what?

Supposez réputation ou contenu. Confirmez que vous envoyez depuis l’IP que vous pensez utiliser, vérifiez la cohérence PTR/HELO,
passez en revue les taux de rebond/plainte, et cherchez des triggers de contenu (URLs, pièces jointes, MIME malformé, tracking agressif).
Vérifiez aussi que vous n’envoyez pas en rafales d’une façon qui déclenche des portes de politique.

3) Can I fix it by changing my IP?

Parfois, mais considérez-le comme un dernier recours pour les mails critiques — surtout si l’IP actuelle est listée à cause d’un compromis réel que vous avez déjà corrigé.
Une nouvelle IP est « froide » et peut aussi être bloquée. Si vous faites pivoter les IPs de façon répétée, vous ressemblez à un abuseur et votre futur devient problématique.

4) What’s the difference between SPF fail and SPF permerror?

Fail signifie que l’IP n’est pas autorisée par la politique SPF du domaine. Permerror signifie que l’enregistrement est cassé (souvent trop de recherches DNS ou plusieurs enregistrements SPF).
Le permerror est particulièrement pénible car il est auto-infligé et peut déclencher l’échec DMARC même pour du mail légitime.

5) Why does forwarding break things?

SPF est évalué contre l’IP connectante. Quand un forwarder renvoie votre mail, l’IP connectante devient celle du forwarder, pas la vôtre — donc SPF échoue souvent.
DKIM peut survivre au forwarding, mais casse si le forwarder modifie le corps ou les en-têtes signés. DMARC échoue si ni SPF aligné ni DKIM aligné ne passent.

6) Should we set DMARC to p=reject to stop spoofing?

Finalement, oui. Mais faites-le comme un SRE, pas comme un joueur. Inventoriez d’abord tous les expéditeurs légitimes, rendez la signature DKIM cohérente,
commencez par p=none pour observer, puis passez à quarantine et enfin reject.
Sinon vous bloquerez vos propres mails business en prétendant faire de la « sécurité ».

7) How do we keep transactional mail flowing when marketing gets us blocked?

Séparez les flux : IPs différentes, sous-domaines différents, et idéalement infrastructures distinctes.
Le mail transactionnel doit avoir une réputation stable et un comportement conservateur. Le marketing peut expérimenter, c’est correct — juste ne laissez pas ça brûler les sorties de secours.

8) Can content alone cause a “policy block” even with perfect authentication?

Oui. L’authentification répond « qui êtes-vous », pas « êtes-vous bienvenu ». Si votre message ressemble à une livraison de malware, un phishing de credentials, ou à du trafic d’affiliation spammy,
certains récepteurs bloqueront à la fin de DATA. Corrigez la validité MIME, retirez les URLs suspectes, et évitez les types de pièces jointes risqués.

9) What’s the quickest “sanity check” to run during an incident?

Récupérez une transcription de bounce, confirmez l’IP d’egress et le PTR, et obtenez un en-tête Authentication-Results depuis une boîte ensemencée.
Cela triangule identité vs réputation vs contenu plus vite que n’importe quel débat Slack.

Conclusion : prochaines étapes qui réduisent réellement les 550

« Blocage de politique 550 5.7.1 » n’est pas un bogue unique. C’est un verdict de l’autre côté d’Internet, généralement fondé sur un tas de signaux que vous ne voyez pas complètement.
Votre travail est de rendre votre identité non ambiguë, votre infrastructure cohérente, et votre comportement d’envoi ennuyeux.
L’ennui, c’est bien. L’ennui se fait livrer.

Étapes pratiques :

1. Construisez un paquet de preuves répétable : transcription du bounce, ID de file, étape, IP d’egress, et enregistrements DNS actuels.
2. Rendez l’alignement non négociable : DKIM avec d= aligné pour votre domaine From, SPF qui correspond vraiment à l’IP d’envoi, DMARC qui reflète la réalité.
3. Renforcez l’identité SMTP : rDNS, HELO, DNS direct, et certificats TLS valides.
4. Contrôlez le comportement : limites de débit, segmentation des flux, et évitez que des rafales ne deviennent des incidents de réputation.
5. Institutionnalisez la pratique ennuyeuse : surveillez les résultats d’authentification et les pics de rebonds avant qu’ils ne deviennent une panne.

Si vous faites ces cinq choses, 550 5.7.1 ne disparaîtra pas pour toujours — l’email reste l’email — mais cela deviendra une irritation occasionnelle plutôt qu’un incident de production récurrent.