An MX RRset tells SMTP senders which hosts accept mail for an owner name and
in what preference order. It does not create mailboxes or prove delivery works.
Purpose and type code
IANA registers MX as type code 15
[1]. RFC 1035
defines each record’s preference and exchange fields
[2]. Lower preference
values are tried before higher values
[4].
Presentation format
example.com. 3600 IN MX 10 mail1.example.net.
example.com. 3600 IN MX 20 mail2.example.net.Equal preferences describe equally preferred candidates. Preference values are ordering hints, not percentages or traffic weights.
Owner-name and coexistence rules
MX commonly coexists with TXT and other ordinary records at an owner. It cannot exist at a CNAME alias owner. The exchange hostname itself must not be a CNAME; it must resolve to address data [3].
SMTP defines an implicit MX fallback when no MX records exist: the domain is treated as its own preference-zero exchanger [4]. Do not rely on that fallback when operating a deliberate mail service.
A domain that accepts no mail can publish a single null MX:
example.com. 3600 IN MX 0 .It must not coexist with another MX record [5].
Caching and changes
Senders can cache the MX RRset and the exchange hosts’ A or AAAA RRsets. Keep old exchangers accepting mail during migration until relevant TTLs and queued retries are accounted for.
Security and operational limits
An MX answer does not prove SMTP reachability, recipient validity, TLS policy, spam filtering, or successful delivery. Mail routing also depends on the exchange addresses and application configuration. Publishing an unintended exchange can expose mail to the wrong operator.
Verify
Query MX at the exact mail domain, then resolve every exchange hostname to A and AAAA without following a CNAME. Check SMTP from an appropriate external network and inspect delivery logs. Validate SPF, DKIM, and DMARC separately.
Next step
Read the TXT record reference for the container used by SPF, DKIM, DMARC, and many ownership-verification schemes.