An MX record, short for mail exchanger record, is the DNS record type that specifies which mail servers accept email for a domain and in what order sending servers should try them. When a message is sent to an address such as user@example.com, the sender’s mail server looks up the MX records of example.com to find where to deliver it.
Among DNS records, MX is one of the original types defined for the domain name system, and its use in mail routing is specified in the SMTP standard. Each MX record contains two values: a preference number and the host name of a mail server. The record governs only incoming mail; outgoing mail and sender authentication rely on other records, mainly TXT.
Structure of an MX record
An MX record follows the standard resource record format with owner name, TTL, class, type and data. A typical entry in zone file syntax reads example.com. 3600 IN MX 10 mx1.example.com., meaning that mail for the domain should go to mx1.example.com with preference 10.
| Field | Example value | Meaning |
|---|---|---|
| Owner name | example.com. | Domain that receives the mail |
| TTL | 3600 | Seconds a resolver may cache the record |
| Class and type | IN MX | Internet class, mail exchanger type |
| Preference | 10 | Priority from 0 to 65535, lower is preferred |
| Exchange | mx1.example.com. | Host name of the receiving mail server |
The exchange field must contain a host name, never an IP address, and that host name must have its own A or AAAA record. Mail standards also state that the exchange should not be an alias defined by a CNAME, because some mail software rejects or mishandles such configurations.
How preference values route mail
The preference value decides the delivery order. A sending server sorts the MX records from lowest to highest preference and tries the lowest first. If that server is unreachable or returns a temporary error, it moves to the next value.
| Configuration | Example values | Resulting behavior |
|---|---|---|
| Single mail server | 10 mx1 | All mail goes to one host |
| Primary and backup | 10 mx1, 20 mx2 | Backup receives mail only when the primary fails |
| Load sharing | 10 mx1, 10 mx2 | Senders choose randomly between equal values |
| Hosted mail service | Provider-specified values | Provider controls its own failover |
| Null MX | 0 and a single dot | Domain declares that it accepts no mail |
The absolute numbers carry no meaning; only their relative order matters. Values of 10, 20 and 30 are customary because they leave room to insert servers later. Equal values create a simple form of load distribution, although sender behavior is not perfectly uniform.
MX compared with other DNS records used for email
Email delivery depends on several DNS record types working together, and the MX record is only the routing part. Confusing their roles is a frequent source of delivery problems.
| Record | Purpose | Affects |
|---|---|---|
| MX | Names the servers that receive mail | Inbound routing |
| A or AAAA | Gives the IP address of each mail server | Connection to the MX host |
| TXT with SPF | Lists servers allowed to send for the domain | Outbound authentication |
| TXT with DKIM key | Publishes the public key for message signatures | Outbound authentication |
| TXT with DMARC | States the policy for failed authentication | Handling of spoofed mail |
| PTR | Maps a sending IP back to a host name | Reputation of outgoing servers |
A domain without any MX record is not automatically unable to receive mail. SMTP rules define an implicit MX: senders fall back to the domain’s own A or AAAA record. Domains that never receive mail should therefore publish a null MX record to stop senders from trying.
Configuring MX records in practice
Most MX changes happen when an organization moves to a new mail provider. The safest migrations plan the TTL in advance and keep the old service accepting mail for a period after the switch.
- Lower the TTL to 300 to 900 seconds a day or more before the change, so resolvers refresh quickly.
- Publish the new MX records exactly as specified by the provider, including the trailing dot in zone files where required.
- Keep the old mailboxes active for at least a few days, because some senders still use cached records.
- Update SPF, DKIM and DMARC at the same time if outgoing mail also moves.
- Raise the TTL again, typically to one hour or more, after the change is confirmed.
Senders do not give up after one failed attempt. SMTP servers queue and retry delivery for several days, often up to about five days, which means a short outage of all MX hosts usually delays mail rather than losing it.
Common MX mistakes and their symptoms
MX errors are often invisible to the domain owner, because outgoing mail keeps working while incoming mail silently bounces or delays.
| Mistake | Symptom | Fix |
|---|---|---|
| IP address in the exchange field | Rejected or failed delivery | Use a host name with A or AAAA records |
| MX target is a CNAME | Intermittent delivery failures | Point MX to the canonical host name |
| Old and new providers mixed | Mail split between two systems | Remove the obsolete records |
| Unprotected backup MX | Spam bypasses the primary filters | Apply the same filtering on every MX |
| Missing trailing dot in a zone file | Domain name appended twice | Write fully qualified names |
The short version
An MX record tells the rest of the internet where to deliver email for a domain. It works like the mailing address on a company’s sign: anyone who wants to send a letter looks it up first.
A domain can list several mail servers with a ranking. Senders try the top-ranked one first and use the others only if it does not answer, much like calling an office’s main number before trying the backup line.
Where it makes a difference
A law firm with 40 employees moves its email from an on-premises server to a hosted mail provider. Two days before the switch, the administrator lowers the TTL of the existing MX record from 86,400 to 300 seconds. On the migration evening, the old record pointing to the office server is replaced by the two MX records with different preference values given by the provider.
Within minutes, most new messages arrive at the hosted service, while a few senders with older cached data still deliver to the office server for several hours. Because the old server stays online for a week and forwards anything it receives, no client messages are lost. Afterward, the administrator raises the TTL to 3,600 seconds and removes the obsolete host.