The contact address that cannot receive mail

A contact address on a domain with no MX record does not fail loudly — it bounces, to the sender, and you never learn anyone wrote. We checked the 1233 sites in the Tranco top 1500 that answered a request, and found 80 still publish an email address at all: every one of them we could resolve accepts mail.

So this is not an epidemic among large sites. It is the failure we shipped on our own site, and the more useful finding turned out to be the denominator rather than the numerator.

What actually breaks

Delivering mail to a domain means asking DNS for its MX record. RFC 5321 §5.1 says that when there is no MX, the sender falls back to the domain's address record and tries SMTP there. On a site hosted by GitHub Pages, Netlify, Vercel or Cloudflare Pages, that address record points at a machine which serves files and does not answer on port 25. The message is attempted, refused, and bounced.

The bounce goes to the person who wrote to you. Nothing arrives at your end — not the message, not a warning, not a record that anyone tried. Your analytics show the contact page being read. Your inbox shows nothing, which looks exactly like nobody having anything to say.

This is why it is worse than a broken link, and worth stating plainly: a 404 tells the visitor it failed. A dead mailbox tells the visitor it worked.

We did this

docketseo.app carried hello@docketseo.app in the footer of all 25 of its pages. The domain has no MX record; it is on GitHub Pages; port 25 is closed there. Every message anyone sent bounced, and we found out by writing a contact page and checking our own advertised channel before publishing it.

An SEO audit tool shipping a dead contact address is embarrassing in a specific and useful way: it is exactly the class of defect that only shows up if something asks the question, and nothing did, because no tool asks it. That is now check 93 — cvr.dead_contact.

What the survey found

We fetched the homepage of the top 1500 sites in the Tranco list; 1233 answered. An address counts as published only where it appears in a mailto: href — text in prose might be an example, a screenshot caption or somebody else's. Free-provider addresses and RFC 2606 reserved names are excluded, because whether gmail.com accepts mail is not a fact about the site quoting it.

Zero is a real result and it deserves an honest reading rather than a triumphant one. Zero out of 80 is not evidence that the true rate is zero; it is consistent with anything up to about 3.8%, which is what a 95% interval allows when you observe no events in 80 trials. What it does rule out is the version of this article we expected to write.

The number we did not go looking for

Only 6.5% of the sites that answered publish an email address at all. Among the largest sites on the web, the contact address has very nearly disappeared — replaced by a form, a help centre, or nothing.

That reframes the risk rather than removing it. A dead address is a failure available only to sites that still publish one, and the sites that still publish one are small: the independent shop, the two-person consultancy, the practice whose owner wants people to be able to just write. Those are also the sites least likely to have anyone watching DNS, and most likely to have moved to a static host in the last few years without thinking about mail. The population most exposed to this is the population we could not sample by taking the top of a popularity list.

So we went and sampled it

Taking the top of a ranking cannot reach small businesses, so the second survey does not use a ranking at all. The frame, in one sentence: every shop in OpenStreetMap inside the boundaries of 10 named UK cities that also carries a website tag, one entry per domain. Nothing selects individual businesses and nothing weights by size or traffic; the whole frame is used, so there is no slice to defend. The Overpass query is in the dataset if you want to re-run it.

2551 distinct domains, 1975 of which answered a request. And the first number is the one that matters:

Small businesses publish an email address 3.2 times as often — 20.9% against 6.5%. And unlike the large sites, some of theirs do not work: 7 of 413, or 1.7%, with a 95% interval of 0.8% to 3.5%. Seven is a small number and the interval says so; what it is not is zero.

All seven are businesses with a single mapped location — the independents, not the chains. That split comes from the data rather than from an opinion about which brands count as chains: a domain appearing at one mapped shop is one business, and at nine is not.

The two ways they break

We are not naming them. These are corner shops and locksmiths that never asked to be audited, and "this named business cannot receive email" is not a thing this site has any business publishing about them. The failure shapes are the useful part, and there are only two:

• The domain in the address does not exist. Six of the seven. The site is on one domain and the email address is at another — a near-miss spelling, or a domain that lapsed — and that second domain has no MX record and no address record at all. Nothing about the website looks wrong, because nothing about the website is wrong.
• An MX record naming a host that does not resolve. One of the seven, and the more interesting one. The domain publishes a mail exchanger, so every "do you have an MX record" test passes. The host it names has no address record — in this case a hosting panel had pasted the domain into the middle of a template value and left it there. The record looks completely correct in the zone file and there is nowhere for the mail to go.

That second shape is why Docket resolves the exchanger rather than stopping at the record. An MX-exists check would have called that domain healthy.

The record that exists and the host that does not

Everything above is about a domain with no MX record. There is a second failure underneath it that is harder to see, and we measured that too — same frame, DNS only, no pages fetched.

Of the 1005 domains in the frame that publish an MX record at all, 18 name a mail exchanger that does not resolve — every one of them, so there is nowhere for the message to go. That is 1.8% of the domains that look correctly configured. Another 2 have one dead exchanger and a working one, so their mail arrives; the finding only speaks when all of them fail.

This is the case that defeats checking. Every "does this domain have an MX record" test passes. The zone file looks right, the record has a sensible priority, and the hostname reads like a mail server. It just names a machine that is not there.

13 of the 18 fall into two shapes. That is what makes it worth naming rather than reporting as "the host does not resolve": telling someone their Microsoft 365 exchanger is missing sends them to the right console, and telling them the host is unreachable sends them to their DNS panel to look at a record that is fine.

We are not saying why. A tenant hostname that stops resolving could be a lapsed subscription, a migration someone started and did not finish, or a record left behind after a move years ago. From outside the domain those look identical, so Docket names the shape and stops. Guessing the cause would be the kind of confident wrongness that costs more than the finding is worth.

One of the 18 is an exchanger under .invalid, which RFC 2606 reserves precisely so that it can never resolve. As a placeholder in a setup wizard that is correct. As a live MX record it is a guarantee of failure.

What this does not cover

Said plainly, because a frame with unstated limits is worse than no frame. OpenStreetMap coverage is uneven and who gets mapped is not random — a shop nobody added is not in this survey. A website tag sometimes points at a social page or a chain's national site rather than the business's own domain; those are excluded, and the exclusion is a judgement we made. 10 UK cities is not the world, and shops are not every kind of small business. The number to take from this is the contrast in the table, not 1.7% as a rate for small businesses everywhere.

Where another tool is better

Any mail-focused service does deliverability far more thoroughly than this. MXToolbox and its equivalents will check SPF, DKIM, DMARC, blacklist status and whether your outbound mail will land in spam — none of which Docket looks at, and all of which matter more than this check if you are actually sending mail.

The difference is what starts the question. Those tools begin with a domain you already suspect. This begins with your website, finds the address you are publishing, and asks whether it works — which is a question nobody thinks to ask about an address they have had for years.

Checking your own

One command, and no tool required:

dig +short MX yourdomain.com

Output means a mail exchanger is published and mail has somewhere to go. Empty output means there is none, and the next question is whether your address record runs a mail server — almost certainly not, if your site is on a static host. The fix is to add MX records at your DNS provider, pointing at whatever mailbox or forwarding service you use.

If you are not going to fix it, delete the address. A visitor who sees no email address looks for another way to reach you. A visitor who emails a dead one believes they already have.

Docket runs this as cvr.dead_contact on every audit, and it will not report a domain it could not resolve — a lookup that failed is not a finding, and a domain with no MX but a working mail server on its address record is legal and fine.

Download Docket

Common questions

How do I know if my contact email works?

Run dig +short MX yourdomain.com. Any output means a mail exchanger is published and mail has somewhere to go. Empty output means there is none, and senders fall back to your address record — which on a static host such as GitHub Pages or Netlify does not run a mail server, so every message bounces.

Why does mail bounce silently?

The bounce is delivered to the sender, not to you. Nothing reaches the address and nothing records the attempt, so an inbox with no messages looks identical to an audience with nothing to say.

Is it common for a published address to be dead?

Not among large sites: of the 1233 in the Tranco top 1500 that answered, 80 publish an address and every one we could resolve accepts mail. Among 1975 UK shop websites sampled from OpenStreetMap, 20.9% publish an address and 7 of 413 cannot receive mail — about 1.7%, with a 95% interval of 0.8% to 3.5%.

My domain has an MX record — is that enough?

No. An MX record names a host, and the host has to exist. Of the 1005 domains in our OpenStreetMap sample that publish an MX record, 18 name an exchanger that does not resolve at all, so mail bounces while every record-presence check passes. Resolve the hostname in the record, not just the record: dig +short A the-name-your-mx-points-at.

Can a domain receive mail without an MX record?

Yes. RFC 5321 section 5.1 says a sender that finds no MX falls back to the domain's address record, so a domain whose web server also runs SMTP works fine. That is why the absence of an MX record is the start of the question rather than the answer to it.