Not every address on your site is yours

By Matt Kerr·Published 18 September 2026

A check that finds published email addresses and tests whether they can receive mail has one job that sounds trivial and is not: deciding which of the addresses on your pages is yours. Get that wrong and you hand somebody a real defect they cannot repair, or a repair for something that was never broken.

Publish DNS for a domain you do not own

A software forum runs a how-to about configuring mailboxes. Like every such document it contains example addresses at a documentation domain — placeholder words where a real mailbox name would go.

Those were reported as the site's dead contact channel, with the remedy: add mail records for that domain, pointing at a mail host. The site cannot publish DNS for a domain it does not own. The finding was true and the instruction was impossible.

The guard that was supposed to prevent this is sensible and is written down: only mailto: links count, because an address sitting in prose may be an example, a customer's, or a fax number's neighbour. It stopped working for a reason nobody chose — any platform whose markdown auto-links bare addresses turns every example in every document into a link, and every forum does that.

It is worth sitting with as a general shape. A rule that depends on authors not linking something stops working the moment the platform links it for them, and nothing about the site changed.

What the tool could actually tell

It cannot distinguish documentation from a real address. That is a judgement about intent and it is not in the page.

It can tell whose domain the address is at. So the remedy is now offered only for a domain the reader can publish records for, matched on label boundaries so one domain is never read as a suffix of a similarly spelled one.

The finding was right; only the instruction changed. That distinction is most of what separates a report somebody acts on from one they dismiss — a reader who is told to do something impossible does not conclude the tool was half-right.

The verdict that meant "I cannot judge this"

The second failure is the one worth borrowing, because the mechanism shows up everywhere.

The domain checker answers with a verdict and a reason. For anything that is not a domain at all, it answers no, with the reason "not a syntactically valid domain". The branch above it tested the verdict and not the reason. So the sentence written to say the tool could not judge the string became a finding about the reader's contact channel.

A law firm's site carries a share-by-email button on every page. Its recipient is deliberately empty, so a reader's mail client opens with a blank To: field and a subject already filled in — they type the address of whoever they are sharing with. Perfectly ordinary, working exactly as designed.

The report said that address could not receive mail, and that anyone writing to it would get a bounce. Nobody writes to it. It is not an address.

And it was skipped, not renamed

There is a tempting second move here: stop calling it a dead mailbox and start calling it a broken link. It is still a finding, it is still technically defensible, and the reader is still being shown a working button and told it is broken.

A mailto: with no recipient and a prefilled subject is the ordinary shape of a share widget. Reporting it under a different name would be the same false positive in a new coat — which is worth watching for whenever a tool "addresses" a complaint about a finding and the finding is still there under a different heading.

The one that must still fire

Not every unusual address is innocent. An address whose domain part is a bare server address — digits and dots, or a block of hexadecimal — is a genuinely dead mailbox, because no mail records can ever be published for it. It is the residue of a site being moved between servers while the old host stayed written into the content.

Skipping everything that fails a domain-validity test would have silenced exactly that case while fixing the two above. A test caught it, which is the usual way — a guard that quietens one false positive can silence a true finding →.

Reading this on your own report

1. Check the domain in the address against your own. If it is not yours, no instruction about mail records applies to you, whatever the finding says.
2. Ask where the address appears. A code sample, a support document or a quoted message is somebody else's address that your platform turned into a link.
3. Look for an empty recipient. A share button has no address in it at all, and it is not a contact channel.
4. If it is your domain, test it in one command. The survey behind this check — what a dead contact address actually is → — has the command and the two ways mail configuration fails.

When it is real, and why it is worse than it looks

Keep the severity where it belongs. A published address at a domain that cannot receive mail means every enquiry bounces — and you get no record that anyone tried. That last part is what makes it different from a broken form or a dead link: there is no error you will ever see, no entry in any log of yours, and no angry follow-up. The people who wrote to you simply conclude you did not reply.

The fixes that make it worse

• Chasing DNS for a domain that is not yours. You cannot, and an hour spent finding that out is the cost of the false positive.
• Deleting the examples from your documentation. They are doing their job. The tool was reading them wrongly.
• Removing the share button. It works. Nothing about it needs fixing.
• Adding a working address and leaving the broken one. The dead address stays on the pages that carry it, and those are the pages people will use.

How to pass this check while staying unreachable

Publish your address as plain text without a mailto: link. Only linked addresses are checked — because an unlinked one might be an example — so the finding disappears and the mailbox is exactly as broken as it was.

A check that must avoid other people's examples can only see the addresses you chose to link, and that boundary is visible from outside. It is the honest limit of this kind of check, and it is why the survey behind it starts from DNS rather than from pages.

Where this sits in an audit

The registered check is cvr.dead_contact, which tests whether published email addresses can receive mail. For what actually breaks in mail configuration, and the measurement behind it, see a dead contact address →. For the same question one channel over, see phone links that will not dial →.

Common questions

An audit says an email address on my site is dead, but it is not my address. Why?

Because a check that finds published addresses cannot tell documentation from a real contact address — that is a judgement about intent and it is not in the page. It can tell whose domain the address is at, which is enough to stop offering you a repair you have no access to.

Why would example addresses in my documentation get reported at all?

The usual guard is that only linked addresses count, because prose may hold an example. Platforms that auto-link bare addresses in markdown turn every example into a link, so the guard stops working without anything on the site changing.

My share-by-email button was reported as a dead mailbox. Is something wrong?

No. A share widget has a deliberately empty recipient so the reader types an address, and nothing about it is a contact channel. Renaming that finding to 'broken link' would be the same false positive under a different heading.

Is an email address at a bare IP address a real problem?

Yes. Mail records cannot be published for a server address, so nothing can ever be delivered. It is usually left behind when a site moves servers and the old host stays written into the content.

What does a dead contact address actually cost?

Every enquiry bounces and you get no record that anyone tried. Unlike a broken form there is no error you will see and no log of yours to check — the people who wrote to you conclude you did not reply.