How MX records work
MX records, defined in RFC 1035, each contain a priority number and a hostname, for example 10 mail.example.com. Lower priority numbers are tried first. A sending server looks up all MX records for the recipient’s domain, sorts them by priority, and attempts delivery to each in order until one accepts the connection.
Why MX lookups are the first step in verification
Before attempting any SMTP handshake, a verification pipeline checks whether the target domain has valid MX records at all. A domain with no MX records (and no usable fallback) can be immediately classified as undeliverable without spending the time or reputation cost of an SMTP connection attempt — this is the cheapest, fastest filter in the entire verification pipeline.
MX priority and load balancing
Multiple MX records at the same priority value are used for load balancing rather than failover — the sending server picks among them (often randomly or round-robin) rather than trying them strictly in order. This is common for high-volume mail providers like Gmail and Microsoft 365, which publish several MX records at matching priorities across their infrastructure.
MX records don’t guarantee a mailbox exists
An MX lookup only confirms a domain can receive mail somewhere — it says nothing about whether any specific address at that domain has an active mailbox. That’s the job of the subsequent SMTP RCPT TO check. A domain can have a perfectly valid MX record and still bounce every message if the specific mailbox doesn’t exist.