Error 550 5.7.1 “Message rejected due to DMARC policy” — causes and fixes

What this error means

The receiving mail server rejected your message because itfailed DMARC evaluation against your own domain’s published policy. Typical bounce texts:

550 5.7.1 Email rejected per DMARC policy for yourdomain.com
550 5.7.1 Unauthenticated email from yourdomain.com is not accepted
554 5.7.5 Permanent error evaluating DMARC policy

Unlike provider-specific errors, 5.7.1 DMARC rejections can come from any receiving server — Gmail, Microsoft, corporate mail gateways, other businesses. The receiver did exactly what your DMARC record told it to do: your policy says p=reject(or p=quarantine), the message failed both SPF and DKIM alignment, so it was refused.

This error is common in one particular scenario: a business moves to p=reject, and a legitimate sending service that was never properly aligned starts bouncing. The policy isn’t wrong — the inventory was incomplete.

Why you’re seeing it

• A legitimate sender isn’t aligned. The service sends real mail for you, but its messages pass neither SPF nor DKIM with your domain. It worked before enforcement; now it doesn’t.
• Forwarded mail. A recipient auto-forwards your message onward; SPF breaks in transit, and if the message wasn’t DKIM-signed, the forwarded copy fails DMARC at the final destination. Mailing lists trigger the same pattern.
• Subdomain mail without subdomain records. Mail from invoices.yourdomain.com inherits the organisational policy via sp=/default inheritance, but the subdomain has no SPF/DKIM of its own.
• You were spoofed — and DMARC worked. If the bounced message isn’t yours at all, this error is the system succeeding: someone forged your domain and the receiver blocked it. Your DMARC aggregate reports will show the source.

How to fix it

1. Determine whether the rejected mail is legitimate.Check the bounce’s message details against your known sending services. If it’s not yours, no fix is needed — file it as evidence the policy is earning its keep.
2. If legitimate, align the sender: enable DKIM signing with your domain in the service’s settings (the durable fix — DKIM survives forwarding), and/or add it to SPF with correct alignment.
3. Check subdomains. Every subdomain that sends mail needs its own SPF and DKIM records.
4. If you moved to enforcement too early, step back to p=quarantine; pct=25 while you complete the sender inventory from aggregate-report data — then return top=reject. Don’t park at p=nonepermanently; that re-opens the spoofing hole the policy exists to close.
5. Read your aggregate reports continuously. They are the only complete record of what passes and fails across all receivers — and the only way to catch the next unaligned sender before enforcement bounces it.

The bigger picture

Enforcement is the destination, not the problem. EU CSIRTs’ standing recommendation — monitor first, then enforce — exists precisely because of this error: the monitoring phase is where you find every legitimate sender before the policy starts rejecting. Across the EU, regulators and large customers increasingly expect enforcement-level DMARC from suppliers; the answer to 5.7.1 bounces is finishing the alignment work, not abandoning the policy.