MX Lookup

MX records reveal your email provider, but also your security gateway architecture, redundancy approach, and subdomain email routing — more information than most administrators intend to expose. Here's how to identify Google Workspace vs Microsoft 365 vs security gateway patterns from MX hostnames, why five MX records at one provider don't protect against a provider outage, and how SMTP queuing means short MX outages don't cause lost email.

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 [email protected] 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.