MX Record

An MX (Mail Exchanger) record is a DNS record that tells the internet which mail servers accept incoming email for a domain. Without MX records, other mail servers have no way to know where to deliver messages addressed to your domain.

How MX Records Work

When a sending mail server needs to deliver an email to user@example.com, it queries DNS for the MX records of example.com. The response contains one or more hostnames — each paired with a priority value — identifying which servers can accept the message. The sending server then attempts an SMTP connection to the mail server with the lowest priority number first.

The MX record itself contains two fields: a priority (a 16-bit unsigned integer) and an exchange (a fully qualified domain name pointing to the mail server). The exchange value must resolve to an A or AAAA record — it cannot be a CNAME.

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

Priority Values and Failover

MX priority is a preference number — lower values are tried first. A sending server will attempt delivery to the lowest-priority MX host and only move to a higher-priority (larger number) host if the primary server is unreachable or returns a temporary failure. This allows you to configure primary and backup mail servers for the same domain.

Multiple MX records with the same priority value are treated as equals: the sending server may choose among them in any order, providing load distribution rather than strict failover. Many hosted email providers (Google Workspace, Microsoft 365) assign the same priority to several MX hosts for exactly this reason.

If a domain has no MX records, RFC 5321 specifies that the sending server should fall back to the domain's A record as an implicit MX with priority 0. In practice, many mail operators discourage relying on this fallback, and a null MX record (RFC 7505) can explicitly signal that a domain accepts no mail.

Interaction with SPF and DMARC

MX records determine where email is received; SPF and DMARC govern which servers are authorized to send email from your domain. The two work at different stages of mail delivery. SPF is checked by the receiving server against the envelope sender's domain; DMARC adds a policy layer that uses SPF and DKIM alignment to decide what to do with failing messages.

Your MX hosts need not be included in your SPF record unless those same servers also send outbound email. Many organizations have separate inbound (MX) and outbound (SMTP relay) infrastructure, and SPF only needs to authorize the outbound servers.

Common Mistakes

• MX pointing to a CNAME. The DNS specification prohibits MX records from referencing a CNAME. Doing so creates undefined behavior: some sending servers will refuse delivery, others may follow the CNAME chain but the result is not guaranteed. Always point MX records directly to A/AAAA hostnames.
• No backup MX. If your only MX host goes down, sending servers will queue messages and retry for a period before bouncing. Adding a secondary MX with a higher priority number gives senders an alternative delivery path during outages.
• Forgetting to update SPF when changing mail providers. When you add a new MX host (often a new mail provider), you must also update your SPF record to authorize that provider to send on your behalf, or outbound mail from them will fail SPF checks.
• Duplicate or stale MX records. Old MX records left over from a previous mail provider can cause senders to attempt delivery to a server that no longer accepts your mail, resulting in delayed or bounced messages.

Look up MX records with the DNS tool →