Yahoo 554 5.7.9: message not accepted for policy reasons
Yahoo's 554 5.7.9 is a permanent policy rejection, most often tied to DMARC: forwarded mail or a p=reject domain failing alignment. Read the headers first.
On this page(7 sections)
A bounce that says 554 5.7.9 Message not accepted for policy reasons means Yahoo refused the message permanently because of a policy decision, and Yahoo's own help page points at DMARC: either the sender is not using it, or a forwarded message looks like it came from an unauthorized server. Retrying will not help. The fix starts with reading the headers of a rejected or forwarded copy, then checking that SPF or DKIM passes and aligns with your From domain.
Yahoo does not publish a long explanation of this code, so this guide sticks to what Yahoo says and marks everything else as a hypothesis to test.
What does 554 5.7.9 mean?
It is a permanent failure in the security-or-policy class. The 554 is a permanent SMTP reply, and 5.7.9 is an enhanced status code in the 5.7.x range (see RFC 3463 and our guide to SMTP enhanced status codes). The full text usually reads:
554 5.7.9 Message not accepted for policy reasons.
See https://postmaster.yahooinc.com/error-codes
Yahoo's help page for this error says the cause may be that the sender is not using DMARC, and that an automatically forwarded email can look like it came from an unauthorized server when the forwarding provider does not use DMARC. It gives no direct fix, only two things to look for in the raw headers.
What should you look for in the headers?
Open the raw source of the rejected message (or the copy that arrived somewhere else) and search for two strings, which are the ones Yahoo names:
| Header text | What it tells you |
|---|---|
X-Yahoo-Forwarded |
The message was forwarded, and the line shows the address it was forwarded to |
p=reject |
The original sender's domain publishes a DMARC policy of reject, and the message was rejected under that policy |
If neither appears, the rejection is a different policy decision and Yahoo has not documented which. Treat that as a case for the checks below, not a guess.
What are the likely causes?
Treat these as ordered suspects. Yahoo's page supports the first two; the rest are common deliverability practice.
- A forwarded message fails DMARC at Yahoo. Forwarding often breaks SPF, because the forwarder's server is not in the original domain's SPF record. If the message also has no valid DKIM signature that survives the forward, and the original domain says
p=reject, Yahoo rejects it. DMARC, forwarding and mailing lists explains why. - Your own domain fails DMARC. SPF or DKIM may pass but not align with the visible From domain. See relaxed vs strict alignment.
- You are sending with someone else's domain in From. If a Yahoo or AOL address is in the From header of mail sent through a third-party service, that service is not authorized by the Yahoo domain's policy. Use your own domain in From and put the person's address in Reply-To. The From, Reply-To and envelope sender explainer covers the difference.
- No DMARC record at all. Yahoo's sender best practices expect bulk senders to authenticate with SPF and DKIM and publish a DMARC policy of at least
p=none. Our Gmail and Yahoo requirements guide lists each rule. - A listing or reputation problem. Some vendors report that blocklist listings can trigger the same text. Yahoo's page does not say so, so check your sending IP against the major lists only after authentication is clean.
How do you fix it, step by step?
-
Save the evidence. Keep the full SMTP reply, the time, the sending IP, the From domain, the envelope sender and the recipient.
-
Check the From domain's DNS. Look up the TXT records and confirm they exist and are valid:
dig +short TXT _dmarc.example.com dig +short TXT example.com -
Send a test to a mailbox you control and read the
Authentication-Resultsheader. You wantdkim=passwith ad=domain that matches the From domain, orspf=passwith an envelope domain that matches it. One aligned pass is enough for DMARC. -
Fix the weaker leg. Prefer a DKIM signature on your own domain, because DKIM survives forwarding when the signed parts are not changed, while SPF does not. SPF, DKIM and DMARC in plain English is the short refresher.
-
If the case is forwarding, tell the recipient the message was forwarded. You cannot fix a forwarder you do not control, but a DKIM-signed message from a domain with aligned DKIM usually gets through.
-
Change your policy only on purpose. If you set
p=rejectbefore your streams were all aligned, step back top=quarantineorp=noneand follow a staged plan such as from none to reject.
Should you retry or suppress the address?
Do not retry the same message: Yahoo's SMTP error codes page says that a 553 or 554 indicates a permanent problem and that you should not retry a message that returns a 5xx error. Do not automatically suppress the recipient either. This code describes a policy decision about the message or sender, not proof that the mailbox does not exist. Yahoo lists a missing mailbox as a separate case, with a message such as "This user doesn't have a yahoo.com account." See hard vs soft bounces for how to treat each class.
A practical rule: record the bounce, fix authentication, then resend a fresh message once a test passes. If the same recipient keeps rejecting after a clean test, suppress that address for that stream and ask them to contact you another way.
Does this error mean Yahoo blocked you?
Not necessarily. A 554 5.7.9 can come from one message with a broken forward path while the rest of your Yahoo mail is delivered. Compare the rate: if only a handful of Yahoo recipients bounce, look at those messages. If every Yahoo-bound message bounces, treat it as a sender-wide authentication or reputation problem and work through the checks above in order.
Bottom line
554 5.7.9 is Yahoo saying no on policy, and the policy Yahoo names is DMARC. Look for X-Yahoo-Forwarded and p=reject in the headers, confirm your SPF or DKIM passes and aligns with the From domain, never send with another provider's domain in From, and do not retry the same message. Everything beyond Yahoo's short help page is a hypothesis, so test it against your own logs and headers.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
