How to Stop Backscatter NDR Emails from Your Server

What Is Backscatter and Why Does It Happen

You receive a complaint. Someone emails you saying your mail server sent them a bounce notification for a message they never sent. They were not trying to reach you. They are not even expecting email from you. Their server is treating your bounce as unsolicited mail.

This is backscatter. Your server is sending Non-Delivery Reports (NDRs) to people who had nothing to do with the original message.

The root cause is a mismatch between who sent the message and who is listed as the sender. Spammers and worms send email with forged sender addresses. When your server receives that forged message and rejects it, it sends the bounce to the forged address. That forged address belongs to an innocent third party. They receive a bounce notification for mail they never sent, and they see your server as the source of the problem.

The Core Problem: Forged Sender Addresses

SMTP was designed at a time when server operators trusted each other. The protocol allows any server to claim any sender address. Modern email builds on this with SPF, DKIM, and DMARC to verify sender authenticity, but the underlying behavior persists.

Backscatter happens in this sequence:

1. A spammer sends an email with your domain forged as the sender (e.g., From: support@yourdomain.com).
2. Your server receives the message and processes it.
3. Your server determines the message is invalid (wrong recipient, spam, or policy violation).
4. Your server sends a bounce NDR to the sender address in the message headers.
5. That sender address was forged. The bounce goes to an innocent third party.

The key problem is step 2. Your server accepted the message before verifying whether the sender was legitimate. If your server had rejected the message at the SMTP connection stage, no bounce would be generated. The difference between a clean mail server and one generating backscatter is almost always in when and how the server chooses to accept or reject incoming mail.

How to Stop Backscatter: Three Methods

#### Method 1: Reject at SMTP Connection Stage

The most effective way to stop backscatter is to reject invalid messages before your server accepts them. During the SMTP transaction, while the sending server is still connected, your server can evaluate the message and reject it with a 5xx error code. The sending server then handles its own bounce locally. No message is accepted, no bounce is generated, no innocent third party is contacted.

This is called connection-stage rejection. It requires your MTA to perform SPF checks, DKIM verification, and other anti-forgery checks during the SMTP conversation, before the DATA command completes.

For Postfix, the configuration looks like this:

smtpd_relay_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    check_policy_service unix:private/policyd-spf
    reject_invalid_hostname
    reject_non_fqdn_helo_hostname
    reject_unknown_reverse_client_hostname
    reject_unknown_sender_domain

The check_policy_service directive invokes a SPF policy daemon. If the connecting server fails SPF checks, the connection is rejected in real time before any message data is accepted. Adding DKIM verification via OpenDKIM and integrating it into the same restriction flow pushes the rejection earlier in the process.

The practical constraint: your server must perform these checks before it accepts the message. Once a message is accepted into the queue, your server is committed to handling it somehow, and bouncing is the default behavior.

#### Method 2: Configure DMARC to Prevent Your Domain From Causing Backscatter

DMARC does not directly prevent your server from generating backscatter, but it does control what happens when receiving servers process messages from your domain.

When you publish a DMARC policy with p=reject, you are telling receiving servers: if a message from your domain fails both SPF and DKIM alignment, discard it silently. Do not send a bounce. Do not generate a notification. The receiving server handles the failure without contacting your domain at all.

This is the mechanism that prevents your domain from causing backscatter on a global scale. If every domain used p=reject, backscatter generated from forged domains would largely disappear.

On your side, the configuration is simple: publish a DMARC record that includes p=reject. The harder part is ensuring your legitimate mail streams pass DMARC alignment so they are not accidentally discarded by receivers.

This is where DMARCFlow fits. DMARCFlow validates your DMARC record syntax to catch configuration errors, and it monitors aggregate reports so you can confirm that receiving servers are actually processing your p=reject policy and discarding forged messages silently. Without that monitoring, you have no way to know whether your policy is being honored or whether your domain is still appearing in backscatter flows on the receiving end. DMARCFlow is not a substitute for MTA configuration, but it is the practical layer that tells you whether your configuration is working as intended.

#### Method 3: Bounce Address Tag Validation (BATS)

BATS is a cryptographic scheme that tags sender addresses with a unique token when messages enter your server. When your server generates a bounce, it checks whether the bounce target was one of your original tagged addresses. If the bounce target was not tagged, it means the original sender address was forged, and the bounce is silently dropped.

The RFC 5230 specification describes this as the correct architectural solution to the backscatter problem. BATS is not widely deployed at scale, but it is available in several open-source MTAs and is the most complete solution for servers that generate a high volume of legitimate outbound mail.

The practical limitation: both the sending server and the receiving server need to support BATS for it to work across the full email flow. For your own outbound mail server, implementing BATS means your bounces never go to forged addresses, even if your server receives forged mail.

Server-Specific Configuration Examples

For Postfix, the most common MTA on Linux servers, the key changes are in main.cf. Beyond the smtpd_relay_restrictions listed above, add these to tighten acceptance criteria:

smtpd_delay_reject = yes
smtpd_client_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_rbl_client zen.spamhaus.org
    reject_rbl_client bl.spamcop.net
    reject_unknown_client_hostname

The RBL (Real-time Block List) checks prevent known spam sources from connecting in the first place. Rejecting at the connection stage is always cleaner than accepting and then trying to sort out the consequences.

For Exim, similar logic applies in the SMTP ACL:

deny    condition = ${if eq {$sender_address_domain}{yourdomain.com}}
        !verify = sender/{dkim_sign}
        message = Message does not pass DKIM verification

The exact syntax depends on your Exim version and configuration, but the principle is the same: check DKIM signatures during the SMTP transaction, before accepting the message.

How to Tell If Your Server Is Causing Backscatter

Three practical checks:

1. Check your server log for an unusual volume of sent bounce messages. A backscatter-generating server will have a queue full of NDRs waiting to be delivered.

2. Check whether your IP is listed on a DNS blocklist. Backscatter-generating servers almost always end up on SORBS, Spamhaus, or similar blocklists within days. Use a lookup tool like MxToolbox or intoDNS to check your IP against the major lists.

3. Listen to your users. If you are receiving complaints that your server is sending bounce messages to unrelated parties, the problem is almost certainly backscatter.

What Happens If You Are Already on a Blocklist

If your IP is already on a DNS blocklist due to backscatter, the remediation sequence is:

1. Fix the root cause first. Apply connection-stage rejection. If you fix the problem and your IP remains listed, blocklist operators will re-list you within hours.

2. Submit a delist request to each blocklist your IP appears on. Most operators provide an automated or email-based delist request form. Provide your IP, describe what you found, and confirm the fix you applied.

3. After delisting, monitor your logs and blocklist status for at least two weeks. Backscatter problems have a tendency to recur if the configuration drift is not addressed.

The servers most likely to be affected are those that accept mail for many recipients, such as mail gateways for organizations with large user bases. If your server accepts mail for thousands of users, a single forged sender campaign can generate thousands of backscatter NDRs in a short time window.

FAQ

Does backscatter damage my server reputation?

Yes. Backscatter-generating servers are quickly listed on DNS blocklists. Once listed, your legitimate outbound mail is refused by any server that queries those blocklists. Remediation requires both fixing the backscatter and requesting delisting from blocklist operators.

Can I filter backscatter after it happens?

You can filter incoming backscatter NDRs on the receiving side by recognizing bounce message patterns, but this does not fix the root cause. Your server will still be listed on blocklists and your IP reputation will still suffer. Fix the server generating backscatter, not the servers receiving it.

Does DMARC p=reject stop backscatter from my domain?

It stops your domain from being the source of backscatter. When you use p=reject, receiving servers discard messages from your domain that fail authentication rather than generating bounces. This prevents your domain from appearing as the source of backscatter across the internet.

How does greylisting help with backscatter?

Greylisting temporarily rejects messages from unknown sending servers with a 450 temporary failure code. Many spam sources do not retry. Legitimate servers do. This means greylisting naturally filters out a portion of spam before it reaches your server, which reduces the volume of messages that could generate backscatter if rejected.

What is the difference between a hard bounce and a backscatter NDR?

A hard bounce is a delivery failure notification sent to the legitimate sender when mail is addressed to a genuinely invalid recipient. A backscatter NDR is a bounce sent to a forged sender address. The technical mechanism is the same; the difference is whether the sender address in the original message was legitimate.

How quickly does backscatter get a server listed on DNS blocklists?

Most major blocklists process backscatter reports within hours of the first complaints arriving. Spamhaus and SORBS in particular act quickly on confirmed backscatter sources. A server generating backscatter at volume can appear on multiple blocklists within the same business day. This is why fixing the MTA configuration before submitting delist requests is essential.

The Short Version

Backscatter happens because your server accepted and then rejected a message with a forged sender address. The bounce went to an innocent third party.

The fix is to reject bad messages at the SMTP connection stage, before acceptance. Add SPF and DKIM checks to your MTA configuration so invalid messages are refused while the sending server is still connected. Use DMARC p=reject so receiving servers discard forged messages from your domain silently. Consider BATS for a cryptographic solution to bounce targeting.

If you are already on a blocklist, fix the problem first, then delist. The blocklists will re-list you within hours if you do not address the root cause.