MX Record: What It Is, How to Check It, and How to Set It Up

An MX (mail exchanger) record is a DNS record that tells other mail servers which hosts accept email for a domain. Each MX record carries a preference number, and senders try the lowest number first. MX controls where inbound mail goes. It does not control who is allowed to send mail from your domain.

RFC 1035 defines the two fields that matter: PREFERENCE, “a 16 bit integer which specifies the preference given to this RR among others at the same owner,” where “lower values are preferred,” and EXCHANGE, “a which specifies a host willing to act as a mail exchange for the owner name.”

What an MX record contains: six fields and four rules

Every MX record has a name, TTL, class, and type like any DNS record, followed by two values specific to MX: preference and exchange.

Field	Example	Meaning
Name	example.net.	The domain that receives mail (@ in most dashboards)
TTL	3600	Seconds a resolver may cache the answer
Class and type	IN MX	Internet class, MX record type
Preference	10	Priority, lower is tried first
Exchange	mail1.example.net.	Hostname of the mail server

In a zone file, one record looks like this (illustrative example):

example.net.    3600    IN    MX    10 mail1.example.net.
example.net.    3600    IN    MX    20 mail2.example.net.

A DNS dashboard shows the same data as separate inputs: Type MX, Name @, Priority 10, Value mail1.example.net, TTL 1 hour. Dashboards differ on the trailing dot, but in a raw zone file it matters. Per RFC 1035, “domain names that end in a dot are called absolute, and are taken as complete,” while a name without a dot is relative and gets the zone origin appended. Writing mail1.example.net without the dot in a raw zone file for example.net can produce mail1.example.net.example.net..

Four rules cause most real-world breakage:

1. The exchange is a hostname, not an IP address. RFC 1035 defines the exchange as a domain name. 10 192.0.2.25 is not a valid MX target.
2. The exchange must not be a CNAME. RFC 2181, section 10.3 says the domain name in an MX record “must not be an alias” and must have address records. RFC 5321, section 5.1 says a target that returns a CNAME “lies outside the scope of this Standard.”
3. The target needs an A or AAAA record. RFC 5321 requires that the name “MUST return at least one address record (e.g., A or AAAA RR).”
4. Equal preferences mean load spreading. When several destinations share a preference, the sender “MUST randomize them to spread the load across multiple mail exchangers,” per RFC 5321.

How a sending server uses MX records to find your mailbox

When someone emails [email protected], the sender’s server does not deliver to example.net directly. It follows the lookup in RFC 5321, section 5.1:

1. Query DNS for MX records on example.net.
2. Sort them by preference, lowest first.
3. Resolve each exchange to A/AAAA addresses and try them in order until a delivery succeeds. RFC 5321 says the sender should try at least two addresses when they exist.
4. If the answer is a temporary DNS error, queue the message and retry later. If the domain does not exist, report an error.

Two special cases sit outside the normal flow. First, the implicit MX: if the MX lookup returns an empty list, RFC 5321 says the address “is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.” A domain with only an A record can still receive mail on that host. The fallback applies only when no MX records exist at all. Once one MX record is present, the sender “MUST NOT utilize any address RRs associated with that name” except through the MX records.

Second, Null MX. RFC 7505 lets a domain declare that it accepts no mail by publishing a single MX record with preference 0 and the root label . as the exchange: 0 .. The RFC adds that “a domain that advertises a null MX MUST NOT advertise any other MX RR.” Senders can then fail immediately instead of falling back to the A/AAAA record. For more on the SMTP conversation that follows the lookup, see how SMTP delivery works.

How to check MX records from the command line

Replace example.com with your own domain in each command.

dig (macOS, Linux):

dig example.com MX +short

+short prints only the answer data. For the documentation domain example.com, which publishes a Null MX, this returned:

0 .

The full form shows the TTL, the resolver that answered, and the response status:

dig MX example.com

Trimmed output from a real run:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24052
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.			IN	MX

;; ANSWER SECTION:
example.com.		300	IN	MX	0 .

;; SERVER: 100.100.100.100#53(100.100.100.100)

SERVER is the resolver that answered, and the answer line reads name TTL class type preference exchange. status: NOERROR with an empty ANSWER section means the domain exists but has no MX record. NXDOMAIN means the domain does not exist.

nslookup (Windows, macOS, Linux):

nslookup -type=mx example.com

PowerShell:

Resolve-DnsName -Name example.com -Type MX

-Type MX and -Server are documented parameters of Resolve-DnsName.

Check a specific resolver, then the authoritative server

Your default resolver may hold a cached answer. Ask a public resolver directly to see what the wider internet sees:

dig example.com MX +short @1.1.1.1
dig example.com MX +short @8.8.8.8
nslookup -type=mx example.com 1.1.1.1

To read the source of truth, find the domain’s nameservers, then query one with recursion off:

dig example.com NS +short
dig example.com MX +norecurse @hera.ns.cloudflare.com

The second command returned flags: qr aa in a real run. The aa flag means the answer is authoritative. If the authoritative server shows your new MX record but public resolvers still show the old one, the change is saved and you are waiting on caches, which expire according to the record’s TTL.

How to set up or change MX records without losing mail

A first-time setup is mostly steps 1 and 4. A migration needs all seven, because mail keeps arriving at the old provider until resolvers pick up the new records.

1. Get the exact values from your mail provider. Copy the hostnames and priorities from their admin console or docs. Do not guess.
2. Lower the TTL on the existing MX records (for example to 300 seconds) at least one full old-TTL period before the change. If the current TTL is 3600, do it an hour or more ahead. Caches then expire quickly when you switch.
3. Create mailboxes at the new provider first. Microsoft states this directly: add users before updating the MX record “to ensure that email continues to work without interruption.”
4. Publish the new MX records and remove the old ones. Or, during a short overlap, give the new records a lower preference number than the old ones.
5. Keep the old mailboxes active until dig against public resolvers returns only the new values and no new mail is arriving at the old provider. Mail already delivered stays where it was, unless you migrate it.
6. Restore a longer TTL once the change is stable.
7. Send test messages from an outside account and check the headers to confirm which server accepted them (see reading email headers).

What Google Workspace, Microsoft 365, and Amazon SES publish

Values below come from each vendor’s current documentation. Confirm against your admin console before you copy them, since providers change these.

Provider	MX host	Priority	Notes
Google Workspace	smtp.google.com	1	One record is enough. Domains set up before 2023 may use older aspmx values, which need no change if mail works. Google says to remove any other MX records.
Microsoft 365	<MX token>.mail.protection.outlook.com	Lower than any other MX record	Your token is shown in the admin center. Microsoft documents a TTL of 3600 and says a single MX record “removes many potential problems.”
Amazon SES (custom MAIL FROM subdomain only)	feedback-smtp.<region>.amazonses.com	10	For bounce routing, not for your mailboxes. Publish exactly one MX record on that subdomain.

Google notes that “it can take up to 72 hours for the new MX records to be recognized.” Treat that as the upper bound for troubleshooting, and expect most changes to appear sooner once caches expire.

MX records and sending: mostly unrelated, with three exceptions

MX decides where mail arrives. Who may send as your domain is decided by SPF, DKIM, and DMARC. You can send from a domain that has no MX record at all, and a perfect MX setup does nothing for your inbox placement. For the wider picture, see email deliverability best practices.

Three places where MX and sending do touch:

• The SPF mx mechanism. In an SPF record, mx authorizes the hosts named in the domain’s MX records to send mail. RFC 7208, section 5.4 describes it as an MX lookup on the target name, then an address lookup on each MX name, and a match if any returned address equals the connecting IP. If you use it, moving MX hosts changes who passes SPF. See the SPF mx mechanism for syntax and lookup limits.
• Custom MAIL FROM (Return-Path) subdomains. Email service providers often ask you to point a subdomain at them so bounces come back to their systems. Amazon SES, for example, requires an MX record on the custom MAIL FROM domain “so that your domain can receive the bounce and complaint notifications that email providers send you.” If that MX is missing or wrong, SES either falls back to its default amazonses.com domain or rejects the send, depending on your setting.
• Receivers that check the sender domain. Some mail servers refuse messages whose envelope sender domain cannot receive mail. Postfix’s reject_unknown_sender_domain option, for instance, rejects when the MAIL FROM domain has “no DNS MX and no DNS A record.” This is server configuration, not a universal rule. Postfix documents the same option as using a 550 reply when the sender domain publishes a Null MX.

MX is a forward lookup that answers “where does mail for this domain go?” A PTR record is the reverse: it maps a sending IP back to a hostname. If you route outbound mail through a third party, an SMTP relay handles the sending side and your MX records stay untouched.

Common MX mistakes, their symptoms, and fixes

Mistake	Symptom	Fix
IP address as the target	Provider or DNS panel rejects the record, or mail is not delivered	Point to a hostname and give that hostname an A record
CNAME as the target	Intermittent bounces, some senders fail and others succeed	Replace the CNAME with the canonical hostname it points to
Target has no A or AAAA record	Senders report they cannot resolve the mail host, mail queues and bounces	Add an A/AAAA record for the target, then re-check with dig <target> A
Old provider’s records left in place	Some mail still lands at the old provider, even after cutover	Delete the old MX records, or give them a higher preference number than the new ones
Wrong preference order	Mail goes to the backup or the wrong server	Remember lower is tried first, and put the primary at the lowest number
MX set on the wrong name	Mail to [email protected] fails while [email protected] works	Put MX on the exact domain used in email addresses, not on a subdomain
Parked domain with no mail, and no Null MX	Senders that find no MX fall back to the A record and try to deliver there	Publish 0 . as the only MX (RFC 7505)
Missing trailing dot in a zone file	Target resolves as mail1.example.net.example.net.	End fully qualified names with a dot

Frequently Asked Questions