What happened
WIRED reported on August 8, 2026 that security researchers Cory Solovewicz and Mike Sheward bought domains such as noreply.net, noreply.us, and deleteduser.com and configured them to receive mail. Instead of only catching spam, those domains began receiving automated messages from companies and organizations that apparently treated placeholder or deleted-user addresses as if they could not belong to anyone.
According to WIRED, one Solovewicz domain had registered 401,796 messages since December 2024. The examples described by the outlet included personal orders, account setup messages, repair-related information, injury reports, and test-platform credentials. The important point is not that a new exploit chain was discovered. It is that ordinary business systems were still sending real information to addresses that were assumed to be harmless.
Why it matters
This is a reminder that email addresses are security boundaries only when ownership and routing are verified. A string that looks like a sink, such as a no-reply or deleted-user placeholder, can still be a deliverable address if the domain is registered and configured to accept mail.
OWASP documents a related class of risk around expired domains and accounts: if a domain or mailbox changes hands, incoming mail can expose personal information, password reset messages, and clues about services connected to former users. That context maps directly to the WIRED report. The failure mode is not limited to one brand name or one mail provider; it can appear wherever applications retain stale addresses, rewrite deleted accounts into generic placeholders, or send transactional messages before validating the recipient.
Email authentication does not fully solve this problem. M3AAWG explains that SPF, DKIM, and DMARC help receiving systems evaluate whether a message is authorized by a sending domain, but they do not prove that the destination address is safe or intended. In other words, a perfectly authenticated email can still be delivered to the wrong domain.
What teams should check
Developers and security teams should audit automated mail flows that handle account deletion, test users, deactivated employees, CRM placeholders, and no-reply conventions. Systems should not transform real users into addresses under public domains unless those domains are controlled and monitored by the organization.
Password-reset and account-recovery flows need special scrutiny. OWASP recommends reset tokens that are random, sufficiently long, stored securely, single use, and time-limited. Those controls reduce damage if an email is exposed, but they do not remove the need to verify that recovery mail is going to the correct recipient.
For addresses that must be obviously non-routable in examples, tests, or internal placeholders, teams should use reserved naming conventions rather than real purchasable domains. RFC 2606 reserves names including .invalid, .test, .example, and .localhost for cases where conflict with real DNS should be avoided.
The practical takeaway
The story is less about no-reply as a style of communication and more about data hygiene. If an application can send invoices, credentials, case notes, or recovery messages to an address nobody owns internally, the system is making a live privacy and security decision based on an unchecked assumption.
The next useful step is boring but valuable: inventory mail templates, bounce handling, deletion workflows, and third-party SaaS integrations. Find every place the system substitutes, stores, or reuses a placeholder address, then make sure each destination is either verified, internally owned, or intentionally non-deliverable.