MX Records Explained for List Owners

Mail either has somewhere to land or it doesn’t. MX records are how the internet answers that question — and checking them is the cheapest deliverability filter you own.

1. What an MX record is

When mail is addressed to user@acme.com, the sender’s server asks DNS: “who accepts mail for acme.com?” The answer is a list of MX records — hostnames with priorities, like 10 mail.acme.com. No MX records, no delivery, ever. Run a check yourself in the MX Lookup.

2. What the three outcomes mean

• Accepts-mail — the domain publishes mail servers. Keep the slice, but remember this says nothing about the individual mailbox.
• No-mx — the lookup completed and found nothing. Quarantine or drop: every address there is a guaranteed hard bounce.
• Unknown — DNS was unreachable or refused. Retry later; deleting on unknown burns real contacts during transient outages.

3. Why subdomains can disagree with parents

mail.acme.com may publish its own records while acme.com publishes different ones — or none at all. Tools that fold every subdomain to its parent silently misclassify these. Ours queries the exact domain first and consults the parent only when DNS is inconclusive.

4. Where MX fits in the pipeline

MX is a domain-level pre-filter, not verification. The full sequence for a campaign-bound list: clean → validate → MX Lookup for the survivors’ domains → dedicated SMTP verification only for the high-value remainder. Each stage shrinks the billable, reputation-risking volume of the next.

5. Common mistakes

Treating accepts-mail as deliverable. A domain can accept mail for addresses that don’t exist (catch-all domains do exactly this). MX passing plus syntax passing still isn’t a mailbox guarantee.

Deleting on unknown. DNS fails for boring reasons — rate limits, captive portals, provider hiccups. Unknown is a retry instruction, full stop.

Checking once, forever. Domains expire and mail infrastructure migrates. Re-check quarterly, or whenever a previously clean cohort starts bouncing.