Zombie MX Records: Mail Routed to Dead Domains

Published 2026-08-18

Figures as of 2026-08-16 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

At least 43,723 dead domains are still telling the world where to send their mail

In the August 2026 census round, at least 43,723 domains that failed every liveness test we ran — dead or unreachable across multiple scan passes — were still publishing MX records, the DNS entries that tell the world’s mail servers where to deliver their email. The websites are gone. Nothing answers. The mail routing instructions are still up.

We call these zombie MX records. The domain, as an operating thing, has stopped. Its mail plumbing hasn’t been told.

And 43,723 is a floor, not an estimate. Our pipeline only fully enumerates mail records for domains healthy enough to be graded, so for the dead and unreachable population we only see MX records where capture happened anyway. The true zombie count is higher. How much higher, we cannot say from this round — the methodology section below explains exactly what we can and cannot see.

Key numbers

At least 43,723 dead or unreachable domains still carried MX records in the August 2026 census round (floor figure; partial capture).
33,078 of 35,385,107 unreachable domains (at least 0.09%) still published mail-routing records.
10,645 of 92,330,029 dead domains (at least 0.01%) did the same.
127,715,136 domains — 30% of the 432,127,908 we scanned — were dead or unreachable in August 2026; the zombie MX cohort lives inside that population.
These counts are floors: MX enumeration in our pipeline runs fully only for graded domains, so zombie MX records are systematically undercounted, never overcounted.

What is a zombie MX record?

An MX record is the forwarding address of the email world. When someone sends mail to any address at a domain, their mail server asks DNS: where does this domain’s mail go? The MX record answers with a hostname, usually a mail provider’s server, and the message is handed over there.

A zombie MX record is that forwarding address left standing after everything else about the domain has died. In our census, “dead” means the domain’s DNS delegation no longer functions — the census could not get its nameservers to answer for it on any pass. “Unreachable” means the delegation exists on paper but nothing behind it responded across our repeated scan attempts. Both are domains that, from the outside, have ceased operating. Yet at least 43,723 of them still carry instructions saying: deliver our mail here.

The mail itself does not stop just because the website did. Old customers reply to old threads. Password-reset emails go to the address on file. Invoices, newsletters, supplier notifications, account-recovery codes — anything ever pointed at that domain keeps being handed to whatever the MX record names, for as long as any part of the DNS still coughs up an answer to somebody.

How does a domain die and leave its MX behind?

Nobody sets out to build a zombie. They accumulate through ordinary neglect, in a few recurring patterns.

The abandoned business. A company winds down. Someone cancels the web hosting, because that has a visible monthly bill. Nobody thinks about the DNS zone, which costs nothing or almost nothing and sits at a registrar or DNS host on autorenew. The website dies loudly; the MX record survives silently.

The half-finished migration. A domain moves providers, or a company gets acquired and its domains get consolidated. The web presence is migrated or shut down deliberately. The mail records were configured years earlier by someone who has since left, and the migration checklist never mentioned them.

The decayed delegation. The domain’s nameservers themselves rot — the DNS provider account lapses, or the nameserver hosts go offline. The domain drifts into our “unreachable” or “dead” buckets not through any single decision but because the infrastructure underneath it crumbled at different speeds. Records that cached well, or that live on a partially-working nameserver, linger.

The common thread: web death is visible and mail-routing death is not. A dead website produces complaints. A zombie MX record produces nothing anyone notices, which is exactly what makes it dangerous.

Why is a zombie MX record a security risk?

Because an MX record is a standing claim: the host named here is authorized to receive all of this domain’s email. When the domain’s owner has walked away, the question becomes who controls that host — today, and next year.

The failure mode security researchers call a dangling or stale MX works like this (this is industry-documented attack knowledge, not a census measurement). The MX record points at a hostname. If that hostname’s own domain expires, or the mail service account behind it lapses and the name becomes claimable, anyone can register it and stand up a mail server there. From that moment, they receive everything sent to the zombie domain. No hacking in any meaningful sense occurred. The DNS did exactly what its last owner told it to do.

What arrives in that inbox is the alarming part. Email is the master key of account infrastructure: password resets, verification links, and recovery flows all terminate in a mailbox. A defunct company’s domain can still be the registered contact address for cloud accounts, SaaS subscriptions, code repositories, financial services, and supplier portals. Receiving its mail can mean inheriting its accounts. Researchers have repeatedly demonstrated this class of takeover against expired mail-provider domains and lapsed third-party services; it is a known, practiced technique, not a theoretical one.

There is a second, quieter harm. A dead domain with a live MX record and no sender-authentication records is an attractive spoofing shell: mail claiming to come from it has an air of legitimacy (the domain existed, it had history, it had mail service) and no owner left to notice the abuse or receive the complaints.

To be precise about what our data shows: we measured that at least 43,723 dead or unreachable domains still publish MX records. We did not probe where those MX targets point, whether the target hostnames are claimable, or whether any have been taken over. The census measures the standing exposure; the takeover mechanics are the well-documented context for why that exposure matters.

The numbers

The zombie MX cohort sits inside the census’s dead and unreachable populations. Both figures are floors, for the capture reason explained below.

Disposition	Domains (August 2026)	With MX record	Share (floor)
Unreachable	35,385,107	33,078	≥ 0.09%
Dead	92,330,029	10,645	≥ 0.01%
Combined	127,715,136	≥ 43,723	≥ 0.03%

For scale: the full census scanned 432,127,908 domains, of which 376,928,781 graded, and 127.7 million above were dead or unreachable — roughly three registered domains in ten are, functionally, gone. The zombie MX domains are the sliver of that dead mass that still has one system pointed outward, accepting deliveries.

The unreachable cohort shows a higher zombie rate than the dead cohort (both floors). That fits the mechanism: an unreachable domain still has working-on-paper delegation, so more of its records survive to be observed, while a dead domain’s records are only visible in the residue of partial capture. It is also a hint that the gap between our floor and the true count is largest precisely where domains are most decayed.

How we measured this

Population: 432,127,908 domains scanned in the August 2026 census round, methodology v9, figures as of 2026-08-16. Dispositions: 376,928,781 graded, 35,385,107 unreachable, 92,330,029 dead (dead domains graded F and included in the graded total; unreachable logged separately).
Definitions: “dead” = the domain’s DNS delegation no longer functioned for our scans on any pass; “unreachable” = delegation existed but nothing behind it responded across repeated passes. Domains are scanned multiple times before landing in either bucket.
The zombie MX count is the number of domains in each of those two buckets whose census evidence includes at least one MX record.
The severe caveat — these are floors. Our pipeline fully enumerates MX records only for domains healthy enough to be graded. For dead and unreachable domains, MX evidence exists only where capture happened anyway — typically because the domain answered partially, or answered on one pass before failing on the ones that determined its final disposition. A dead domain whose MX record we never got the chance to observe is invisible to this count. Every figure in this article should therefore be read as “at least”; the true zombie MX population is larger, by an amount this round cannot measure.
What we did not measure: where the MX targets point, whether the target hostnames are registered, claimable, or answering, and whether any zombie domain’s mail has actually been intercepted. The takeover mechanics described above are established industry security research, labelled as such, not census findings.
Vantage: all measurements from our EU scanning infrastructure; a single organization’s vantage, not a global anycast view.
Aggregate only. We never name, grade, or publish data about an individual registrant’s domain.
Data is stored and processed within the EU.

What should you do about it?

If you have ever retired a domain, wound down a company, or migrated mail providers, the check takes under a minute: look up the domain’s MX records (any public DNS-lookup tool will do). If a domain you no longer operate still returns an MX record, you have a zombie.

The clean fixes, in order of preference. If the domain is truly finished, remove the MX records entirely, along with any SPF or other mail records. Better still, publish a Null MX record — a single MX with priority 0 and target ”.” — which is the standard way (RFC 7505, an industry standard from 2015) to declare “this domain does not accept mail,” so senders fail fast instead of retrying or falling back. And if the domain must keep receiving mail during a wind-down, keep the mail service account alive and monitored until the day you cut the records; an MX pointing at a cancelled account is the worst of both worlds.

For domains you still operate, the same census that found the zombies grades the living. Decayed mail configuration rarely announces itself; it just waits.

FAQ

Can a dead domain really still receive email? Yes, within limits. Delivery requires some part of the domain’s DNS to still answer with an MX record and the named mail host to accept the message. Our unreachable cohort (delegation exists, services don’t respond) is exactly the twilight zone where this happens, and at least 33,078 of those 35.4 million domains still published MX records in August 2026. Mail delivery infrastructure is deliberately persistent: senders retry for days, and resolvers cache, so mail flow can outlive a domain’s visible death by a long way.

How many domains have zombie MX records? At least 43,723 as of the August 2026 census round: 33,078 among 35.4 million unreachable domains and 10,645 among 92.3 million dead ones. The honest answer includes the caveat: our pipeline only fully enumerates MX records for healthy, graded domains, so this is a floor from partial capture, and the true count is higher.

Is a zombie MX record the same as a dangling MX? They overlap but aren’t identical. A zombie MX (our term) is any MX record surviving on a dead or unreachable domain. A dangling MX (the security-research term) is an MX whose target hostname is unregistered or claimable, making mail interception possible. Every dangling MX on a dead domain is a zombie; not every zombie is danglingly claimable. We measured the zombie population; we did not probe which of the 43,723 are claimable.

Who would want to take over a dead domain’s email? Anyone who profits from receiving mail meant for someone else: password-reset and account-recovery messages for services the defunct owner registered, invoices and supplier correspondence usable for payment fraud, and customer replies rich in personal data. Security researchers have demonstrated this class of takeover repeatedly against lapsed mail services and expired domains. The victim often no longer exists as an organization, which means nobody is watching and nobody complains.

How do I check and fix my own retired domain? Query the domain’s MX records with any DNS lookup tool. If records remain on a domain you’ve retired, delete them along with SPF and other mail records, or publish a Null MX (RFC 7505) to declare the domain mail-free. If the domain still has value, keep its DNS under active management; the census’s dead and unreachable buckets are full of domains nobody decided to kill.

How does this relate to account takeover attacks? A zombie MX pointing at a claimable hostname is a direct account-takeover vector. A password reset for any service where the defunct domain is the registered contact email will be delivered to whoever controls the MX target. Researchers have used this technique to demonstrate takeovers of cloud accounts, code repositories, and SaaS subscriptions tied to expired domains. The risk is not theoretical — it has been demonstrated repeatedly in published security research.

What should I check when winding down a company or product? Before decommissioning any domain, check and remove: MX records (and ensure the mail service account is cancelled or transferred), NS records pointing at provider accounts being closed, SPF and DKIM records that reference mail services being disconnected, and any DS records at the registrar if DNSSEC was configured. Leave a null MX if the domain will be retained. Document these steps in your decommissioning checklist — the DNS cleanup is the step that most teams skip, and it is the step that creates long-tail liability.

What this means

For IT managers and security teams, zombie MX records represent a class of risk that falls into the gap between IT and operations: the domain is technically “dead” so it falls off the monitoring dashboard, but its DNS records persist and create ongoing exposure. Every domain retirement process in your organisation should include an explicit DNS cleanup step that removes or replaces MX records before the domain is considered fully decommissioned. This is particularly important for acquired company domains, product brands that have been sunset, and any domain whose mail services were tied to a vendor account that is being cancelled.

For business owners who have wound down a company, subsidiary, or product domain, the check takes under a minute and the risk is concrete. Old email addresses at retired domains are often still in use as contact addresses for active services — cloud accounts, SaaS subscriptions, supplier portals, financial services. A zombie MX pointing at a claimable hostname gives whoever registers that hostname access to the password reset flows for all of those accounts. This is not a sophisticated attack; it requires no exploitation and no technical skill beyond registering an expired domain name.

For security professionals assessing third-party risk, suppliers and partners with retired domains in their portfolio are a supply chain concern. A supplier whose historic domain still accepts email for their accounts at shared services creates indirect exposure. Asking vendors to confirm their DNS cleanup procedures for retired domains as part of supplier security questionnaires is a proportionate addition to any third-party risk programme.

Data to cite

“At least 43,723 dead or unreachable domains still published MX records in the August 2026 census — a floor figure, not an estimate, because zombie MX records are systematically undercounted.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“33,078 of 35,385,107 unreachable domains still published mail-routing MX records in August 2026, at a rate of at least 0.09%.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“127,715,136 domains — 30% of all 432 million scanned — were dead or unreachable in August 2026; zombie MX records are the standing exposure inside that population.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“A zombie MX pointing at a claimable hostname is a direct account-takeover vector: anyone who registers the expired MX target receives all password resets and recovery codes sent to that domain.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“Email is the master key of account infrastructure; a defunct company’s domain can still be the registered contact for cloud accounts, SaaS services, and financial portals.” — defaults.exposed August 2026 Domain Security Census (432M domains)
“A dead website produces complaints; a zombie MX record produces nothing anyone notices — which is exactly what makes it dangerous.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

Zombie domains can’t be fixed by their departed owners, but yours can. Our census grades live domains across 34 externally observable security checks, mail configuration included, and most of what a failing domain is missing is free and quick to fix — the barrier is almost never cost, it’s that nobody told the owner it mattered. You can check your domain privately and free.

Check your domain free at defaults.exposed — see your domain’s full mail configuration including MX records, SPF, DMARC, and whether your setup has any zombie-creating gaps that would survive a future retirement. Takes 30 seconds. No account needed.

Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). Zombie MX Records: Mail Routed to Dead Domains. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/zombie-mx-mail-routed-to-dead-domains

Academic: defaults.exposed. (2026, August 18). Zombie MX Records: Mail Routed to Dead Domains. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/zombie-mx-mail-routed-to-dead-domains

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=432,127,908 scanned)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026