MX Record Checker — Look Up Mail Server Records

#What this tool does

Enter a domain and this tool resolves its MX (Mail Exchange) records via public DNS servers. You get the mail server hostnames and their priority values — the two pieces of information that determine where email for that domain is routed. Lookups run server-side; your domain is not stored or logged.

#What is an MX record?

An MX record maps a domain to one or more mail servers responsible for accepting email on its behalf. Every MX record contains two fields: a priority number and a mail server hostname.

example.com  →  MX  →  10  mail.example.com
example.com  →  MX  →  20  mail-backup.example.com

When someone sends email to user@example.com, the sending mail server queries DNS for MX records, sorts them by priority, and attempts delivery to the highest-priority server first. If that server is unreachable, it falls back to the next one.

MX records work alongside other DNS record types like CNAME records, but serve a distinct purpose — they exclusively control email routing.

#How MX priority works

Lower numbers mean higher priority. A server with priority 10 receives mail before a server with priority 20.

example.com  →  MX  →  10  primary.mail.example.com    (tries first)
example.com  →  MX  →  20  backup.mail.example.com     (fallback)
example.com  →  MX  →  30  disaster.mail.example.com   (last resort)

If two MX records share the same priority, the sending server picks one at random — this is how you load-balance inbound email across multiple servers.

Convention uses multiples of 10 (10, 20, 30) to leave room for inserting new servers later without renumbering.

#Common MX configurations

Google Workspace

10  aspmx.l.google.com
20  alt1.aspmx.l.google.com
20  alt2.aspmx.l.google.com
30  alt3.aspmx.l.google.com
30  alt4.aspmx.l.google.com

Google uses five MX records with staggered priorities. The two pairs at priority 20 and 30 provide round-robin load balancing within each tier.

Microsoft 365

10  example-com.mail.protection.outlook.com

Microsoft typically uses a single MX record. The hostname follows the pattern {domain-with-dashes}.mail.protection.outlook.com.

Amazon SES

10  inbound-smtp.us-east-1.amazonaws.com

SES inbound uses a single region-specific MX record. The region in the hostname must match your SES configuration.

Self-hosted (Postfix / Dovecot)

10  mail.example.com
20  mail2.example.com

Self-hosted setups typically point MX records to servers running Postfix (SMTP) and Dovecot (IMAP/POP3). The MX hostnames must have their own A records resolving to the server IP addresses.

#Debugging email delivery

If email to your domain is bouncing or not arriving, MX records are the first thing to check.

No MX records found — SMTP falls back to the domain's A record (RFC 5321), but many sending servers treat a missing MX as a misconfiguration and refuse delivery. Always set explicit MX records.

Wrong priority order — if your backup server has a lower priority number than your primary, it receives all the mail. Verify that your primary server has the lowest number.

MX points to a CNAME — RFC 2181 forbids MX records from pointing to a CNAME. The MX target must resolve directly via an A or AAAA record. Some mail servers tolerate this, many do not.

Propagation delay — DNS changes take time to propagate. If you recently updated MX records, allow 1-48 hours depending on the previous TTL value.

You can also verify from the command line:

# macOS / Linux
dig MX example.com
 
# Windows
nslookup -type=mx example.com

#Open source

This tool is powered by @azin-tech/mini-tools, an open-source developer toolkit. View source on GitHub.