# What is an MX Record? Mail Exchange DNS Explained > What an MX record is, how mail servers use priority to route email, the exact records for Google Workspace and Microsoft 365, and how to check yours. ## What is an MX record? An [MX record](/tools/mx) (Mail Exchange record) is a [DNS](/learning/what-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](/learning/what-is-spf), [DKIM](/learning/what-is-dkim), and [DMARC](/learning/what-is-dmarc) are for. Publishing MX records does not protect you from [spoofing](/learning/what-is-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](/learning/what-is-an-mta) 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 ![MX record examples](/images/figures/mx-record-examples.webp) **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](/tools/mx). ## 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](/tools/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. ## Frequently asked questions ### Can one domain have MX records pointing at two different providers? Technically yes, but do not. Whichever host answers first accepts the message, so mailboxes end up split unpredictably across both providers. Migrations should cut over, not run in parallel. ### Does the priority number affect deliverability or reputation? No. It only orders delivery attempts. A lower number is tried first; the value itself carries no weight with spam filters, and there is no advantage to using 1 over 10. ### Do subdomains need their own MX records? Only if they receive mail. `mail.yourdomain.com` needs its own MX record if messages are addressed to it — there is no inheritance from the parent domain. Subdomains that never receive mail should publish a null MX. ### Does changing MX records affect SPF, DKIM, or DMARC? Not directly, but changing mailbox providers almost always does. A new provider sends from different servers and signs with different DKIM keys, so SPF and DKIM must be updated in the same migration. Verify once the cutover is complete. ### What is the `mx` mechanism in an SPF record? It authorises the hosts listed in your MX records to *send* mail for your domain. It is a convenience for setups where the same servers send and receive, and it counts against SPF's ten-lookup limit. Most cloud mailbox setups do not need it. ## Related reading - [What are DMARC, DKIM, and SPF?](/resources-post/what-are-dmarc-dkim-and-spf) - [What is a DNS?](/learning/what-is-a-dns) - [What is email deliverability?](/learning/what-is-email-deliverability)