Email Rejected per DMARC Policy (550 5.7.0 / 5.7.1)

"Email rejected per DMARC policy" means the domain in your From address publishes a DMARC policy of p=reject, your message failed DMARC, and the receiving server did what the policy asked: it refused the message. Failing DMARC means neither SPF nor DKIM passed for a domain that matches the From domain. The fix is to get at least one of them passing and aligned for the system that sent the message.

It's a permanent rejection, so nothing is retried. If you own the domain, the policy is yours and so is the fix.

What the bounce says

Each receiver words it differently. The generic form you'll see from many servers:

550 5.7.1 Email rejected per DMARC policy for example.com

Gmail:

550 5.7.26 Unauthenticated email from example.com is not accepted due to
domain's DMARC policy. Contact the administrator of example.com domain if
this was legitimate email.

Microsoft 365 (Exchange Online):

550 5.7.509 Access denied, sending domain [example.com] does not pass DMARC
verification and has a DMARC policy of reject.

Yahoo (its help page ties this one to DMARC and forwarding, though it can have other policy causes):

554 5.7.9 Message not accepted for policy reasons.

The enhanced code varies: 5.7.1 ("delivery not authorized"), 5.7.0 (the catch-all "other security" code in RFC 3463), or a provider's own number. They all mean the same thing. Gmail's version has its own page at 550 5.7.26, and Microsoft's at 550 5.7.509.

What it means

DMARC checks one thing on top of SPF and DKIM: alignment. A message passes DMARC if SPF passes for a domain that matches the visible From domain, or DKIM passes with a signature from a domain that matches it. A pass for your ESP's domain doesn't count. (The authentication overview explains how the three fit together.)

If the message fails and the From domain says p=reject, the domain owner has asked receivers to refuse it. The DMARC standard, now RFC 9989 (published May 2026, replacing RFC 7489), says rejection should happen during the SMTP conversation, which is why you get a bounce instead of a quiet trip to the spam folder. Receivers aren't obliged to honor the policy, but the big mailbox providers generally do. So the question is which sending system isn't aligned, and whose domain is in the From line.

Common causes, most likely first

1. A sending service that was never authenticated. Your main platform is set up, but the CRM, billing system, helpdesk, survey tool or website form sending as your domain isn't. Moving to p=reject is the moment these surface, because before that they were failing quietly.
2. SPF passes, DKIM is the provider's. The service signs with its own domain and uses its own return-path. Both pass, neither aligns, DMARC fails.
3. SPF broke. Too many DNS lookups (over 10) gives a permanent error, and SPF stops passing for everything. See the SPF lookup limit guide.
4. DKIM broke. A key rotation without a DNS update, a missing selector record, or something modifying the message after signing. See DKIM fail.
5. Forwarding and mailing lists. A forwarder sends your message from its own IP, so SPF fails. A mailing list adds a footer or subject tag, so DKIM fails too. Yahoo's help page calls out forwarding specifically: look for an X-Yahoo-Forwarded header in the raw message.
6. Sending "from" a domain you don't own. Your app or ESP sends with a From address at yahoo.com, aol.com or a customer's domain. Those domains publish p=reject, and you can never authenticate as them. Use your own domain in the From line and put the person's address in Reply-To.

How to fix it

1. Get the full bounce and identify the From domain. That's the domain whose policy rejected you. If it isn't yours, jump to cause 6.
2. Identify the sending system from the IP in the bounce or the headers of a copy of the message. The header analyzer shows the SPF, DKIM and DMARC results and which domains they evaluated.
3. Check your DMARC aggregate reports. They list every IP sending as your domain and whether it passed and aligned. A new failing source stands out quickly. See how to read DMARC reports.
4. Set up custom DKIM in the failing service so it signs with d=example.com or a subdomain. This is the fix that matters most, because DKIM survives forwarding and SPF doesn't.
5. Align SPF where you can by setting a custom return-path (bounce) domain on your own domain, and add the service to SPF. Count lookups with the SPF analyzer.
6. Verify the records with the email checker.
7. If you need breathing room, step the policy down to p=quarantine for a fixed, short period while you fix the source, then go back. Don't drop to p=none and forget about it. The DMARC policy guide covers the trade-offs.
8. Resend the rejected messages once the source passes.

How to confirm it's fixed

Send a test from the fixed service to Gmail and a Microsoft-hosted address, view the original, and check that DMARC passes with an aligned DKIM d= or SPF domain. Then watch a few days of aggregate reports to see the source pass at volume.

How to keep it from coming back

• Keep an inventory of every system that sends as your domain, with an owner for each.
• Make "custom DKIM and return-path on our domain" part of buying any new tool that sends email.
• Read the DMARC reports weekly. The DMARC fail guide covers the usual culprits.

When to get help

If you're at p=reject and can't tell which of a dozen services is failing, or forwarded mail to important recipients keeps bouncing, it's worth having someone read the reports and headers with you. Get in touch.

FAQ

Should I just change my DMARC policy to p=none?

It stops the bounces, but it also stops protecting your domain from spoofing, and the failing mail usually lands in spam anyway. Fix the failing source. If you need time, use p=quarantine briefly with a date to move back.

Someone else's mail to me is being rejected per DMARC. Can I fix it?

Only partly. The sender's domain policy and authentication are theirs to fix. If the rejection happens because your own server forwards their mail somewhere else, change how you forward (or use a forwarder that supports ARC and SRS) so their authentication survives.

Why does it pass at Gmail but get rejected somewhere else?

Receivers evaluate the same records but can reach different results, especially with forwarding, DNS timeouts or partial DKIM failures. Gmail also defers with 451 4.7.26 when a DNS lookup fails temporarily rather than rejecting. Check the headers from the receiver that rejected you, not the one that accepted.

Is this a blocklist?

No. It's an authentication result. There's nothing to request removal from, and the bounces stop as soon as the message passes DMARC.