MX records: what they are, how to check them, and why they matter for email validation

Every email starts with a DNS query. Before a server attempts delivery, it asks: who accepts mail for this domain? The answer lives in the MX record. Without one, there is nowhere to send the message.

What is an MX record

MX stands for Mail Exchanger. It is the DNS record type that points to the server responsible for accepting email for a specific domain. When you send to user@example.com, your mail server queries DNS for the MX record of example.com.

An MX record carries two values: a priority number and a mail server hostname. Lower priority numbers win. If the top-priority server is down, the sender tries the next one in order.

example.com.    IN  MX  10  mail1.example.com.
example.com.    IN  MX  20  mail2.example.com.
example.com.    IN  MX  30  mail3.example.com.

Here mail1.example.com is the primary server (priority 10). If it does not respond, mail goes to mail2 (priority 20), then mail3 (priority 30). Built-in failover.

How MX records work in practice

Say you send a message to ivan@company.com. Here is what happens under the hood:

1. Your mail server extracts the domain part of the address: company.com
2. It sends an MX query to DNS for company.com
3. The DNS server returns a list of MX records with their priorities
4. The server picks the lowest-priority record and resolves its hostname to an IP address (via an A or AAAA record)
5. It opens an SMTP connection on port 25 and starts the transfer

The whole process takes milliseconds. But if step 3 returns an empty answer, delivery is impossible. The sending server will bounce the message: "domain does not accept mail."

MX records of real mail providers

Looking at MX records for major providers is useful: it tells you which infrastructure a domain is running on.

Gmail (google.com)

$ dig MX gmail.com +short
5   gmail-smtp-in.l.google.com.
10  alt1.gmail-smtp-in.l.google.com.
20  alt2.gmail-smtp-in.l.google.com.
30  alt3.gmail-smtp-in.l.google.com.
40  alt4.gmail-smtp-in.l.google.com.

Five servers. Primary at priority 5, four backups. Each of those hostnames is itself a load balancer sitting in front of thousands of machines.

Outlook / Microsoft 365

$ dig MX outlook.com +short
10  outlook-com.olc.protection.outlook.com.

One record. Redundancy is handled at the DNS level: the hostname olc.protection.outlook.com resolves to multiple A records. Different approach, same result.

Corporate domain on Google Workspace

$ dig MX company.com +short
1   aspmx.l.google.com.
5   alt1.aspmx.l.google.com.
5   alt2.aspmx.l.google.com.
10  alt3.aspmx.l.google.com.
10  alt4.aspmx.l.google.com.

From the MX records alone you can see this domain runs Google Workspace. Knowing the provider lets a validator apply provider-specific rules for the next validation stages.

How to check MX records: dig, nslookup, host

Three command-line tools cover the job. Both Linux and macOS ship with all three. On Windows, nslookup is available out of the box; dig can be installed via BIND tools.

dig (recommended)

# Basic query
dig MX example.com

# Clean output, no noise
dig MX example.com +short

# Query through a specific resolver (e.g. Google Public DNS)
dig MX example.com @8.8.8.8 +short

# Full resolution trace
dig MX example.com +trace

The +short flag strips all the header noise and prints just the answer. Fine for quick checks and scripts. +trace is useful for debugging: it shows every step from the root servers down to the final answer.

nslookup

# MX query
nslookup -type=mx example.com

# Via a specific resolver
nslookup -type=mx example.com 8.8.8.8

Output is less readable than dig, but nslookup is on every system. Good fallback when dig is not installed.

host

# Terse output
host -t MX example.com

One line per record. Useful in scripts where you just want a clean list of hostnames.

Sample full dig output

$ dig MX yandex.ru

;; QUESTION SECTION:
;yandex.ru.                  IN      MX

;; ANSWER SECTION:
yandex.ru.           7200    IN      MX      10 mx.yandex.net.

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; MSG SIZE  rcvd: 58

This shows the TTL (7200 seconds, or 2 hours), the priority (10), and the server hostname. Query time of 12 ms means the record was cached locally.

What happens when there is no MX record

RFC 5321 specifies a fallback. If a domain has no MX record, the sending server looks for an A record (or AAAA) for the bare domain and attempts delivery directly to that IP. This actually works, though it is rare in practice.

# No MX
$ dig MX tinydomain.org +short
(empty response)

# But an A record exists
$ dig A tinydomain.org +short
93.184.216.34

# The sender will attempt delivery to 93.184.216.34:25

There is also the null MX case. An MX record with priority 0 and hostname "." (a single dot) is defined in RFC 7505. It means the domain explicitly refuses all mail.

example.org.    IN  MX  0  .

If a domain returns a null MX, every address on it is invalid. No fallback, no delivery attempts. A validator should treat this as a hard reject.

The role of MX records in email validation

MX lookup is the second stage in a validation pipeline, right after syntax parsing. It is also the most cost-effective check: one DNS query in 50 to 200 ms.

Syntax alone catches maybe 2 to 3% of bad addresses. MX lookup adds another 8 to 12%. These are addresses on typo domains (gmial.com, gamil.com), expired domains, and domains that never had mail set up. One DNS query removes a tenth of your junk before you run anything heavier.

What MX lookup does not tell you is whether the specific mailbox exists. The domain gmail.com accepts mail fine, but qwerty12345zzz@gmail.com almost certainly does not exist. Checking a specific mailbox requires an SMTP handshake.

What MX lookup gives a validator

• Whether the domain accepts mail. The foundational check. No MX and no A record means the address is dead.
• Which mail provider is running it. The MX hostname reveals the provider: Google Workspace, Microsoft 365, custom server. This drives provider-specific validation logic for later stages.
• Catch-all probability. Exchange-hosted corporate servers are often configured as catch-all. Knowing the provider lets a validator adjust its confidence score accordingly.
• Where to connect for SMTP. The SMTP check needs an IP. That IP comes from resolving the MX hostname.

MX lookup in code: minimal examples

If you are building your own validator, MX lookup should be one of the first things you implement. Here it is in two languages.

Python

import dns.resolver

def check_mx(domain: str) -> bool:
    try:
        answers = dns.resolver.resolve(domain, "MX")
        return len(answers) > 0
    except (dns.resolver.NoAnswer,
            dns.resolver.NXDOMAIN,
            dns.resolver.NoNameservers):
        return False

# Usage
domain = "gmail.com"
if check_mx(domain):
    print(f"{domain}: MX found, domain accepts mail")
else:
    print(f"{domain}: no MX records")

Node.js

const dns = require("dns").promises;

async function checkMx(domain) {
  try {
    const records = await dns.resolveMx(domain);
    // Sort by priority, lowest first
    records.sort((a, b) => a.priority - b.priority);
    return records;
  } catch (err) {
    return [];
  }
}

// Usage
const records = await checkMx("gmail.com");
if (records.length > 0) {
  console.log("Primary server:", records[0].exchange);
}

Both examples are intentionally minimal. In production, add timeouts, result caching keyed to the DNS TTL, null MX handling, and the A record fallback.

Common MX record problems

A few issues come up repeatedly when working with DNS validation.

• MX pointing to an IP address instead of a hostname. RFC 5321 requires a domain name in the MX record, not a bare IP. Most servers handle it anyway, but it is technically wrong.
• MX pointing to a CNAME. Another RFC violation. MX records should resolve directly to A/AAAA without an intermediate CNAME. It usually works, but creates extra DNS round-trips and can break with stricter servers.
• High TTL during a migration. A company moves to a new mail server, but the old MX records have a TTL of 86,400 seconds (24 hours). For a full day, some senders still reach the old server. Lower the TTL to 300 seconds at least 24 hours before any migration.
• Forgetting to copy MX records after a DNS move. The domain switches DNS providers, but nobody migrates the MX entries. Mail stops arriving. Always verify MX after any DNS change.
• Identical priorities. Two servers at priority 10 is valid. Senders distribute mail between them roughly evenly, which is useful for load balancing.

MX priorities: how to set them up

The numbering scheme depends on what you need. Three common patterns.

One primary, one backup. The classic setup for smaller organizations. The primary handles all mail; the backup only kicks in on failure.

company.com.   IN  MX  10  mail.company.com.
company.com.   IN  MX  20  backup.company.com.

Load balancing. Two servers at the same priority. Senders split traffic between them roughly 50/50.

company.com.   IN  MX  10  mail1.company.com.
company.com.   IN  MX  10  mail2.company.com.
company.com.   IN  MX  20  backup.company.com.

Cloud provider. If you are on Google Workspace, Microsoft 365, or a similar service, the provider tells you exactly which MX records to use. Do not adjust the priorities; add the records exactly as documented.

MX records and security

MX records are public. Anyone can look up which servers handle your mail. That is not a problem on its own, but knowing your infrastructure makes targeted attacks easier.

DNSSEC protects MX records against spoofing at the DNS layer. Without DNSSEC, an attacker in a man-in-the-middle position can return a forged DNS response and redirect mail to their own server. If your domain supports DNSSEC, make sure the MX records are signed.

MTA-STS (RFC 8461) adds another layer. It tells the sending server: when connecting to my MX, use TLS and validate the certificate. Without MTA-STS, the connection can be established without encryption even if the server supports STARTTLS. Google, Yahoo, and Microsoft all enforce MTA-STS on their own domains.

How MX records relate to SPF, DKIM, and DMARC

MX, SPF, DKIM, and DMARC are four DNS record types that together define a domain's mail infrastructure. They solve different problems but work as a group.

MX handles inbound mail: where to deliver it. SPF handles outbound: which servers are authorized to send. DKIM proves the message was not altered in transit. DMARC ties SPF and DKIM into a single policy.

For email validation, all four records carry useful signal. MX comes first because it is the fastest check and cuts out the most obvious dead addresses. SPF and DKIM are verified by the receiving server after the message has been sent.

Quick MX record checklist

• Check your domain's MX records: dig MX yourdomain.com +short
• Confirm that the MX hostname resolves to an A or AAAA record
• Use different priorities for primary and backup servers
• Before any migration, lower the TTL to 300 seconds at least 24 hours in advance
• Do not put an IP address directly in an MX record, only hostnames
• Enable DNSSEC to protect against record spoofing
• Configure MTA-STS to enforce encrypted delivery