550 5.7.1: email rejected per DMARC policy, and how to fix it

What the bounce means

A 550 5.7.1 rejection means the receiving server refused your message because it is not authorized by policy. The 5.7.1enhanced status code (RFC 3463) is the generic “delivery not authorized, message refused.” On Microsoft 365 / Exchange Online, the most common reason behind it is a DMARC failure: a message used your domain in the From: address, failed DMARC, and the domain publishes p=reject, so Microsoft honored that policy and rejected the message during the SMTP conversation.

You will usually see one of these in the bounce or the message headers:

Authentication-Results: ... dmarc=fail action=oreject ...

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

The action=oreject stamp means “the sender published p=reject, so this message was rejected.” The newer 5.7.509 variant says the same thing in plain words.

First: 5.7.1 is not always DMARC

Here is the part most articles get wrong. 550 5.7.1 is a catch-all “refused by policy” code, and DMARC is only one of the things it covers. The same number is returned for:

• Relay denied (550 5.7.1 Unable to relay), when a server will not relay mail it is not responsible for.
• A blocklisted sending IP (Client host [IP] blocked using Blocklist 1).
• A recipient or mailbox policy that does not permit you to send to that address.
• Authentication required (RESOLVER.RST.AuthRequired; authentication required).

So read the words after the number. If they mention DMARC, authentication, or dmarc=fail, you are in the case this page covers. If they mention relay, blocklist, or permission, the fix is about the sending server's authorization, not your DMARC records. (Two more notes: Gmail uses 550 5.7.26 for the unauthenticated and DMARC case, not 5.7.1, and Yahoo uses 554 5.7.9. The numeric code alone never identifies the cause.)

Why your DMARC failed

When 5.7.1 really is DMARC, it is almost always one of these:

• Authenticated but not aligned (most common, and the confusing one). SPF or DKIM technically passes, but for the service's domain, not yours. DMARC requires alignment: the SPF MAIL FROM domain or the DKIM d= domain has to match your From: domain. A pass that does not align still fails.
• Not authenticated at all. A tool sends as your domain, but you never published its SPF include or its DKIM key, so there is nothing to align.
• Forwarding broke it. A forwarder or mailing list changed the envelope (SPF breaks) or the body (DKIM breaks), so a message that was fine at the first hop fails at the final one.
• Strict alignment. Your record sets aspf=s or adkim=s, and a subdomain sender that would pass under relaxed alignment fails under strict.
• A real spoofer. If the failing source is not yours, the rejection is your protection working. Nothing to fix.

How to fix it

• Confirm it is alignment, and which half failed. Open the message headers and read Authentication-Results. Compare header.from (your visible domain) against smtp.mailfrom (the envelope) and the DKIM d=. If neither the envelope domain nor the d= matches your From: domain, that is the alignment gap, even when you see spf=pass or dkim=pass.
• Make at least one mechanism align. You only need one. The reliable path is aligned DKIM: have the sending service sign with d=yourdomain.com (usually by CNAMEing its selector onto your domain) and publish the key. DKIM also survives forwarding, where SPF does not.
• Authorize the legitimate sender. Add the service to your SPF record or enable its DKIM, then confirm it stops showing as unaligned in your DMARC reports.
• For forwarded mail, the real fix is sender-side alignment (DKIM); the final receiver can also be configured to trust an ARC sealer.
• Do not retreat to p=none to stop the bounces. If it is your own mail failing, fix the alignment. Weakening the policy just stops enforcement and re-opens the door to spoofers.

How to confirm it is fixed

• Re-check the records. Run a free DMARC audit and the SPF and DKIM checkers to confirm what you published actually resolves and aligns.
• Send a test and read the headers. Mail yourself, open the original, and confirm dmarc=pass with an aligned dkim=pass or spf=pass. Our header analyzer reads it in plain English.
• Watch the reports. Over a day or two the failing source should flip to passing in your DMARC aggregate reports. If it does not, the record published but is still not aligned, recheck the first step.

Frequently asked

Does 550 5.7.1 always mean DMARC?

No. 5.7.1is a general “refused by policy” code. On Microsoft 365 a DMARC rejection does land on 550 5.7.1 (or the more specific 5.7.509), but the same code also covers relay denied, a blocklisted sending IP, and recipient permission errors. Read the text after the number. Gmail uses 550 5.7.26 for the DMARC case, and Yahoo uses 554 5.7.9.

Is 550 5.7.1 the sender's problem or the recipient's?

For the DMARC flavor it is the sending side. Mail using your domain in the From:address reached the recipient's server, failed DMARC, and was rejected per a published p=reject policy. The recipient did nothing wrong; the fix is to authenticate the sender so it aligns with your domain.

My SPF and DKIM pass, so why does DMARC still reject?

Because DMARC needs alignment, not just a pass. If a service authenticates with its own domain and neither the SPF MAIL FROM domain nor the DKIM d= domain matches your From: domain, DMARC still fails. This authenticated-but-unaligned case is the most common cause of a 550 5.7.1 DMARC rejection.

Should I switch my DMARC policy to p=none to stop the bounces?

No. If it is your own legitimate mail failing, fix the alignment. Retreating to p=none just stops enforcing your policy and lets spoofers back in. Weaken the policy only as a deliberate, temporary step while you authenticate a specific sender.