Defaults.Exposed › Åtgärder › Guides
Yahoo 554 5.7.9 "Message Not Accepted for Policy Reasons" — Avsändarfixen (2026)
Publicerad 2026-07-08
Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.
Yahoo returnerar 554 5.7.9 när ett meddelande bryter mot dess avsändarpolicy — vanligtvis misslyckad SPF/DKIM-autentisering eller en DMARC-policy som Yahoo tillämpar. Åtgärda det genom att få SPF eller DKIM att godkännas, anpassat till din From-domän. Bara 10.59% av domänerna tillämpar DMARC — 27,640,987 av dem — enligt Defaults.Exposed-censuset med 261,086,232 domäner (2026-06-29).
Fixen är DNS och listhygien, inte ett överklagandeformulär: diagnostisera vilken policy du bryter mot, få SPF eller DKIM att godkännas för rätt domän, anpassa det vinnande benet till din From-adress, publicera DMARC om du skickar i volym och lägg till ettpklicksavprenumeration. Nedan finns stegordningen plus en avkodare för Yahoos syskorkoder — 553 5.7.1, 553 5.7.2 och 421-uppsoven.
Vad betyder Yahoo-felet 554 5.7.9?
Sedan februari 2024 tillämpar Yahoo samma avsändarregeluppsättningsfamilj som Gmail: varje avsändare bör godkännas med SPF eller DKIM; bulk-avsändare måste godkännas med båda, med det godkända mekanismet anpassat till From-domänen, publicera en DMARC-policy, erbjuda RFC 8058 ettpklicksavprenumeration på prenumererad e-post och hålla klagomålsfrekvensen låg. Yahoo vägrar avsiktligt att publicera ett volymtröskel för “bulk” — Googles parallella regel drar sin linje vid 5 000 meddelanden per dag, och det är det fungerande riktmärket de flesta avsändare använder. AOL-postlådor kör på samma infrastruktur, så en fix täcker båda.
554 5.7.9 är Yahoos permanenta policyavvisning. Den klassiska formen lyder: “554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes” — avsiktligt generisk, eftersom den täcker hela policyfamiljen: autentiseringsfel, DMARC-tillämpning (inklusive den sändande domänens egna p=reject) och avsändarriktlinjeöverträdelser. Till skillnad från Gmails 550-5.7.26 talar texten sällan om vilket ben som misslyckades, så steg 1 nedan — en utifrån-in-skanning av din domän — spelar större roll här, inte mindre.
Det underliggande gapet är enormt: i 2026-06-29-censuset med 261,086,232 domäner publicerar 46.4% (121,145,609) ingen SPF-post alls, och bara 10.59% tillämpar DMARC. Yahoo begär ingenting exotiskt — det avvisar e-post från den oautentiserade majoriteten.
Vilken Yahoo-studskod har du?
Matcha ditt NDR mot den här tabellen — behandla varje post som “en studs som:”, eftersom Yahoo officiellt publicerar felkategorier snarare än verbatimsträngar, och den exakta formuleringen och hakparentes-orsakstaggarna (som [TSS04]) observeras i verkligheten och förskjuts med tiden. Kontrollera fragmenten mot din faktiska studs och Yahoos Sender Hub-felkodslista.
| Kod | En studs som (fragment) | Vad det betyder | Var fixen är |
|---|---|---|---|
| 554 5.7.9 | ”Message not accepted for policy reasons” | Permanent policyavvisning — autentisering, DMARC eller avsändarriktlinjefel | Den här guiden, steg 2–6 |
| 553 5.7.1 | IP- eller innehållspolitytext, ofta med en hakparentes-orsaks-tag (t.ex. blocklista-referens) | Yahoo accepterar inte från den här IP/källan — rykte eller policyblock | Steg 2–3, sedan ren sändning; autentisering förhindrar återfall men tar inte bort en IP från blocklistan |
| 553 5.7.2 | ”will be permanently deferred” / att försöka igen lyckas inte | Ihållande ryktes-misslyckande på den sändande IP:n — den hårda versionen av ett uppskov | Steg 2–7, ny-IP-uppvärmning om egenhostad |
| 421 4.7.0 | ”temporarily deferred due to unexpected volume or user complaints” (ofta en [TSS]-tag) | Tillfälligt uppskov — hastighets- eller klagomåls-topp, inte ett permanent block | Omförsöksköer töms; åtgärda steg 5–7 så det slutar återkomma |
Två ärliga noteringar om den tabellen. Ett 421-uppskov är Yahoo som stryper dig medan det bestämmer sig — respektera omförsöket, sakta ner och åtgärda klagomåls-sidan; att bombardera kön omvandlar uppskov till 553:or. Och ingen DNS-post tar bort en blocklist-ad IP: autentisering stoppar policy-avvisningarna och förhindrar återfall, men IP-rykte återhämtar sig bara genom ren sändning med tiden.
Hur åtgärdar du 554 5.7.9, steg för steg?
- Kör den kostnadsfria sökningen på defaults.exposed först. Den läser dina live SPF-, DKIM- och DMARC-poster utifrån — samma vy som Yahoo får — och visar vilket ben som misslyckas innan du rör DNS.
- Få SPF att godkännas för domänen Yahoo faktiskt kontrollerar. Varningen som fångar hälften av alla avsändare: mottagare utvärderar SPF mot Return-Path (RFC5321.MailFrom)-domänen, inte From-rubriken. Om ett nyhetsbrevverktyg eller CRM skickar åt dig utvärderas SPF vanligtvis mot deras studsdomän — vilket är varför din egna SPF-post kan vara perfekt och irrelevant. Bekräfta vilken domän dina studsmeddelanden returnerar till, se sedan till att den domänens SPF täcker den sändande källan.
- Aktivera DKIM-signering med din egna domän. Hos din leverantör eller ESP, slå på anpassad domän-DKIM (vanligtvis två eller tre CNAME-poster) så att signaturer säger
d=yourdomain.com, inte plattformens standard. Plattformsgenomgångar: Mailchimp, Brevo och Klaviyo DMARC-misslyckanden. - Gör det godkända benet anpassat till din From-domän. Yahoos krav — precis som DMARC — bryr sig om anpassning: SPF eller DKIM som godkänns för en domän som matchar den i din From-adress. Om din sökning visar SPF och DKIM gröna men Yahoo fortfarande avvisar befinner du dig i anpassningsfällan — se DMARC misslyckas men SPF och DKIM godkänns.
- Publicera en DMARC-post om du skickar i volym. Yahoo kräver minst
p=nonemed en rapportadress från bulk-avsändare — det publicerar inget hårt volymtal, så behandla Googles 5 000/dag som det fungerande riktmärket. Det är en TXT-post vid_dmarc— se DMARC-fixguiden för posten och trappprocedurplanen, och IONOS DMARC-konfigurationsguiden för ett genomarbetat kontrollpanelexempel. Du kommer att vara steget före 89.41% av domänerna genom att tillämpa det så småningom. - Lägg till RFC 8058 ettpklicksavprenumeration (
List-Unsubscribe+List-Unsubscribe-Post-rubriker) på marknadsförings- och prenumererad e-post, och hedra avprenumerationer inom två dagar. Välrenommerade ESP:er lägger till dessa automatiskt när domänautentisering är på — verifiera i ett skickat meddelandets rubriker. - Håll klagomål låga. Yahoo väger användares “markera som skräppost”-åtgärder tungt — håll din skräppostfrekvens under 0,3% — och ihållande klagomålstoppar är huvudvägen från 421-uppskov till 553/554-avvisningar. Registrera dig för Yahoos klagomålsfeedback-loop via dess Sender Hub, rensa inaktiva adresser och mejla aldrig köpta listor.
De flesta avsändare rensar 554 5.7.9 vid steg 2–4; steg 5–7 är det som håller dig borta från uppskovscykeln efteråt. För den fullständiga kravlistan hos båda leverantörerna — trösklar, rubriker, skräppostfrekvens-tal — se vår referensartikel om Googles och Yahoos avsändarkrav; den här guiden fokuserar på att få studsen åtgärdad.
Gäller Yahoos regler för små avsändare?
Den fullständiga bulk-checklistan — både SPF och DKIM, anpassning, DMARC publicerat, ettpklicksavprenumeration — gäller formellt avsändare av betydande volym, och Yahoo vägrar uttryckligen att sätta ett tal på “betydande” (Googles parallella regel använder 5 000 meddelanden per dag, det vanliga fungerande riktmärket). Men grundläggande autentisering förväntas av alla, och 554 5.7.9 kontrollerar inte din volym innan den utlöses: små avsändare träffar den via sin ESP:s delade infrastruktur, via sin egna domäns p=reject med oanpassad e-post, eller helt enkelt genom att skicka från en domän utan autentisering alls — de 46.4% av domänerna utan SPF-post (2026-06-29-censuset). Behandla steg 1–4 som obligatoriska vid vilken volym som helst.
Är detta detsamma som Gmails 550-5.7.26?
Samma regeluppsättningsfamilj, annat dialekt. Google och Yahoo tillkännagav sina krav tillsammans i slutet av 2023 och båda började tillämpa i februari 2024, så en domän åtgärdad för en är i princip åtgärdad för den andra. De praktiska skillnaderna: Gmails studstext namnger vanligtvis den misslyckade mekanismen, Yahoos 554 5.7.9 gör det vanligtvis inte; och Yahoo lutar hårdare på klagomålsdrivna IP-uppskov. Studsar hos båda? Åtgärda här en gång, kontrollera sedan Gmail-specifiken i 550-5.7.26-guiden.
Vanliga frågor
Betyder 554 5.7.9 att Yahoo har blocklist-at min domän? Vanligtvis inte. Det är en policyavvisning — oftast autentisering — inte en ryktes-dom, och den är fullt åtgärdbar i DNS. Det är också extremt vanlig mark att stå på: bara 10.59% av 261,086,232 domäner tillämpar en DMARC-policy per 2026-06-29-censuset. Ihållande 553 5.7.2-avvisningar efter att din autentisering är ren är ryktessfallet.
Varför studsar mitt nyhetsbrev hos Yahoo när From-adressen är @yahoo.com?
Eftersom Yahoo publicerade p=reject på sina egna konsumentdomäner redan 2014 — vilken tredjepartstjänst som helst som skickar From @yahoo.com misslyckas med Yahoos egna DMARC och avvisas, med avsikt. Fixen är strukturell: skicka från din egna domän med dess egna autentisering, inte från en gratismejl-adress. Din ESP:s anpassade domänkonfiguration är vägen — se nyhetsbrevplattformsguiden.
Hur länge efter att ha åtgärdat DNS kommer Yahoo att acceptera min e-post? Autentiseringsfixar verkar så snart dina nya poster är synliga — minuter till några timmar, upp till 48 för låga TTL:er. Ryktes-återhämtning är långsammare: 421-uppskov avtar över dagar av ren, klagomålsfri sändning, och ett permanent 553 5.7.2-uppskov kan ta veckor eller en ny uppvärmning.
Skicka ägaren rapporten
Om du rensar den här studsen för en kund, avsluta inte ärendet med “Yahoo accepterar vår e-post igen”. Kör om den kostnadsfria sökningen efter dina ändringar och vidarebefordra den graderade rapporten till företagsägaren. Den visar, på klarspråk, att domänen nu autentiserar sin e-post och var den fortfarande faller kort — beviset de behöver för förnyelse av cyberförsäkring och leverantörers säkerhetsenkäter. Du åtgärdade studsen; rapporten bevisar det.
Kontrollera din domän → · Gmail 550-5.7.26-guiden → · Åtgärda DMARC → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.