What is an MX Record? Mail Exchange DNS Explained

What is an MX record?

An MX record (Mail Exchange record) is a DNS record that names the mail servers responsible for receiving email sent to your domain. It is the address label on your domain's mailbox: when someone sends mail to you@yourdomain.com, their server reads your MX records to decide where to deliver it.

MX records control incoming mail only. They say nothing about who is allowed to send mail as your domain — that is what SPF, DKIM, and DMARC are for. Publishing MX records does not protect you from spoofing.

How does an MX record work?

An MX record pairs a preference number with a mail server hostname. In zone-file form:

yourdomain.com. 3600 IN MX 10 mail1.yourdomain.com.

That reads: mail for yourdomain.com goes to mail1.yourdomain.com, at preference 10, with a TTL of 3600 seconds.

When a sending mail server has a message for your domain, it:

1. Queries DNS for your domain's MX records.
2. Sorts the results by preference. RFC 5321 states that lower numbers are more preferred than higher ones — so preference 10 is tried before preference 20.
3. Attempts delivery to the most-preferred host. If that host is unreachable, it moves down the list.
4. Queues and retries if nothing answers, rather than bouncing immediately.

If two records share the same preference, the sending server must randomise between them, which spreads load across both.

What the records actually look like

Google Workspace now uses a single MX record: smtp.google.com at priority 1. Domains set up before 2023 may still have the older five-record set whose hostnames begin with aspmx — Google states these continue to work and need no change.

Microsoft 365 uses one record following the pattern yourdomain-com.mail.protection.outlook.com, at a priority lower than any other MX record on the domain. The exact hostname is generated per tenant, so copy it from the Microsoft 365 admin centre rather than guessing.

Always take the exact values from your provider's admin console. Check what is currently published with the MX lookup tool.

Rules that trip people up

An MX record must point to a hostname with an A or AAAA record — never a CNAME. RFC 5321 requires the MX target to return at least one address record, and notes that a target which returns a CNAME "lies outside the scope of this Standard." Some resolvers tolerate it; the behaviour is undefined, so do not rely on it.

An MX target is a hostname, never an IP address. If you only have an IP, publish an A record first and point the MX at that name.

No MX record does not mean no mail. RFC 5321 specifies that if an empty list of MX records is returned, the sending server treats the domain's address record as an implicit MX with preference 0. Deleting your MX records therefore does not stop inbound mail — it silently redirects it at whatever your A record points to, which is usually your web server.

To genuinely accept no mail, publish a null MX. RFC 7505 defines this as a single record with preference 0 and the root label as its target:

yourdomain.com. IN MX 0 .

This tells senders the domain accepts no email at all, so they fail immediately instead of retrying for days. A domain advertising a null MX must publish no other MX record. Use it on parked and brand-protection domains — and pair it with v=spf1 -all and a DMARC record at p=reject, so nobody can send as the domain either.

Why MX records matter

• Reliable delivery. Correct records get mail to the right server rather than into a black hole.
• Failover. Multiple records at different preferences give you a backup path when the primary is down.
• Portability. You can move mailbox providers by changing MX records, without touching web hosting.
• A prerequisite, not a control. Authentication sits alongside MX, not inside it. Check all of it at once with the Email Security Score tool.

Common issues with MX records

Why is inbound mail still going to the old provider after I changed MX records?

Because a change is not "propagated" on a global timer — it is governed by the TTL of the record you replaced. Resolvers that cached the old record keep serving it until their copy expires, which takes at most that TTL. With a 300-second TTL, everyone sees the change within about five minutes; with a 24-hour TTL, it can take a day. The widely repeated "up to 48 hours" figure is a conservative legacy buffer, not a technical rule. Lower the TTL a day or two before a planned migration, then raise it again afterwards.

Why did mail stop after I deleted my MX records?

It probably did not stop — it went somewhere worse. With no MX records, senders fall back to your domain's A record and try to deliver there, under the implicit MX rule. Mail ends up aimed at your web server, which usually refuses it. If a domain should receive no mail, publish a null MX rather than deleting the records.

Why do I see "MX points to a CNAME" warnings?

A DNS provider that flattens or aliases the MX target will trigger this. It violates RFC 5321's requirement that the MX target return an address record. Point the MX at a hostname with a real A/AAAA record instead. It may appear to work today and break against a stricter receiver tomorrow.

Why is our backup mail server receiving all the spam?

Because it is the least-preferred host, and spam senders deliberately target it — backup servers historically ran weaker filtering. Either apply the same filtering to every host in your MX set, or remove the backup entirely. Modern mailbox providers queue and retry on their own, so a secondary MX is rarely worth the exposure.

Related reading

• What are DMARC, DKIM, and SPF?
• What is a DNS?
• What is email deliverability?