Why DMARC Reject Policy Sends You Backscatter Emails and How to Stop Them

What is backscatter and why does it happen after enabling p=reject

You switched your DMARC policy to p=reject. Your users are now getting delivery failure notifications from email servers they have never contacted. These are not attacks. This is backscatter.

Here is what is actually happening. A legitimate email is sent from a third-party service on your behalf. That service does not align with your DMARC record. Your reject policy tells receiving servers to refuse the message. The receiving server then sends a bounce notification back to the supposed sender address. If the original email had your domain in the From header, that bounce lands in your users' inboxes.

The emails are not coming from your domain. They are failure notifications generated by someone else's server because it refused a message that appeared to come from you.

This is different from a DMARC authentication failure. The failure is real, but the bounce is generated by a third-party server that is following RFC compliance rules when rejecting unaligned mail.

Why p=reject is still the right call despite backscatter

Backscatter is annoying. It is not a reason to roll back to p=none.

Your reject policy is doing exactly what it should. Unaligned third-party senders are being rejected, which prevents spoofing attacks that impersonate your domain. The fact that some of those rejections come from legitimate forwarding scenarios does not change the security value of the policy.

Rolling back to p=none or p=quarantine reopens your domain to spoofing. The correct response to backscatter is to find the legitimate senders that are triggering it and fix their configuration. That work is worth doing.

How to find the legitimate senders causing your backscatter

Open your DMARC aggregate reports. Look for entries where your domain is the sending domain and the result is fail. Ignore anything clearly malicious. Focus on entries with the following patterns:

• Forwarding services that use your domain in the From header but send through their own infrastructure
• Internal systems or scripts that send on behalf of your domain without DKIM signing
• Marketing automation tools, CRM platforms, or ticketing systems that use your domain but have never been configured for DKIM alignment

The DMARC report gives you the sending domain, the result, and the count. Cross-reference the sending infrastructure with your known third-party services. Any legitimate service that appears repeatedly is a candidate for backscatter generation.

Raw DMARC XML is tedious to review manually. DMARCFlow aggregates the same reports and shows misaligned sending sources by name, so you can go from backscatter complaint to targeted fix list without opening a single XML file.

How to stop backscatter without disabling reject policy

Once you have identified the problematic senders, you have three practical options:

Fix DKIM alignment on the sending service. If the third-party service supports DKIM signing, add the required DKIM record to your DNS and enable signing in the service settings. A DKIM-signed message that passes alignment satisfies DMARC even when sent from infrastructure outside your control.

Use SRS for forwarded mail. If your organization forwards email for users, configure Sender Rewriting Scheme (SRS) on your forwarder. SRS rewrites the return path so that bounces go back to the forwarder rather than the original sender, breaking the backscatter loop. Most modern mail transfer agents support SRS out of the box.

Add List-ID headers to mailing lists. If you run mailing lists that forward mail on behalf of subscribers, use the List-ID header as defined in RFC 5359. This provides an authenticated identifier that some receivers use to accept forwarded mail even when DMARC alignment fails. Some large mailing list providers also offer address hiding modes that reduce backscatter surface area.

Not every misaligned sender can be fixed. Some legacy systems, some SaaS tools, some forwarding chains have no SRS option. For those cases, you can use a subdomain isolation strategy: move specific use cases to a subdomain with its own DMARC record set to p=none or p=quarantine, keeping your main domain at p=reject.

What to tell your users about failure notifications

If your users receive backscatter failure notifications, tell them the following:

• Do not click any links in the failure message. Backscatter notifications are as susceptible to social engineering as any other email.
• The failure notification is generated by a third-party server. It does not mean your account has been compromised.
• If the failure happened to an email the user did send, it means the recipient's server rejected it due to a configuration problem on the receiving side. The user may want to contact the recipient through another channel to resolve the delivery issue.

Backscatter does not indicate a breach. It indicates a configuration gap between your DMARC policy and your sending infrastructure. Fix the gap.

FAQ

Does p=reject cause backscatter?
No. Your reject policy causes receiving servers to refuse unaligned mail. Backscatter comes from the bounce notifications those servers generate. The policy is working correctly. The gap is in your legitimate sender alignment.

Can I block backscatter emails at my gateway?
You can filter bounce notifications that arrive at your inbound gateway, but blocking them risks filtering legitimate bounces. A better approach is to reduce the number of unaligned legitimate senders generating bounces in the first place.

Why do some forwarding services cause backscatter and others do not?
It depends on how the forwarding service handles the From header. Some services rewrite the From to indicate the original sender. Others forward the message with the original From intact, which triggers DMARC rejection at the next hop. Services that follow RFC 5321 forwarding best practices are less likely to cause backscatter.

Does SPF alignment help with backscatter?
SPF alignment alone is not sufficient. DMARC requires either SPF alignment or DKIM alignment (or both). A forwarded message that passes SPF on the original hop may still fail DMARC if the forwarded infrastructure does not align. DKIM signing at the original sending service is the more reliable fix for forwarding scenarios.

---

DMARC reject policy is a strong security control. Backscatter is a signal that your sending ecosystem has configuration gaps, not that your policy is wrong. Use your DMARC reports to find the gaps, fix what you can, SRS what you cannot, and keep your reject policy in place.

If you want a practical way to turn your DMARC reports into a prioritized fix list without parsing XML, DMARCFlow handles the aggregation and flags the sending sources generating the most alignment failures. That is the fastest path from backscatter complaint to a specific configuration fix.