MX Record Lookup

Resolver{{ summaryResolver }} Active hosts{{ resultsReady ? computation.values.active_hosts : '—' }} Findings{{ resultsReady ? `${computation.values.fail_count} fail · ${computation.values.warn_count} warn` : '—' }}

Domain or email address:

Example: google.com or admin@google.com. One target is processed per run.

Resolver strategy:

Comparison highlights differing MX fingerprints without treating either cache as authoritative.

Validation depth:

Every depth checks MX routing first; deeper modes expand more active targets.

Review profile:

Routing mode is unchanged; only the severity of standards findings differs.

Related mail-policy signals:

The neutral default is off and opening Advanced issues no requests.

Manual host cap:

hosts

Use 0 for the depth default. Omitted hosts remain explicit in the result.

Timeout override:

Use 0 for the selected depth default.

Preference	Exchange	Addresses	Alias	Finding	Copy
{{ row.preference_label }}	{{ row.exchange }}	{{ row.addresses_label }}	{{ row.has_cname ? 'CNAME found' : 'Canonical' }}	{{ row.finding }}

Check	Status	Evidence	Next action	Copy
{{ row.label }}	{{ row.status_label }}	{{ row.evidence }}	{{ row.next_action }}

Question	Resolver	Response	Answers	DNSSEC	Time	Fingerprint	Copy
{{ row.question }}	{{ row.resolver }}	{{ row.response }}	{{ row.answer_count }}	{{ row.ad ? 'AD set' : 'AD not set' }}	{{ row.elapsed_ms }} ms	{{ row.fingerprint }}

A mail server consults the Domain Name System (DNS) before it can deliver a message. The recipient domain's mail exchanger (MX) records name the hosts that accept inbound mail and assign each host a preference number. A lower number is tried before a higher one, while hosts with the same number are peers rather than a fixed first-and-second pair.

MX records matter during mail-provider changes, delivery failures, domain retirement, and resilience reviews. A stale exchange can send mail to an old provider. A host name with no address can stop delivery. Two public resolvers can briefly disagree while cached data expires, so a comparison is evidence of what those resolvers currently see, not proof of the authoritative zone's final state.

Meaning of common MX answer patterns
DNS result	Mail-routing meaning	Important limit
One or more exchange hosts	Senders try the lowest available preference group first.	DNS does not prove that SMTP is listening or accepting recipients.
No MX data, but an apex address exists	SMTP may use the domain itself as an implicit preference-0 exchange.	An explicit MX route is clearer and easier to audit.
`MX 0 .`	A standalone Null MX declares that the domain accepts no inbound mail.	It must not coexist with ordinary exchange hosts.
No MX and no apex address	No usable SMTP route was found.	A cached resolver failure can resemble a broken route.

Related TXT records answer different questions. SPF, DMARC, MTA-STS, and TLS-RPT can describe sender authorization, message handling, transport policy, and reporting, but their presence does not repair an MX route. Likewise, a clean DNS route does not test port 25, TLS negotiation, mailbox existence, or provider configuration.

How to Use This Tool:

Start with the domain that receives mail, then choose how much public DNS evidence the review needs.

Enter a domain, URL, or email address in Domain or email address. The value is reduced to one valid host name before any lookup runs.
Choose Google Public DNS, Cloudflare, or Compare Google and Cloudflare. Use comparison when propagation or resolver-cache differences are part of the investigation.
Select the validation depth and review profile. Quick, Standard, and Deep expand up to 4, 10, and 20 active exchange hosts; Strict RFC scoring raises mixed Null MX and alias-target findings from warnings to failures.
Run Inspect MX route, then read the summary and the routing findings. Increase the host cap only if the result says active hosts were omitted.

Interpreting Results:

Start with the reported mail mode and failure count. Active MX means at least one ordinary exchange was returned. Null MX is valid only for a domain that intentionally receives no mail. Implicit fallback means no MX answer was returned but the domain had an A or AAAA address. No SMTP route means neither route was found.

Confirm that the lowest-preference hosts belong to the intended mail provider.
Treat an unresolved exchange or mixed Null MX as a configuration problem, not a harmless score change.
When resolver fingerprints differ, inspect authoritative DNS and allow for caching before changing records.
Test SMTP reachability separately. DNS evidence alone cannot confirm end-to-end delivery.

Technical Details:

An MX resource record contains an unsigned 16-bit preference and an exchange domain name. Ordering applies to preference groups: lower values are preferred, and equal values do not establish a permanent order. The lookup sorts by preference and then by host name for a stable report, but that secondary display order is not an SMTP routing rule.

Lookup Core:

The selected public resolver receives an MX question for the normalized domain. Compare mode asks both resolvers and builds a fingerprint from each ordered preference:exchange pair. Active exchange hosts are then expanded with A, AAAA, and CNAME questions up to the selected cap. If the MX answer set is empty, the domain's own A and AAAA answers supply the implicit-fallback check.

MX lookup depth limits
Depth	Default host cap	Request timeout
Quick	4	5 seconds
Standard	10	8 seconds
Deep	20	12 seconds

A manual cap from 1 to 40 or a timeout from 3 to 15 seconds replaces the selected depth default. Hosts beyond the cap remain counted as omitted, so a partial expansion is visible rather than silently treated as complete.

Rule Core:

Ordered MX routing and validation rules
Condition	Classification	Finding
Active MX and Null MX both appear	Mixed Null MX	Warning in Operational review; failure in Strict RFC scoring
Only `MX 0 .` appears	Null MX	Pass when the domain intentionally accepts no inbound mail
Active exchange has no A or AAAA answer	Unresolved exchange	Failure
Expanded exchange returns CNAME evidence	Alias target	Warning in Operational review; failure in Strict RFC scoring
Only one active exchange exists	Limited redundancy	Advisory resilience warning, not an RFC validity rule
Compared MX fingerprints differ	Resolver disagreement	Warning to check authoritative DNS and cache timing

The optional mail-policy pass checks only whether correctly prefixed TXT answers contain recognizable SPF, DMARC, MTA-STS, or TLS-RPT version markers. It does not parse policy semantics, follow includes, evaluate alignment, or test enforcement.

Privacy and Accuracy Notes:

The normalized domain and requested DNS record types are sent from the browser to Google Public DNS, Cloudflare, or both, depending on the resolver choice. Do not enter a private internal name unless disclosure to that public resolver is acceptable.

Answers are resolver snapshots and may be cached, stale, filtered, or temporarily unavailable.
A resolver's authenticated-data flag is evidence from that response, not an independent DNSSEC validation performed here.
Address resolution, marker presence, and the evidence scorecard do not test an SMTP connection or deliver a message.

Worked Examples:

Mail-provider migration

Compare both resolvers after changing MX records. If the routing matrix still contains an old provider or the fingerprints differ, check the authoritative zone and record TTLs before removing service from the old route.

Domain that should receive no mail

A standalone MX 0 . result is an intentional no-mail declaration. If an ordinary exchange appears beside it, remove either the Null MX or the active route so the policy is unambiguous.

References:

RFC 5321: Simple Mail Transfer Protocol, RFC Editor, October 2008.
RFC 7505: A Null MX Resource Record for Domains That Accept No Mail, RFC Editor, June 2015.
RFC 2181: Clarifications to the DNS Specification, RFC Editor, July 1997.
How to check MX records with dig, Simplified Guide.