is it dns? / wiki ← back to the live monitor

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.

Type number15
RFC1035 (with email handling in 5321)
RDATAA 16-bit preference + an FQDN (the mail server)

What it holds#

A preference number 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.

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:

PreferenceUsed as
LowestFirst-choice MX
Equal lowestRound-robin / random tie-break (cheap "primary cluster")
HigherBackup 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#

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.

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): ``text 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.

See also#