An MX record names the mail server that accepts email for a domain, together with a priority number. Each MX target must be a hostname that has an A or AAAA record; it must not be an IP address and must not be a CNAME (RFC 2181 §10.3). Use the hostnames and priorities your mail provider documents, publish them at the domain apex (@) for addresses like [email protected], and check the result with the MX lookup.
example.com. 3600 IN MX 10 mail1.provider.example.
example.com. 3600 IN MX 20 mail2.provider.example.
The hostnames are placeholders; take real values from your provider’s documentation or from the provider setup check, which compares your MX with the expected hosts. Full walk-throughs: Google Workspace, Microsoft 365, Zoho Mail.
Priority
RFC 5321 §5.1: a sender tries MX hosts in order of preference, and lower numbers are more preferred. If several records share a preference, the sender picks among them at random to spread load. Backup servers get higher numbers (20, 30). The absolute values carry no meaning, only their order. Providers that publish a single host often use 0 or 10.
If a domain has no MX at all, RFC 5321 §5.1 says the sender falls back to the domain’s own A/AAAA record as an “implicit MX”. That is why a domain that accepts no mail should say so explicitly (see below).
What the target may be
| Target | Allowed? | Why |
|---|---|---|
| Hostname with A/AAAA | Yes | Normal case |
| IP address | No | The data field is a domain name; an IP is read as a hostname and fails to resolve |
| Hostname that is a CNAME | No | RFC 2181 §10.3: the name must not be an alias |
| Hostname without address records | No | Delivery fails; the name must have at least one A or AAAA |
. with preference 0 | Only as null MX | RFC 7505 |
RFC 5321 §5.1 describes how to process a CNAME if one is found, but also says an MX data field that resolves to a CNAME lies outside its scope, so behavior is not guaranteed across senders. Avoid it. If your provider gives you a CNAME-style name, resolve it and use the final hostname only if the provider says that is supported.
Also note RFC 2181 §10.1: a name with a CNAME cannot hold other records, so the MX must not sit on a name that is a CNAME. This is why a CNAME at the zone apex breaks mail; if your registrar’s website redirect uses one at @, it conflicts with MX.
Apex versus subdomain
MX records apply to exactly the name they sit on. An MX on example.com handles [email protected], not [email protected]. To receive mail at a subdomain, create MX records at that subdomain. Subdomains do not inherit the parent’s MX. Wildcard MX records exist but are easy to get wrong; list the subdomains you need.
Null MX: a domain that receives no mail
If a domain never receives email, publish a single null MX so senders learn at once and do not retry for days (RFC 7505 §3):
example.com. 3600 IN MX 0 .
A domain with a null MX must not have any other MX record. Senders then reject with 556 5.1.10 Recipient address has null MX. Pair it with v=spf1 -all if the domain also never sends (see How to create an SPF record).
Migrating with TTL
- Lower the TTL on the existing MX records to 300 seconds, and wait for the old TTL to expire (if the old TTL was 24 hours, wait 24 hours).
- Add the new provider’s MX records, and remove the old ones in the same change. Mixing old and new hosts at equal priority sends some mail to each.
- Send tests from an outside address and watch both mailboxes. Senders that cached the old answer keep using the old server until their cached TTL expires.
- Keep the old mailboxes for a few days, then restore a longer TTL (3600 or higher).
Setting new MX at a higher priority number than the old ones does not make a staged migration: the old server accepts mail and the new one is used only as a fallback.
FAQ
Can I use an IP address in an MX record?
No. The value is a hostname. Create an A record for a name such as mail.example.com and point the MX at that name.
Does MX affect sending mail? No. MX controls inbound delivery. Outbound authentication uses SPF, DKIM and DMARC.
Why do I see MX records I did not add? Your DNS host or registrar may add default records. Remove them if they point to a different mail provider.
Sources
- RFC 5321, §5.1 Locating the target host: https://www.rfc-editor.org/rfc/rfc5321#section-5.1
- RFC 2181, §10.3 MX and NS records: https://www.rfc-editor.org/rfc/rfc2181#section-10.3
- RFC 2181, §10.1 CNAME resource records: https://www.rfc-editor.org/rfc/rfc2181#section-10.1
- RFC 7505, A “Null MX” No Service Resource Record for Domains That Accept No Mail: https://www.rfc-editor.org/rfc/rfc7505