MX Record: The DNS Record That Routes Mail

An MX (Mail Exchanger) record is a DNS record that names a host willing to accept mail for a domain. Its data is two fields: a 16-bit preference number and an exchange host name. Lower preference numbers are preferred. A sending SMTP client looks MX records up before delivery. A domain with no MX record can still receive mail, and a domain with one is not guaranteed to hold any given mailbox.

The record itself is old and stable. RFC 1035 defined its data format in November 1987, and that definition still governs what goes on the wire. The behavior around it accumulated later. RFC 5321 (October 2008) specifies how a sender uses the records it finds, RFC 2181 (July 1997) rules out one kind of value, and RFC 7505 (June 2015) added a way for a domain to declare that it accepts no mail at all.

What is inside an MX record?

Two fields of record-specific data, sitting on top of the header that every DNS resource record carries.

RFC 1035, Section 3.3.9, defines the first one:

PREFERENCE A 16 bit integer which specifies the preference given to this RR among others at the same owner. Lower values are preferred.

The second field, EXCHANGE, is described in the same section as "A <domain-name> which specifies a host willing to act as a mail exchange for the owner name." Two details in that sentence do real work. The value is typed as a domain name, so an IP address literal is not a valid MX value. And the host is described as willing to act as a mail exchange, which is a statement about routing, not about any individual mailbox behind it.

Because PREFERENCE is a 16-bit integer, its range is 0 to 65535. Most DNS control panels label the field "priority" rather than "preference", and the numbers run the opposite way to the word: a lower number is the more preferred host.

The rest of the record is the generic resource-record header from RFC 1035 Section 4.1.3: NAME, TYPE, CLASS, TTL, RDLENGTH, RDATA. The TTL is "a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded." Any MX answer you read is a cached answer until that timer expires.

How does a sender pick between multiple MX records?

By sorting on preference and working down the list. RFC 5321, Section 5.1:

MX records contain a preference indication that MUST be used in sorting if more than one such record appears (see below). Lower numbers are more preferred than higher ones. If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization.

So equal preference values are a load-spreading instruction, not a tie the sender is free to break however it likes. The same section sets a floor on persistence: the client must be able to try and retry each address in order until a delivery attempt succeeds, it may impose a configurable limit on how many alternates it tries, and it "SHOULD try at least two addresses."

The two largest mailbox providers both publish a single MX host today, which makes preference ordering moot on their domains. Google Workspace states: "The Google Workspace MX record value is smtp.google.com." Priority is 1. Google also notes that domains onboarded before 2023 may still carry the legacy five-record set whose hostnames start with aspmx, at priorities 1, 5, 5, 10 and 10, and that "the legacy MX record values are still supported."

Microsoft 365 also uses one MX record per domain, with the host value generated per tenant and copied out of the admin center rather than published as a fixed string. Microsoft's guidance on the numbers is "Priority: Set to the highest value available, typically 0" and "TTL: 3600 (1 hour)", with the caveat that "Exchange Online only supports TTL values less than 6 hours (21,600 seconds)." Note the inversion again: Microsoft's "highest value available" means the numerically lowest preference, which is the most preferred host under RFC 1035.

What happens when a domain publishes no MX record?

Mail is still attempted. RFC 5321, Section 5.1, is explicit:

If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.

That is the implicit MX rule. With no MX records present, the sender falls back to the domain's own address records and tries to deliver there. This is why "no MX record" is not the same statement as "this domain cannot receive mail."

The fallback is narrow. When MX records do exist, senders "MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the 'implicit MX' rule above applies only if there are no MX records present." A working A record does not rescue a domain whose MX targets are all broken.

The same section handles the remaining cases. If neither usable MX records nor a usable implicit MX exists, "this situation MUST be reported as an error." A non-existent domain error must also be reported as an error, while a temporary error must cause the message to be queued and retried.

Why can an MX record not point to a CNAME?

Because the target has to answer with an address, and additional section processing does not chase aliases. RFC 5321 requires that the exchange name, when queried, "MUST return at least one address record (e.g., A or AAAA RR) that gives the IP address of the SMTP server to which the message should be directed", and says that any other response, "specifically including a value that will return a CNAME record when queried, lies outside the scope of this Standard."

RFC 2181, Section 10.3, states the rule and the cost of breaking it. "The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias." And: "if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. This can cause extra queries, and extra network burden, on every query."

What does a null MX record declare?

That the domain accepts no mail, deliberately. RFC 7505 defines it as a single MX RR "with an RDATA section consisting of preference number 0 and a zero-length label, written in master files as '.', as the exchange domain, to denote that there exists no mail exchanger for a domain." The RFC adds the constraint that makes it unambiguous: "A domain that advertises a null MX MUST NOT advertise any other MX RR."

RFC 7505 also names reply codes, and they differ by direction. A submission or relay server rejecting a recipient whose domain has a null MX should use reply code 556 with enhanced status code 5.1.10. A server rejecting mail because the sender domain publishes a null MX should use 550 with enhanced status code 5.7.27. Both are stated as SHOULD, not MUST.

The motivation is in the RFC's introduction. Without a null MX, a domain that publishes no MX record and runs no SMTP listener on its A or AAAA address leaves senders retrying: "message delivery will be attempted repeatedly for a long period, typically a week, before the sending Mail Transfer Agent (MTA) gives up."

For anyone reading DNS as a signal, that is the useful distinction. A null MX is a positive declaration. An empty MX answer is not.

How do you look up a domain's MX records from a shell?

Three standard utilities, all from the BIND 9 toolset:

• dig example.com MX, or the equivalent dig -t MX example.com. Without a type argument, dig queries for an A record.
• host -t MX example.com.
• nslookup -query=mx example.com. The BIND 9 manual page documents the flag as -query=; the -type= spelling is a long-standing alias in common use.

Reading the answer matters as much as getting it. RFC 1035 separates two response codes that both look like "nothing there". Code 0 is "No error condition", so an empty answer section with code 0 means the name exists and simply has no records of the requested type. Code 3 is Name Error, which "signifies that the domain name referenced in the query does not exist", the condition usually called NXDOMAIN. A domain with no MX records and a domain that does not exist are different findings.

Two operational notes from Google's own documentation. Formatting of the trailing dot is registrar-dependent, since "some domain registrars require a period at the end (smtp.google.com.)". And propagation is not instant: Google states it can take up to 72 hours for new MX records to be recognized. Google's troubleshooting guidance points administrators at its Admin Toolbox Dig tool to compare published records against expected values.

What does an MX record not tell you?

Whether a specific mailbox exists. RFC 5321 splits those jobs across the document. Section 5 covers locating the target host, which is where the MX lookup lives. Verification of an individual mailbox sits in Section 3.5, which describes VRFY and EXPN: "For the VRFY command, the string is a user name or a user name and domain (see below). If a normal (i.e., 250) response is returned, the response MAY include the full name of the user and MUST include the mailbox of the user."

To be plain about the evidence: no RFC consulted for this page states, in so many words, that an MX record does not prove a mailbox exists. The conclusion follows from the specification's own division of labor rather than from a quotable line. Routing is resolved against the domain. Mailboxes are resolved at the SMTP conversation.

Two further limits follow from the sections above. An empty MX answer does not mean the domain refuses mail, because of the implicit MX fallback. And a published exchange host is a statement of intent in DNS, not proof that the host is reachable or currently accepting connections.

How Trueguard handles this

Trueguard's email validation API reports MX presence as its own field. deliverability.isMxValid is true when the domain publishes at least one MX record, and deliverability.mxRecords returns the exchange hostnames it found. Preference values are not returned, only hostnames. A domain with no MX record produces the reason string "No MX record".

The same hostnames drive mail-provider detection: an exchange containing mail.protection.outlook.com indicates Microsoft, one containing google.com indicates Google. Presence of an A record is tracked separately as domain.isLive, so a domain without MX records but with an address record is visible as exactly that, rather than collapsed into one verdict.