The short version: If your inbox is suddenly full of bounce notices for emails you never sent, you almost certainly haven’t been hacked. A spammer somewhere has picked your address off a list and used it as the “return address” on a batch of spam. The failed deliveries — the ones the receiving mail servers couldn’t hand to a real person — come back to you, because your address is what’s stamped on the envelope. The fix isn’t at your end. It’s a small setting on the mail server that tells it to quarantine the incoming spam instead of formally rejecting it.
Read the full technical breakdown ↓
What’s actually happening
Email has a quirk that’s older than most of the people using it. When a message is sent, the return address on the envelope — the “if you can’t deliver this, send it back here” line — is set by whoever is sending. Nothing on the internet checks that the person listed as the sender actually agreed to it. A spammer can grab any address they like off a leaked list and put it on their outbound batches, and the receiving world has no way to tell that the real owner of that address knows nothing about it.
So the spam goes out with your address on the envelope. Most of it gets accepted by whatever inbox it lands in, filtered to a junk folder, and quietly ignored. But some of it gets rejected — the recipient doesn’t exist, the mailbox is full, the receiving server is grumpy that day. And when a message gets rejected, the rejecting server does the polite thing: it sends a bounce notice back to the return address on the envelope. To you.
Multiply that by a spammer sending a hundred thousand messages, and a small percentage of bounces is still a lot of inbox noise on your end.
Why your first instinct doesn’t help
The instinct, once this starts happening, is to look at your own mailbox and try to lock it down harder. Change the password, turn on two-factor, tighten filters. Those aren’t bad ideas in general, but they don’t touch this problem, because the spam isn’t coming from your mailbox. Your mailbox has nothing to do with it. Someone across the internet is putting your name on their outbound, and there’s no button on your side of the fence that can stop them.
What you can stop is the echo — the bounces coming home.
Why the fix lives on the mail server
Here’s the piece that surprises people. Most cPanel-style mail servers have two ways to deal with a message the spam-scoring layer has already decided is junk:
- Reject it. The receiving server tells the sending server, formally, “nope, not accepting this”, and hands back an SMTP-level failure. That failure becomes a bounce notice. The bounce goes to the return address on the envelope. When the envelope’s return address is a spoofed victim, the bounce lands on the victim.
- Quarantine it. The receiving server accepts the message on the wire (so no bounce is ever generated), then routes it away from the inbox — into a spam folder, or straight into the bit-bucket, or held for admin review. The wire-level transaction ends cleanly. No bounce. Nothing comes back to a victim’s inbox.
For a normal mailbox, either setting is a defensible choice. The bounce-back approach has the marginal upside of giving a legitimate sender who accidentally trips a spam filter a chance to see the rejection. The quarantine approach avoids the reflection problem entirely.
When a mailbox becomes a target for backscatter — when spammers have decided to reuse your address on their outbound in volume — the quarantine setting is the one that stops the pain. Switching it silences the flood on the mailbox’s own end. The spammer keeps sending; the world keeps rejecting some of it; but none of the rejections turn into email that touches your inbox.
What to do if this is happening to you
Three things, in order:
- Sanity-check that your account really hasn’t been hacked. Look at the actual bounce notices. If every rejected message is going to strangers, and the message body is spam that has nothing to do with anything you’d write, and there are no successful outbound copies in your sent folder — that’s backscatter. If the bounces are going to your contacts with content that reads like phishing, that’s a different problem and you want to change your password immediately. The difference matters.
- Ask whoever manages your mail server to switch spam handling from reject to quarantine. On a cPanel host, this is one setting per mailbox, applied in minutes. Once it’s flipped, the bounces stop within an hour or two as any in-flight backscatter clears.
- Wait it out. Once your address stops being a productive return path for the spammer, they eventually rotate off it and move on to another victim. That can take days or weeks. There isn’t a way to make it happen faster, but there also isn’t anything you need to actively do while it plays out.
Sometimes the internet’s problems land in your inbox for no other reason than a stranger picked your name off a list. There isn’t much you can do to stop the picking. There’s a lot you can do to stop the echo.
The technical breakdown
The rest of this post is for admins and mail-server operators who want the mechanics. If you came for the plain-English summary, you’re done — thanks for reading.
The forgery
The address that receives a bounce is the envelope sender (SMTP MAIL FROM), not the From: header. On a well-configured server the two usually match, but nothing in SMTP requires it. A spammer’s outbound MTA sets MAIL FROM: < on the wire and puts whatever From: they like in the message header. Downstream receiving servers see the envelope as authoritative for delivery-status routing.
Backscatter is what happens when a receiving MTA generates a bounce (DSN — Delivery Status Notification) in response to a failed delivery and sends that DSN to the envelope MAIL FROM. If the envelope was forged, the DSN goes to the forgery victim.
Why SPF doesn’t fully save you
SPF (v=spf1 ...) authorizes a set of sending IPs for a domain. When a receiving MTA sees MAIL FROM: < from an IP that isn’t on example.com’s SPF record, it can refuse the message. In practice, receiving MTAs vary widely on how strictly they enforce SPF, and many hit spam-scoring logic first and reject on the score rather than on the SPF result. When the reject happens after the wire has been accepted (post-DATA), some MTAs still generate a bounce — and that bounce goes back to the (forged) envelope sender.
There’s also the not-uncommon case where the spammer is forging a domain whose SPF is intentionally loose (~all softfail) or missing entirely. There’s nothing SPF can do on those.
Tightening SPF on your own domain reduces the volume of successful incoming backscatter, but only for MTAs that enforce SPF pre-DATA. It doesn’t stop the spammer from continuing to send with your address on the envelope.
The mail-server-side fix on a cPanel host
The setting to flip is per-mailbox, under the SpamAssassin-family plumbing that cPanel exposes as “Spam Filters”. There are two related knobs:
- Auto-Delete Spam — when a message crosses the spam-score threshold, delete it silently at the wire level (accept + drop). This is the quarantine-equivalent behavior from an external-observer standpoint: no bounce is generated.
- Reject Mail At Or Above SpamAssassin Score — when a message crosses the threshold, refuse the message at SMTP. This generates a bounce. Backscatter victim gets the bounce.
The straightforward remediation for an active backscatter case is: turn Auto-Delete Spam ON, and turn the reject-at-threshold behavior off. In cPanel UAPI terms:
uapi --user=<cpanel-user> Email disable_spam_autodelete email=<local-part>@<domain>…where the “disable” verb is a bit of a naming trap: it disables the reject-and-bounce branch and enables the accept-and-drop branch. Confirm the current state with:
uapi --user=<cpanel-user> Email get_pop_setting email=<local-part>@<domain> setting=spam_autodeleteFor account-wide changes, the same operation is available under Email/set_spam_settings in newer cPanel versions. Match the specific host’s API surface.
Confirming this isn’t a real compromise
Before assuming backscatter, rule out the case where the mailbox itself is being used to send. On the mail server:
# Any authenticated outbound from this mailbox in the last 24h?
grep 'dovecot_login:<mailbox>' /var/log/exim_mainlog | tail -50If the answer is none, the account isn’t sending anything — the flood is inbound bounces on a forged envelope. If the answer is lots, from unfamiliar IPs, going to strangers — that’s a compromised mailbox and a completely different response (rotate the password, kick active sessions, audit the sent folder, notify the account owner).
The distinction takes one grep. Do it before flipping any spam-handling settings, so the diagnosis is on record.
What the fix does and doesn’t do
- Does: stop new backscatter from landing in the victim mailbox. Effect is near-immediate on the server side; the mailbox-visible reduction takes an hour or two as in-flight bounces from remote MTAs work through their retry cycles.
- Doesn’t: stop the spammer from continuing to forge the address. That’s a decision made across the internet on the spammer’s own MTA; nothing on the receiving end can influence it.
- Doesn’t: protect the reputation of the forged domain. If the spam is landing widely enough, receiving MTAs will start reputation-tagging the domain name, which affects legitimate outbound from that domain. This is a downstream problem worth watching for — check the domain’s placement in the major reputation-scoring feeds a week or two after the backscatter clears.
Lessons filed away
- Bounce-back spam handling is a symmetric attacker gift. Reject-at-threshold looks polite — it tells legitimate senders when their mail was refused. It also weaponizes the mail server into a backscatter reflector the moment a spammer decides to forge one of its addresses. On a shared mail host, the default choice worth revisiting is whether any mailbox ships with reject-at-threshold on, given the asymmetry.
- SPF is necessary but not sufficient. It reduces backscatter volume against your own domain but does nothing when the forgery uses a different domain’s envelope. There’s no configuration on the victim side that fully closes the loop.
- The diagnosis takes one grep. “Is this account actually sending anything?” is a five-second question against the mail log and separates the two very different remediation paths cleanly. It’s the first check before any other work.
- Watch for domain reputation drift after the fact. The mailbox owner is off the hook fast; the domain’s outbound-reputation score takes longer to recover if the spam volume was large. A quick check against the common reputation feeds after the backscatter clears will catch any drift before it starts blocking legitimate outbound.
← Back to the plain-English summary
Add comment