Phantom Bounces and Borrowed Reputations: Auditing Mail You Never Sent

Somewhere in a UK inbox, a non-delivery report is sitting unread. It refers to a message you never wrote, sent to an address you have never contacted. The headers mention a mail server you do not run. The attachment may be a copy of spam. This is backscatter: the email equivalent of someone using your address as the return label on a pile of junk post.

It is not a breach. It is not necessarily a sign that your domain has been hacked. But it is a signal that someone is borrowing your identity at the envelope level, and that your filters, logs and sender policies deserve a closer look.

The return label problem

Most people think of the From: header as the sender. Mail servers often use a different field: the envelope sender, also called MAIL FROM or the return path. When a delivery fails, the receiving server sends a non-delivery report (NDR) to that envelope sender, not to the visible From: address.

Spammers know this. They forge the envelope sender so the bounce goes to an innocent third party. If they use your domain, your mailbox gets the fallout: failed delivery notices for messages you never sent, often with spam samples attached. At scale, this is backscatter.

The awkward part is that backscatter looks like email from your domain to some filters. Your domain may appear in NDR headers, authentication reports or blocklist chatter. You did not send the spam, but you may inherit the noise. That is the borrowed reputation in the headline: not a reputation you earned, but one you have to manage.

Why filters get twitchy

NDRs are difficult mail. They are often automated, sometimes unauthenticated, and frequently carry attachments or links. Legitimate bounces matter: they tell you a customer never got an invoice or a supplier missed a purchase order. But a flood of bounces for messages you never sent is a different beast.

Some filtering engines treat inbound NDR floods as a sign that a domain is noisy or suspicious. Others quarantine every bounce because so many are phishing lures. Neither approach is ideal. If you block all NDRs, you lose genuine delivery intelligence. If you accept all NDRs, you give phishing a free pass and let backscatter clutter the inbox.

The practical answer is context. A bounce should be judged against your outbound logs, not just its headers.

A quick audit for UK teams

Start with your inbound NDR traffic. Pull 30 days of messages that look like bounces and group them by envelope sender, reporting mail server and recipient domain. Look for patterns: DSNs for addresses you have never emailed, spikes after a spam run, or bounces that reference message IDs absent from your outbound logs.

Next, check the domains you actually own. Every domain and subdomain should have an SPF record that reflects reality. If a subdomain never sends mail, publish v=spf1 -all. If it does send, list only the services that are allowed. Do not use a soft fail as a permanent compromise unless you have a migration plan.

Then look at DMARC. Start with p=quarantine if you need a stepping stone, and move to p=reject when your legitimate senders are aligned. Set up aggregate reports (rua) and read them. They will show you which servers are sending as your domain and whether anyone is borrowing it.

For domains that do not receive mail, consider a null MX record: MX 0 . plus an SPF record of v=spf1 -all. This tells the world not to send mail there. Do not apply it to a domain that needs to receive bounces, replies or customer mail.

Finally, review your inbound bounce rules. A blanket quarantine on all NDRs is tempting, but it will catch legitimate failures. A blanket allow is worse. Build rules that correlate bounces with outbound message IDs, flag attachments and links, and route suspicious NDRs to a review queue rather than a user inbox.

Reject or quarantine?

The reject-versus-quarantine decision is often framed as a binary. It is not. For outbound authentication, p=reject is the stronger signal: it tells receiving servers to refuse mail that fails DMARC. That reduces the chance of forged mail landing, but it does not magically stop backscatter. Bounces may still arrive because the envelope sender was forged.

For inbound filtering, quarantine is useful for uncertain NDRs, but it needs an owner. Someone must review the queue, tune the rules and release genuine bounces. If nobody owns it, quarantine becomes a landfill with a reassuring name.

Reject at SMTP is cleaner for obvious forgeries, but it can be too blunt for NDRs. A legitimate bounce from a small supplier may fail authentication because the supplier's mail server is misconfigured. Rejecting it outright could hide a real delivery problem. Quarantine gives you a second look; reject gives you a clean inbox and a possible blind spot.

The human layer

Backscatter also creates a phishing opportunity. An attacker can send a fake NDR with a link to a delivery portal or an attachment that claims to be the failed message. UK users are used to parcel redelivery scams and invoice phishing, so a bounce-themed lure fits the pattern. Tell staff not to click links in unexpected NDRs and not to open attachments unless they can match the bounce to a message they actually sent.

Keep an eye on shared mailboxes too. A finance inbox that receives supplier invoices may also receive backscatter from forged supplier domains. If those bounces are quarantined silently, the team may miss a real failed invoice. If they are allowed through, the inbox becomes noisy. A dedicated bounce-review mailbox is often the least bad compromise.

Treat bounces as telemetry

Backscatter is annoying, but it is also free intelligence. It tells you which domains are being forged, which of your subdomains are exposed, and where your authentication setup is vague. Do not just delete the phantom bounces. Sample them, log them and use them to tighten SPF, DMARC and inbound rules.

Spamdex's rule of thumb: if a bounce cannot be tied to an outbound message ID, treat it as telemetry first and a delivery failure second. The bounce you never sent is not your fault. But the reputation it creates is yours to manage. A short audit now is cheaper than explaining to a client why your domain looks noisy next month.