An MX record answers where, not who
"""Half of the contact checks in the wild stop at the domain: does it resolve, does it have an MX record, does the domain answer. That check is real work - it removes mistyped domains, dead companies and parked names - but it answers a different question than the one being asked. An MX record is a routing instruction: mail addressed to this domain should be handed to that server. It says nothing about who is on the other end.
Five setups where the domain checks out and the mailbox does not
| Setup | Why domain-level checks pass | What actually happens |
|---|---|---|
| Live MX, no such mailbox | The domain is real and reachable | The address was guessed from a pattern (first.last@) and never existed - the server says so only if you ask about the address |
| Company migrated mail providers | The new provider's MX is live | Old addresses keep resolving as a domain while bouncing as addresses, often for months after the migration |
| Forwarding rule in place | The domain accepts everything addressed to it | The message is relayed to a mailbox nobody reads, or dropped silently by a filter at the far end |
| Catch-all domain | Every probe gets a yes | The domain is not verifying anything - it accepts addresses for people who left years ago alongside real ones |
| Parked or for-sale domain with mail | MX records exist and answer | There is no organisation behind it; a company name scraped alongside it was a coincidence |
In all five rows the domain-level signal is true and the conclusion drawn from it is false. The gap is not a bug in the check; it is the check answering a narrower question than the one you asked.
Why this matters more for agent-built lists
When a list is assembled by an agent, the cheapest thing to verify is the domain - one DNS lookup instead of one conversation per address. So domain validation becomes the default, and the output looks verified: a column of domains that resolve. The false positives all land in the send, where they are expensive: bounces spend sending reputation, not just budget, and the published spread between checked and unchecked contacts (2-5% against 10-35%) is exactly this gap.
What an address-level check adds
- Ask about the specific address. The receiving server's answer about this mailbox - accepted, rejected, or no answer - is the only signal that is about the contact rather than the organisation.
- Keep the three states separate. Deliverable, undeliverable, and unresolved (including
unknownfor catch-all domains) are three different facts, and collapsing them into a boolean is how good contacts get deleted. - Date the answer. A domain that was right in March and a mailbox that was right in March are the same statement six months later, and both decay: 23% of contacts change jobs annually (ZoomInfo, 2025) and 40% of addresses are dead within two years (NeverBounce).
- Keep the source of the address. A guessed pattern and a page where the address was published fail for different reasons, and only one of them is worth re-guessing after a job change.
Freshness is the part that compounds: scraped data outperforms stale databases by 42% (Harvard Business Review, 2024). A domain check cannot see any of it, because the domain is not the thing that went stale.
What TAPAC does with the two layers
The search that finds the contact returns it with the mailbox state already probed - deliverable, undeliverable, or unknown for catch-all domains - along with the time of the call and the source page or profile it came from. Domain-level problems show up as whole sets of failures in one place; address-level problems show up per contact. Pay-per-use at $0.10-0.50 per contact, 100 free searches.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status # or hosted: https://tapacapi.com/mcp # or REST: POST https://tapacapi.com/v1/contacts/search
Related: what a catch-all domain really tells you, what happens during an SMTP handshake, and why role addresses behave differently.
""" ← Back to TAPAC