Records

MX: mail exchange

Where does mail for this domain go? MX records are how a sending SMTP server discovers the receiving server for user@example.com. Each MX has a numeric preference: lower wins.

run it right here; the full tool has every option

open in the full tool →

typeMXwire type15rfc1035, 5321common ttl300

In one line:

example.com.    MX    10    mx1.mailprovider.com.
└── mail for ┘ └type┘ └#┘   └── goes to this server (lowest # first)

What it holds#

A preference number (16 bits on the wire) and a hostname. The hostname must be resolvable to A/AAAA records: it cannot be a CNAME (RFC 2181 §10.3).

mx.example.isitdns.net.   MX  10  mx.example.com.

Mail addressed to anyone at mx.example.isitdns.net should be delivered to the server mx.example.com. The 10 is its place in line: lowest number gets tried first.

A real-world apex usually has two or more MX records for redundancy, e.g.:

example.com.   MX  10  mx1.mailprovider.com.
example.com.   MX  10  mx2.mailprovider.com.
example.com.   MX  20  backup-mx.mailprovider.com.

Preference is a tie-breaker for sender behavior:

Preference	Used as
Lowest	First-choice MX
Equal lowest	Round-robin / random tie-break (cheap "primary cluster")
Higher	Backup if all primaries fail: the sending side decides when to escalate

When to use it#

For any domain that receives mail. The apex is the typical place, but you can have MX at any name (for departmental routing, e.g., sales.example.com).
For backup MX in front of an on-prem mail server: a higher-preference MX at a hosted service that queues during outages.

When not to use it#

For a domain that doesn't send or receive mail: publish a null MX instead (see Gotchas). Easier than fighting senders that keep retrying for days.
For load balancing: preference is a discrete ranking, not a weighted load distribution. Use equal-preference for round-robin instead.

dig example#

Asks which servers take mail for mx.example.isitdns.net.

$ dig @1.1.1.1 mx.example.isitdns.net MX

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> @1.1.1.1 mx.example.isitdns.net MX

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status:

NOERRORThe server had no complaint about the question.

, id: 47825

;; flags:

qrThis message is the answer coming back, not the question going out.

rdYou asked this server to go and find the answer for you.

raThis server says it is willing to go and find answers for you.

adThis server says it checked the signatures, and they held up.

; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;mx.example.isitdns.net. IN

MXYou asked which servers take mail for this name.

;; ANSWER SECTION:

mx.example.isitdns.net.

300How many seconds this answer can be reused before asking again. From a cache it is the time left, so it counts down.

IN MX 10 mx.example.com.

;;

Query timeHow long this one lookup took, start to finish.

: 36 msec

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

;; WHEN: Mon Sep 14 13:45:34 CDT 2026

;; MSG SIZE rcvd: 81

good: NOERROR, one MX record, preference 10

bad: NOERROR with no answer, which means nothing accepts mail for this name

run this query in the dig tool →

dig @1.1.1.1 mx.example.isitdns.net MX +short

10 mx.example.com.

nslookup -type=MX mx.example.isitdns.net 1.1.1.1

Server:   1.1.1.1
Address:  1.1.1.1#53

Non-authoritative answer:
mx.example.isitdns.net  mail exchanger = 10 mx.example.com.

To check whether the resolver hands back anything beyond the MX answer, ask dig to print the additional section too:

dig @1.1.1.1 mx.example.isitdns.net MX +noall +answer +additional

mx.example.isitdns.net.  300  IN  MX  10 mx.example.com.

No additional section appears, and that is normal: modern recursive resolvers like 1.1.1.1 send minimal responses and do not attach A/AAAA records for the MX target, even for real production domains with cached addresses. A sending mail server follows the MX lookup with its own A/AAAA query for the target hostname. (An authoritative server may still add addresses for an in-zone MX target, but a recursive will not pass them along as an answer.)

nslookup has no flag to select which sections it prints. When a reply does carry authority or additional records, nslookup prints them after the answer under an Authoritative answers can be found from: heading. Against 1.1.1.1 the reply carries nothing beyond the MX answer, so the output is identical to the earlier nslookup example.

See it live: isitdns.net/#dig?name=mx.example.isitdns.net&qtype=MX

RFC: RFC 1035 defines the MX record; RFC 5321 §5.1 defines how a sender uses it.

DoH query (HTTPS)#

DNS-over-HTTPS (DoH) carries the same DNS wire protocol over an HTTPS connection. Use curl to query a DoH endpoint directly and read the JSON answer:

curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=mx.example.isitdns.net&type=MX' \
  | jq .Answer

[
  {
    "name": "mx.example.isitdns.net",
    "type": 15,
    "TTL": 300,
    "data": "10 mx.example.com."
  }
]

The application/dns-json content type is a Cloudflare/Google extension; it is not defined by RFC 8484, which specifies the wire-format DoH transport.

nslookup cannot do DoH, DoT, or DoQ. Windows' Resolve-DnsName has no DoH option either: its documented parameters include nothing for encrypted transports. Windows 11 configures DoH per resolver at the OS level, not per query. To probe a specific DoH service, use the curl example above.

Gotchas#

The MX target (the hostname field) must resolve to an A or AAAA record, not a CNAME (RFC 2181 §10.3) or a bare IP. Most authoritative servers will load anything as RDATA; the failure surfaces on the sending side, where an IP-shaped target is parsed as a hostname that will not resolve, and senders are not required to chase a CNAME.
No MX does not mean no mail. If a name has no MX at all, senders fall back to an implicit MX: the domain's own A/AAAA record, treated as a mail server with preference 0 (RFC 5321 §5.1). A web-only domain with an A record still gets delivery attempts, which is exactly what null MX (next bullet) exists to switch off.
Null MX for non-mail domains: RFC 7505 says a domain that never receives mail should publish a single MX record with preference 0 and a target of . (literal dot):

example.com.   MX   0   .

Senders interpret this as "do not deliver here" and bounce immediately rather than retrying for days.

MX implies forward+reverse alignment. Receiving mail servers commonly do FCrDNS on the sender's IP. If your outbound mail server's PTR doesn't match its A record, deliverability suffers. See ptr.
SPF/DKIM/DMARC are separate: having an MX does not authorize anyone to send on your behalf. See email-records.
Hosted email providers usually require helper records. Apple's iCloud Mail custom domain needs an apex apple-domain= verification TXT plus one DKIM CNAME (sig1._domainkey); Google Workspace needs a site-verification TXT and publishes DKIM as a TXT record, not a CNAME; Microsoft 365 needs a TXT verification token, with autodiscover and DKIM as CNAMEs. Without the verification record the provider will not activate the domain; without the rest, mail flows but authentication or client autoconfig breaks.