554 5.7.9 Message not accepted for policy reasons
554 5.7.9 is Yahoo’s permanent policy rejection. It fires when a message fails SPF or DKIM, fails a DMARC policy Yahoo is enforcing (including your own p=reject), or breaks one of Yahoo’s sender guidelines. If you cleared Gmail’s 550-5.7.26 last week and Yahoo started bouncing this week, the same requirement is at work. The difference is that Yahoo’s text rarely tells you which leg failed, so you’ll need to test each cause against your domain’s public records in turn.
Why the Yahoo code says less than the Gmail one
Yahoo has enforced the same sender rules as Google since February 2024. AOL mailboxes run on the same infrastructure, so one fix covers both. Both providers want SPF or DKIM passing for ordinary senders, both passing and aligned for bulk senders, a DMARC record published, one-click unsubscribe on subscribed mail, and a low complaint rate.
Google’s bounce usually names the failing mechanism. Yahoo’s 554 5.7.9 is deliberately generic and covers the whole policy family. The bounce reads “554 5.7.9 Message not accepted for policy reasons”, sometimes with a pointer to Yahoo’s error reference, and you won’t get much more than that from the bounce itself.
That’s why reading your domain’s records from the outside comes before any DNS edit. Four causes are possible and the bounce text doesn’t distinguish between them.
Yahoo doesn’t publish a volume threshold for “bulk”. Google’s parallel rule draws its line at 5,000 messages a day, so treat that as the working assumption until Yahoo says otherwise.
Which domain Yahoo checks
The three checks each read a different part of the message, so the domain your record sits on isn’t always the domain Yahoo tested.
Receivers evaluate SPF against the Return-Path domain, the RFC5321.MailFrom address that bounces go back to, and ignore the From header for that check. When a newsletter tool or CRM sends on your behalf, the Return-Path is usually that platform’s bounce domain. A perfect SPF record on your own domain can be irrelevant to Yahoo’s SPF check.
DKIM is judged on the d= tag in the signature header. If your platform signs with its own default, the signature carries the platform’s domain, and your domain gets no credit for it.
Alignment, the thing DMARC and the Yahoo bulk rules care about, compares the passing leg against the domain in the From header. SPF or DKIM must pass for a domain that matches the From domain. Each cause below fails that test in a different way.
Cause one: SPF fails for the bounce domain
To test it, open the headers of a message that bounced (or a copy sent to a mailbox you control) and find the Return-Path line. That’s the domain Yahoo tested SPF against. If it’s your ESP’s bounce domain, the ESP owns that SPF record and there’s nothing to change on yours. If it’s your own domain, look up its TXT record and check that the sending source is inside it.
An SPF record that covers a sending platform looks like this:
v=spf1 include:spf.yourplatform.example -allThe include is whatever your platform documents, and the -all at the end tells receivers to fail anything else. If the record ends in ~all or ?all, Yahoo sees a softer signal, and if the sending IP is missing from the record altogether, SPF fails outright. The SPF piece goes through the Return-Path trap and the limit of ten lookups in detail.
If SPF already passes for your ESP’s bounce domain and Yahoo still rejects, this cause isn’t yours, and you’re most likely in cause three.
Cause two: DKIM signs with the platform’s domain
In the same headers, find the DKIM-Signature line and read the d= value. If it says your platform’s domain, the mail is signed on the platform’s behalf and your domain gets none of the credit.
The fix lives in the provider or ESP settings, labelled custom-domain DKIM, domain authentication or something close. The platform gives you two or three CNAME records to publish at your domain, and once they resolve, signatures carry d=yourdomain.com instead of the platform default. Copy the CNAMEs exactly, because a trailing dot missing or added is why the platform’s verify button so often stays red.
Once custom-domain DKIM is on, the d= value matches your From domain and Yahoo has an aligned leg to pass.
Cause three: both pass and neither aligns
You’ve published SPF, your platform signs with DKIM, both pass, and Yahoo still returns 554 5.7.9.
Read the Authentication-Results header on a delivered copy (most receivers add one) and check the domain each pass is recorded against. SPF passing for your ESP’s bounce domain plus DKIM passing for the platform’s default d= gives you two green results and zero alignment, because neither passing domain matches your From domain.
The fix is the one from cause two, or an SPF fix on a custom Return-Path if your platform offers one. You need at least one leg to pass for a domain that matches the From header.
It’s this alignment gap that makes the requirement bite so widely. Of the 78,444,857 DMARC records the September 2026 census parsed, 41,798,631 sit at p=none and 36,602,897 are at quarantine or reject. A p=none record meets the “publish DMARC” part of Yahoo’s bulk rule and says nothing about whether the mail behind it aligns, which the rule also asks for.
Cause four: a p=reject, yours or Yahoo’s
If your domain publishes p=reject and the mail doesn’t align, you’ve asked Yahoo to reject it. The DMARC record is one TXT record at _dmarc, and it looks like this:
_dmarc.yourdomain.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Look up that record. If it’s p=reject or p=quarantine and any of causes one to three applies, the rejection is your own policy working as designed. Fix alignment first, and the policy will let the mail through. If you send in volume and have no record at all, Yahoo asks for at least p=none with a reporting address, and the rua reports it produces will show you every source that fails alignment. The DMARC piece covers the record and the ratchet from none to reject.
The other p=reject belongs to Yahoo. It published p=reject on its own consumer mailbox domains in 2014, so a third-party service sending with a Yahoo consumer address in the From header fails Yahoo’s own DMARC by design. Since no ESP setting changes Yahoo’s policy, the way through is to send from your own domain with its own authentication, so the From address becomes one you control.
The reputation codes next to it: 553 and 421
Yahoo publishes error categories rather than verbatim strings, and the bracketed reason tags such as [TSS04] shift over time, so treat the fragments below as observed in bounces, and check them against your own NDR.
| Code | A bounce like | What it means | Where the fix is |
|---|---|---|---|
| 554 5.7.9 | “Message not accepted for policy reasons” | Permanent policy rejection: authentication, DMARC or a guideline failure | This piece, causes one to four |
| 553 5.7.1 | IP or content policy text, often with a bracketed reason tag | Yahoo won’t accept from this IP or source | Authentication to prevent relapses, then clean sending |
| 553 5.7.2 | “will be permanently deferred” | Sustained IP reputation failure, the hard version of a deferral | Authentication, then weeks of clean sending or a fresh warm-up |
| 421 4.7.0 | “temporarily deferred due to unexpected volume or user complaints” | Temporary deferral on a volume or complaint spike | Respect the retry, then fix complaints and volume |
A 421 deferral is throttling while Yahoo decides. Respecting the retry interval matters, because hammering the queue turns deferrals into 553s.
The line between 554 5.7.9 and the 553 family sets your expectations. 554 5.7.9 is a policy rejection, and policy is something you fix in DNS and in your platform settings. A 553 is about the IP, and no DNS record delists a blocklisted IP. Authentication stops the policy rejections and prevents relapses. IP reputation recovers only through clean sending over time, so a 553 5.7.2 after your authentication is clean means the IP is the problem, and it recovers on its own timescale.
Timing follows the same split. Authentication fixes take effect as soon as the new records are visible, minutes to a few hours, up to 48 for slow TTLs. Reputation recovery is slower: days for 421 deferrals, weeks or a fresh warm-up for a 553 5.7.2.
Keeping it fixed: unsubscribe headers and complaints
Aligned mail gets through the door, and two of Yahoo’s guideline items decide whether it stays that way.
RFC 8058 one-click unsubscribe means two headers on marketing and subscribed mail:
List-Unsubscribe: <https://yourdomain.com/unsub?id=...>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickYou have to honour a request within two days. Reputable ESPs add these headers once domain authentication is on, so verify by reading a sent message’s headers rather than trusting the settings page.
Yahoo weighs complaint rate heavily. Keep the spam rate under 0.3 percent, register for Yahoo’s complaint feedback loop through its Sender Hub, prune addresses that haven’t engaged, and don’t mail purchased lists. Sustained complaint spikes are how a 421 deferral turns into a 553.
Small senders aren’t exempt from the authentication part. 554 5.7.9 doesn’t check your volume before firing: unaligned mail under your own p=reject trips it at any size, and so does a domain with no SPF record at all. Work causes one to four at whatever volume you send, then run the free scan again to confirm the records Yahoo sees match the ones you meant to publish. The email delivery piece is the parent for the other bounce codes.
Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.