550 5.7.1: email rejected per DMARC policy

The receiving server checked DMARC for the domain in your From header, and the check failed. That domain's policy says to refuse mail that fails, so the server refused it. Make SPF or DKIM pass in alignment with your From domain for the system that sent this. The recipient can't fix it for you.

Is this a DMARC rejection? Only when the word DMARC, or a policy for your domain, appears in the bounce text. Receivers use 5.7.1 for any message a rule refused.

What the bounce says

Gmail sends this when the domain publishes quarantine or reject:

Postfix and Exim hosts running OpenDMARC, which covers most self-hosted receivers, send this:

Yahoo uses its own wording for policy rejections:

Yahoo changes its codes more often than the others do. Its sender hub at senders.yahooinc.com has the current list. If your bounce text differs by a word, go by your bounce text.

Confirming it's DMARC

Run these checks to tell a DMARC rejection from the other refusals that use this code.

1. Check the bounce text for DMARC, a policy or your domain. A 5.7.1 with the text Relay access denied comes from a misconfigured relay and has nothing to do with authentication.
2. Check that your domain publishes an enforcing policy:
   dig +short TXT _dmarc.example.com
   If you get p=none back, the rejection has another cause. With p=none, you've told receivers to deliver failing mail anyway.
3. Check that it fails for one sending system and not the others. A tool that sends through your own mail server usually passes. The tool that sends through a vendor is usually the one failing.

The DMARC checker reads every tag in the record. Look closely at sp=, which sets the policy for subdomains, and pct=. A pct= tag applies the policy to a fraction of messages, so the rejections come and go and look like flakiness.

Causes

1. A vendor that was never authenticated for your domain. This is the most common cause.
2. A subdomain covered by an inherited policy. p=reject on the parent applies to mail.example.com unless you set sp=. The clean fix is a separate DMARC record on the subdomain. Leave the parent's policy as it is.
3. Strict alignment. If you set aspf=s or adkim=s, an exact domain match is required and a subdomain no longer counts. Most people who set this didn't mean to. Alignment, explained covers the difference.
4. SPF permerror. Past the lookup limit, a sender that receivers need an eleventh lookup to find gets permerror instead of pass, so its mail can only pass DMARC on DKIM. SPF permerror from too many DNS lookups has the fix.

Fixes

1. Find the sending system. If you can't tell which one it is from the bounce, check your aggregate reports, which list every source sending as your domain. How to read a DMARC aggregate report walks through one.
2. Complete its domain authentication so it signs with d=example.com.
3. Set a custom return-path if the system offers one.
4. Retest with a single message to a Gmail address, then check the results in Gmail's Show original.

If you're mid-rollout and this is breaking real mail, go back to p=none for a week while you fix the sender. Don't move back to reject until that sender passes.

Once the sender passes, guided enforcement can move your policy back to p=reject. We move the policy a step at a time, and you approve each step. With hosted DMARC, we read the reports in the days after each step. When a sender you marked as yours sends enough mail to measure and a step starts blocking it, we put the previous policy back and email you. Our rollback rules list the thresholds. We can't bring back mail a receiver already refused. Rollback comes with the Starter plan and up. You can try it free for 30 days with no card. Set up guided enforcement.