The Address Said No Reply. The Domain Belonged to Someone Else.
Organisations have sent hundreds of thousands of messages, credentials and attachments to addresses at domains they did not control because developers treated names such as noreply.net and deleteduser.com as harmless placeholders.
Those domains were not fictional. Security researchers registered them and began receiving the traffic. The result is a slow, permissionless data leak created by application defaults, account-deletion routines and automated workflows rather than by an intrusion.
A placeholder can still have an owner
Researcher Cory Solovewicz acquired noreply.us in 2020 and noreply.net in 2024. According to WIRED’s reporting, one of the domains received 401,796 messages from December 2024 onward, averaging about 700 a day.
The stream included 28,365 attachments and messages from more than 14,000 sender addresses across 6,200 root domains. The content ranged from routine notifications to city injury reports, school account setup messages, repair orders and test credentials.
Mike Sheward found the same design error from a different direction. He registered deleteduser.com for about $15. Three organisations sent mail to the domain within the first hour, and at least 100 did so as the experiment continued.
Deletion did not remove the identity
Some systems replace a deleted account’s address with a readable stub such as user@deleteduser.com. Other products use an external-looking no-reply address when a field cannot be empty. If downstream systems keep that address subscribed, mail leaves the organisation and reaches whoever controls the domain.
The failure crosses several trust boundaries at once. A database cleanup decision becomes an outbound-email destination. An account considered deleted remains part of notification groups. A human-readable placeholder is interpreted by mail infrastructure as a real routable address.
No malware is required, and ordinary security monitoring may see a successful delivery rather than a breach. The leakage can persist quietly for years because every individual message looks like normal automated mail.
Use domains that cannot be delivered
The Internet standards reserve the top-level domain .invalid for names that should never resolve. A placeholder such as deleted-user@account.invalid communicates intent to people and software without delegating trust to an external registrant.
An organisation can also use a domain it owns, but ownership must be monitored and maintained. The safest design is to remove a deleted identity from subscriptions and workflows completely rather than depend on a substitute address.
What defenders should audit
- Search outbound mail logs. Identify deliveries to no-reply, deleted-user, example and test-style domains outside the organisation.
- Inventory hard-coded addresses. Review application defaults, templates, test fixtures, scripts and identity-deletion routines.
- Validate every domain. Confirm that the organisation owns or intentionally trusts every domain used in an email field.
- Remove identities fully. Deprovision group membership, notification rules, workflow assignments and forwarding when an account is deleted.
- Use reserved names. Prefer
.invalidwhen a non-deliverable syntactic placeholder is unavoidable. - Alert on delivery anomalies. A sudden new destination domain or successful mail to a deletion stub should be investigated.
The BlackTree view
This research exposes a category of data leak that sits between software design and domain governance. The application did exactly what it was told, the mail server delivered successfully and no attacker bypassed a control. The trust mistake happened when a plausible-looking string was treated as nowhere.
Defenders should consider every registrable domain a potential external party, even when its name says no reply, deleted or test. Human meaning does not change DNS ownership.
Sources
- WIRED, He Bought the Noreply.net Domain and Ended Up Receiving Secrets, published 13 August 2026. The Spanish page provides no publication time.
- WIRED Türkiye, Sensitive information keeps going to no-reply addresses, published 13 August 2026 at 12:14 local publication time.
- IETF RFC 6761, section 6.4, invalid names, published February 2013.
