Security researcher Cory Solovewicz owns noreply.net and noreply.us, two domains that companies assume nobody actually reads. Since December 2024, one of them has taken in 401,796 messages, an average of 699.99 per day by his own count. None of it is spam. It is automated mail from real company systems, carrying real people's data. This analysis draws on reporting from Arstechnica.

Emails have arrived from more than 14,000 distinct "from" addresses across 6,200 root domains, with 28,365 of the noreply.net messages carrying attachments.

Solovewicz bought noreply.us in 2020 to use as a catch-all address, meaning it accepts mail sent to any @ address on that domain. He wanted a privacy tool. He got what he calls an accidental honeypot, because other organizations' platforms were already firing messages at @noreply.us addresses that had never been registered by anyone.

What lands in that inbox is the kind of material your compliance team would classify as sensitive. Injury reports from a city government. Account setup emails from a school platform. Service orders for customer repairs. Test platform credentials, sent in volume. The older noreply.us domain has collected 37,255 messages across 2,345 days, and in the month before his conference talk the two domains together took in more than 11,000.

The pattern extends past those two names. Mike Sheward, head of security at EV charging company Xeal, spent around $15 on deleteduser.com earlier this year. Three different organizations emailed it within the first hour. He has since received messages from at least 100 organizations, including cybersecurity firms and Microsoft partner companies, covering hotel bookings with full names, leave approval requests, and Zoom invitations from a UK government agency.

The mechanism is the same in every case. A system is configured to send from or to a placeholder address on a domain someone else can buy. If your applications use a noreply address on a domain your company does not control, that mail is going to a stranger's server.

Why Companies Email Secrets to Catch-All Noreply Addresses

The root cause sits in application code, not in mail servers. A developer needs a "from" address for automated notifications, types something that looks obviously fake, and ships it. The address never gets validated against a domain the company actually controls, so whoever registers that domain later receives everything the application sends to it.

Two failure patterns produce most of the traffic. The first is the wrong-TLD problem: an engineer intends an unroutable placeholder but picks a real, registrable top-level domain instead of one of the reserved namespaces set aside for exactly this purpose, such as .invalid, which is guaranteed never to resolve. The second is account lifecycle handling, where a system marks a user as removed by overwriting the email field with a placeholder value instead of deleting the record and the notification subscriptions attached to it.

Mike Sheward, head of security at EV charging company Xeal, tested the second pattern directly. He spent around $15 on deleteduser.com, a string that reads like a null value in a database. "Within the first hour, there were three different organizations that had emailed stuff to @deleteduser.com," Sheward told WIRED. Companies, he notes, appear to be changing email addresses rather than removing accounts, which means every workflow tied to that former employee or customer keeps firing.

What arrives is ordinary business traffic that happens to contain other people's data. Sheward has received mail from at least 100 different organizations across the domains he owns, including approval requests for employees' vacations and leaves of absence, hotel bookings carrying full names, Viagra orders, and Zoom meeting invitations from a UK government agency. Among the senders are cybersecurity companies and Microsoft partner organizations, which tells you the misconfiguration is not limited to firms without security staff.

Solovewicz's inbound traffic follows the same shape. He has received injury reports from a city government, service orders for people needing repairs, account setup emails from a school platform, pizza order confirmations, and what he describes as a steady supply of test platform credentials. Those credential emails matter most from an access standpoint, because staging and QA environments frequently mirror production data and often sit behind weaker authentication than the live system.

Three conditions keep this running. There is no ownership validation, since nothing in SMTP requires a sender to prove it controls the recipient domain. There is no monitoring, because a noreply address is designed as one-way traffic, so nobody reads the mailbox, nobody watches bounce rates, and delivery to an unexpected third party looks identical to delivery to a dead address. And there is an assumption of safety, where noreply reads as a reserved keyword to a developer even though it carries no protected status in DNS.

The traffic is entirely machine-generated. Solovewicz says the messages come from automated company systems rather than people, which is why the volume stays consistent for years and why nobody internally notices. An automated sender does not complain about a missing reply.

This is also a well-documented failure. Roughly 20 years ago, security journalist Brian Krebs, then at the Washington Post, reported that companies were sending millions of messages to @donotreply.com. The pattern survived two decades of email infrastructure changes because it lives in application configuration, where nobody audits it. If your development team ever needed a throwaway sender address, that string is still in your codebase.

Sensitive Data Flowing to an Attacker-Controlled Mailbox

Test platform credentials and account setup emails from a school platform were among the messages landing in Solovewicz's inbox. Those are not marketing blasts. An account setup email typically carries a live activation link or a temporary password, and whoever opens it first controls the account.

That changes the math on what a misdirected mailbox costs you. If your application sends provisioning mail to a placeholder domain someone else owns, every affected account is claimable by that owner with no exploitation involved. There is no vulnerability to patch, no malware to detect, and no failed login to alert on, because from your system's perspective the message was delivered successfully.

The personal data flowing through these mailboxes covers categories regulators treat seriously. Solovewicz has received injury reports from a city government. Mike Sheward, head of security at EV charging company Xeal, has received orders for Viagra, hotel bookings with people's full names, and requests to approve employees' leaves of absence. Health-adjacent purchase records and named travel itineraries sitting in a third party's mailbox meet most working definitions of a personal data disclosure to an unauthorized recipient, which is the trigger for breach notification duties under GDPR and state laws such as the CCPA.

Notification obligations scale with the volume you cannot account for. If your billing platform has been emailing a dead domain since deployment, your exposure is not one incident but every message sent since the code shipped, and you likely have no log retention going back that far to enumerate the recipients. Solovewicz has held noreply.us for 2,345 days, and whoever registered it before him received the same traffic.

Operational mail leaks structure as much as content. Leave-approval requests expose your reporting lines and staff absences. Service orders and repair tickets expose customer addresses and equipment. Sheward has received Zoom meeting invitations from a UK government agency, which reveal internal meeting cadence and attendee lists. Anyone collecting this builds an accurate picture of your org chart, your vendors, and your internal naming conventions, which is the reconnaissance work that makes a later business email compromise attempt convincing.

Your suppliers create the same exposure on your behalf. Sheward notes that the senders include a number of cybersecurity companies and several Microsoft partner firms. When a partner's ticketing or provisioning system misroutes mail about your environment, the data leaves your control through a channel you do not monitor and cannot audit.

The economics favor the collector. Sheward paid around $15 for deleteduser.com, and within the first hour three separate organizations had emailed material to it. He has since received unintended mail from at least 100 different organizations across the domains he owns. Anyone willing to spend a registration fee and wait can accumulate credentials and customer records passively, and the companies supplying them never see an incident.

Two details make this harder to scope after the fact. The messages are generated by automated systems, so no employee ever notices sending them, and the volume means no single leak stands out. If your applications use a placeholder sender or recipient domain you never registered, treat the exposure as ongoing and undated rather than as a discrete event with a start and end.

Immediate Actions: Audit Email Configurations and Reclaim the Domain

Start with an inventory of every "from" address your applications actually send. Search your code repositories, container images, environment files, and email template libraries for sender strings, then resolve each domain and confirm your organization owns the registration. A simple pass across a monorepo with grep -rEi "noreply|no-reply|donotreply|deleteduser" --include="*.{yml,yaml,env,json,py,js,rb,tf}" usually surfaces more distinct sender addresses than the mail team knows exist.

Do not stop at noreply. Mike Sheward's purchase of deleteduser.com for roughly $15 drew mail from three separate organizations inside the first hour, because systems that anonymize an account often rewrite the user's address to a placeholder and keep sending to it. Search for that pattern too, along with any anonymization or "scrubbed user" logic in your identity and HR platforms.

Once you have the list, sort it into three buckets and work them in order.

• Today: every sender domain your company does not own goes on a block list at the outbound mail gateway, so queued messages stop leaving before you have finished fixing the code.
• This week: check WHOIS on each unowned domain. If it is available, register it. If it is already taken, treat it as a third party holding your mail and route around it.
• Sprint planning: replace hardcoded senders with a single validated configuration value, and add a CI check that fails the build when a sender domain is not on your approved list.

Credential rotation belongs in the same-day bucket. Any test platform credential, activation link, API key, or password reset token that your systems mailed to a domain you do not control should be treated as issued to a stranger. Revoke and reissue rather than waiting for evidence of use, because the recipient never has to authenticate against your systems to hold the secret. In environments Capstone manages, Adlumin ITDR watches authentication behavior across managed environments, which gives you a way to spot use of a credential that left through this channel even when nothing in your application logs looks unusual.

Tighten DNS on the domains you do own. Publish SPF, sign with DKIM, and move DMARC from p=none to p=reject once your aggregate reports are clean. That will not stop mail your own systems intentionally send to an outside placeholder, but it stops someone else sending mail that appears to come from your notification addresses, and the DMARC aggregate reports themselves are a useful inventory of every service sending on your behalf.

Put monitoring on the mailboxes you keep. Alert on volume changes, on senders your platform has never seen before, and on outbound messages to any domain outside your approved sender list. Bounce logs are equally revealing, since delivery failures to a placeholder domain tell you the address exists in production code.

Finally, handle the disclosure side. If your review shows personal data went to an address outside your control, document what categories of data were in those message bodies and attachments, check the notification thresholds in your applicable privacy regulations, and tell affected customers what was sent and when. Solovewicz has been contacting affected organizations directly, so an inbound notice from a domain owner is a real possibility and your team should know who fields it.

Long-Term: Validate Email Addresses and Enforce Domain Governance

The fix that prevents recurrence is a single authoritative registry of every domain your organization is allowed to send mail from, enforced automatically at build time. Once that list exists, add a check to your CI pipeline that fails any build containing a sender address whose domain is not on it. That turns a one-time cleanup into a control that holds after the engineers who did the cleanup move on.

Domain ownership verification belongs in the same check. A string that parses as a valid email address tells you nothing about who controls the mailbox behind it, so the validation step should resolve the domain and compare it against your registrar records, not just against a regular expression. Solovewicz received messages from 6,200 root domains, which means thousands of separate engineering teams shipped a sender address nobody ever traced back to a registration.

Make hardcoded email addresses a named item in your code review standard. Reviewers catch what they are told to look for, and "sender address is defined in configuration and points to a registry-approved domain" is a checkable line item in a way that "be careful with email" is not. Pair it with a static analysis rule so the reviewer is confirming a machine finding rather than hunting for one.

Then look at what your automated mail actually contains. Notification systems that include a temporary password, an activation link, an injury report, or a full booking record put the sensitive payload in the message body, where a misrouted send hands it over intact. Reducing what the email carries limits the damage from every future misconfiguration, including ones you have not found yet.

• Bind activation links to short expiry windows so a link sitting in someone else's inbox becomes useless quickly.
• Replace credential-bearing mail with a notification plus an in-app retrieval step, keeping the secret behind an authenticated session.
• Strip full names, order details, and case identifiers from automated subject lines and bodies where a reference number would do.

Monitoring closes the loop. Your outbound mail gateway already logs every sender domain your applications use, so build an alert on any sending domain that does not appear in the approved registry, plus a periodic review of bounce and delivery-failure reports. Placeholder domains that nobody owns produce distinctive delivery patterns, and the same telemetry catches a new microservice that was stood up with a fake sender address last week.

Extend the audit to your vendors. The organizations feeding these inboxes included cybersecurity companies and Microsoft partners, which is a reasonable indication that internal engineering maturity does not predict whether this specific mistake was made. Ask each SaaS provider that sends mail on your behalf, including HR platforms, ticketing systems, and CRM tools, which sender domains they use for your tenant and whether they verify ownership of those domains.

Write the approved sender addresses into policy so the registry has an owner and a review cadence. Assign the domain portfolio to whoever holds registrar access, require renewal monitoring on every domain on the list, and document who approves an addition. The problem is not confined to noreply variants. Any generic or unclaimed domain in a "from" header, including deletion placeholders, test-environment stand-ins, and vendor defaults, sends your data to whoever registers it next.

The Broader Risk: Generic Domains as Attack Surface

The pattern is old enough to have been documented in a national newspaper. Nearly 20 years ago, security journalist Brian Krebs, then at the Washington Post, reported that companies were sending millions of automated messages to @donotreply.com addresses. The same defect is still shipping in new code today, which tells you it is an architectural default rather than a bug in any one product.

The reason it repeats is the naming convention itself. Developers treat strings like noreply, no-reply, donotreply, and deleteduser as if they were reserved words rather than ordinary labels that anyone can register under any registrable top-level domain. Each spelling variant, in each TLD, is a separate asset available to whoever files for it first.

Template inheritance multiplies the problem. Email logic gets copied between services, forked from starter projects, and carried forward through platform migrations, so a single organization frequently sends from several placeholder variants at once without any one team owning the list. Your mail gateway sees valid, well-formed sender addresses in every case, so nothing in the delivery path flags them.

Mike Sheward's collection across the multiple domains he owns has drawn mail from at least 100 different organizations, and he notes that the senders include cybersecurity companies and several Microsoft partner companies. Firms that sell security engineering carry the same defect as everyone else, which is a useful data point when assessing vendor risk in your supply chain.

The content categories matter more than the volume, because they show which business processes route through these addresses:

• HR workflow mail asking the recipient to approve vacation requests and leaves of absence
• Hotel bookings containing travelers' full names
• Zoom meeting invitations sent by a UK government agency
• Pharmacy order confirmations, including Viagra orders
• Injury reports from a city government and service orders for physical repairs
• Routine consumer traffic such as pizza order confirmations, alongside an invitation to a San Francisco company's summer BBQ addressed to "Dear Deleted User"

Approval workflows and meeting invitations are the two categories with the most direct operational reach. An approval request implies a reply path back into the originating system, and a meeting invitation carries live join details for a call the recipient was never meant to attend. For a public sector body, that means an outsider holding an access link to an internal discussion with no authentication event to review afterward.

Mapped to adversary behavior, registering one of these domains is infrastructure acquisition (MITRE ATT&CK T1583.001, Acquire Infrastructure: Domains) followed by passive email collection (T1114) and identity reconnaissance (T1589). The collection is entirely passive. There is no scanning, no phishing lure, and no interaction with the target network, so nothing an intrusion detection product monitors ever fires.

Scale is a slow accumulation rather than a spike. The noreply.us domain took in 37,255 messages across 2,345 days of ownership, and in the month before Solovewicz's conference talk his domains together received more than 11,000. Systems configured years ago keep sending, because misconfigured senders do not age out on their own and nobody downstream reports a bounce.

The exposure applies to any organization whose email templates reference a sender domain it does not hold the registration for, regardless of vendor, platform, or industry.

What to Do Now: Audit, Acquire, and Alert

Two researchers, working independently and without any exploitation, now hold mail from thousands of organizations. Mike Sheward alone has received unintended messages from at least 100 different organizations, including cybersecurity firms and Microsoft partner companies. If those companies did not know their own systems were sending vacation approval requests, hotel bookings with customers' full names, and meeting invitations from a UK government agency to a stranger's mailbox, you cannot assume yours does either.

The takeaway is narrower than it first appears. Your exposure is not measured by how good your mail security is. It is measured by whether your organization actually owns the registration behind every sender domain your applications use. The noreply.us domain has taken 37,255 messages across 2,345 days, and in the month before Solovewicz's conference talk his two domains combined pulled in more than 11,000. That traffic arrives whether or not the sending company has DMARC, SSO, or a mature security program.

So the single action worth taking is an ownership check: produce the list of domains your systems send from, and confirm you control each one at the registrar. Everything else in this story follows from that one unanswered question.

Keep in mind that nobody will tell you when you fail this check. Solovewicz contacts affected companies and declines to name them publicly, which is generous behavior from a stranger who has no obligation to do either. The next person to register one of these placeholder domains may not make the same choice. Run the ownership check this week and close the gaps in your current sprint.