Yahoo 554 5.7.9 « Message Not Accepted for Policy Reasons » — le correctif côté expéditeur (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Yahoo renvoie 554 5.7.9 quand un message viole sa politique d’expéditeur — généralement une authentification SPF/DKIM en échec ou une politique DMARC que Yahoo applique. Corrigez cela en faisant passer SPF ou DKIM, aligné avec votre domaine From. Seuls 10,59% des domaines appliquent DMARC — 27 640 987 d’entre eux — selon le recensement Defaults.Exposed portant sur 261 086 232 domaines (2026-06-29).

Le correctif relève du DNS et de l’hygiène de liste, pas d’un formulaire d’appel : diagnostiquez quelle politique vous déclenchez, faites passer SPF ou DKIM pour le bon domaine, alignez la branche gagnante avec votre adresse From, publiez DMARC si vous envoyez en volume, et ajoutez le désabonnement en un clic. Ci-dessous, l’ordre des étapes plus un décodeur pour les codes cousins de Yahoo — 553 5.7.1, 553 5.7.2 et les reports 421.

Que signifie l’erreur Yahoo 554 5.7.9 ?

Depuis février 2024, Yahoo applique la même famille de règles d’expéditeur que Gmail : chaque expéditeur doit passer SPF ou DKIM ; les expéditeurs en masse doivent passer les deux, avec le mécanisme qui passe aligné sur le domaine From, publier une politique DMARC, offrir le désabonnement en un clic RFC 8058 sur le courrier sur abonnement, et garder le taux de plainte bas. Yahoo refuse délibérément de publier un seuil de volume pour « masse » — la règle parallèle de Google fixe sa limite à 5 000 messages par jour, et c’est le repère de travail que la plupart des expéditeurs utilisent. Les boîtes AOL fonctionnent sur la même infrastructure, donc un seul correctif couvre les deux.

554 5.7.9 est le rejet de politique permanent de Yahoo. La forme classique se lit : « 554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes » — délibérément générique, parce qu’elle couvre toute la famille de politique : échecs d’authentification, application DMARC (y compris le p=reject du domaine émetteur lui-même), et violations des règles d’expéditeur. Contrairement au 550-5.7.26 de Gmail, le texte indique rarement quelle branche a échoué, donc l’étape 1 ci-dessous — un scan externe de votre domaine — compte davantage ici, pas moins.

L’écart sous-jacent est énorme : sur le recensement 2026-06-29 de 261 086 232 domaines, 46,4% (121 145 609) ne publient aucun enregistrement SPF du tout, et seuls 10,59% appliquent DMARC. Yahoo ne demande rien d’exotique — il rejette le courrier de la majorité non authentifiée.

Quel code de rebond Yahoo avez-vous ?

Comparez votre NDR à ce tableau — en traitant chaque entrée comme « un rebond du type », parce que Yahoo publie officiellement des catégories d’erreur plutôt que des chaînes verbatim, et la formulation exacte ainsi que les balises de raison entre crochets (comme [TSS04]) sont observées dans la nature et évoluent avec le temps. Vérifiez les fragments contre votre rebond réel et la liste des codes d’erreur du Sender Hub de Yahoo.

Code	Un rebond du type (fragment)	Ce que cela signifie	Où se trouve le correctif
554 5.7.9	« Message not accepted for policy reasons »	Rejet de politique permanent — échec d’authentification, DMARC ou règle d’expéditeur	Ce guide, étapes 2–6
553 5.7.1	Texte de politique IP ou contenu, souvent avec une balise de raison entre crochets (par ex. référence de liste noire)	Yahoo n’accepte pas de cette IP/source — réputation ou blocage de politique	Étapes 2–3, puis envoi propre ; l’authentification empêche les rechutes mais ne déliste pas une IP
553 5.7.2	« will be permanently deferred » / relancer ne réussira pas	Échec de réputation soutenu sur l’IP d’envoi — la version dure d’un report	Étapes 2–7, montée en puissance sur nouvelle IP si auto-hébergé
421 4.7.0	« temporarily deferred due to unexpected volume or user complaints » (souvent une balise [TSS])	Report temporaire — pic de taux ou de plaintes, pas un blocage permanent	Les files de relance se videront ; corrigez les étapes 5–7 pour que cela cesse de se reproduire

Deux notes honnêtes sur ce tableau. Un report 421 est Yahoo qui vous ralentit pendant qu’il décide — respectez la relance, ralentissez, et corrigez le côté plaintes ; marteler la file transforme les reports en 553. Et aucun enregistrement DNS ne déliste une IP sur liste noire : l’authentification arrête les rejets de politique et empêche les rechutes, mais la réputation d’IP ne se rétablit qu’avec un envoi propre dans le temps.

Comment corriger le 554 5.7.9, étape par étape ?

Lancez d’abord le scan gratuit sur defaults.exposed. Il lit vos enregistrements SPF, DKIM et DMARC en direct depuis l’extérieur — la même vue que Yahoo — et montre quelle branche échoue avant que vous touchiez au DNS.
Faites passer SPF pour le domaine que Yahoo vérifie réellement. Le garde-fou qui piège la moitié des expéditeurs : les destinataires évaluent SPF contre le domaine du Return-Path (RFC5321.MailFrom), pas l’en-tête From. Si un outil de newsletter ou un CRM envoie pour vous, SPF est généralement évalué contre leur domaine de rebond — c’est pourquoi votre propre enregistrement SPF peut être parfait et sans importance. Confirmez vers quel domaine reviennent vos rebonds, puis assurez-vous que le SPF de ce domaine couvre la source d’envoi.
Activez la signature DKIM avec votre propre domaine. Chez votre prestataire ou ESP, activez le DKIM en domaine personnalisé (généralement deux ou trois enregistrements CNAME) pour que les signatures disent d=votredomaine.com, pas le défaut de la plateforme. Guides par plateforme : échecs DMARC de Mailchimp, Brevo et Klaviyo.
Faites en sorte que la branche qui passe s’aligne avec votre domaine From. Les exigences de Yahoo — comme DMARC — se soucient de l’alignement : SPF ou DKIM qui passe pour un domaine correspondant à celui de votre adresse From. Si votre scan montre SPF et DKIM en vert mais que Yahoo rejette quand même, vous êtes dans le piège de l’alignement — voir DMARC échoue mais SPF et DKIM passent.
Publiez un enregistrement DMARC si vous envoyez en volume. Yahoo exige au moins p=none avec une adresse de rapport pour les expéditeurs en masse — il ne publie aucun chiffre de volume strict, donc traitez les 5 000/jour de Google comme le repère de travail. C’est un enregistrement TXT à _dmarc — voir le guide de correction DMARC pour l’enregistrement et le plan de resserrement, et le guide de configuration DMARC sur IONOS pour un exemple concret de panneau de contrôle. Vous serez devant 89,41% des domaines en l’appliquant à terme.
Ajoutez le désabonnement en un clic RFC 8058 (en-têtes List-Unsubscribe + List-Unsubscribe-Post) sur le courrier marketing et sur abonnement, et honorez les désabonnements sous deux jours. Les ESP réputés les ajoutent automatiquement une fois l’authentification de domaine activée — vérifiez dans les en-têtes d’un message envoyé.
Gardez les plaintes basses. Yahoo pèse lourdement les actions « marquer comme spam » des utilisateurs — gardez votre taux de spam sous 0,3 % — et les pics de plaintes soutenus sont la principale voie des reports 421 vers les rejets 553/554. Inscrivez-vous à la boucle de rétroaction plaintes de Yahoo via son Sender Hub, élaguez les adresses non engagées, et n’envoyez jamais à des listes achetées.

La plupart des expéditeurs résolvent le 554 5.7.9 aux étapes 2–4 ; les étapes 5–7 vous gardent hors du cycle de report par la suite. Pour la liste complète des exigences des deux prestataires — seuils, en-têtes, chiffres de taux de spam — voir notre article de référence sur les exigences des expéditeurs Google et Yahoo ; ce guide reste concentré sur la correction du rebond.

Les règles de Yahoo s’appliquent-elles aux petits expéditeurs ?

La checklist en masse — SPF et DKIM tous deux, alignement, DMARC publié, désabonnement en un clic — s’applique formellement aux expéditeurs de volume significatif, et Yahoo refuse explicitement de mettre un chiffre sur « significatif » (la règle parallèle de Google utilise 5 000 messages par jour, le repère de travail courant). Mais l’authentification de base est attendue de tout le monde, et le 554 5.7.9 ne vérifie pas votre volume avant de se déclencher : les petits expéditeurs le rencontrent via l’infrastructure partagée de leur ESP, via le p=reject de leur propre domaine avec du courrier non aligné, ou simplement en envoyant depuis un domaine sans aucune authentification — les 46,4% de domaines sans enregistrement SPF (recensement 2026-06-29). Traitez les étapes 1–4 comme obligatoires à tout volume.

Est-ce la même chose que le 550-5.7.26 de Gmail ?

Même famille de règles, dialecte différent. Google et Yahoo ont annoncé leurs exigences ensemble fin 2023 et ont tous deux commencé à les appliquer en février 2024, donc un domaine corrigé pour l’un est essentiellement corrigé pour l’autre. Les différences pratiques : le texte de rebond de Gmail nomme généralement le mécanisme en échec, celui du 554 5.7.9 de Yahoo généralement pas ; et Yahoo s’appuie davantage sur les reports d’IP pilotés par les plaintes. Vous rebondissez sur les deux ? Corrigez ici une fois, puis vérifiez les spécificités Gmail dans le guide 550-5.7.26.

Questions fréquentes

Le 554 5.7.9 signifie-t-il que Yahoo a mis mon domaine sur liste noire ? Généralement non. C’est un rejet de politique — le plus souvent une authentification — pas un verdict de réputation, et c’est entièrement corrigible dans le DNS. C’est aussi un terrain extrêmement commun : seuls 10,59% des 261 086 232 domaines appliquent une politique DMARC au moment du recensement 2026-06-29. Des rejets 553 5.7.2 persistants après que votre authentification est propre relèvent du cas de réputation.

Pourquoi ma newsletter rebondit-elle chez Yahoo alors que l’adresse From est @yahoo.com ? Parce que Yahoo a publié p=reject sur ses propres domaines grand public dès 2014 — tout service tiers envoyant depuis @yahoo.com échoue le propre DMARC de Yahoo et se fait rejeter, par conception. Le correctif est structurel : envoyez depuis votre propre domaine avec sa propre authentification, pas depuis une adresse freemail. La configuration de domaine personnalisé de votre ESP est la voie — voir le guide plateforme de newsletter.

Combien de temps après avoir corrigé le DNS Yahoo acceptera-t-il mon courrier ? Les correctifs d’authentification agissent dès que vos nouveaux enregistrements sont visibles — de quelques minutes à quelques heures, jusqu’à 48 pour les TTL lents. Le rétablissement de la réputation est plus lent : les reports 421 s’estompent après des jours d’envoi propre et sans plainte, et un report permanent 553 5.7.2 peut prendre des semaines ou une nouvelle montée en puissance.

Envoyez le rapport au propriétaire

Si vous corrigez ce rebond pour un client, ne fermez pas le ticket avec « Yahoo accepte à nouveau notre courrier ». Relancez le scan gratuit après vos modifications et transmettez le rapport noté au chef d’entreprise. Il montre, en langage clair, que le domaine authentifie désormais son e-mail et où il reste en retard — la preuve dont il aura besoin pour les renouvellements de cyberassurance et les questionnaires de sécurité fournisseur. Vous avez corrigé le rebond ; le rapport le prouve.

Vérifiez votre domaine → · Guide Gmail 550-5.7.26 → · Corriger DMARC → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.