554 / 550 5.7.9 from Yahoo — message not accepted for policy reasons

Yahoo's 554 5.7.9 Message not accepted for policy reasons — you may also see it with a 550 prefix, and often a link to postmaster.yahooinc.com/error-codes — is a permanent rejection, and "policy reasons" is Yahoo's phrasing for a DMARC failure. It is the Yahoo counterpart to Gmail's 550 5.7.26, built on the same authentication requirements, but it shows up most often through a few distinctly Yahoo situations: mail sent with a From domain you do not control, and forwarded mail. This page explains what triggers it, with the specifics that matter when you run your own PowerMTA or KumoMTA.

What 5.7.9 means

The useful part of the code is the enhanced status, 5.7.9, which Yahoo maps to "message not accepted for policy reasons." That policy is DMARC. When a message arrives whose From domain publishes a reject policy, and the message does not pass DMARC for that domain — because neither SPF nor DKIM aligns with the From — Yahoo follows the instruction in the policy and rejects it. The basic SMTP code you see in front, usually 554 and occasionally 550, only tells you the failure is permanent; the diagnosis is the 5.7.9 and the "policy reasons" text, not the choice of 554 versus 550. Either way the message bounces rather than being filed to spam.

Yahoo's error codes: temporary vs permanent

It helps to place 5.7.9 in Yahoo's wider set, because the right response depends on whether the code is a deferral or a rejection. Temporary 4xx codes hold mail for retry; permanent 5xx codes reject it.

Code	Type	Typical meaning
421 / 451	Temporary (4xx)	Rate limiting or complaints — mail deferred and retried, often a sign to slow down.
553	Permanent (5xx)	Mailbox or sender-address problem.
554 / 550 5.7.9	Permanent (5xx)	Message not accepted for policy reasons — a DMARC failure.

A burst of 421/451 means you are being throttled and should ease your rate and check complaints; a 554 5.7.9 means a requirement is unmet and the message will never arrive until you fix it. The two call for opposite responses — patience for one, action for the other.

Cause 1: a From domain you don't control

This is the most common and most surprising trigger. Yahoo, like many mailbox providers, publishes a DMARC policy of p=reject on its own domains — yahoo.com among them. That policy instructs every receiver to reject mail claiming to be from yahoo.com that does not come from Yahoo's authorised servers. So the moment you put a @yahoo.com address in the From and send it through your own server, your own ESP, or a marketing tool, the mail fails DMARC for yahoo.com and gets rejected — by Yahoo and by everyone else honouring the policy. The same applies to any domain you do not control that publishes reject, including gmail.com.

Yahoo's own advice is blunt and correct: send from your own domain. A domain you control is one you can authenticate — you can publish its SPF, sign its mail with DKIM, and set its DMARC — whereas a free-mailbox domain is one you never can. For any real sending, and certainly for bulk, the From address has to be on a domain you own. Using a free-provider address as the From for outbound mail through your own infrastructure is the single fastest way to earn a 5.7.9.

Cause 2: your own domain fails DMARC alignment

If the From is a domain you do control and you still see 5.7.9, the problem is the same alignment issue behind any DMARC rejection: a signature passed, but its domain did not match the visible From, and your DMARC policy is reject. DMARC only counts SPF or DKIM when it aligns with the From domain, so a DKIM signature on a different d= domain, or an SPF pass on an envelope domain that differs from the From, authenticates something but not the identity DMARC checks. The fix is to align: set your DKIM d= to the From domain, and make the envelope/return-path domain match it too. This is identical to the alignment fix for Gmail's code, covered step by step in the p=reject troubleshooting guide and the Gmail 5.7.26 page; clear it once and both providers accept the mail.

Cause 3: forwarded mail

Forwarding is where 5.7.9 bounces appear for mail you do not think you sent. When a message is automatically forwarded — a Yahoo user forwarding to another account, or an Office 365 address forwarding to Yahoo — the forwarding server becomes the new envelope sender, which breaks SPF for the original domain. If the original message was not DKIM-signed in a way that aligns and survives the hop, DMARC fails at the forwarder, and if the original domain publishes p=reject, the forwarded copy is rejected with 5.7.9. Yahoo's support guidance is to view the raw message and look for an X-Yahoo-Forwarded line, which shows the message was forwarded, and a p=reject indication, which shows the original domain's policy caused the rejection.

The durable fix lives at the source, not the forwarder. The original sender should sign with aligned DKIM, because a DKIM signature travels with the message and survives forwarding where SPF does not — so an aligned DKIM pass keeps DMARC intact across the hop. Forwarding systems, for their part, should apply ARC (Authenticated Received Chain) so a receiver can see the authentication results from before the forward. For your own sending the lesson is the same one that prevents the other causes: aligned DKIM on your own domain is what makes your mail survive being forwarded into a Yahoo inbox.

Cause 4: bulk sending failures and complaints

For bulk senders, 5.7.9 and its 5xx neighbours also appear when you fall short of Yahoo's bulk guidelines: unauthenticated bulk mail missing SPF, DKIM or DMARC; a spam-complaint rate over the line; or a sending IP or domain on a blocklist such as Spamhaus. Two Yahoo specifics matter here. First, the complaint threshold is effectively stricter than Gmail's: Yahoo measures complaints against inbox-delivered mail only, excluding anything filed to spam, so the same complaints produce a higher rate — you can be compliant at Gmail and over the line at Yahoo with identical sending. Second, Yahoo runs a Complaint Feedback Loop you should enrol in, so complaints feed back to you and into suppression rather than silently eroding your reputation. The complete picture of Yahoo's bulk rules sits in the 2026 bulk sender requirements, and the mechanics of complaint loops in what a feedback loop is.

A worked example: the From-domain trap

A small business runs its newsletter through a self-hosted PowerMTA. To make replies land in a familiar inbox, someone sets the From address to [email protected] — the address the owner actually reads — while the mail sends from the company's own IPs. The campaign goes out, and every message to a Yahoo recipient bounces with 554 5.7.9 Message not accepted for policy reasons.

The cause is exact. yahoo.com publishes p=reject, so Yahoo requires any mail claiming to be from yahoo.com to come from Yahoo's own authorised servers. This mail claimed @yahoo.com in the From but left from the company's PowerMTA, so SPF and DKIM cannot align with yahoo.com — they would have to belong to yahoo.com, which the company does not control — and DMARC fails under the reject policy. The PowerMTA setup was otherwise correct; the single mistake was borrowing a free-mailbox domain for the From. The fix is to send from the company's own domain, say [email protected], authenticate that domain, and set reply-to: [email protected] if replies should still reach the personal inbox. Replies go where they want; authentication works because the From is now a domain the company can actually sign for.

This pattern — a correct MTA undone by a From address on a domain the sender does not own — is the most common self-hosted route to 5.7.9, precisely because it looks harmless and even helpful.

Reading the raw bounce

Yahoo's own guidance for diagnosing 5.7.9 is to view the raw message and look for two markers, and they tell you which cause you are facing. An X-Yahoo-Forwarded header means the message was forwarded — pointing at the forwarding cause rather than your original send — and the line names the address it was forwarded to. A p=reject indication tells you the relevant domain's DMARC policy is what triggered the rejection. Beyond those, the Authentication-Results header is the decisive read: it shows whether SPF and DKIM passed and, more importantly, whether they aligned with the From domain. A result where DKIM passes on a d= that differs from the From, or SPF passes on a different envelope domain, with dmarc=fail, is the alignment cause in black and white. Reading these three things turns a generic "policy reasons" bounce into a specific, fixable diagnosis instead of guesswork.

Fixing it on a self-hosted PowerMTA or KumoMTA

On your own MTA the fix gathers the causes into a short checklist, all of it yours to own. Send from a domain you control, never a free-mailbox domain. Publish an SPF record naming your sending IPs. Sign with DKIM whose d= matches your From domain — PowerMTA does this through its domain-key directive, KumoMTA in its Lua policy — and publish the public key. Publish an aligned DMARC record for the From domain, and keep your complaint rate low with feedback-loop suppression wired into the MTA through its bounce and FBL handling. The authentication guide covers the records and the signing setup. Because there is no ESP doing any of this for you, the From-domain discipline and the alignment are the two things to get right, and they are exactly the two things 5.7.9 punishes.

A useful pre-send habit closes the gap before it costs you a campaign: for every new From domain or subdomain you intend to send from, confirm it has SPF, an aligned DKIM key and a DMARC record published, and send one seed to a Yahoo address to read the Authentication-Results before any volume goes out. Most 5.7.9 bounces trace back to a From domain that was never set up to authenticate — a free-mailbox address, a fresh subdomain, or a domain whose DKIM was signing on the wrong d=. Catching that with a single seed test is far cheaper and faster than discovering it the hard way, across an entire send that has already bounced.

Verify before resending

Because 5.7.9 is permanent, do not keep resending the same message — it bounces identically and each attempt is another negative signal. After correcting the records or the From domain, send a single seed to a Yahoo address you can inspect and read the Authentication-Results header: confirm SPF and DKIM pass and, crucially, that DMARC passes with the signing and envelope domains aligned to the From. Yahoo's Sender Hub and postmaster pages show the reputation and authentication picture for your domain over time, which is worth watching after a fix. The SMTP code lookup confirms you are reading the bounce correctly. Let DNS changes propagate within their TTL, verify a real message passes, then resume volume gradually.

The same rejection at Gmail and Microsoft

Yahoo's 5.7.9 is one of three sibling codes the big providers use for the same family of authentication failures. Gmail returns 550 5.7.26 and names the protocol — unauthenticated, or DMARC policy. Microsoft returns 550 5.7.515 for non-compliant bulk mail. The fix is shared across all three because the requirements are: SPF, DKIM, and an aligned DMARC, sent from a domain you control. Yahoo simply expresses it as "policy reasons" and, through the From-domain and forwarding traps above, surfaces the DMARC angle more directly than the others. Fix authentication and alignment once, send from your own domain, and you clear the policy rejection across the board.

The bottom line

Yahoo's 554 5.7.9 — or 550 5.7.9 — means your mail was rejected for policy reasons, and the policy is DMARC. The three things that trigger it are using a From domain you do not control, your own domain failing DMARC alignment under a reject policy, and forwarded mail that lost its authentication on the way. All three resolve the same way: send from a domain you own, sign it with DKIM that aligns to the From, publish SPF and an aligned DMARC, and keep your complaints under Yahoo's stricter inbox-only line. On a self-hosted PowerMTA or KumoMTA those are your controls to set, which is why the error is common during setup and gone for good once your own domain authenticates cleanly.