An MX record (mail exchanger record) is a DNS record that tells the rest of the internet which server accepts email for your domain. When someone sends a message to you@example.com, the sending server looks up the MX records for example.com, ranks them by preference, and connects to the lowest-numbered host to deliver the mail. Without a correct MX record, inbound email either bounces or silently disappears.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
MX records govern one direction only: mail coming in. They say nothing about which servers are allowed to send on your behalf, which is the job of SPF, DKIM, and DMARC. Confusing these two concerns is one of the most common sources of trouble in email setup, so it is worth being precise about what an MX record does and does not do.
What an MX record actually contains
An MX record has two parts: a preference value (usually called priority) and a hostname that points at the receiving mail server. In zone-file notation it looks like this:
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
Reading left to right: the domain the record covers, the TTL in seconds, the class (IN), the type (MX), the preference value, and the target hostname. The target must resolve to an A record (IPv4) or AAAA record (IPv6), because SMTP ultimately needs an IP address to open a connection.
The preference value is an unsigned 16-bit integer, so it ranges from 0 to 65535. A lower number means higher priority. Sending servers always try the lowest preference value first, which is the opposite of what intuition suggests, so 10 is preferred over 20.
How a receiving server gets chosen
When a sending mail server has a message to deliver, it runs this sequence:
- Query DNS for the recipient domain's MX records.
- Sort the returned records by preference value, lowest first.
- Attempt SMTP delivery to the lowest-preference host.
- If that host is unreachable or returns a temporary failure, move to the next preference value and retry.
This is how failover works. A primary mail server at preference 10 handles normal traffic, and a backup at 20 only receives mail when the primary is down. Once the primary recovers, a well-behaved backup forwards the queued mail back to it. The backup is only useful if it knows how to relay to the primary; a secondary MX that cannot reach your real mailboxes just becomes a spam magnet, since spammers deliberately target higher-preference hosts hoping they filter less strictly.
When two or more MX records share the same preference value, the sending server picks among them at random. This spreads inbound load roughly evenly across the hosts, a crude but effective form of load balancing that RFC 974 and later RFC 5321 describe. It is not precise, since each sender chooses independently, but across many senders the distribution evens out.
| MX configuration | Behavior |
|---|---|
Different preference values (10, 20) | Failover: the lower value is used first, the higher only as backup |
Equal preference values (10, 10) | Load balancing: senders choose randomly between them |
A special case is the null MX record defined in RFC 7505: a single MX record with preference 0 and a lone dot (.) as the target. It explicitly declares that a domain accepts no mail at all, and a domain that publishes it must not publish any other MX record. That is the correct signal for a domain you never want to receive email on, such as a parked or send-only domain (see DMARC for parked and non-sending domains).
MX vs A vs PTR
These three record types are often confused because they all involve mail servers, but each answers a different question.
| Record | Question it answers | Direction | Lives in |
|---|---|---|---|
MX | Which host accepts mail for this domain? | Inbound | The recipient domain's zone |
A / AAAA | What IP address does this hostname have? | Both | The mail server's zone |
PTR | What hostname owns this IP address? | Outbound | The reverse DNS zone (in-addr.arpa) |
An MX record points to a hostname, the A record turns that hostname into an IP, and the PTR record does the reverse lookup that many receivers run on your sending IP. Receivers check that the PTR resolves to a hostname whose A record points back to the same IP, a match known as forward-confirmed reverse DNS. MX is what lets mail reach you. PTR is what helps your outbound mail pass reputation checks at the far end. For a deeper look at reverse DNS and why receivers care about it, see the guide on what a PTR record is.
Common MX record mistakes
A handful of errors account for most broken inbound-mail setups.
Pointing an MX at a CNAME. RFC 2181 and RFC 5321 prohibit the target of an MX record from being a CNAME. The hostname in an MX record must resolve directly to an A or AAAA record. Strict receivers, including some large providers, refuse to deliver when the MX target is an alias, and even lenient ones incur extra lookups and potential loops. If your mail provider gives you a hostname, verify it is a real address record, not an alias.
Missing or wrong trailing dot. In zone-file notation, a hostname ending in a dot is fully qualified. Without the trailing dot, the DNS server appends the zone's origin, so mail.example.com written without the dot inside the example.com zone becomes mail.example.com.example.com., which does not exist. Most hosted DNS panels hide this by supplying the fully qualified name for you, but if you edit raw zone files, the trailing dot matters.
Using an IP address as the target. An MX target must be a hostname, never a literal IP. If your only reference is an IP, create an A record for a hostname first, then point the MX at that hostname.
Duplicate or conflicting records. Two providers each publishing MX records for the same domain, or leftover records from an old host, cause mail to route to the wrong place. When you migrate email providers, remove the old MX records rather than leaving them alongside the new ones.
Assuming MX affects sending. Changing your MX record does nothing for your outbound authentication. If recipients reject your outgoing mail, the fix is in SPF, DKIM, or DMARC, not MX.
MX is inbound, SPF is outbound
This is the distinction to lock in. Your MX record tells other servers where to send mail addressed to you. Your SPF record tells other servers which IP addresses are permitted to send mail as you. They are independent, and getting one right does not help the other.
There is one narrow overlap worth knowing: the SPF mx mechanism. An SPF record can include the token mx, which authorizes the hosts listed in your MX records to also send mail. This is convenient when your inbound and outbound servers are the same machine, but each mx mechanism costs a DNS lookup against SPF's limit of 10, and exceeding that limit produces a PermError that fails SPF outright. Use it deliberately rather than by default. For the full picture of which records email needs, read what DNS records do I need for email, and for how the outbound side fits together, see SPF, DKIM and DMARC explained.
MX records are MX-type DNS entries; the authentication records that protect your outbound mail are TXT-type entries. If the difference between record types is fuzzy, the guide on what a DNS TXT record is covers where SPF and DMARC actually live and why they share one record type.
Verifying your MX records
You can inspect MX records from the command line:
dig MX example.com +short
This returns each preference value and target hostname. Confirm that every target resolves to an address record, that the preference values reflect the failover or load-balancing behavior you intend, and that no stale records from a previous provider remain. If you are unsure who controls your DNS zone in the first place, the guide on how to find your DNS host walks through identifying it.
Frequently asked questions
Can a domain have multiple MX records?
Yes, and most production domains do. Multiple records with different preference values give you failover, and multiple records with the same preference value spread inbound load. Sending servers use the preference values to decide the order in which they attempt delivery.
What happens if a domain has no MX record?
Under RFC 5321, if no MX record exists, sending servers fall back to the domain's A or AAAA record and attempt delivery there, treating it as an implicit MX at preference 0. This fallback is fragile and easy to misconfigure, so publishing an explicit MX record is always the correct approach for any domain that receives mail.
Does changing my MX record affect SPF or DMARC?
No. MX records control inbound mail routing only. SPF, DKIM, and DMARC govern outbound authentication and live in separate TXT records. Editing your MX record will not change how recipients authenticate mail you send.
Why does the MX target need a trailing dot?
In zone-file syntax, a trailing dot marks a hostname as fully qualified. Omit it and the DNS server appends the zone origin, producing a broken name like mail.example.com.example.com.. Most hosted DNS interfaces handle this for you, but it matters when editing raw zone data.
Your MX records decide whether mail reaches you, and a single misplaced dot or CNAME target can quietly break delivery. Run a free scan with SPFWise to check your MX setup alongside your SPF, DKIM, and DMARC records, and catch inbound and outbound problems before they cost you email.