Defaults.Exposed › Javítások › Guides

Yahoo 554 5.7.9 „Message Not Accepted for Policy Reasons" — A küldői javítás (2026)

Közzétéve 2026-07-08

Adatok: 2026-06-29 · 7. módszertan. Összesített népszámlálási adatok 261 millió értékelt domain alapján. Lásd: hogyan értékelünk.

A Yahoo 554 5.7.9 választ ad, ha az üzenet megsérti a küldői szabályzatát — általában sikertelen SPF/DKIM hitelesítés vagy a Yahoo által érvényesített DMARC-szabályzat miatt. Javítsa azzal, hogy az SPF vagy DKIM átmenjen, igazítva a Feladó domainjéhez. A Defaults.Exposed 261,086,232 domainre kiterjedő népszámlálása (2026-06-29) szerint csupán 10.59% érvényesíti a DMARC-ot — 27,640,987 domain.

A javítás DNS és listatisztítás, nem egy panaszűrlap: diagnosztizálja, melyik szabályzatot sérti, biztosítsa az SPF vagy DKIM átmenetét a megfelelő domainhez, igazítsa a sikeres igazítást a Feladó-cím domainjéhez, tegyen közzé DMARC-ot, ha tömeges küldőként küld, és adjon hozzá egyetlen kattintásos leiratkozást. Az alábbiakban a lépéssorrend, plusz a Yahoo testvérkódjainak — 553 5.7.1, 553 5.7.2 és a 421 halasztások — dekódolója.

Mit jelent a Yahoo 554 5.7.9 hiba?

2024 februárja óta a Yahoo ugyanazt a küldői szabálykészletet érvényesíti, mint a Gmail: minden küldőnek át kell mennie az SPF-en vagy a DKIM-en; a tömeges küldőknek mindkettőn át kell menniük, a sikeres mechanizmusnak igazodnia kell a Feladó domainjéhez, DMARC-szabályzatot kell közzétenniük, RFC 8058 egyetlen kattintásos leiratkozást kell kínálniuk a feliratkozott levelekhez, és alacsonyan kell tartaniuk a panaszarányt. A Yahoo szándékosan nem tesz közzé volumetriás határt a „tömeges” meghatározásához — a Google párhuzamos szabálya 5 000 naponta küldött üzenetnél húzza meg a határt, és ez a munkabenchmark, amelyet a legtöbb küldő használ. Az AOL postaládák ugyanazon az infrastruktúrán futnak, tehát egyetlen javítás fedez mindkettőt.

Az 554 5.7.9 a Yahoo végleges szabályzati visszautasítása. A klasszikus alak: “554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes” — szándékosan általános, mert az egész szabályzatcsaládot lefedi: hitelesítési hibák, DMARC-érvényesítés (beleértve a küldő domain saját p=reject értékét), és küldői irányelvek megszegése. A Gmail 550-5.7.26-tól eltérően a szöveg ritkán mondja meg, melyik igazítás hibázott, ezért az alábbi 1. lépés — a domain külső-belső vizsgálata — itt még fontosabb, nem kevésbé.

Az alapvető rés hatalmas: a 2026-06-29 dátumú 261,086,232 domainre kiterjedő népszámlálás szerint 46.4% (121,145,609) egyáltalán nem tesz közzé SPF-rekordot, és csupán 10.59% érvényesíti a DMARC-ot. A Yahoo nem kér semmi egzotikusat — a hitelesítetlen többségtől utasítja vissza a leveleket.

Melyik Yahoo visszapattanás-kódja van?

Hasonlítsa a hibaértesítőjét (NDR) ehhez a táblához — minden bejegyzést „hasonló visszapattanásként:” kezelve, mert a Yahoo hivatalosan hibakategóriákat tesz közzé, nem szó szerinti karakterláncokat, és a pontos szöveg és a zárójelben lévő okjelölők (mint [TSS04]) a valós megfigyelésből valók, és időről időre változnak. Hasonlítsa a töredékeket a tényleges visszapattanáshoz és a Yahoo Sender Hub hibakód-listájához.

Két őszinte megjegyzés a táblához. A 421 halasztás a Yahoo szabályozása, amíg dönt — tartsa be az újrapróbálkozást, lassítson, és javítsa a panasz oldalát; a sor erőltetése a halasztásokat 553-assá változtatja. És egyetlen DNS-rekord sem vesz le egy blokklistán lévő IP-t: a hitelesítés megállítja a szabályzati visszautasításokat és megelőzi a visszaeséseket, de az IP hírneve csak idővel, tiszta küldésen keresztül áll helyre.

Hogyan javítja a 554 5.7.9-et, lépésről lépésre?

1. Futtassa először az ingyenes vizsgálatot a defaults.exposed oldalon. Kívülről olvassa az élő SPF-, DKIM- és DMARC-rekordokat — ugyanaz a nézet, amit a Yahoo kap —, és megmutatja, melyik igazítás hibázik, mielőtt hozzányúl a DNS-hez.
2. Biztosítsa az SPF átmenetét arra a domainre, amelyet a Yahoo ténylegesen ellenőriz. Az a gát, amely a küldők felét elkapja: a vevők az SPF-et a Return-Path (RFC5321.MailFrom) domain, nem a Feladó fejléc ellen értékelik. Ha egy hírlevéleszköz vagy CRM küld Önért, az SPF-et általában az ő bounce-domainjük ellen értékelik — ezért lehet tökéletes és irreleváns a saját SPF-rekordja. Erősítse meg, melyik domainre pattannak vissza a levelei, majd gondoskodjon arról, hogy az adott domain SPF-je lefedi a küldési forrást.
3. Engedélyezze a DKIM-aláírást a saját domainjével. A szolgáltatójánál vagy ESP-jénél kapcsolja be az egyéni domainre szóló DKIM-et (általában két-három CNAME-rekord), hogy az aláírások d=sajatdomain.hu értéket mutassanak, ne a platform alapértelmezettjét. Platform útmutatók: Mailchimp, Brevo és Klaviyo DMARC-hibák.
4. Igazítsa az átmenő igazítást a Feladó domainjéhez. A Yahoo követelményei — a DMARC-hoz hasonlóan — az igazítással törődnek: az SPF vagy DKIM olyan domainre megy át, amely egyezik a Feladó-cím domainjével. Ha a vizsgálat zölden mutatja az SPF-et és a DKIM-et, de a Yahoo még mindig visszautasítja, igazítási csapdában van — lásd: DMARC megbukik, de az SPF és a DKIM átmegy.
5. Ha tömeges küldőként küld, tegyen közzé DMARC-rekordot. A Yahoo legalább p=none értéket vár el egy jelentési címmel a tömeges küldőktől — nem tesz közzé kemény volumetriás számot, tehát kezelje a Google 5 000/nap értékét munkabenchmarkként. Ez egyetlen TXT-rekord a _dmarc alatt — lásd a DMARC javítási útmutatót a rekordhoz és az emelési tervhez, illetve az IONOS DMARC-beállítási útmutatót egy kidolgozott vezérlőpaneles példáért. Az érvényesítéssel a domaineknek 89.41%-a előtt jár.
6. Adjon hozzá RFC 8058 egyetlen kattintásos leiratkozást (List-Unsubscribe + List-Unsubscribe-Post fejlécek) a marketing- és feliratkozott levelekhez, és teljesítse a leiratkozásokat két napon belül. A jó hírű ESP-k automatikusan hozzáadják ezeket, amint a domain-hitelesítés be van kapcsolva — ellenőrizze egy elküldött üzenet fejlécében.
7. Tartsa alacsonyan a panaszokat. A Yahoo komolyan veszi a felhasználói „spam”-jelöléseket — tartsa a spam-arányát 0,3% alatt —, és a tartós panasznövekedések a fő út a 421 halasztástól a 553/554 visszautasításokig. Regisztráljon a Yahoo panaszvisszajelzési hurkára a Sender Hubon keresztül, tisztítsa meg az inaktív címeket, és soha ne küldjön megvásárolt listákra.

A küldők többsége a 2–4. lépésnél tisztítja az 554 5.7.9-et; az 5–7. lépések tartják ki a halasztási ciklusból utána. A mindkét szolgáltatóra vonatkozó teljes követelmény-listához — küszöbök, fejlécek, spam-arány-számok — lásd a Google és Yahoo küldői követelményeiről szóló referenciacikkünket; ez az útmutató a visszapattanás javítására összpontosít.

Vonatkoznak-e a Yahoo szabályai a kis küldőkre?

A tömeges ellenőrzőlista — mindkét SPF és DKIM, igazítás, DMARC közzétéve, egyetlen kattintásos leiratkozás — formálisan a jelentős mennyiséget küldőkre vonatkozik, és a Yahoo kifejezetten megtagadja a számot a „jelentős” meghatározásában (a Google párhuzamos szabálya 5 000 naponta küldött üzenetet használ, a szokásos munkabenchmarkot). De az alapvető hitelesítést mindenktől elvárják, és az 554 5.7.9 nem ellenőrzi a forgalmát, mielőtt tüzel: a kis küldők azért kapják az ESP megosztott infrastruktúráján keresztül, a saját domain p=reject értékével nem igazított levél miatt, vagy egyszerűen azért, mert hitelesítés nélküli domainről küldenek — a domaineknek az SPF-rekord nélküli 46.4%-a (2026-06-29 népszámlálás). Kezelje az 1–4. lépéseket kötelezőként minden kötetben.

Ez ugyanaz, mint a Gmail 550-5.7.26?

Ugyanaz a szabálykészlet-család, más dialektus. A Google és a Yahoo 2023 végén együtt jelentette be a követelményeit, és mindkettő 2024 februárjától kezdett érvényesíteni, tehát az egyikre javított domain lényegében a másikra is javított. A gyakorlati különbségek: a Gmail visszapattanás szövege általában megnevezi a hibás mechanizmust, a Yahoo 554 5.7.9-e általában nem; és a Yahoo keményebben támaszkodik a panasz-vezérelt IP-halasztásokra. Mindkettőn visszapattan? Javítson itt egyszer, majd ellenőrizze a Gmail-specifikus dolgokat az 550-5.7.26 útmutatóban.

Gyakran ismételt kérdések

Az 554 5.7.9 azt jelenti, hogy a Yahoo blokklistára tette a domainemét? Általában nem. Ez szabályzati visszautasítás — leggyakrabban hitelesítési —, nem hírnévítélet, és teljesen javítható a DNS-ben. Rendkívül általános is az álláspont: 261,086,232 domain 2026-06-29 dátumú népszámlálása szerint csupán 10.59% érvényesít DMARC-szabályzatot. A tartós 553 5.7.2 visszautasítások a hitelesítés rendbe hozása után azok a hírnév-esetek.

Miért pattan vissza a hírlevelem a Yahoohoz, ha a Feladó cím @yahoo.com? Mert a Yahoo 2014-ben p=reject értéket tett közzé a saját fogyasztói domainjein — minden harmadik fél által @yahoo.com Feladóval küldött levél megbukik a Yahoo saját DMARC-ján és elutasításra kerül, szándékosan. A javítás strukturális: küldjön a saját domainjéről, saját hitelesítéssel, nem egy ingyenes e-mail-címről. Az ESP egyéni domain-beállítása az út — lásd a hírlevélplatform útmutatót.

Mennyi idővel a DNS javítása után fogadja el a Yahoo a leveleimet? A hitelesítési javítások azonnal hatnak, amint az új rekordok láthatók — perceken belül néhány óráig, lassú TTL esetén legfeljebb 48 óra. A hírnév-helyreállítás lassabb: a 421 halasztások napok alatt elmúlnak tiszta, panaszmentes küldéssel, és egy 553 5.7.2 végleges halasztás hetekig tarthat, vagy egy friss felmelegítésre lehet szüksége.

Küldje el a tulajdonosnak a jelentést

Ha ezt a visszapattanást egy ügyfél érdekében tisztítja, ne zárja le a jegyet azzal: „A Yahoo megint elfogadja a leveleinket”. Futtassa újra az ingyenes vizsgálatot a módosítások után, és küldje el az értékelt jelentést a vállalkozás tulajdonosának. Egyszerű magyar nyelven megmutatja, hogy a domain most hitelesíti az e-mailjeit, és hol marad még el — az a bizonyíték, amelyre szükségük lesz a kibervédelmi biztosítás megújításakor és a szállítói biztonsági kérdőíveknél. Javította a visszapattanást; a jelentés bizonyítja.

Ellenőrizze a domainjét → · Gmail 550-5.7.26 útmutató → · DMARC javítása → · Hogyan értékelünk → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.