MX Lookup

MX records are public reconnaissance data — attackers use them to identify email providers, target backup MX servers that have weaker filtering than primary MX, and exploit dangling MX records pointing to decommissioned servers. Here's the backup MX vulnerability, how null MX (RFC 7505) protects parked domains, the TTL preparation step for email migrations, and why using "mx" in SPF creates maintenance traps.

An MX lookup can show valid, correctly-configured mail servers — and "does jane@example.com actually exist" still can't be answered, because MX records describe where mail for the domain goes, not which specific addresses are valid mailboxes. Here's how catch-all configurations make every local part "work" regardless of whether it's real, why this makes SMTP-based email verification inconclusive for catch-all domains, and why list-cleaning reports show an "unknown/risky" category for exactly this reason.

Multiple MX records don't load-balance by default — lower priority numbers are tried first, in strict order, with fallback only on connection failure (not on "recipient doesn't exist" responses). Here's how MX priority actually governs mail server selection, when equal priorities create real load distribution, the null MX convention for email-free domains, and practical MX configuration patterns.

Switching email providers is one of the most common causes of lost email. Here's the correct migration sequence (never update MX first), how Google Workspace, Microsoft 365, and Zoho Mail configure their MX records, and how to verify after migration.

When email stops working, MX records are almost always part of the diagnosis. Here's how MX records control email delivery, how to debug bounces and delivery failures, common provider configurations, and the null MX for non-email domains.