- › Researchers registered noreply.net and deleteduser.com and simply collected what arrived.
- › One domain has received roughly 400,000 messages over about 18 months, and 28,365 of them carried attachments.
- › Another logged 401,796 messages since December 2024, averaging around 700 a day.
- › The traffic includes injury reports from a city government and account setup mail from a school platform, sent by organizations that assumed nobody was on the other end.
- › The fix is to send from a domain you control, and to check whether any placeholder domain in your systems is currently registered to somebody else.
Somewhere in your stack is a form field that needed an email address and did not have one.
Maybe an account was deleted and the record still needed a value. Maybe an integration required a sender and nobody wanted replies. Maybe a developer in 2019 needed a placeholder to get past a validation rule and typed the first thing that looked obviously fake. The system has worked ever since. Nobody has thought about it in seven years.
Two researchers went and bought those domains.
They registered noreply.net and deleteduser.com, pointed a mail server at them, and waited. One of the domains has taken in roughly 400,000 messages over about 18 months of ownership. Of those, 28,365 arrived with attachments. Another has logged 401,796 messages since December 2024, running around 700 a day.
Among what showed up: injury reports from a city government. Account setup mail from a school platform. Confirmations, resets, internal replies, and the ordinary sediment of automated systems, all sent by organizations operating on the assumption that the address was a hole in the ground.
The Assumption Underneath
Nobody chose to leak this. That is what makes it worth writing about.
The mental model behind a no-reply address is that it is a write-only endpoint. Mail goes in and nothing comes out, so it functions as a way to satisfy a required field without creating an inbox somebody has to staff. Under that model the address is not a destination at all. It is a formatting requirement.
That model is correct only while the domain is under your control or under nobody’s.
The moment somebody registers it, every assumption inverts. The address stops being a hole in the ground and becomes a working mailbox belonging to a stranger, and nothing in your system notices, because from your side the mail sends successfully. There is no bounce. There is no error. Delivery is the failure.
That last part is what makes this category so durable. Almost every misconfiguration you deal with announces itself eventually. A cert expires, a service throws errors, a queue backs up. This one has no symptom. The healthier your mail infrastructure, the more reliably it delivers your data to someone else.
The Truck With No Plates
I spent time around freight before I did this work, and the closest thing I have seen is a trailer with no markings sitting in a yard.
A yard has a rhythm. Trailers arrive, get staged, get pulled. Somebody drops one with nothing on it, no carrier, no numbers, nothing. It does not belong to a scheduled move so it does not appear on a manifest, and because it is not on a manifest, no one is responsible for it. It sits. People walk past it for months. It becomes furniture.
Then one day it is gone, and the interesting question is not who took it. The interesting question is how long it would have been before anyone noticed, and the answer is that nobody was ever going to, because there was no system that expected it to be there.
An unowned placeholder domain is that trailer. It is not on anyone’s asset inventory, because inventories track things you bought. It generates no cost, no alert, and no ticket. The only way it surfaces is if somebody goes looking specifically for it, and nobody is assigned to look.
What Comes Out of This That Actually Matters
Run the categories rather than the volume, because 400,000 messages is a number and the content is the risk.
Password resets and account setup mail. A reset link sent to an address an attacker controls is an account takeover with no exploit involved. If any system in your estate sends credential mail to a placeholder, that is not a data leak, it is a live path in.
Attachments. 28,365 of them on one domain. Automated systems attach the things automated systems attach: reports, invoices, exports, statements. Whatever your systems mail out on a schedule, assume the full file arrived intact.
Internal reply chains. People reply to no-reply addresses constantly, usually with the whole thread quoted underneath. The original message was automated and boring. The reply frequently is not.
Metadata even when the body is dull. A pizza order confirmation tells somebody your employee’s name, their delivery address, and roughly when they are at home. Volume of that across an organization is a targeting package, which matters more now that ransomware crews are researching individual managers rather than blasting a company.
What to Do About It
This is an afternoon of work, and the first two steps are the ones that matter.
Find every non-existent domain your systems send to or from
Search your mail logs and your application configuration for sender addresses and default values. You are looking for anything at a domain your organization does not own: noreply.net, deleteduser.com, example.com, test.com, localhost.com, plus whatever a developer invented on a Tuesday. Grep your codebase for hardcoded addresses while you are at it.
Check whether those domains are currently registered
A quick lookup tells you whether each one is unowned or belongs to somebody. If it is registered, treat everything you have sent there as delivered to a third party and work out what that included. If it is unowned, you got lucky and you still have the problem.
Send from a subdomain you control
The correct pattern is a domain you own and can never lose: noreply@mail.yourcompany.com or a dedicated subdomain with no inbox behind it. You keep the write-only behavior and you keep the destination. Configure it to discard rather than bounce if you want silence.
Make the placeholder unroutable rather than fake-but-real
Where you need a value that can never receive mail, the reserved options exist for exactly this. Anything ending in .invalid can never be registered by anyone, which is the actual guarantee you were assuming you had.
Put domain registration on the offboarding checklist
Most of these got created because somebody needed a domain for a project, and the risk arrives when it lapses. A domain your organization used and let expire is worse than one you never had, because the mail is already flowing and the name records are already pointed at it. Renewal is cheap next to the alternative.
The Wider Version of This
I keep coming back to a pattern that runs through most of what we have covered this month. The Snowflake breaches that touched 100 million people ran on valid credentials against tenants without multi-factor authentication. The attackers who took control of water utility equipment set passwords on controllers that had none, rather than using the buffer overflow available to them. Three separate intrusion campaigns in one day all ended with the attacker installing legitimate remote management software.
None of that required breaking anything. Each one turned on an assumption that had gone unexamined long enough to feel like a fact.
A no-reply address is the smallest possible version of that, and probably the cheapest to fix. It costs a registrar fee and a configuration change, and the alternative is a stranger holding eighteen months of whatever your systems have been mailing into the dark.
Go find out what your applications are sending from. If the answer is a domain you do not own, look up who does.
Want a clear picture of the assets nobody in your organization is assigned to watch? Take our free Human Attack Surface Score assessment, or contact us for a full risk assessment.
Operating on the philosophy that 'you can't build a secure system if you don't know how to break it,' Chris leads our engineering division. A top 1% National Cyber League competitor, he hardens our digital infrastructure against the very exploits he has mastered.
View Author Page →
