554 5.7.9 “Message not accepted for policy reasons”: zo los je het op bij Yahoo en AOL

Weigert Yahoo of AOL je e-mail regelrecht met een melding als deze, dan heb je te maken met een 554 5.7.9-weigering op basis van beleid:

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

Dit is geen tijdelijke deferral, niet de doorlopende throttling op basis van klachten ([TSS04]) en geen algemeen inhoudsfilter. 554 5.7.9 is een harde, permanente weigering op grond van het verzendersbeleid van Yahoo: iets aan de manier waarop het bericht is verstuurd, voldoet niet aan de basiscontroles die Yahoo uitvoert op bulk- of commerciële e-mail, en Yahoo weigert de bezorgpoging direct in plaats van hem in de wachtrij te zetten.

Omdat AOL, AIM en Verizon.net allemaal op de mailinfrastructuur van Yahoo draaien, geldt dezelfde 554 5.7.9-weigering voor al deze domeinen op precies dezelfde manier.

Wat 554 5.7.9 echt betekent

Ontleed het antwoord onderdeel voor onderdeel:

• 554: SMTP "transaction failed". Een 5xx-code is een permanente fout. Je MTA probeert het niet zelf opnieuw; het bericht bounct direct terug naar de oorspronkelijke verzender.
• 5.7.9: de uitgebreide statuscode. De 5 vooraan bevestigt de permanente fout. 7 is het onderwerp beleid/beveiliging. 9 staat geregistreerd als "authentication mechanism is too weak", een SMTP AUTH-code uit RFC 4954 (IANA-register); Yahoo hergebruikt hem voor berichten die het verzendersbeleid schenden.
• Message not accepted for policy reasons: de leesbare uitleg van Yahoo. Details ontbreken bewust: Yahoo vertelt niet welke beleidsregel afging, zodat misbruikers de drempels niet kunnen terugrekenen.
• senders.yahooinc.com: de postmasterdocumentatie van Yahoo, waar de onderliggende beleidseisen zijn gepubliceerd.

Het belangrijkste verschil met TSS04: TSS04 is een tijdelijke 4xx-deferral (421) die voortkomt uit je doorlopende klachtenpercentage. 554 5.7.9 is een permanente 5xx-weigering die voortkomt uit een beleidsschending in het bericht zelf of bij de verzender erachter. TSS04 verdwijnt vanzelf zodra je klachtenpercentage daalt; 554 5.7.9 verdwijnt pas als het onderliggende beleidsprobleem is opgelost.

De meest voorkomende oorzaken

Bij echte incidenten is 554 5.7.9 bijna altijd terug te voeren op een van deze oorzaken:

• Een ontbrekende, kapotte of niet-uitgelijnde DKIM-handtekening. Yahoo handhaaft de eisen voor bulkverzenders die Gmail en Yahoo in 2024 invoerden: DKIM is verplicht, en het domein in de From:-header moet overeenkomen met het DKIM-domein in d= of met het SPF-domein om DMARC te laten slagen. Een ontbrekende DKIM-handtekening of een fout in de alignment is veruit de meest voorkomende trigger.
• SPF mislukt of is niet uitgelijnd. Bulkverzenders moeten naast DKIM ook SPF implementeren. Alignment kan van een van beide komen, dus een SPF-pass zonder alignment is alleen in orde als DKIM wel uitgelijnd is.
• Geen DMARC-record, of DMARC p=none waarbij SPF noch DKIM uitgelijnd is. Het beleid van Yahoo voor bulkverzenders eist minimaal p=none en minstens één uitgelijnde authenticatie. Verzenders zonder enig gepubliceerd DMARC-record lopen het grootste risico op 554 5.7.9.
• Bulkmail versturen vanaf een gloednieuw domein zonder reputatie. Yahoo weigert koude domeinen bij het eerste contact sneller dan Gmail, vooral als het bericht qua opzet transactioneel of promotioneel oogt.
• Niet aangemeld bij de Complaint Feedback Loop (CFL) van Yahoo. Voor verzenders met een hoog volume is het ontbreken van een CFL-aanmelding op zichzelf al een beleidssignaal, omdat Yahoo verwacht dat bulkverzenders bereikbaar zijn voor klachtrapporten.
• Ontbrekende uitschrijfheader. Commerciële e-mail zonder werkende List-Unsubscribe-header schendt de eisen van Yahoo voor bulkverzenders (Yahoo accepteert de mailto:-methode, maar raadt de POST volgens RFC 8058 met List-Unsubscribe-Post: List-Unsubscribe=One-Click sterk aan) en kan een harde weigering opleveren in plaats van een soft deferral.
• Inhoud of een template die een beleidsregel activeert. URL-verkorters, een weergavenaam die niet bij het From-adres past, of HTML die de echte verzender verhult, gaan allemaal in tegen de gedocumenteerde verzendersrichtlijnen van Yahoo.

Toont je bounce letterlijk de tekst Message not accepted for policy reasons en niets specifiekers, dan vertelt Yahoo je bewust niet welke regel afging. Je moet dan elk van de bovenstaande punten op volgorde controleren.

Stap voor stap oplossen

Werk deze lijst van boven naar beneden af. De stappen voor authenticatie overslaan en meteen naar "het domein opwarmen" springen, is de meest voorkomende reden dat verzenders dagenlang vast blijven zitten op 554 5.7.9.

1. Pauzeer de getroffen campagne. Een 5xx-weigering betekent dat het bericht permanent bounct. Elke extra poging is weer een bounce op je naam en weer een datapunt waarmee Yahoo je ziet als verzender die zich niet aan de regels houdt. Stop met versturen naar ontvangers bij Yahoo en AOL totdat het onderliggende beleidsprobleem is opgelost.
2. Controleer SPF op het verzenddomein. Haal het From-domein door de SPF-lookup. Controleer of het record bestaat, syntactisch geldig is, minder dan 10 DNS-lookups heeft, en of het IP-adres dat de e-mail echt verstuurt geautoriseerd is, direct of via een include: die je zelf beheert.
3. Controleer DKIM op het bericht. Pak een recent bericht en bekijk de header DKIM-Signature. Haal selector en domein door de DKIM-lookup om te bevestigen dat de publieke sleutel resolvet. Cruciaal: controleer of het DKIM-domein in d= overeenkomt met het From:-domein (of er relaxed mee uitgelijnd is). Een niet-uitgelijnde DKIM-handtekening slaagt voor DKIM maar faalt voor DMARC, en Yahoo behandelt dat als beleidsfout.
4. Controleer DMARC. Haal het From-domein door de DMARC-lookup. Je hebt minimaal een gepubliceerd record met p=none nodig, maar voor het bulkbeleid van Yahoo moet ook SPF of DKIM slagen met alignment. Een DMARC-record waarbij beide authenticaties op alignment falen, is in de praktijk hetzelfde als helemaal geen DMARC.
5. Controleer de headers voor bulkverzenders. Elk commercieel bericht naar Yahoo moet zowel List-Unsubscribe: <https://...>, <mailto:...> als List-Unsubscribe-Post: List-Unsubscribe=One-Click bevatten. Haal de ruwe headers op van een verzonden bericht en controleer of beide regels aanwezig en correct opgebouwd zijn. Zie onze gids over de eisen van Gmail en Yahoo voor bulkverzenders voor het precieze formaat.
6. Meld je aan voor de Complaint Feedback Loop van Yahoo. Registreer je verzenddomein via senders.yahooinc.com. Zonder CFL-aanmelding heb je geen zicht op klachten bij Yahoo en mis je een gedocumenteerde stap die bulkverzenders moeten zetten.
7. Controleer de inhoud en de From-header. Zorg dat de weergavenaam in From: past bij het echte verzenddomein (geen "Bank of America" <random@cheapdomain.xyz>), dat er geen URL-verkorters in de tekst staan en dat eventuele trackingredirects op een subdomein van het From-domein staan, niet bij een externe linkverkorter.
8. Test één bericht op laag volume. Staan authenticatie, headers en CFL op orde, stuur dan één bericht vanaf dezelfde infrastructuur naar een testadres bij Yahoo. Wordt het geaccepteerd, bouw dan langzaam op (zie de TSS04-gids voor de herstelcurve). Wordt het nog steeds geweigerd met 554 5.7.9, dan faalt een van de authenticatiechecks hierboven nog.

Hoe lang het duurt voordat 554 5.7.9 verdwijnt

Anders dan TSS04 is 554 5.7.9 niet tijdgebonden. Hij verdwijnt op het moment dat de overtreden beleidsvoorwaarde is gecorrigeerd, dus er is geen doorlopende periode om uit te zitten.

In de praktijk:

• Binnen enkele minuten als de oorzaak een ontbrekende of kapotte DKIM-handtekening of een niet-gepubliceerd DMARC-record was. Zodra DNS is doorgevoerd en het volgende bericht correct is ondertekend, stopt de weigering.
• Binnen 24 tot 48 uur als je je moet aanmelden voor de CFL, je List-Unsubscribe-headers moet repareren of moet wachten tot DNS-wijzigingen volledig zijn doorgevoerd bij de resolvers van Yahoo.
• Een week of langer, maar alleen als je in de weigering blijft versturen (elke gebouncede 5xx is een nieuw datapunt over je beleid) of als de onderliggende oorzaak een koud domein zonder reputatie is, dat ook na het repareren van de authenticatie nog een opwarmcurve nodig heeft.

Er bestaat geen delistingformulier voor 554 5.7.9. Het beleid van Yahoo verwijst verzenders uitdrukkelijk naar het oplossen van het onderliggende probleem en opnieuw proberen, niet naar het aanvragen van een handmatige beoordeling.

Veelgestelde vragen

Is 554 5.7.9 een blacklisting? Nee. Het is de eigen beleidsweigering van Yahoo, toegepast door de inkomende MTA's van Yahoo op basis van het bericht en de verzender. Yahoo noemt een Spamhaus-listing van je IP-adres wel als een van de oorzaken van zijn 5xx-weigeringen (Yahoo SMTP error codes), dus controleer je verzend-IP op Spamhaus voordat je dat uitsluit.

Waarin verschilt dit van TSS04? TSS04 is een tijdelijke 4xx-deferral die voortkomt uit je doorlopende klachtenpercentage, en hij verdwijnt vanzelf als dat percentage daalt. 554 5.7.9 is een permanente 5xx-weigering die voortkomt uit een beleidsschending (meestal authenticatie), en hij verdwijnt pas als je die schending oplost. Zie de TSS04-gids voor de kant van het klachtenpercentage.

Gedraagt AOL zich hetzelfde? Ja. AOL, AIM en Verizon.net draaien op de mailinfrastructuur van Yahoo en passen identieke 554 5.7.9-weigeringen toe. Weigert Yahoo je met 5.7.9, dan doet AOL dat ook.

Helpt het om het opnieuw te proberen? Nee. 554 is permanent. Je MTA probeert het niet zelf opnieuw, en handmatig opnieuw proberen stapelt alleen meer bounces op je verzendersreputatie. Los eerst de oorzaak op.

Moet ik contact opnemen met Yahoo om dit op te lossen? Nee. Er is geen supportticket of delistingprocedure voor 554 5.7.9. De documentatie van Yahoo zegt uitdrukkelijk dat je het beleidsprobleem moet verhelpen en het bericht opnieuw moet versturen. Continue monitoring van authenticatie en DMARC (zie Prijzen voor plannen met 24/7 monitoring) is de praktische preventieve oplossing.

Conclusie

Met 554 5.7.9 vertelt Yahoo je, permanent en zonder nieuwe poging, dat het bericht dat je probeerde te versturen zijn verzendersbeleid schendt. Bijna altijd komt dat door ontbrekende of niet-uitgelijnde authenticatie, ontbrekende headers voor bulkverzenders of een gloednieuw verzenddomein zonder enige compliancegeschiedenis. Het is omkeerbaar zodra je het onderliggende probleem oplost, en anders dan bij TSS04 is er geen wachttijd: het volgende bericht slaagt of faalt op eigen kracht.

Controleer eerst de alignment van SPF, DKIM en DMARC met de SPF-lookup, de DKIM-lookup en de DMARC-lookup. Voeg de headers voor one-click unsubscribe toe. Meld je aan voor de CFL van Yahoo. Stuur dan één testbericht. Klopt de authenticatie, dan stopt 554 5.7.9 meteen.

Wil je continu zicht op de authenticatiesignalen achter deze beleidsweigeringen (DMARC-rapporten, afwijkende DKIM- en SPF-alignment, ontbrekende headers voor bulkverzenders), dan bewaakt MailVitals dat allemaal 24/7, zodat je de volgende 554 5.7.9 voorkomt in plaats van hem te ontdekken in een bouncerapport.

👉 Lees verder: Yahoo 421 4.7.0 TSS04-deferral · Eisen van Gmail en Yahoo voor verzenders in 2026 · SMTP-foutcodes uitgelegd

Bronnen

• Sender Requirements and Recommendations (Yahoo Sender Hub), de eisen van Yahoo: SPF of DKIM voor alle verzenders; SPF, DKIM, DMARC, alignment en List-Unsubscribe voor bulkverzenders.
• SMTP Error Codes (Yahoo Sender Hub), de oorzaken die Yahoo noemt voor 553- en 554-weigeringen, waaronder mislukte authenticatie en Spamhaus-listings, en de regel om een 5xx nooit opnieuw te proberen.
• IANA SMTP Enhanced Status Codes registry, de geregistreerde betekenis van 5.7.9 en de andere X.7-codes.
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), hoe DMARC-alignment werkt met SPF of DKIM.
• RFC 8058: Signaling One-Click Functionality for List Email Headers, de one-click unsubscribe via POST die Yahoo aanraadt.