---
title: "Backscatter"
description: "Backscatter is spam-like bounce traffic generated when forged sender addresses cause other mail servers to send bounce messages to a spoofed victim."
url: "https://mailmum.io/glossary/backscatter/"
---

# Backscatter

Backscatter is the flood of automated replies &mdash;
[bounce messages](https://mailmum.io/glossary/bounce-message/), out-of-office notices, virus
warnings &mdash; that arrives at an address which was forged as the sender of
mail it never sent.

The victim is not the recipient of the spam. The victim is whoever's address the
spammer put in the envelope sender, because every bounce generated along the way
is delivered there.

## How does backscatter happen?

The mechanism is a mail server that accepts a message first and only afterwards
discovers it cannot deliver it:

1. A spammer sends a message to `nonexistent@example.net` with a forged envelope
   sender of `you@your-domain.example`.
2. The receiving server accepts the message during the SMTP session without
   checking whether the recipient exists.
3. Delivery fails afterwards, so the server generates a non-delivery report as
   it is required to do.
4. That report goes to the envelope sender &mdash; your address.

Repeat across millions of messages and a mailbox becomes unusable. The root
cause is step 2, and it has a name: accept-then-bounce.

## What does backscatter look like?

It looks like an ordinary bounce for a message you have no record of sending:

```txt
From: Mail Delivery System <MAILER-DAEMON@mx.example.net>
To: <you@your-domain.example>
Subject: Undelivered Mail Returned to Sender
Auto-Submitted: auto-replied

This is the mail system at host mx.example.net.

I'm sorry to have to inform you that your message could not be
delivered to one or more recipients.

<nonexistent@example.net>: host mx.example.net said:
    550 5.1.1 <nonexistent@example.net>: Recipient address rejected:
    User unknown in local recipient table

Reporting-MTA: dns; mx.example.net
Final-Recipient: rfc822; nonexistent@example.net
Action: failed
Status: 5.1.1
```

Three signs distinguish it from a genuine bounce:

* The quoted original message is one you never sent, often addressed to someone
  you have never heard of.
* The `Received:` headers of the returned message show it originating from an IP
  address that is not yours.
* Volume. Genuine bounces trickle; backscatter arrives in waves of hundreds or
  thousands within a short period.

## What should you do when you receive backscatter?

There is no way to stop other people's servers from bouncing to you, so the
response is filtering and, if the volume is sustained, damage control:

* **Verify the returned message's origin** before assuming a compromise. If the
  `Received:` chain does not include your servers, nothing of yours has been
  breached &mdash; your domain has merely been forged.
* **Publish SPF, and a DMARC policy.** These do not stop the bounces directly,
  but they let receiving servers reject the forged mail before it is accepted,
  which removes the bounce at the source over time.
* **Filter bounces against a list of messages you actually sent.** Bounce
  address tag validation (BATV) does this by signing the envelope sender, so
  bounces for messages you never sent can be discarded automatically.
* **Do not disable your `postmaster@` or `abuse@` mailboxes** to escape the
  flood. Losing those channels costs you more than the backscatter does; see
  [abuse desk](https://mailmum.io/glossary/abuse-desk/).

## How do you avoid emitting backscatter?

This matters more than receiving it, because a server that generates backscatter
is itself sending unsolicited mail to innocent third parties &mdash; and gets
listed for it.

* **Reject unknown recipients during the SMTP session,** at `RCPT TO`, with a
  `550`. If the message is never accepted, no bounce is ever generated: the
  rejection is the sending server's problem to report, not yours.
* **Never accept-then-bounce for spam or virus verdicts.** If a content scanner
  decides a message is spam after acceptance, discard or quarantine it. Bouncing
  it sends a notification to a sender who is almost certainly forged.
* **Suppress auto-replies to bulk mail.** Out-of-office responders should honour
  `Auto-Submitted:`, `Precedence: bulk` and `List-*` headers, and must never
  reply to a null envelope sender (`<>`).
* **Check your relay configuration.** A server accepting mail for domains it
  does not host will bounce all of it, to forged senders, at volume.

## Backscatter and blacklisting

Backscatterer.org and comparable services list IP addresses observed sending
bounces and auto-replies to addresses that never sent anything. Because the
traffic they list is generated by ordinary misconfiguration rather than by
malice, well-run servers do end up on it &mdash; usually because of an
accept-then-bounce configuration or an over-eager auto-responder.

The fix is always configuration rather than a delisting request: reject at
`RCPT TO`, stop bouncing spam verdicts, and the source of the listing
disappears. See [IP blacklisting](https://mailmum.io/glossary/ip-blacklisting/) for how listings
and delisting generally work.

## Related reading

* [Bounce message or report](https://mailmum.io/glossary/bounce-message/) &mdash; what a
  legitimate non-delivery report looks like, for comparison.
* [Manage Postfix mail server queues like a
  pro](https://mailmum.io/posts/manage-postfix-mail-server-queues/) &mdash; identifying and
  clearing a queue full of bounces to forged senders.
* [Monitoring your local Postfix blacklist with
  Munin](https://mailmum.io/posts/monitoring-your-local-postfix-blacklist-with-munin/) &mdash;
  spotting the traffic spike a backscatter wave produces.
