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 it failed 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 5.7.1 code alone does not identify DMARC: check that the accompanying text names it. Under p=reject, a receiver is asked to refuse mail for which neither SPF nor DKIM passes with alignment. p=quarantine requests suspicious handling; rejection can still follow a receiver's local rules.

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 sender does not pass SPF or DKIM with alignment to the visible From domain.
• 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. Received DMARC aggregate reports may 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 (DKIM can survive forwarding if signed content is unchanged), and/or add it to SPF with correct alignment.
3. Check subdomains. Check the visible From domain, SPF envelope domain and DKIM signing domain used by each service. Publish records where those identities require them and check the inherited DMARC policy.
4. If legitimate mail is being rejected, considerp=none temporarily while you fix senders. Review your sender inventory, message headers and received reports before returning to p=quarantine or p=reject. Historic pct= sampling is removed in RFC 9989 and cannot reliably limit enforcement. Its t=y test mode requests one level less strict handling, but older receivers may ignore it.
5. Read your aggregate reports continuously. They show what participating receivers observed. Coverage can be incomplete and reports delayed; combine them with your own sender inventory and message tests.

The bigger picture

A stricter DMARC policy can reduce direct spoofing of your domain. It does not stop lookalike domains, display-name impersonation or account takeover. Start with reporting, check legitimate senders, and tighten the policy when you have evidence that supports it. Merula helps assess configuration and received reports; it does not guarantee delivery or identify every sender.