How to Stop Backscatter NDRs When You Enforce DMARC

You turn on DMARC p=reject, finally. The next morning your inbox is full of bounce messages for mail you never sent. Nothing on your side changed except the policy. That is backscatter, and it is a near-universal side effect of enforcing DMARC on a domain that anyone on the internet can pretend to be.

This post explains the chain that creates the noise, what DMARC p=reject actually does to bounce traffic, and three defenses you can deploy today. None of them require you to weaken your policy.

Why you are getting NDRs for mail you never sent

Backscatter starts with a forged sender. Someone sends spam with your domain in the envelope sender (MAIL FROM:), so when their message bounces, the bounce comes back to your domain. Before DMARC, your MX accepted the original spam. After p=reject, your MX rejects it during the SMTP conversation.

Two things happen then. If the receiver rejects with a 5xx at SMTP time, no bounce is generated - the spoofer's server simply gets a non-delivery report they will discard. But many senders - especially older scripts, list managers, and notification systems - do not bother to use the address they actually sent from. They put the user's address in the Reply-To: or use a From: that is unrelated to the envelope sender. The bounce then arrives at the address in Reply-To, which is your domain.

The second mechanism is forged From: headers in spam. The spoofer puts victim@yourdomain.com in the visible From line, sends to a million addresses, and when 999,999 of them bounce, your address gets the NDRs. DMARC p=reject on your domain does nothing here - the bounces are coming from the spoofer's outbound, not from your MX.

So the question is not whether DMARC caused this. The spam was always being sent. The question is why your inbox is suddenly a destination, and which defenses cut through it. That is also where a monitoring tool helps before you start cutting traffic. DMARCFlow surfaces the spoofing sources in aggregate reports so the bounce noise stays separate from the real signal.

What DMARC p=reject actually does to bounce traffic

DMARC p=reject tells receivers to drop mail that fails both SPF and DKIM alignment. It does not control what those receivers do with their outbound mail. Your policy only governs whether mail claiming to be from your domain reaches the inbox.

Backscatter NDRs that arrive at your domain are usually generated by the spammer's outbound server or by misconfigured mailers using your address as a Reply-To. Your MX can either accept them or reject them at SMTP time. Most operators' MX currently accepts them, which is why they land in user inboxes.

In other words, the backscatter problem is mostly a receiver-side filtering problem on your MX, not a DMARC configuration problem. The fix lives in your inbound mail flow, not in your published DNS records.

Three defenses you can deploy

These are listed in order of how much they protect you. Each one is independent - you can run all three.

1. Block NDRs at SMTP-time before queueing

The most effective single defense is rejecting bounce messages during the SMTP conversation, not after. The relevant Postfix pattern looks like this:

smtpd_sender_restrictions =     reject_unauth_pipelining,     reject_non_fqdn_sender,     reject_unknown_sender_domain,     reject_unverified_sender  smtpd_recipient_restrictions =     reject_unauth_destination,     reject_unverified_recipient

The key setting is reject_unverified_sender. When a sender claims to be bounce-12345@yourdomain.com, Postfix does a verification probe to your MX. If the probe confirms the address does not exist, the inbound NDR is rejected at SMTP time and never reaches a queue. The probe is cheap - one SMTP call per inbound NDR, usually completing in well under a second.

If you use OpenDMARC, you can additionally reject mail that fails DMARC alignment at SMTP time using reject_failures. This is independent of your published policy - even if you publish p=none, you can still reject non-aligned mail locally.

A subtle but important point: do not enable reject_unverified_sender on outbound mail from your own MX. Only enable it on the public-facing smtpd listener, not on the submission port.

2. Sign outbound mail with BATV or VERP-style addressing

Bounce Address Tag Validation (BATV) and Variable Envelope Return Path (VERP) both tag the envelope sender with a per-recipient token. When an NDR arrives at the tagged address, your MX can verify the tag came from you, and discard it if it did not.

BATV is the lighter lift for most operators. Postfix supports it through the postfix-bat patch set, and Exim has it built in. The token is prepended to the envelope sender, like bounce+tag=xyz@yourdomain.com. The downside is that some mailers do not handle BATV-style addresses well, so test before deploying broadly.

VERP is conceptually similar but uses per-recipient addresses derived from the recipient list. It is most often used by mailing list operators, not by general-purpose MXs.

Neither approach eliminates backscatter, but they sharply reduce the rate of false positives: the bounces that do arrive are tagged and verifiable, so the untagged ones can be dropped with high confidence.

3. Use DMARC reports to find and stop the upstream abuse

Backscatter that comes from spammers using your domain as the envelope sender means someone is pretending to be you. If you have not already cleaned up your legitimate sending sources, those reports are buried under spoofed traffic.

This is where DMARC reporting earns its keep. Aggregate reports show every IP claiming to send mail as your domain. If you see an IP you do not recognize, it is either a misconfigured legitimate sender or a spoofing source. Forensic reports (when enabled) include the headers of failed messages, which makes identifying the spoofed pattern faster.

DMARCFlow is built for this step. The aggregate reports are usually too large to read manually, and the spoofing patterns are often hidden in the noise. A monitoring tool surfaces the unknown senders so you can chase them down instead of drowning in NDRs. This is the operational payoff: the policy is set, the spoofing sources are visible, and the residual backscatter is no longer the loudest signal in your inbox.

Decision rule: which defense when?

If you only have an hour, do step 1. reject_unverified_sender plus DMARC reject-at-SMTP cuts backscatter by 80 to 90 percent on most operators' MXs and does not require any DNS changes.

If you have a day, add step 3. Pull the last 30 days of DMARC aggregate reports and identify every IP sending as your domain. Most operators find at least one unrecognized source - usually an old ESP, a SaaS tool that sends notifications, or a misconfigured transactional sender. Each one is a real backscatter generator.

If you have a week and a mature mail environment, add step 2. BATV is the right answer for high-volume transactional senders and mailing lists. It takes longer to deploy and test, but it gives you a reliable way to distinguish real bounces from forged ones.

A common mistake is to skip step 3 entirely and rely only on filtering. Filtering suppresses the noise, but the underlying spoofing is still happening and will eventually show up as a deliverability problem when a major receiver starts penalizing your domain for the spoofed traffic.

FAQ

Does p=none reduce backscatter compared to p=reject?

No. p=none is a monitoring policy. Your published policy does not control how spammers forge your address or how your MX handles inbound bounces. The choice between p=none and p=reject affects whether receivers deliver mail claiming to be from your domain. It does not affect whether NDRs for forged senders reach your inbox. That is a property of your inbound filtering.

Can I tell whether an NDR is real or a backscatter?

Usually. Real NDRs include the original message headers or at least the message ID, the sending server's identity, and timestamps from the original transaction. Backscatter NDRs typically have empty bodies, generic subjects like "Mail delivery failed", and headers that do not reference any mail you actually sent. The most reliable test is whether the original recipient in the NDR matches any address you actually sent to. If not, it is backscatter.

Is there a way to sign outbound mail so receivers can verify the NDR?

Yes. DKIM signs the message body, which the receiver can verify if it kept a copy. SRS (Sender Rewriting Scheme) rewrites the envelope sender when forwarding so SPF still passes. Neither solves the backscatter problem on the receiver side directly, but they make legitimate mail more verifiable, which over time reduces the rate of false-positive backscatter.

Should I disable null-sender rejection if I run a mailing list?

Probably not at the MX. Null-sender rejection is a feature of how your MX handles mail with an empty envelope sender, which is what legitimate bounces use. Mailing lists rarely generate null-sender bounces to your MX - they generate them to the original sender. If you are seeing NDRs with empty envelope sender coming into your MX, those are almost always backscatter. Keep null-sender rejection on.

Closing

Backscatter is the price of a real DMARC enforcement policy. It is also the signal that spoofers were abusing your domain all along and you only noticed because you finally gave receivers permission to reject. The fix is not to soften the policy. It is to filter NDRs at SMTP time, sign outbound mail so the real bounces are verifiable, and use DMARC reports to find the upstream sources.

If backscatter is still the loudest thing in your inbox after the steps above, the answer is almost always an unrecognized sender showing up in your aggregate reports. Pull the last month of reports and work that list. The remaining handful of unknown IPs are the spoofers, not your mail server.

For operators managing multiple domains or who want a single dashboard that turns aggregate reports into a list of unknown senders, DMARCFlow handles the report-parsing and source-tracking layer so the inbox stays focused on real mail.