blog
Tools Guide

How to Read DNS MX Records When Email Is Not Arriving

Learn what MX priorities and mail hostnames mean, how to check the exact domain, and which DNS results to verify before changing email delivery settings.

Published 2026-10-20 · Updated 2026-10-20 · 5 min read

An MX (mail exchange) record tells sending mail systems which hostnames accept mail for a domain. It does not contain an inbox name, password, or a webmail address. An MX record contains a preference value and an exchange domain name. RFC 1035, section 3.3.9

If email is not arriving, an MX lookup is a good first DNS check—but only for the recipient domain and only as one part of the delivery path. The answer can show where a sender is directed to try delivery; it cannot prove that a mailbox exists, that the receiving server accepts the message, or that a message was not filtered later.

Start with the recipient domain, not the full email address

For person@example.com, the relevant DNS name is example.com. Do not query person.example.com unless the mail provider specifically gave you that hostname. Subdomains can have their own mail routing, so example.com and alerts.example.com are separate questions.

Use the exact domain that appears after the @ sign. Then record the lookup time, queried name, response code, TTL, and every MX answer. Keeping that small record is more useful than relying on a screenshot after a DNS change.

The yukt.tools DNS Dig utility can inspect a published DNS response. Use the result to compare the hostname and values with your mail provider's current setup instructions; it cannot determine which provider configuration your account is supposed to use or diagnose a mailbox by itself.

Read the two parts of each MX answer

MX answers are commonly displayed as a number followed by a hostname:

10 mail1.example.net.
20 mail2.example.net.

The number is the preference. When multiple MX records exist, a sending SMTP system tries lower preference values first; equal-preference records can be tried in any order. RFC 5321, section 5.1

The hostname is the exchange: the mail server name the sender should resolve and contact. It is a domain name, not an IP address. RFC 1035, section 3.3.9

That means the example is not a ranking of two inboxes. It is a delivery order for two mail hosts. A lower number does not mean a faster or more important mailbox; it simply has higher delivery preference.

Follow the exchange hostname one step further

An MX result is incomplete if its exchange hostname does not resolve to an address. After noting the MX result, look up A and, where relevant, AAAA records for each exchange hostname. The SMTP specification requires a sender to resolve the selected MX host to an address before attempting a connection. RFC 5321, section 5.1

Keep the names separate while checking:

QuestionExample name
Where should mail for the domain go?example.com queried for MX
What address does the first mail host use?mail1.example.net queried for A or AAAA

Do not replace the exchange hostname with an address in the MX record. MX RDATA is defined as a preference plus an exchange domain name. RFC 1035, section 3.3.9 Follow the destination mail provider's documented hostname and record type exactly.

Distinguish an absent MX answer from a broken one

An absent MX record does not always mean a domain cannot receive SMTP mail. SMTP specifies an "implicit MX" fallback: if no MX records exist, a sender can treat the recipient domain itself as the mail host and look up its address records. RFC 5321, section 5.1

That standards fallback is not a reason to remove or guess records for a managed email service. If a provider tells you to publish specific MX values, publish those exact values and preserve any priority values it supplies. An NXDOMAIN response is different again: it says the queried domain name does not exist in DNS, so first confirm the spelling and the domain you are checking.

A practical MX-check sequence

  1. Copy the recipient domain exactly from the email address or provider instructions.
  2. Query that domain for MX and save the response code, TTL, preference values, and exchange hostnames.
  3. Compare every published value with the destination provider's current documentation or control panel.
  4. Resolve the listed exchange hostnames to A and/or AAAA addresses; do not put an address in the MX value.
  5. If a recent DNS change appears missing, compare the authoritative answer with a recursive lookup and note the TTL before making another change.
  6. If DNS matches the intended setup, investigate the next evidence available: SMTP rejection details, the receiving provider's logs, mailbox status, authentication policy, or filtering.

Frequently asked questions

Is the lowest MX number the primary mail server?

It has the highest preference for SMTP delivery: lower preference values are tried first. When two records have the same preference, the SMTP specification permits them to be tried in any order. RFC 5321, section 5.1 Treat provider-supplied values as a routing configuration, not as a label for a particular inbox.

Can I put an IP address in an MX record?

No. An MX record's exchange field is a domain name. Publish the hostname supplied by the mail service, then ensure that hostname has the necessary address records. RFC 1035, section 3.3.9

My MX records look correct. Why is mail still failing?

MX data answers only the routing question. The receiving host may still be unreachable, reject a message during SMTP, lack the intended mailbox, or apply filtering or policy after delivery is attempted. Preserve the confirmed DNS result and use the sender's error details or the mail provider's logs to investigate the next layer rather than changing known-good records.

Use the DNS Dig utility to inspect the MX result, then consult the DNS troubleshooting guide when authoritative and recursive answers differ.

Sources and research

  1. RFC 1035, section 3.3.9: MX RDATA format — IETF specification of the MX preference and exchange fields, accessed 2026-10-20.
  2. RFC 5321, section 5.1: Locating the target host — IETF SMTP requirements for MX preference, equal preferences, address lookup, and implicit MX fallback, accessed 2026-10-20.
Related tools and guides