Are Backscatter NDRs Normal with DMARC? What You Can Do

The short answer

Yes. Backscatter Non-Delivery Reports are a normal and expected result of DMARC enforcement at p=reject. They are not a sign that your DMARC policy is broken.

Here is what is happening: someone sends email that claims to be from your domain. Your DMARC policy tells receivers to reject those messages. The receiver cannot deliver the message, so it sends a bounce notification to the envelope sender address. That bounce is what lands in your inbox.

You cannot eliminate backscatter entirely without dropping the security benefit of p=reject. You can reduce the volume, and you can route what remains away from user mailboxes.

What makes backscatter different from legitimate bounces

A legitimate bounce is a Non-Delivery Report for a message you actually sent. A backscatter NDR is a bounce for a message you never sent. The difference matters because the response is different.

The fastest way to tell: look at the message ID in the bounce. If your mail system has no record of sending that message ID, it is backscatter. Search your outgoing mail logs for the message ID in the bounce headers. If it is not there, you did not send that message.

You can also look at the subject line. Backscatter subjects often contain addresses or subject fragments you do not recognize. Legitimate bounces reference messages you submitted.

bounce. If your mail system has no record of sending that message ID, it is backscatter. Search your outgoing mail logs for the message ID in the bounce headers. If it is not there, you did not send that message.

You can also look at the subject line. Backscatter subjects often contain addresses or subject fragments you do not recognize. Legitimate bounces reference messages you submitted.

Why p=quarantine does not solve backscatter

Some admins move from p=reject to p=quarantine hoping it will stop backscatter. It usually does not work the way they expect.

At p=quarantine, the message is delivered to the spam or quarantine folder rather than rejected outright. The receiver may still generate a bounce notification depending on how their system is configured. The backscatter volume at p=quarantine is receiver-dependent, not reliably lower than at p=reject.

If you are considering p=quarantine to reduce backscatter, the trade-off is explicit: you are reducing DMARC enforcement strength to reduce bounce volume. For most organizations, the security benefit of p=reject outweighs the operational inconvenience of some backscatter.

p=quarantine is a legitimate staging step before moving to p=reject. It is not a backscatter fix.

Why backscatter happens at all

When a receiver cannot deliver a message, their mail system generates a Delivery Status Notification (DSN) to inform the sender. The DSN is addressed to the envelope sender (the Return-Path address), not the From address.

The key point: DMARC does not govern DSNs. The DSN is not a new message claiming to be from your domain. It is a system message generated as a consequence of message delivery failure. When the DSN is generated before the receiver evaluates DMARC policy, the bounce goes out before the rejection is applied.

This is not a bug in DMARC. The DMARC specification describes the correct behavior (evaluate DMARC before generating a DSN), but not all receivers follow it. That gap is where backscatter originates.

Which receivers generate backscatter and which do not

Receiver behavior varies significantly. Your DMARC aggregate reports are the authoritative source for which specific receivers are generating backscatter for your domain.

Gmail: Gmail generally evaluates DMARC before generating DSNs. Most spoofed messages that fail DMARC are silently rejected with no bounce generated. Gmail is not a major source of backscatter volume for most domains.

Microsoft (Exchange Online): Exchange Online may generate NDRs when messages fail DMARC alignment, particularly for messages that pass SPF or DKIM individually but fail alignment. The volume is lower than from less sophisticated receivers, but Microsoft is a common backscatter source for organizations that send to Microsoft 365 recipients.

Smaller or misconfigured receivers: Receivers that generate DSNs before applying DMARC policy, or that do not implement DMARC at all, are the most common source of backscatter. These are often smaller operators or systems behind certain filtering services.

The practical way to identify backscatter sources: look in your DMARC reports for receivers with high message counts where the pattern is SPF pass + DKIM pass + DMARC fail. That pattern means the receiver authenticated your domain but alignment failed, which is the signature of backscatter rather than direct spoofing attempts.

If you are using DMARCFlow, the receiver breakdown in your dashboard highlights exactly which receivers are generating this pattern and in what volume, without requiring manual XML parsing.

What you can actually do to reduce backscatter

Three approaches help. None eliminates backscatter entirely at p=reject, but they reduce volume and route it more intelligently.

1. Route bounces to a dedicated Return-Path domain you control

Your Return-Path domain is where bounces are delivered. Use a subdomain you control that is not used for normal user email. Backscatter NDRs will arrive at this address instead of real user mailboxes.

For example, if your sending domain is example.com, your Return-Path might be bounces.example.com or mail.example.com. Set up a dedicated monitored address like bounce-handler@example.com for this subdomain.

This does not reduce total backscatter volume. It moves it to an address that is easier to filter and monitor separately from normal email flow.

2. Deploy abuse and postmaster addresses at your Return-Path domain

The IETF recommends that domains accept bounces at abuse@domain and postmaster@domain. Some receivers check for these addresses before generating a backscatter NDR for an unknown address. Setting them up does not eliminate backscatter from all receivers, but it reduces volume from those that check.

Configure:

abuse@your-return-path-domain

postmaster@your-return-path-domain

Point both to a monitored mailbox that can handle automated bounces.

3. Filter misconfigured receivers at your mail gateway

Most backscatter comes from a small number of misconfigured receivers. Your DMARC aggregate reports show which receivers are generating messages that pass SPF and DKIM but fail DMARC alignment. You can filter or rate-limit those specific receivers at your mail gateway if the backscatter volume is excessive, rather than blocking your domain broadly.

This approach requires reviewing your DMARC reports regularly. Services that parse these reports and surface receiver-level backscatter patterns make it practical to act on this data without manual review.

What you cannot reduce

Some backscatter is structural and unavoidable at p=reject:

Messages that pass SPF and DKIM individually and fail DMARC alignment will generate bounces from receivers that generate DSNs before evaluating DMARC
Receivers that do not implement DMARC correctly will always produce backscatter for certain message patterns
Forwarded mail that fails DMARC alignment after forwarding may generate backscatter to the original sender

Accept these as the operational cost of strong DMARC enforcement. For most organizations, the security benefit of blocking spoofed mail justifies the trade-off.

Monitoring backscatter over time

Backscatter volume is not static. Changes in your email sending patterns, new receiver implementations, or modifications to your DMARC policy can all affect backscatter volume.

Review your DMARC reports periodically for shifts in backscatter patterns. A sudden increase in backscatter from a specific receiver may indicate a configuration change on their end worth investigating.

If you are receiving DMARC reports manually, this review cycle is easy to deprioritize. Automated monitoring keeps the pattern visible and flags changes without requiring you to open XML files.

FAQ

Are backscatter NDRs a sign my DMARC policy is wrong?

No. Backscatter is a normal consequence of p=reject. Bounces for messages you did not send mean your DMARC policy is working. The bounces are not from your mail system.

Why do some receivers generate backscatter and others do not?

It depends on when the receiver evaluates DMARC relative to generating the DSN. Receivers that evaluate DMARC before generating a DSN reject the message silently. Receivers that generate the DSN first, or that do not implement DMARC correctly, send a bounce before applying your policy.

Can I stop backscatter NDRs entirely?

No, not at p=reject. You can route backscatter to a monitored address and reduce volume from specific receivers, but some backscatter is unavoidable as long as you are enforcing DMARC.

Does p=quarantine produce less backscatter than p=reject?

Not reliably. Backscatter volume at p=quarantine depends on receiver implementation, not on your policy level. Some receivers generate the same volume at both levels. The backscatter reduction from p=quarantine is not guaranteed.

Should I switch from p=reject to p=quarantine to reduce backscatter?

Only if you are comfortable reducing DMARC enforcement to reduce bounce volume. Backscatter is an operational inconvenience. Reducing your security policy to reduce operational noise is a trade-off you should make deliberately and document.

How do I tell from a DMARC report if backscatter is coming from a specific receiver?

Look for high message counts where the receiver reported SPF pass and DKIM pass but DMARC fail. This pattern indicates messages that passed individual authentication checks but failed alignment, which is consistent with backscatter from bounced or forwarded mail rather than direct spoofing attempts.