Findings · 2026-08-13 · By VSNARY | Emmanuel Orta · 0 views
Email bounce case study: every contact address failed for one character
A contractor site linked the same misspelled address on every page. Two DNS lookups proved it, and the fix took one line.
A Denver contracting site linked mailto: the same address on its homepage, its contact page, its quote page and every service page. It was the only email address anywhere on the site.
The domain in that address was misspelled — one transposed pair of letters away from the company’s own domain.
How we knew, rather than guessed
Two DNS lookups settled it:
- The misspelled domain: NXDOMAIN. No address record, no mail exchanger. It does not exist, so every message a visitor sent bounced.
- The correct domain: a live address record and Google Workspace mail exchangers. That mailbox receives.
That is the difference between a correction and a guess. We did not decide what the address should be — we established that only one spelling could receive mail at all.
Why nobody noticed
A bounce goes to the sender, not to the business. The owner sees fewer enquiries; nothing in any dashboard says why. There is no error state anywhere in the system — the form of failure is silence.
It is the same class of failure as a machine file that answers 200 and cannot be read: every layer reports success, because every layer did its own job. The link was well-formed. The mail client opened. The message was sent. The only party that learned anything was a stranger, who received a bounce from a domain they had never heard of and moved on to the next contractor.
Two DNS lookups, one answer
| Domain in the mailto: link | Mail exchanger | Result |
|---|---|---|
| The linked domain, misspelled | none — NXDOMAIN | every message bounced |
| The company’s real domain | Google Workspace mail exchangers | mail accepted |
We did not decide what the address should be. We established that only one spelling could receive mail at all.
What each DNS answer means
The lookup is cheap and the answer is one of four states. Reading them correctly is the whole check; reading them loosely produces a false accusation, which is worse than no check at all.
| DNS answer for the domain after the @ | What it means for mail | What to do |
|---|---|---|
| NXDOMAIN — the name does not exist | Nothing can deliver. Every message bounces at the sender’s own mail server. | The address is wrong. Find the spelling that resolves. |
| MX records present | Someone accepts mail for this domain. Delivery is possible; whether the mailbox exists is a separate question. | Send a test message from outside and wait for a human reply. |
| No MX, but an A or AAAA record | Mail falls back to the web host. It may deliver, may bounce, may vanish into a server nobody reads. | Treat as unverified. Ask the owner where mail actually lands. |
A single MX of . (null MX, RFC 7505) | The domain declares that it never accepts mail. | The address is deliberately dead. Remove it. |
Only the first and last rows are proof. The middle two are where a careful reader stops and a careless tool keeps going: an MX record proves a door exists, not that anyone is behind it, and a bare A record proves nothing about mail at all. This case sat in the first row, which is why we could say it plainly.
Where the misspelling lives
A contact address on a modern site exists in at least three places, and they drift independently: the mailto: link a visitor clicks, the email property in the site’s structured data that an assistant reads out, and the visible text a human copies by hand. On this site all three carried the misspelling, because all three had been pasted from the same source on launch day and nobody had reason to touch them since. That is the common case, and it is the reason the fix was one line: the template held the string once.
The less common case is worse. When the schema says one address and the page says another, a machine and a human are told different things, and neither is wrong in a way either can detect. Two copies of one fact are not redundancy; they are a second place for it to be stale.
What this scanner does and does not check
Honesty about scope, because a post that implies a check exists when it does not is exactly the kind of claim this site is built to expose. The scanner reads the contact details a site declares — the name, phone, address and profile links in its structured data and on its page — and compares them against each other. It does not, today, resolve the mail exchanger behind an email address. The two lookups above were run by hand on a domain we operate, and the correction was made by the same hand; no automated finding fired, because no automated check exists for it yet.
Adding the lookup is cheap. Adding it honestly means reporting all four states rather than collapsing them into working and broken, and never scoring a domain for the middle two. Until it clears that bar it stays out of the grade, the same rule that keeps every unverifiable claim out of the score.
The general lesson
Contact details are the part of a site that a machine reads out loud, and the part nobody re-reads after launch. Check that every address, every phone number and every profile link on your site resolves to something that answers — not by looking at it, but by asking the network the same question a stranger’s mail server will ask.
How to check every contact address on your site
Pull every mailto: from your homepage, contact page and footer, then resolve the domain of each one. A mailbox that receives has a mail exchanger; a misspelled domain has nothing:
curl -s https://yoursite.com/ | grep -o 'mailto:[^"?]*' | sort -u
dig +short MX yourdomain.comAn empty MX answer on a domain you believe you own is the whole finding. Do the same for the phone number: call it from a phone that is not yours. And do it after every redesign, because contact details are copied from the previous build by hand and that is where a transposed pair of letters comes from.
Where this shows up in a scan
The NAP rows in the local-presence section compare the phone and address in your structured data against what the page shows and what your declared profiles carry, and the E-E-A-T proxy rows check that a contact route is declared in schema at all. Neither can send an email. A live scan tells you what is declared; only a DNS lookup tells you whether it can be reached. Related: the two facts almost nobody publishes.
Every figure above came out of this scanner.
Point it at your own domain and see the same measurements, free.
Questions this post answers
How do you prove an email address is undeliverable?
Two DNS lookups. Check whether the domain in the address resolves and whether it publishes MX records. A misspelled domain fails both, and that is proof rather than a guess.
Why does a bad contact address go unnoticed for so long?
Because nothing bounces back to the site owner. The sender gets the failure, the owner sees no traffic signal, and every page keeps linking the same broken address.
What is the general lesson?
Any contact detail repeated site-wide is a single point of failure worth verifying mechanically, not by eye.
Related findings
Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.