Why am I getting bounce messages for emails I didn't send?

Backscatter is the flood of bounce messages you receive for email you never sent. It's alarming, because it looks like someone is using your account. Usually they aren't: they're using your address, which anyone can type into a sender field.

What is backscatter?

Microsoft defines backscatter as "non-delivery reports (also known as NDRs or bounce messages) that you receive for messages you didn't send." Spammers use real email addresses as the sender "to lend credibility to their messages," and when spam reaches a nonexistent recipient, the destination server "unwittingly sends the NDR to the forged sender."

M3AAWG, the industry anti-abuse group, described the same problem in its Abuse Desk Common Practices (published in 2007, when it was called MAAWG). It notes that because many spam messages are sent to invalid addresses, "a large number of bounce-backs can be generated." At worst, the volume can be classified as spam and put the bounce recipient's provider "at risk for blacklisting."

How it happens, step by step

1. A spammer sends a message with your address as the envelope sender (the Return-Path, also called MAIL FROM). Often your address is in the visible From line too.
2. The message goes to an address that doesn't exist, or to a mailbox that is full or blocked.
3. A server along the way accepts the message first and only later discovers it can't deliver it.
4. SMTP requires that server to report the failure. Per RFC 5321, section 6.1, once a server accepts a message it is "accepting responsibility for delivering or relaying" it, and if delivery later fails it "MUST formulate and mail a notification message."
5. That notification goes to the envelope sender, which is you.

Out-of-office replies, "mailbox moved" notices and challenge-response systems ("reply to confirm you're human") cause the same effect. RFC 3834, which covers automatic responses, warns that "the vast majority of email is unauthenticated, and return addresses are easily forged."

Why do servers still send backscatter?

The standards already discourage it. RFC 5321, section 6.2 says that when a message is rejected for hostile content, bounce messages "SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered." RFC 7208, section 2.5 calls notices sent to forged identities "nuisance rejection notices that are not actionable," and says "Operators are strongly advised to avoid such practices."

The root cause is the accept-then-bounce design. A server that checks recipients only after accepting the message has no choice but to send a bounce later. A server that checks during the SMTP conversation can reply with an error straight away. That error goes to whatever connected, which for spam is the spammer's own machine. No bounce message is ever created.

Microsoft is open that this can't be perfect at scale: it "makes every effort to identify and silently drop messages from dubious sources without generating an NDR," but "it's almost impossible" to send none at all.

Why backscatter matters even if you ignore it

It's tempting to delete the bounces and move on. A few things make that risky:

• Real bounces get lost. When hundreds of fake non-delivery reports arrive, the one that says your invoice to a customer didn't arrive is easy to miss.
• Mailbox quotas fill up. A large campaign can push a small mailbox toward its storage limit, and then genuine mail starts to fail.
• Fake bounces carry payloads. Some "undeliverable" messages are phishing in disguise, with a link to "view the returned message" or an attachment that isn't the original email.
• Staff lose trust in warnings. If people learn that bounces are always noise, they'll ignore the one that signals a real compromise.
• It hints at a reputation problem. Spammers forging your domain means receivers are seeing unauthenticated mail claiming to be you. Without an enforced DMARC policy, some of that mail may be delivered, and recipients may blame your brand.

Is it backscatter or a real problem?

Before you treat it as noise, rule out a compromised account. The two look similar in the inbox.

Open one bounce, find the attached original, and read its headers in the Email Header Analyzer. If the first Received hop is a server you've never used and the message fails SPF for your domain, it's forged. If it came from your own platform, reset the password, revoke sessions and check mailbox forwarding rules now. Our guide to someone sending email from your address walks through the full spoofed-or-hacked check.

How SPF and DMARC reduce backscatter

You can't fix other people's servers. You can give them the information they need to reject forged mail instead of bouncing it.

• SPF lists the servers allowed to send with your domain in the envelope sender. A receiver that checks SPF during the SMTP session can refuse mail from anywhere else. In the M3AAWG document, some members reported good results from not returning bounces when the SPF result was "fail" or "soft fail." Check your record with the SPF Checker, and see our SPF syntax examples if you need to fix it.
• DMARC (RFC 9989) ties SPF and DKIM to the visible From domain and lets you publish a policy. With p=reject, receivers that honor it can refuse forged messages during the SMTP session. The error then goes to the spammer's server rather than to you. The DMARC Checker shows your current policy; our guide on moving from p=none to p=reject covers doing it safely.

Neither stops it completely. Receivers that don't check, or that accept first and bounce later, will still send you bounces. Expect a reduction, not silence.

Recipient validation at the gateway: don't create backscatter yourself

The other half of the problem is your own mail system. If your domain accepts mail for any address and bounces unknown ones later, you are sending backscatter to other people. That can get your servers listed on blocklists that track it. The free Blacklist Checker shows whether your mail server's IP is on a public blocklist.

The fix is recipient validation during the SMTP session: reject RCPT TO for addresses that don't exist, with a 5xx reply, before the message is accepted. The M3AAWG document recommends the same idea: "check a message for deliverability on the way into the email system."

How this works depends on where your MX points:

• MX points straight to Microsoft 365. Microsoft's Directory-Based Edge Blocking rejects invalid recipients "at the service network perimeter" with 550 5.4.1 Recipient address rejected: Access denied. Microsoft notes DBEB needs the MX to point to Microsoft 365 to work in hybrid setups.
• MX points to a filtering gateway. The gateway now receives the internet's mail first, so it needs to know your valid recipients. If it accepts everything and your mail server later rejects unknown users, the bounce comes from the gateway. Ask your provider how it validates recipients.
• Your own server, such as cPanel/WHM or Exchange on-premises. Turn off catch-all ("default address") forwarding and make sure unknown recipients are rejected during the SMTP session rather than bounced. See our cPanel/WHM platform notes.

Also check your automatic replies. RFC 3834 says responders "MUST NOT generate any response" to a null return path, and "SHOULD NOT" respond to messages with an Auto-Submitted header whose value is anything other than no. Limit out-of-office replies to internal senders or known contacts where your platform allows it.

What to do when backscatter hits

Work through this checklist:

1. Confirm it's forged. Check Sent Items, sign-in logs and one original message's headers, as above.
2. Don't interact. Don't reply to the bounces, and don't open attachments or links in them. Some fake bounces are phishing.
3. Filter the noise. Create a rule that moves bounces whose attached original you didn't send to junk. In Microsoft 365, anti-spam policies include an option to mark NDR backscatter as spam, though Microsoft says it "isn't required in most environments."
4. Publish SPF and DMARC. Make sure SPF ends in -all or ~all and covers your real senders, and move DMARC towards p=reject.
5. Check you aren't the source. Confirm your own servers reject unknown recipients during the session and don't use catch-all addresses.
6. Wait it out. Backscatter campaigns usually stop when the spam run ends. If it continues for weeks, it's worth asking your provider to filter bounces more aggressively.

Next steps

• Run the SPF Checker and DMARC Checker on your domain and fix any gaps.
• Read our explainer on what email spoofing is to see why forged senders are so easy to create.
• Confirm how your current filter validates recipients, so your domain never generates backscatter itself.
• If you're choosing an MX-level filter, ask about recipient validation, and see how iBlockSpam works for where filtering sits in your mail flow.

Browse our other phishing and threat guides.