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 refused by policy. The 5.7.1 enhanced 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 low-reputation sending IP (Gmail: This message is likely suspicious due to the very low reputation of the sending IP address.).
• A recipient or mailbox policy that does not permit you to send to that address.
• Authentication required (530 5.7.1 Client was not authenticated).

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, reputation, or permission, the fix is about the sending server's permissions, 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 forged source. If the failing source is not yours, the rejection is your policy 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.
• List 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 ends enforcement and re-opens the door to forged mail.

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 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