MX records are DNS records that tell the internet which mail servers are responsible for accepting email on behalf of a domain. Without them, email cannot be delivered. Every time someone sends a message to [email protected], the sending mail server performs an MX lookup to find out where to route that message. If no MX record exists, the delivery fails before a single byte of the message is transmitted.
What Is an MX Record?
An MX record — short for Mail Exchanger record — is a type of DNS resource record that maps a domain name to one or more mail servers. It is defined in RFC 1035 and has been part of the DNS specification since the early days of the internet.
Each MX record contains two fields: a priority value (also called preference) and a hostname pointing to the mail server. The priority is a non-negative integer — lower numbers indicate higher priority. The hostname must resolve to an A or AAAA record; it cannot be a CNAME or an IP address directly.
A typical MX record in a zone file looks like this:
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.Here, mail1.example.com has priority 10 and mail2.example.com has priority 20. The sending server will always try the lower-priority (higher-preference) host first.
How MX Record Priority Works
Priority values determine the order in which mail servers are tried during delivery. A lower number means higher priority — so a server with priority 5 is tried before one with priority 10. When two records share the same priority value, the sending server chooses between them randomly, effectively load-balancing across those hosts.
Multiple MX records exist primarily for redundancy. If the primary mail server (lowest priority number) is unavailable — due to maintenance, a network outage, or hardware failure — the sending server moves on to the next record in priority order. This failover happens automatically and is transparent to the sender.
When the primary server is unreachable, the sending server will retry delivery to secondary MX hosts for a period defined by the message's expiry time (typically 4–5 days). If no MX host accepts the message within that window, the sender receives a bounce notification.
How to Look Up MX Records
You can query MX records directly from the command line using dig ornslookup. Here is what a dig query looks like for a real domain:
$ dig MX gmail.com
;; ANSWER SECTION:
gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com.
;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)The output shows five MX records. The primary server is gmail-smtp-in.l.google.com at priority 5. The four alt servers serve as fallbacks in ascending priority order. The TTL of 3600 seconds means DNS resolvers cache this result for one hour before re-querying.
On Windows, you can use nslookup -type=MX gmail.com to get the same information. Online tools like MXToolbox and Google's Dig tool provide a browser-based interface if you prefer not to use the command line.
MX Records and Email Verification
MX record lookup is the second stage of the email verification pipeline, sitting between syntax validation and the SMTP handshake. When a verifier checks an address, it queries the domain's MX records to confirm the domain is configured to receive mail before attempting any SMTP connection.
If no MX records exist for a domain, the verifier marks the address as undeliverable immediately — there is no point attempting an SMTP connection to a domain that has no mail server. This catches a large class of bad addresses: defunct domains, newly registered domains that have not yet configured email, and domains used only for web hosting.
The MX hostnames returned by the lookup also determine which server the verifier connects to during the SMTP stage. The verifier follows the same priority ordering that a real mail server would use. For a complete walkthrough of how all the stages fit together, see our guide to how email verification works. To review these checks for addresses in an existing file, use the bulk verification workflow.
Common MX Record Problems
MX record misconfigurations are one of the most common causes of email delivery failures. Here are the problems that come up most often:
Missing MX records. A domain with no MX records cannot receive email. This is sometimes intentional — a domain used only for a website — but it is often an oversight during DNS migration or domain setup. Senders receive a bounce with a "no route to host" or "domain not found" error.
Misconfigured priority values. Setting all MX records to the same priority when you intend a primary/backup relationship means the sending server will load-balance across all hosts rather than preferring one. This is harmless in most cases but can cause issues if the backup server has lower capacity.
Pointing to non-existent hosts. An MX record that references a hostname with no corresponding A record will cause delivery failures. The sending server resolves the MX hostname to an IP address before connecting — if that resolution fails, the delivery attempt fails too.
TTL issues. A very high TTL (24 hours or more) means DNS changes propagate slowly. If you are migrating to a new mail provider, old MX records cached by resolvers worldwide will continue directing mail to the old server until the TTL expires. Lowering the TTL to 300–600 seconds before a migration gives you faster propagation and easier rollback.
MX Records vs A Records for Email
The DNS specification includes a fallback behavior: if a domain has no MX records, a sending mail server may attempt delivery to the IP address returned by the domain's A record. This is defined in RFC 5321 and is sometimes called the "implicit MX" or "A record fallback."
In practice, most modern mail servers do not implement this fallback, and relying on it is strongly discouraged. The A record fallback was designed for a simpler era of the internet and does not support priority-based routing, redundancy, or the separation of web and mail infrastructure. Any domain that intends to receive email should have explicit MX records.
MX is always preferred over A for email routing because it gives you explicit control over which servers handle mail, independent of where your web server lives. This separation is essential for hosted email services like Google Workspace and Microsoft 365, where the mail servers are entirely separate from the domain's web infrastructure. For more on how SMTP connections use MX data, see our SMTP email verification guide.
MX Records and Email Authentication
MX records are closely related to email authentication, though they serve different purposes. Authentication protocols like SPF, DKIM, and DMARC are DNS-based records that prove a message was sent by an authorized server — they protect against spoofing and phishing. MX records, by contrast, control where inbound mail is delivered.
The connection between them is SPF. An SPF record can include an mx mechanism, which automatically authorizes all servers listed in the domain's MX records to send mail on behalf of the domain. This is a convenient shorthand when your outbound mail servers are the same as your inbound ones — a common setup for smaller organizations. For larger deployments, explicit IP ranges or include mechanisms are more precise.
Getting MX records right is a prerequisite for a healthy authentication setup. If your MX records are misconfigured, your SPF mx mechanism will reference the wrong servers, potentially causing legitimate mail to fail authentication checks. For a complete guide to SPF, DKIM, and DMARC configuration, see our SPF, DKIM, and DMARC guide.