MX Record Lookup: Check Mail Routing and Interpret DNS Results

An MX record lookup asks DNS which mail servers are designated to receive email for a domain. The result helps you investigate mail routing, but it does not prove that a particular mailbox exists or that a message will reach an inbox.

The key is to distinguish an ordinary MX answer from an empty answer, an explicit no-mail declaration, and a DNS failure. Those outcomes require different next steps.

What an MX record contains

An MX record identifies a mail exchanger and a numeric preference. Lower preference numbers are tried before higher numbers; the number is an ordering value, not a performance score.

For example, a server with preference 10 normally has priority over one with preference 20. The receiving domain publishes those values. Do not change them based on an assumption that a larger number means a better server.

Equal-preference records do not define a single fixed first choice. The mail transfer process handles selection and retry behavior; an MX listing alone is not a complete map of every delivery attempt.

Run a lookup for the domain

For an address such as person@example.com, query the domain after the at sign. Where the relevant tools are installed, dig MX example.com or nslookup -type=mx example.com can display the DNS result.

For diagnosis, preserve the full output. A shortened answer may omit the response status that distinguishes a nonexistent domain from a temporary DNS problem. Record the time, resolver, status, returned records, and TTL values.

A lookup observes DNS through a particular resolver at a particular time. Cached answers can differ during a migration. If you manage the domain, compare the result with the authoritative DNS configuration and the mail provider's current setup instructions.

Interpret the result before deciding what to do

One or more ordinary MX records

The domain advertises mail exchangers. Confirm that the names and preferences match the intended mail service if you administer it. This is routing evidence, not confirmation of an individual recipient, available storage, or inbox placement.

No MX records in an otherwise successful answer

An empty MX answer does not always mean the domain cannot receive mail. SMTP's address-resolution rules specify an implicit MX fallback when no MX records are found, using the domain itself and the applicable address lookup. Whether delivery can proceed depends on the resulting addresses and server behavior.

Do not convert every empty MX answer directly into “invalid mailbox.” Preserve the DNS status and evaluate the applicable routing behavior.

A null MX record

A record with preference 0 and the root label as its exchanger, commonly displayed as 0 ., explicitly declares that the domain does not accept email. This is a different result from an empty answer. RFC 7505 defines the null MX convention.

NXDOMAIN

The DNS response indicates that the queried domain name does not exist. Check spelling and the exact domain being queried. A mistyped address and a temporary server problem should not receive the same diagnosis.

SERVFAIL or a lookup timeout

The lookup did not produce a reliable routing answer. Investigate the resolver, authoritative DNS service, and relevant configuration. Use a bounded retry policy rather than treating an unavailable DNS answer as proof that a mailbox is valid or invalid.

What MX records cannot tell you

Many addresses can share the same domain and MX records while having different mailbox states. The domain may also apply catch-all behavior, anti-abuse controls, or temporary restrictions.

An MX result does not establish consent, sender authentication, message acceptance, or inbox placement. Keep routing checks separate from SPF, DKIM, and DMARC, which concern other parts of email authentication.

For the recipient-level question, read how to verify an email address without sending. Verification adds evidence, but uncertain outcomes still need a handling policy.

Use routing checks in a practical review workflow

1. Check the input. Extract the intended domain and look for obvious transcription errors without silently rewriting the address.
2. Capture the DNS result. Keep status and records together, including whether the answer was empty or explicitly null MX.
3. Separate temporary failures. Queue unresolved lookups for a bounded retry or manual review.
4. Continue recipient-level checks where appropriate. Do not treat a reachable mail exchanger as a verified mailbox.
5. Keep the timestamp. DNS configuration and mailbox state can change after the check.

If you are moving a domain between mail services, use the provider's current instructions and confirm the authoritative configuration. A list of records copied from an older tutorial may not match your account's current setup.

Connect DNS evidence to an email decision

Use an MX lookup to answer a routing question, then decide what additional evidence the workflow requires. Avoid reducing every outcome to a single yes-or-no label before understanding the response.

Email Awesome supports email verification workflows that go beyond a manual DNS lookup. Keep verification results, check times, and suppression rules together so that a technically usable address is not automatically treated as permission to contact someone.