5.7.9 Message Not Accepted For Policy Reasons | Fix Now

You hit send, then a bounce lands in your inbox with a blunt line: 5.7.9 message not accepted for policy reasons. It isn’t personal. This code is a gatekeeper response from the receiving mail system. It’s saying your message failed a policy check and won’t be accepted.

This guide shows what the code points to, how to read the bounce for clues, and the fixes that clear most blocks. You’ll also see what to do when forwarding to Yahoo or AOL breaks authentication, or when Microsoft 365 or Google Workspace sits in the middle.

What A 5.7.9 Policy Rejection Is Telling You

Email servers run checks before they store a message. Some checks are about sender identity. Some are about spam patterns. When one of those checks fails, the server can reject the message during the SMTP conversation and return a permanent failure code.

“5.7.9” is part of the enhanced status code set. In plain terms, it means the recipient’s side decided your message violates a policy. For Yahoo and AOL, this code often shows up with a 554 response and a postmaster link that points to the block family.

• Read the exact bounce line — Look for extra text after 5.7.9, a bracket tag like [TSxx] or [PHxx], or a link to a postmaster page.
• Identify the hop that rejected — In the bounce headers, find the “Remote Server returned” line to see which domain issued the rejection.
• Confirm the sender identity used — Check the From domain, the Return-Path, and which server actually sent the mail.

If the rejection comes from the recipient’s provider, you must fix what that provider checks. If it comes from your own relay or security gateway, fix your outbound controls first.

5.7.9 Message Not Accepted For Policy Reasons In Yahoo Mail

Yahoo’s own help docs tie this error to authentication policy, with DMARC commonly in the mix. It also appears after auto-forwarding, since forwarding can break alignment even when the original sender did nothing wrong.

Many cases fall into one of these buckets. The bounce often includes a Yahoo postmaster URL and sometimes a code tag. That tag matters because it hints at the rule that fired.

Likely Trigger	What You’ll Notice	First Fix To Try
DMARC reject due to SPF/DKIM fail	Yahoo link in the bounce, mail blocked fast	Align SPF or DKIM to the From domain
Forwarding broke alignment	Original sender is fine, forwarded copy bounces	Use SRS on forwarders or stop raw forwarding
IP or domain reputation hit	New server or sudden volume jump	Slow ramp, clean lists, check blocklists
Content triggered filters	Only some messages bounce, often with links	Simplify HTML, remove risky URLs, add plain text

Start with authentication. If Yahoo can’t verify who sent the message, or the verified identity doesn’t match the From domain, a policy block is a common end point.

Fast Checks That Pinpoint The Real Cause

Before you change DNS or mail settings, collect proof. You want to know which identity failed and where.

Pull the full bounce details

• Open the NDR or bounce body — Copy the full SMTP response, not just the subject line.
• Save the message headers — View the raw source for the bounce so you can trace the rejecting host.
• Find the rejecting host — Note the hostname and the receiving provider (Yahoo, AOL, Outlook, Gmail).

Run a quick auth check

• Check SPF for the From domain — Confirm the sending IP or service is listed, and that you have a single SPF record.
• Check DKIM signing — Confirm your mail is signed and the signature passes at the receiver.
• Check DMARC alignment — Ensure either SPF or DKIM aligns with the From domain used in the visible header.

If you’re using a mailing platform, your DNS may be split across multiple senders. A pass is not enough. You need alignment with the From domain.

Check for forwarding side effects

Forwarding can turn a clean message into a failure. It happens when the forwarder sends the mail from its own server while keeping the original From address. If the original domain publishes a DMARC policy of “reject,” the forwarded copy can be blocked.

• Test sending direct vs forwarded — Send to the final mailbox and to the forward address; compare results.
• Check SRS capability — Forwarders that implement Sender Rewriting Scheme help SPF survive forwarding.
• Try a rewrite option — Some systems can change the From domain to your domain so alignment holds.

Fix Steps For Senders And Site Owners

Most 5.7.9 policy blocks clear once the receiver can authenticate you cleanly and your sending posture looks stable. Work through these steps in order. Stop after the first change that resolves the bounces, then keep monitoring.

Lock down SPF the right way

• List every legitimate sender — Add your web host, transactional mail service, and CRM senders using includes.
• Use one SPF record only — Merge records; multiple SPF records can cause a permerror.
• End with a clear qualifier — “-all” is strict; “~all” is softer; choose based on your setup.

Enable DKIM on every outbound stream

• Turn on DKIM in your provider — Microsoft 365, Google Workspace, and many send platforms provide a toggle plus DNS selectors.
• Rotate DKIM selectors on schedule — Periodic rotation reduces risk if a selector ever leaks.
• Confirm the signing domain — If DKIM signs as a subdomain, DMARC alignment rules still apply.

Publish DMARC with a measured policy

• Start with “p=none” if you’re unsure — Collect reports first so you see who sends on your domain.
• Move to “quarantine” then “reject” — Tighten once SPF/DKIM pass for all real streams.
• Set alignment mode deliberately — Relaxed alignment is easier to keep stable; strict is harder.

DMARC does two jobs: it tells receivers what to do with fails, and it gives you a view of your sender map. If you enforce “reject,” forwarding failures become more common unless forwarders rewrite identities.

Clean up message content and formatting

• Send both HTML and plain text — Single-part HTML can raise filter scores at some providers.
• Limit link shorteners — Replace short links with clear links on trusted domains.
• Check message headers — Missing Date, malformed Message-ID, or bad encoding can trigger rejections.

Fix WordPress and server sending setups

If you send from a website, a fast win is to stop relying on raw PHP mail. Many hosts send through shared pools with mixed reputation.

• Send through authenticated SMTP — Use a mail plugin that routes through Microsoft 365, Google Workspace, or a transactional provider.
• Match the From address — Use an address on your domain, not a free mailbox, and keep Reply-To consistent.
• Set reverse DNS and HELO — For your own server, align rDNS and the HELO/EHLO name with your sending domain.
• Avoid mixed tracking domains — If links rewrite to a different domain, keep it branded, or turn it off for testing.

After this change, resend a plain email to a Yahoo address. If it lands, add links back in and test again.

Stabilize sending volume and list quality

• Warm up new IPs slowly — Start with engaged recipients, then ramp over days.
• Remove hard bounces fast — Keep unknown users and invalid mailboxes off your list.
• Stop sudden spikes — A sharp jump in volume can trip policy filters at large inbox providers.

Microsoft 365 And Google Workspace Scenarios

When your mail flows through Microsoft 365 or Google Workspace, the policy block can still be issued by Yahoo, AOL, Gmail, or Outlook. First confirm which system sent the final SMTP response, then tune the right layer.

Microsoft 365 outbound routing checks

• Check message trace — Use Exchange Online message trace to confirm the message left your tenant.
• Review outbound spam controls — A tenant policy can throttle or block if it flags an account.
• Confirm the correct route — If you relay through a smart host, align SPF/DKIM for that path.

Microsoft’s guidance for 5.7.x errors points to recipient-side security settings and blocked senders across the 5.7.0–5.7.999 range. Treat it as a policy-gate family, then narrow it using the details in your bounce.

Google Workspace sending and forwarding quirks

• Check DKIM status — In Admin, confirm DKIM is turned on for the domain and selectors match DNS.
• Confirm SPF includes Google — Add Google’s SPF include if you send from Gmail or Workspace.
• Watch invite mail flow — Invites can bounce when forwarding leads to DMARC alignment failure at Yahoo.

If you use a third-party sender with Workspace, align the visible From domain with the sender’s authenticated identity. A mismatch can pass SPF for the vendor yet fail DMARC alignment for your From domain.

When You’re The Recipient Or The Mail Admin

Sometimes the sender is doing the right things and the block is on your side. That can happen in corporate filtering, inbound allow/deny lists, or mailbox rules. If you manage the recipient domain, you can speed up resolution with targeted checks.

• Check allow and block lists — Review tenant or gateway lists for the sender’s domain and IP ranges.
• Review security gateway logs — A gateway may reject at SMTP time based on your settings.
• Ask for a fresh resend — Once you adjust policy, request a new message to confirm delivery.

If you’re a single mailbox user at Yahoo or AOL, you can still rule out local filters that make delivery look like a hard rejection.

• Check spam and filters — Filters can auto-delete and make delivery look like rejection.
• Try another recipient address — If only one mailbox rejects, it may be mailbox-level filtering.
• Share the exact bounce text — The sender needs the host, timestamp, and response line.

Prevention Tests That Keep You Out Of Policy Blocks

After you fix the immediate bounce, set up a small routine so the block doesn’t return the next time you change a sender, add a plugin, or move hosts.

• Send a seed test — Deliver to one mailbox each at Gmail, Outlook, Yahoo, and a custom domain.
• Re-check alignment after changes — Re-test after DNS edits or a sender switch.
• Track bounce types — Separate hard blocks from temporary deferrals so you respond the right way.
• Keep lists permission-based — Purchased lists can lead to fast 5.7.x blocks at large providers.

Keep a copy of the full bounce text for each failed send.

When you see 5.7.9 message not accepted for policy reasons, treat it as a policy gate. Pull the full response, confirm which identity failed, fix alignment first, then tune content and sending patterns. That order clears most cases.