Why You Still Get Backscatter NDRs With DMARC at Enforcement

You set DMARC to p=reject. You expected spoofed emails to disappear. Instead, your queue fills with bounce messages. This is the most common confusion after moving to DMARC enforcement.

Here is what is happening: DMARC p=reject tells receiving servers to reject mail that fails authentication. It does not control what happens when your own servers send mail or what third-party servers do with rejected messages.

When a receiving server rejects a message due to DMARC failure, it should reject it at the SMTP level. But many servers do not. They accept the message, process it, realize something is wrong, and send a Non-Delivery Report to the From: address listed in the message. This is backscatter, and it is generated by third-party servers that do not follow RFC 5321 bounce handling rules.

What Is Backscatter and Why Does It Happen

Backscatter is bounce mail sent to the From: header address. It happens when a mail server receives a message, rejects it after acceptance, and sends an NDR to whoever the From: header claims sent it.

When you set DMARC to p=reject, you are instructing receiving servers to reject non-compliant mail. You are not controlling how those servers handle the rejection, whether they send bounces, or where those bounces go. Large email providers, enterprise mail systems, and outdated mail servers routinely send backscatter regardless of DMARC policy.

The result: you block more spam, but you receive more NDRs for spam that used your domain in the From: header. Attackers spoof your domain. Receiving servers reject the spam. Those servers send bounce notifications to your postmaster address. You see bounces for messages you never sent.

How DMARC Enforcement Actually Works

DMARC enforcement happens at the receiving server, not your sending infrastructure. Your DNS record is a set of instructions you send to other servers. It does not govern your own mail behavior.

When a message fails DMARC alignment at the receiving server, that server is supposed to reject it with an SMTP error code. Your server never learns about that rejection unless the receiving server sends a bounce. Many do. They send bounces to the From: address in the message, not to a bounce handling address you control.

This is the key point: DMARC p=reject is an instruction to other servers. It does not make your infrastructure stop generating bounces. Your own mail server can still send bounces for legitimate reasons: quota violations, mail loops, invalid recipients. These are not backscatter. Backscatter specifically comes from third-party servers.

The Difference Between a Legitimate Bounce and Backscatter

A legitimate bounce is an NDR generated by your own server because it could not deliver a message. The destination did not exist, the mailbox was full, or your server could not reach the destination.

Backscatter is an NDR generated by a third-party server after it accepted and then rejected a message. The bounce goes to your From: address because the third-party server does not know who actually sent the message. It only knows what the From: header claims.

This distinction matters because backscatter often appears to come from your own domain. Attackers spoof your domain in the From: header. Receiving servers reject those messages and send NDRs to your domain. You get bounces for messages you never injected into the mail stream.

The fastest way to tell the difference is to check your DMARC aggregate reports. These reports show which sending sources generate authentication failures for your domain. If the failures come from IP addresses you recognize, your infrastructure has a configuration problem. If they come from IPs you do not recognize, you are seeing spoofing attempts.

How to Identify Backscatter Sources in Your DMARC Reports

When you review your DMARC aggregate reports, look for the failure sources.

If failures originate from your own mail server IP addresses, your outbound mail is failing DMARC alignment. Common causes: your relay changes the envelope sender, DKIM signing is broken due to header canonicalization mismatches, SPF alignment fails because your Return-Path does not match your envelope sender, or some of your mail servers are not authorized in your SPF record.

If failures come from IP addresses you do not recognize, someone is spoofing your domain. The backscatter NDRs are replies to those spoofed messages. This is expected behavior when you enforce DMARC - you are blocking more spam, which means more NDRs go to addresses that appear to be from your domain.

DMARCFlow parses aggregate reports and flags which sending sources generate the most alignment failures. A typical backscatter report might show a sending IP you do not recognize generating 1,200 alignment failures in a 24-hour period - that is spoofing, not your infrastructure.

Practical Steps to Reduce Unwanted Backscatter NDRs

1. Fix your own alignment failures first. Review your DMARC reports weekly. If your own servers appear in alignment failures, fix SPF and DKIM configuration immediately. Your bounces will decrease as your outbound mail becomes compliant.

2. Use Null MX for domains that do not receive mail. RFC 7505 specifies that a Null MX record tells compliant servers the domain does not accept mail. Servers that follow RFC 5321 will not generate bounces for addresses at that domain.

3. Implement RFC 6522-compliant bounce handling. Modern mail servers can send bounces to the reverse-path envelope sender rather than the From: header. Configure your servers to use the envelope sender for bounces, not the From: header.

4. Monitor with a DMARC reporting service. Daily summaries and alerting tell you about alignment failures within hours, not days. The faster you know your own servers are failing, the faster you can fix them before they generate backscatter.

5. Do not worry about backscatter from spoofing. When third-party servers reject spoofed messages and send NDRs to your domain, that is normal and expected. It means DMARC enforcement is working. Focus on fixing your own infrastructure, not on blocking bounces from servers you do not control.

When Backscatter Indicates a Real Problem

Backscatter from third-party servers spoofing your domain is normal. More enforcement means more rejections, which means more NDRs to spoofed addresses.

But if you see backscatter that originates from your own mail servers, that is a problem. It means your outbound mail is failing DMARC alignment. Check your DMARC reports for the specific failure reasons. The report will show whether SPF alignment, DKIM alignment, or both are failing.

Common causes of your own infrastructure generating backscatter:

Your mail relay changes the envelope sender after submission

DKIM signing breaks due to header modifications in transit

SPF alignment fails because your Return-Path domain does not match your From: domain

Multiple mail servers exist but only some are authorized in your SPF record

FAQ

Does DMARC p=reject block emails from being delivered?
It tells receiving servers to reject emails that fail authentication. This happens at the receiving server. Your own server can still send bounces for other reasons, including backscatter from third-party servers that rejected mail claiming to be from your domain.

Why am I getting bounce messages from my own domain when I set DMARC to reject?
You are likely seeing backscatter. Receiving servers rejected spoofed messages that claimed to be from your domain and sent NDRs to your domain's postmaster address. You did not send those original messages.

Is backscatter a sign my DMARC setup is wrong?
Usually no. Backscatter from third-party servers is normal when you enforce DMARC. If you see bounces originating from your own mail servers, that indicates your outbound mail is failing DMARC alignment, which you should fix.

How can I stop backscatter NDRs?
You cannot stop third-party servers from sending backscatter. You can reduce it by fixing alignment failures in your own infrastructure and by using Null MX records for domains that do not receive mail.

What is the difference between a bounce and backscatter?
A bounce is generated by your own server when you cannot deliver a message. Backscatter is generated by a third-party server that accepted then rejected a message, sending the NDR to the From: header address.