Why You Get Backscatter Emails After Setting DMARC to Reject (and How to Stop Them)

The bounce that is not your fault

You set DMARC to p=reject to block email spoofing. A week later your inbox is full of Delivery Status Notifications. The messages claim your mail server tried to send a phishing email, a cryptocurrency scam, or a malware payload. You did not send any of it.

The bounces are real but the mail was not yours. This is backscatter, and it is one of the most confusing side effects of DMARC enforcement.

If you came here because you are already knee-deep in backscatter bounces, here is the short version: the messages you are receiving are rejection notices sent back to the forged sender address in the envelope, which happens to be your domain. You did not send the spam. You are just seeing the collateral damage from a receiving server rejecting it.

This is where DMARCFlow fits naturally into the picture. DMARC aggregate report monitoring catches the authentication failure spikes that precede a backscatter flood. Rather than waiting for your users to report an inbox full of bounces, you get an alert when your domain is being forged at scale. That gives you context and lead time even before the backscatter arrives.

Keep reading for the full explanation and what to actually do about it.

What is backscatter, exactly

Backscatter is a bounce message that is sent to the envelope sender of a message, after that message is rejected by a receiving mail server. When a spammer forges your domain as the sender and the receiving server rejects the mail, the receiving server looks at the envelope sender address and sends its rejection notice there. The rejection notice lands in your inbox, not the spammer's.

This is different from a misdirected bounce, where someone types the wrong recipient address and mail meant for another person lands in yours. A misdirected bounce is a single message gone to the wrong place. Backscatter is a targeted blast of rejection notices triggered by a spam run that used your domain as the From address.

The term backscatter comes from optics: light scattered backward. In email, the name fits because the rejection notices are scattered back to the wrong person.

Why DMARC p=reject makes it worse

Before DMARC, backscatter existed but was less predictable. With p=none or p=quarantine, you might never see it because the receiving server accepted the mail, even if it was forged. With p=reject, the receiving server actively rejects the mail and sends a bounce back to the envelope sender. If that envelope sender domain matches your domain, you receive the backscatter.

The problem is amplified by how SMTP works. The envelope sender address (also called Return-Path) is separate from the From header address that users see in their email client. Spammers typically forge the From header because that is what users see. But the envelope sender is what receiving servers use to route bounces. When a receiving server rejects a message, it sends its rejection notice to the envelope sender.

If your DMARC policy is p=reject and a spammer forges your domain in the From header, the receiving server checks alignment and rejects the message. If the envelope sender also uses your domain, you get the backscatter.

Not all backscatter comes from DMARC enforcement. Some comes from servers that reject mail based on content, spam filters, or other criteria. But when your DMARC policy is set to reject, you will see more of it because more forged mail is being rejected at the border.

The difference between backscatter and misdirected bounces

These two are often confused. Here is how to tell them apart.

A misdirected bounce happens when someone sends a message to an address that does not exist or belongs to the wrong person. The sending server tries to deliver it, fails, and sends a bounce to the original sender. If you are the original sender because someone typed your address wrong, you get a bounce for a message you did not send. The From address and envelope sender in the original message are both likely your domain, and the bounce is a response to a single mistaken delivery.

Backscatter from spam forgery looks different. The forged message may have hundreds or thousands of recipients at many different domains. When those receiving servers reject the mail, they all send rejection notices back to the same forged envelope sender address, which is your domain. You get a sudden flood of bounces, all referencing different messages to different recipients, all rejected at roughly the same time.

If you see a burst of dozens or hundreds of bounces in a short window, all with different subject lines and recipient addresses, that is backscatter from a spam run that forged your domain. If you see one or two bounces with messages that look like they were meant for you personally, that is more likely a misdirected bounce.

How to identify backscatter sources using DMARC aggregate reports

Your DMARC aggregate reports are the most useful tool for figuring out what is actually being forged and rejected. Each report shows you which servers are sending mail that fails DMARC alignment. When a spam run uses your domain, you will typically see a spike in failed authentication from IP addresses you do not control.

Aggregate reports will not show you the spam that was rejected. They will show you the authentication failures, which gives you the context: if you see thousands of failures from IP addresses in ranges you do not recognize, and the timing aligns with when your backscatter started, you have confirmed a forgery incident.

DMARCFlow aggregates these reports and surfaces the spikes in authentication failures that correspond to backscatter-generating spam runs. A sudden increase in DMARC failures from untrusted sources is a reliable signal that someone is forging your domain and that you will likely see backscatter as a result.

The SUBMITTER scheme: a real fix for envelope sender backscatter

RFC 8297 defines the SUBMITTER scheme, and it is specifically designed to address the problem of backscatter sent to the envelope sender of a message.

The idea is straightforward: when a submitting server receives a message to relay, it should encode its own identity in the envelope sender address rather than blindly preserving the original From header or envelope sender. That way, when a receiving server rejects the message, the bounce goes back to the actual submitting server, not to a forged address.

In practice, the SUBMITTER scheme replaces the envelope sender address with a hashed or encoded form that routes back to the originating mail system. If a receiving server then bounces the message, the bounce routes to the real sender, not to an innocent domain that was forged.

Not all mail servers implement SUBMITTER yet. It is a standards-track RFC but adoption has been gradual. If your mail infrastructure supports SUBMITTER, enabling it will significantly reduce backscatter. Check with your mail server vendor or hosting provider to see if it is available.

Envelope From alignment: using a safe sender address

Another approach is to control what gets used as the envelope sender address for your outbound mail. Most legitimate bulk mail senders use a dedicated subdomain as the Return-Path, something like noreply@mail.example.com rather than @example.com. This means that if a receiving server rejects a message, the bounce goes to that dedicated subdomain, not to a main domain address that users actually monitor.

If your mail system is sending from @example.com as the envelope sender and you are seeing backscatter, consider switching to a dedicated sending subdomain. That subdomain can have its own SPF record and can be isolated from user-facing addresses. When bounces come back, they come to the sending infrastructure, not to your users.

This is a configuration change rather than a protocol change, and most enterprise mail systems support it. The trade-off is that bounces routed to a noreply address are harder to monitor manually, so you may want to route those bounces to a monitored alias or aggregation system.

Null MX: does it actually help with backscatter?

Null MX does not help with backscatter. The reason is structural: backscatter rejection notices are sent to the envelope sender address, which is set by the sending mail server in the Return-Path header. It has nothing to do with your MX records. Even if you remove your MX records entirely, the receiving server has already captured the envelope sender address during the SMTP session and uses that to route the rejection notice. The bounce goes to the address in the Return-Path, not to your DNS configuration.

Null MX on your main domain also breaks legitimate mail routing. If you set null MX for example.com, any server that checks your DNS before sending will see that you accept no mail and may reject messages at that stage, before the SMTP transaction completes. This makes your bounce messages less useful and can cause legitimate senders to give up.

The only appropriate use for null MX is on subdomains that genuinely have no mail function and never will, such as a www-only subdomain with no mail service of any kind. Even then, null MX does not reduce backscatter. It only reduces the possibility of direct mail delivery to that subdomain.

What to do right now

If your inbox is already flooded with backscatter, here is a practical sequence:

First, confirm it is backscatter and not something else. Look at the bounce messages. Are they all referencing messages to different recipients, sent at around the same time, with subjects that look like spam or phishing? That is backscatter. Are they referencing messages that look like they were actually sent from your server to specific people? That might be a misconfiguration on your end.

Second, check your DMARC aggregate reports for an authentication failure spike. If you see a spike from IP addresses you do not recognize, that confirms a forgery incident. DMARCFlow surfaces these spikes automatically and alerts you when they happen, so you catch the incident before your users start reporting the bounce flood.

Third, do not try to unsubscribe from backscatter messages or reply to them. They are automated bounces, not real conversations. Replying or clicking links in backscatter messages is how users end up on spam lists.

Fourth, if you want to reduce future backscatter, check whether your mail sending infrastructure supports SUBMITTER or whether you can use a dedicated sending subdomain with its own envelope sender address.

Checklist: diagnosing and reducing backscatter

• Understand the difference: backscatter is a flood of bounces from forged mail; a misdirected bounce is one message to the wrong address
• Check DMARC aggregate reports for spikes in authentication failures from untrusted IP addresses
• Use DMARCFlow alerts to catch authentication failure spikes early -- this is your backscatter early warning system
• Use a dedicated sending subdomain for bulk or automated mail so bounces route there, not to user addresses
• Ask your mail infrastructure vendor whether SUBMITTER support is available
• Do not set null MX on your main domain in an attempt to stop backscatter -- it will not work and will break legitimate mail routing
• Route bounces from your sending infrastructure to a monitored alias so you can track backscatter events

Frequently asked questions

Does setting DMARC to p=reject cause backscatter?

Setting p=reject causes more backscatter than p=none because more forged messages are rejected at the border rather than accepted and filtered silently. The backscatter itself comes from the receiving server sending rejection notices to the forged envelope sender address. If that envelope sender is your domain, you receive the bounces.

Why am I getting bounces for spam I never sent?

You are not actually getting bounces for mail you sent. You are getting rejection notices that were addressed to your domain because a spammer forged your domain as the sender. The bounce notices are the receiving server's automated response to a rejected message. You did not send the original spam and you are not responsible for it.

How can I stop backscatter?

You cannot completely eliminate backscatter because you do not control what happens after a receiving server rejects a forged message. You can reduce it by using a dedicated sending subdomain as your envelope sender address, by implementing the SUBMITTER scheme if your infrastructure supports it, and by monitoring DMARC aggregate reports to catch forgery incidents early. DMARCFlow helps by alerting you when authentication failure spikes suggest a forgery run is underway, giving you context before the backscatter arrives in your users' inboxes.

Does null MX stop backscatter?

No. Null MX removes your MX records so that no mail can be delivered to your domain. It does not affect where rejection notices are sent. Those notices go to the envelope sender address set by the sending server, not to your DNS records. Null MX is not a backscatter solution.

Can DMARCFlow help with backscatter?

Yes. DMARCFlow aggregates your DMARC reports and alerts you to sudden spikes in authentication failures, which typically correspond to a forgery incident generating backscatter. By catching the forgery incident early through aggregate report monitoring, you can investigate and take action even before users start reporting the bounce flood. DMARCFlow's alerting on authentication failure spikes is the closest thing to a backscatter early warning system that most organizations have access to.