MX Record Complete Guide: How Mail Exchange Records Work, Priority & Troubleshooting

What Are MX Records and How Do They Work?

MX (Mail Exchange) records are DNS resource records that tell the world where to deliver email for your domain. When someone sends an email to you@example.com, the sender's mail server (MTA) performs a DNS query for the MX records of example.com. It then connects to the returned mail server hostname on TCP port 25 and delivers the message using SMTP.

Without MX records, your domain cannot receive email. Well, technically RFC 5321 defines a fallback to the A record — but modern mail servers largely ignore this fallback, meaning in practice, missing MX records = no email delivery.

Anatomy of an MX Record

Each MX record has exactly two data fields:

• Priority (Preference): An unsigned 16-bit integer. Lower = higher priority. Range: 0–65535.
• Hostname: A fully qualified domain name (FQDN) of the mail server. Must resolve to an A or AAAA record. Never an IP address directly.

Example MX records for a Google Workspace domain:

example.com.  3600  IN  MX  1   ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  5   ALT1.ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  5   ALT2.ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
example.com.  3600  IN  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

MX Priority in Detail

For a deep dive into how sending servers actually behave around priority values — including equal-priority load distribution and how to assign values across primary/backup hosts — see our dedicated guide, MX Priority Explained. For diagnosing delivery problems specifically, see MX Troubleshooting Guide.

The sending MTA always tries the lowest-priority-number host first (ASPMX.L.GOOGLE.COM at priority 1). If that server is unreachable (connection refused, timeout, TLS failure), the sender falls back to the next lowest priority. If two records share the same priority value (e.g. both ALT1 and ALT2 at priority 5), the sender chooses between them at random — this is MX-level load balancing.

This hierarchical fallback system means: a domain with only one MX record has zero email redundancy. If that server goes down for maintenance, all inbound email delivery fails until the server recovers (senders will retry for 72–96 hours before bouncing). Professionally managed domains always have 2+ MX records.

Diagnosing Email Delivery Problems with MX Lookup

The MX Lookup tool is the first step in diagnosing inbound email failures. Common issues found via MX lookup:

• No MX records: Domain cannot receive email. Add MX records in your DNS provider.
• MX points to wrong hostname: After migration, old MX records still point to the previous mail server. Update DNS and wait for TTL.
• MX hostname doesn't resolve: The MX hostname has no A record — delivery fails with "host not found". Verify the MX hostname has a valid A record.
• High TTL blocking updates: If you changed MX records but email still goes to the old server, the TTL hasn't expired yet. Use our DNS Propagation tool to check global propagation status.
• Null MX on sending-only domain: A domain that only sends (never receives) email should have a null MX record (RFC 7505) — 0 . — to signal this explicitly and prevent mail queuing.

MX Records and Email Authentication

MX records interact with SPF authentication via the mx mechanism. v=spf1 mx -all means: authorize all IP addresses that the domain's MX hostnames resolve to. This is convenient — you don't need to list individual IPs — but it means your SPF policy implicitly changes whenever your MX records change. Use our SPF Lookup tool to verify SPF is configured correctly alongside your MX records.

DMARC builds on both SPF and DKIM. If your DMARC policy is p=reject, a failing SPF or DKIM check (combined with DMARC alignment failure) causes email to be rejected. Incorrect MX records won't affect outbound DMARC, but they mean you won't receive the DMARC aggregate reports (RUA) that tell you whether your outbound email is passing authentication.

MX Record TTL Best Practices

TTL (Time to Live) is how long DNS resolvers cache your MX record before re-querying. A typical TTL is 3600 seconds (1 hour) or 86400 (24 hours). For stable production domains, higher TTLs reduce DNS load. For upcoming changes:

• 24–48 hours before migration: lower MX TTL to 300 seconds (5 minutes)
• Perform the migration and update MX records
• After confirming email delivery is working on new servers, restore TTL to 3600+

How to Perform an MX Lookup Manually

On Linux/Mac: dig MX example.com +short. On Windows: Resolve-DnsName example.com -Type MX. Both return the priority and hostname for each MX record. Our MX Lookup tool replicates this in your browser with provider detection, priority visualisation, and raw DNS response.

Related Tools

Verify email authentication with SPF Lookup. Check full DNS records with DNS Lookup. Validate email addresses end-to-end with Email Checker. Read the companion guide: SPF Record Complete Guide. Also see SPF vs DKIM vs DMARC.