554 5.7.9 — Message not accepted for policy reasons

What does 554 5.7.9 mean?

Yahoo may return this error for policy-based authentication failures, including DMARC-related failures. The diagnostic string is typically:

554 5.7.9 Message not accepted for policy reasons

Yahoo may also return 553 or 554 codes with similar policy-related diagnostic text for permanent authentication failures.

The underlying cause is often the same as Gmail's 550 5.7.26 and Microsoft's 550 5.7.515: the message did not meet Yahoo's authentication policy checks, often because DMARC failed due to SPF or DKIM not passing and aligning with the From: domain.

Since 2024, Yahoo's bulk-sender requirements have called for both SPF and DKIM, a valid DMARC policy with at least p=none, and DMARC pass with relaxed alignment acceptable.

DMARCit processes aggregate reports from Yahoo alongside Gmail, Outlook, and every other provider — so you can see authentication results across all major receivers in one place.

Why did this happen?

The causes are the same as for other DMARC rejections. Starting with the most common:

Cause 1: A third-party service is sending without DMARC alignment

The sending platform uses its own domain in the Return-Path and signs DKIM with its own domain. Neither aligns with your From: domain. → See: DMARC alignment failure.

Cause 2: SPF is broken

PermError from exceeding the 10-lookup limit, duplicate SPF records, or syntax errors. → See: SPF PermError.

Cause 3: DKIM isn't configured for your domain

The platform signs with its default domain, not yours. Or DKIM was configured but the key rotated and DNS wasn't updated. → See: DKIM body hash did not verify.

Cause 4: Email forwarding broke authentication

Forwarding changed the sending IP (SPF fails) and potentially modified the message (DKIM fails). Both fail, DMARC fails.

Cause 5: Sending from a @yahoo.com address through a non-Yahoo server

This is a Yahoo-specific scenario. Yahoo publishes p=reject on yahoo.com. If anyone sends email with a @yahoo.com From: address through a non-Yahoo server, DMARC will fail and DMARC-enforcing receivers will reject the message. The fix is to use a domain you control in the From: address and put the Yahoo address in Reply-To instead.

How to fix 554 5.7.9

Step 1: Identify the sender

Check headers for Return-Path, DKIM-Signature: d=, and Authentication-Results to determine which service sent the message and what failed.

Step 2: Fix alignment

Configure custom DKIM for your domain on the sending platform (preferred), or set up a custom Return-Path for SPF alignment. → See: DMARC alignment failure.

Step 3: Verify SPF is healthy

Confirm your SPF record is under the 10-lookup limit and doesn't have duplicates or syntax errors. → See: SPF PermError.

Step 4: Confirm the fix

Wait 24-48 hours and check your DMARC aggregate reports for the sending source showing alignment pass.

If the problem is a @yahoo.com From: address: Stop using @yahoo.com as the From: address on non-Yahoo sending infrastructure. Use a domain you own and control. Put the Yahoo address in Reply-To: if recipients need to reply there.

This isn't a one-time fix

• Most third-party senders start misaligned by default. Each new service needs custom DKIM or Return-Path configuration for your domain.
• SPF records drift. Vendor IP changes, new includes, lookup limit pressure — all ongoing.
• Shadow IT adds unknown senders. Teams adopt services that send email as your domain without IT involvement.

The most reliable way to catch these failures is continuous monitoring of your DMARC aggregate reports across all providers.