554 5.7.9 « Message not accepted for policy reasons » : corriger le rejet Yahoo/AOL

Si Yahoo ou AOL rejette purement et simplement vos e-mails avec un message de ce type, vous êtes face à un rejet pour raison de politique 554 5.7.9 :

554 5.7.9 Message not accepted for policy reasons.
Please visit https://senders.yahooinc.com

Ce n'est pas un report temporaire, ni le throttling progressif lié aux plaintes ([TSS04]), ni un filtre de contenu générique. Le 554 5.7.9 est un rejet dur et définitif dicté par la politique d'expéditeur de Yahoo : quelque chose dans la façon dont le message a été envoyé échoue aux vérifications de base de Yahoo pour l'e-mail en masse ou commercial, et Yahoo refuse la tentative de livraison au lieu de la mettre en file d'attente.

Comme AOL, AIM et Verizon.net tournent tous sur l'infrastructure de messagerie de Yahoo, le même rejet 554 5.7.9 s'applique à l'identique sur chacun d'eux.

Ce que signifie vraiment 554 5.7.9

Décomposons la réponse élément par élément :

• 554 : « transaction failed » en SMTP. Un code 5xx est un échec définitif. Votre MTA ne réessaiera pas de lui-même ; le message revient immédiatement en bounce à l'expéditeur d'origine.
• 5.7.9 : le code de statut étendu. Le 5 initial confirme l'échec définitif. 7 désigne la catégorie politique/sécurité. 9 est enregistré comme « authentication mechanism is too weak », un code SMTP AUTH issu de la RFC 4954 (registre IANA) ; Yahoo le réutilise pour les messages qui enfreignent sa politique d'expéditeur.
• Message not accepted for policy reasons : l'explication lisible de Yahoo. Il n'y a volontairement aucun détail : Yahoo ne révèle pas quelle règle précise s'est déclenchée, pour empêcher les abuseurs de retrouver ses seuils par rétro-ingénierie.
• senders.yahooinc.com : la documentation postmaster de Yahoo, où sont publiées les exigences de politique sous-jacentes.

La différence clé avec TSS04 : TSS04 est un report temporaire 4xx (421) dicté par votre taux de plaintes glissant. Le 554 5.7.9 est un rejet définitif 5xx dicté par une violation de politique qui tient au message lui-même ou à l'expéditeur derrière lui. TSS04 se lève tout seul dès que votre taux de plaintes baisse ; le 554 5.7.9 ne se lève qu'une fois le problème de politique corrigé.

Les causes les plus fréquentes

Dans les incidents réels, le 554 5.7.9 remonte presque toujours à l'une de ces causes :

• Signature DKIM absente, cassée ou non alignée. Yahoo applique les exigences 2024 de Gmail/Yahoo pour les expéditeurs en masse : DKIM est obligatoire, et le domaine de l'en-tête From: doit s'aligner soit sur le domaine DKIM d=, soit sur le domaine SPF, pour que DMARC passe. Une signature DKIM absente ou un défaut d'alignement est de loin le déclencheur le plus fréquent.
• SPF en échec ou non aligné. Les expéditeurs en masse doivent mettre en place SPF en plus de DKIM. L'alignement peut venir de l'un ou de l'autre, donc un SPF qui passe sans être aligné ne pose problème que si DKIM n'est pas aligné non plus.
• Pas d'enregistrement DMARC, ou DMARC p=none sans SPF ni DKIM aligné. La politique de Yahoo pour les expéditeurs en masse exige au minimum p=none et au moins une authentification alignée. Les expéditeurs qui n'ont publié aucun enregistrement DMARC sont les plus exposés au 554 5.7.9.
• Envoi en masse depuis un domaine tout neuf, sans aucune réputation. Yahoo rejette les domaines froids dès le premier contact plus agressivement que Gmail, surtout quand le message a l'allure d'un e-mail transactionnel ou promotionnel.
• Pas d'inscription à la Complaint Feedback Loop (CFL) de Yahoo. Pour les gros expéditeurs, l'absence d'inscription à la CFL est en soi un signal de politique, car Yahoo attend des expéditeurs en masse qu'ils puissent recevoir les rapports de plaintes.
• En-tête de désinscription manquant. Un e-mail commercial sans en-tête List-Unsubscribe fonctionnel enfreint les exigences de Yahoo pour les expéditeurs en masse (Yahoo accepte la méthode mailto: mais recommande fortement le POST de la RFC 8058 List-Unsubscribe-Post: List-Unsubscribe=One-Click) et peut déclencher un rejet dur plutôt qu'un simple report.
• Contenu ou modèle qui déclenche une règle de politique. Les raccourcisseurs d'URL, les couples nom affiché/adresse From incohérents ou un HTML qui masque le véritable expéditeur enfreignent tous les règles documentées de Yahoo pour les expéditeurs.

Si votre bounce affiche la chaîne littérale Message not accepted for policy reasons sans rien de plus précis, c'est que Yahoo refuse délibérément de vous dire quelle règle s'est déclenchée : il faut donc vérifier chacun des points ci-dessus, dans l'ordre.

Correction étape par étape

Suivez cette liste de haut en bas. Sauter les étapes d'authentification pour passer directement à « chauffer le domaine » est la raison la plus courante pour laquelle des expéditeurs restent bloqués des jours sur le 554 5.7.9.

1. Mettez en pause la campagne concernée. Un rejet 5xx signifie que le message part définitivement en bounce. Chaque tentative supplémentaire est un bounce de plus à votre dossier et une donnée de plus qui vous fait passer, aux yeux de Yahoo, pour un expéditeur non conforme. Cessez d'envoyer aux destinataires Yahoo/AOL jusqu'à ce que le problème de politique soit corrigé.
2. Vérifiez SPF sur le domaine d'envoi. Passez le domaine From dans l'outil de recherche SPF. Vérifiez que l'enregistrement existe, que sa syntaxe est valide, qu'il fait moins de 10 requêtes DNS et que l'IP qui envoie réellement le courrier est autorisée, directement ou via un include: que vous contrôlez.
3. Vérifiez DKIM sur le message. Récupérez un message récent et regardez l'en-tête DKIM-Signature. Passez le sélecteur et le domaine dans l'outil de recherche DKIM pour confirmer que la clé publique se résout. Surtout, vérifiez que le domaine DKIM d= correspond au domaine From: (ou s'aligne avec lui en mode relaxed). Une signature DKIM non alignée passe DKIM mais échoue à DMARC, et Yahoo traite cela comme un échec de politique.
4. Vérifiez DMARC. Passez le domaine From dans l'outil de recherche DMARC. Il vous faut au minimum un enregistrement publié avec p=none, mais pour la politique de Yahoo sur les envois en masse, il faut aussi que SPF ou DKIM passe avec alignement. Un enregistrement DMARC dont les deux authentifications échouent à l'alignement revient, dans les faits, à ne pas avoir de DMARC du tout.
5. Vérifiez les en-têtes d'expéditeur en masse. Chaque message commercial envoyé à Yahoo doit porter à la fois List-Unsubscribe: <https://...>, <mailto:...> et List-Unsubscribe-Post: List-Unsubscribe=One-Click. Récupérez les en-têtes bruts d'un message envoyé et vérifiez que les deux lignes sont présentes et bien formées. Consultez notre guide des exigences de Gmail et Yahoo pour les expéditeurs en masse pour le format exact.
6. Inscrivez-vous à la Complaint Feedback Loop de Yahoo. Enregistrez votre domaine d'envoi sur senders.yahooinc.com. Sans inscription à la CFL, vous n'avez aucune visibilité sur les plaintes chez Yahoo et vous manquez une étape de conformité documentée pour les expéditeurs en masse.
7. Vérifiez le contenu et l'en-tête From. Assurez-vous que le nom affiché du From: correspond au véritable domaine d'envoi (pas de "Bank of America" <random@cheapdomain.xyz>), que le corps ne contient aucun raccourcisseur d'URL et que toutes les redirections de suivi sont sur un sous-domaine du domaine From, pas sur un raccourcisseur tiers.
8. Testez un message à faible volume. Une fois l'authentification, les en-têtes et la CFL en place, envoyez un seul message depuis la même infrastructure vers une adresse de test Yahoo. S'il est accepté, remontez lentement (voir le guide TSS04 pour la courbe de reprise). S'il est encore rejeté en 554 5.7.9, l'une des vérifications d'authentification ci-dessus échoue toujours.

Combien de temps avant que le 554 5.7.9 se lève

Contrairement à TSS04, le 554 5.7.9 n'est pas lié au temps. Il se lève dès que la condition de politique fautive est corrigée : il n'y a pas de fenêtre glissante à attendre.

En pratique :

• En quelques minutes si la cause était une signature DKIM absente ou cassée, ou un enregistrement DMARC non publié. Dès que le DNS s'est propagé et que le message suivant est correctement signé, le rejet s'arrête.
• En 24 à 48 heures s'il faut vous inscrire à la CFL, corriger les en-têtes List-Unsubscribe ou attendre que les modifications DNS se propagent complètement jusqu'aux résolveurs de Yahoo.
• Une semaine ou plus, mais seulement si vous continuez d'envoyer malgré le rejet (chaque 5xx en bounce est une nouvelle donnée de politique) ou si la cause profonde est un domaine froid sans réputation, qui a encore besoin d'une courbe de warm-up même une fois l'authentification corrigée.

Il n'existe aucun formulaire de délistage pour le 554 5.7.9. La politique de Yahoo invite explicitement les expéditeurs à corriger le problème de fond et à réessayer, pas à demander un examen manuel.

FAQ

Le 554 5.7.9 signifie-t-il que je figure sur une blacklist ? Non. C'est le propre rejet de politique de Yahoo, appliqué par ses MTA entrants en fonction du message et de l'expéditeur. Yahoo cite bien le fait que votre IP figure chez Spamhaus parmi les causes de ses rejets 5xx (Yahoo SMTP error codes) : vérifiez donc votre IP d'envoi chez Spamhaus avant d'écarter cette piste.

En quoi est-ce différent de TSS04 ? TSS04 est un report temporaire 4xx dicté par votre taux glissant de plaintes pour spam, et il se lève tout seul quand ce taux baisse. Le 554 5.7.9 est un rejet définitif 5xx dicté par une violation de politique (le plus souvent l'authentification), et il ne se lève que lorsque vous corrigez cette violation. Voir le guide TSS04 pour le volet taux de plaintes.

AOL se comporte-t-il de la même façon ? Oui. AOL, AIM et Verizon.net reposent sur l'infrastructure de messagerie de Yahoo et appliquent les mêmes rejets de politique 554 5.7.9. Si Yahoo vous rejette en 5.7.9, AOL le fera aussi.

Est-ce que réessayer peut aider ? Non. Le 554 est définitif. Votre MTA ne réessaiera pas de lui-même, et forcer des renvois manuels ne fait qu'empiler les bounces contre votre réputation d'expéditeur. Corrigez d'abord la cause.

Dois-je contacter Yahoo pour lever ce rejet ? Non. Il n'y a ni ticket de support ni procédure de délistage pour le 554 5.7.9. La documentation de Yahoo dit explicitement de corriger le problème de politique puis de renvoyer. Une surveillance continue de l'authentification et de DMARC (voir les tarifs pour les formules qui incluent une surveillance 24 h/24, 7 j/7) est la mesure préventive qui marche en pratique.

En résumé

Le 554 5.7.9, c'est Yahoo qui vous dit, de façon définitive et sans nouvelle tentative, que le message que vous avez voulu envoyer enfreint sa politique d'expéditeur, presque toujours à cause d'une authentification absente ou non alignée, d'en-têtes d'envoi en masse manquants ou d'un domaine d'envoi tout neuf sans historique de conformité. Il est réversible dès que vous corrigez le problème de fond et, contrairement à TSS04, il n'y a aucun délai d'attente : le message suivant passe ou échoue selon ses propres mérites.

Vérifiez d'abord l'alignement SPF, DKIM et DMARC avec les outils de recherche SPF, de recherche DKIM et de recherche DMARC. Ajoutez les en-têtes de désinscription one-click. Inscrivez-vous à la CFL de Yahoo. Puis envoyez un seul message de test. Si l'authentification est correcte, le 554 5.7.9 s'arrête immédiatement.

Si vous voulez une visibilité continue sur les signaux d'authentification à l'origine de ces rejets de politique (rapports DMARC, dérive de l'alignement DKIM/SPF, en-têtes d'envoi en masse manquants), MailVitals surveille tout cela 24 h/24, 7 j/7 pour que vous puissiez prévenir le prochain 554 5.7.9 au lieu de le découvrir dans un rapport de bounce.

👉 À lire ensuite : Report Yahoo 421 4.7.0 TSS04 · Exigences de Gmail et Yahoo pour les expéditeurs en 2026 · Les codes d'erreur SMTP expliqués

Sources

• Sender Requirements and Recommendations (Yahoo Sender Hub), les exigences de Yahoo : SPF ou DKIM pour tous les expéditeurs ; SPF, DKIM, DMARC, alignement et List-Unsubscribe pour les expéditeurs en masse.
• SMTP Error Codes (Yahoo Sender Hub), les causes données par Yahoo pour les rejets 553 et 554, dont les échecs d'authentification et les listages Spamhaus, et sa règle de ne jamais réessayer un 5xx.
• IANA SMTP Enhanced Status Codes registry, la signification enregistrée du 5.7.9 et des autres codes X.7.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), le fonctionnement de l'alignement DMARC avec SPF ou DKIM.
• RFC 8058: Signaling One-Click Functionality for List Email Headers, le POST de désinscription one-click que recommande Yahoo.