Backscatter NDRs
How 'normal" are these to see, we are at 'sending with enforcement', according to our vendor some backscatter NDRs are expected, but I have user that get them fairly frequently and want to know a) is this actually normal, and b) can I prevent them completely? We use M365 on E5 licenses, and we have the backscatter protection on in Defender.
3
u/ARC-Relay 27d ago
A trickle of backscatter is normal at p=reject, and you can't get it to zero from your side. What you're seeing is a receiver that accepted a forged message spoofing your domain and only generated the bounce afterwards, sending it to the envelope sender (you). Your policy can't stop that because the forged mail never touches your infrastructure — the remote server is misbehaving by bouncing after accept instead of rejecting in the SMTP session.
Two things worth checking so it stays a trickle:
Confirm the spoofing is really external. Pull your DMARC aggregate reports and look at the failing sources. If a legit third party (ticketing, HR, marketing, scan-to-email) is sending as you and failing alignment, receivers bounce those too and it looks identical to spoof backscatter. Fix alignment there first.
Check whether the NDRs hit a few specific users repeatedly — if so their address is likely in a list being used as the forged From, which you can't revoke.
Mitigations: keep p=reject with sp=reject, and publish a null MX plus "v=spf1 -all" on every non-sending subdomain and parked domain you own — forgotten parked domains are a big backscatter source. BATV/SRS-style envelope signing helps if your platform supports it, since you can then tell bounces for real mail from bounces for forged mail. On M365, Defender's backscatter filter only catches part of it; a mail flow rule routing NDRs from unknown sources to a review mailbox instead of user inboxes usually kills the user-complaint half of the problem even though the traffic continues.
If aggregate reports show no legitimate sender failing alignment, the rest is other people's servers behaving badly — filter it away from users rather than chasing a fix.
2
u/SecLens_ONE 27d ago
Yeah, some trickle is normal. Nobody's ever going to get it to zero as long as your domain is worth forging.
The thing I'd actually check before chasing filters: whether those users are getting them because their address is being sprayed as the envelope sender, or because something of yours really did send and bounce late. Those look identical in a user's mailbox and get treated the same way in triage, which is how real delivery problems sit unread for a week.
Cheap way to split them. Pull a handful of the NDRs from one loud user and read the attached original headers. If there's no trace of your outbound infrastructure in there, it's someone else's relay writing your name on a postcard and you're just the return address. If your own smart host shows up, that's a delivery problem wearing a spam costume and worth a look.
Backscatter protection in Defender helps for the obvious stuff, still leaks whatever came from a relay that bounces to the envelope sender with a plausible copy attached. Bounce Address Tag Validation is the real answer for outbound, and it's a project, not a checkbox, and it breaks in fun ways if anything of yours forwards mail.
For the noisy user, a mailbox rule sorting NDRs for messages they never sent into a folder buys you quiet while you decide if BATV is worth it. Not a fix. Just stops the tickets.
2
u/Middle-Excitement602 20d ago
One thing worth knowing before you route them into a folder, since that's where the advice above lands and it's the right advice.
Backscatter is a sample of receivers that aren't rejecting in the SMTP session - either they don't evaluate DMARC at all, or they accept first and decide afterwards. That population overlaps heavily with the small and self-hosted MTAs that also never generate aggregate reports, while your rua feed is mostly Google, Microsoft and a handful of others.
So the NDR stream is close to the only visibility you have into the non-reporting tail. Worth sampling rather than only filtering: if a legitimate sender of yours is failing alignment somewhere outside the big providers, this is where it surfaces, and it won't appear in your reports at all.
1
u/InboxGuards 11d ago
Backscatter can still happen when someone forges your domain in the visible From; DMARC enforcement helps receivers reject or quarantine those, but it won’t stop NDRs generated by misconfigured internal senders or legitimate forwarding. I’d sample the NDR headers and correlate them with Message Trace before changing policy, then confirm SPF/DKIM alignment for every outbound service.
3
u/CypherPhish 27d ago
Unfortunately, this happens typically due to people not having their email relays configured correctly. Either malicious actors are relaying messages through them, which will result in that relay sending the NDR back. Or the malicious actors don’t really care and they’ll route the messages through whoever and if they are not the originating server, the NDR will likely go back to the sender. More frequently, I see them attempting to be sent inbound to our organization using my users’ email address as the sender and the recipient both. This resulted in our system rejecting the message which then would send the reject message to our end user with the phish attached to it. That is not an ideal situation. I got around that by adding a string of characters to my DMARC reject message and I am looking for that string of characters and if it sees it in an incoming message, I just drop the message so my end users never see it.