MX Record

For an in-depth treatment, see the dedicated guide: What is an MX Record? This page is a quick reference for the term.

Format and priority

Each MX record has two parts: a priority value (an unsigned 16-bit integer) and a target hostname.

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

Senders try the lowest-priority value first (lower number = higher preference). If priority 10 is unreachable, fall back to priority 20. Records with equal priority are tried in random order — useful for load balancing.

What happens during mail delivery

1. Sender looks up MX records for the recipient's domain.
2. Sorts them by priority (ascending).
3. Resolves the hostname of the lowest-priority MX to A/AAAA records.
4. Connects to that IP on port 25.
5. If connection or SMTP transaction fails with a temporary error (4xx), tries the next MX.
6. If permanent error (5xx), bounces immediately without trying other MX records.

Common patterns

Google Workspace

example.com.    IN MX  1   aspmx.l.google.com.
example.com.    IN MX  5   alt1.aspmx.l.google.com.
example.com.    IN MX  5   alt2.aspmx.l.google.com.
example.com.    IN MX  10  alt3.aspmx.l.google.com.
example.com.    IN MX  10  alt4.aspmx.l.google.com.

Five MX records across Google's mail infrastructure for redundancy.

Microsoft 365

example.com.    IN MX  0  example-com.mail.protection.outlook.com.

Microsoft uses a single MX record; their backend handles redundancy.

Self-hosted

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

Two mail servers — primary and backup, both at your own domain.

Null MX (no mail accepted)

example.com.    IN MX  0  .

Standardized in RFC 7505. Signals that this domain does not accept email; senders should bounce immediately.

Required properties

• MX target must be a hostname (FQDN), not an IP address.
• MX target must NOT be a CNAME (strict RFC; some receivers tolerate it but many don't).
• MX target hostname must resolve to A or AAAA records.
• Mail servers should have matching reverse DNS (PTR) records for deliverability.

Common problems

• No MX record. RFC 5321 allows fallback to the domain's A/AAAA record (implicit MX), but this is fragile. Always publish an explicit MX.
• MX points at a CNAME. Some mail servers reject delivery in strict-RFC mode. Point at a hostname with direct A/AAAA records.
• MX hostname has no A/AAAA. Senders cannot resolve it; mail fails.
• Stale backup MX. A backup MX that doesn't actually know how to handle your mail accepts messages and bounces them later, or worse, queues them indefinitely.
• Priority numbers in wrong order. Confusion about "lower is higher priority" leads to backup MX getting tried first.

Related records for email

MX is just the routing layer. Modern email also requires:

• SPF — list of IPs authorized to send on behalf of the domain.
• DKIM — cryptographic signature on outgoing messages.
• DMARC — policy tying SPF and DKIM to the visible From: domain.
• Reverse DNS (PTR) on the sending mail server's IP, matching the hostname used in SMTP HELO.

Without all of these properly configured, your mail will be filtered as spam or rejected outright by Gmail, Yahoo, and Microsoft. See SPF, DKIM, DMARC: How Email Authentication Works.

Frequently Asked Questions

What is the priority value in an MX record?

Priority is a number indicating which MX server to try first. Lower number = higher preference. A record with priority 10 is tried before priority 20. When multiple MX records share the same priority, senders pick one at random for load balancing. The naming is counterintuitive — think of it as "order of attempts" rather than "importance."

Can an MX record point to an IP address?

No. RFC 5321 explicitly requires MX records to point at a hostname, not an IP. The hostname must resolve to A or AAAA records but cannot itself be a CNAME (strict RFC interpretation). If your mail provider gave you an IP, you need to ask them for the hostname instead, or create a regular A record and point MX at that hostname.

What is a null MX record?

A null MX record (priority 0, target ".") tells senders that the domain does not accept email at all. Specified by RFC 7505. Used by domains that exist for purposes other than mail — domain redirects, web-only properties — to make rejection immediate rather than letting senders fall back to implicit MX via A records and timeout.

How long does an MX change take to propagate?

As long as the previous record's TTL. If MX TTL was 3600 seconds (1 hour), the change propagates worldwide within ~1 hour. The standard practice for planned MX changes is to reduce TTL to 300 seconds (5 minutes) 48 hours before the change, then make the change, then raise TTL back. This minimizes the window during which different resolvers return different MX values.