MX Record Lookup

{{ summaryStatusBadge.text }} {{ summaryRouteBadge.text }} {{ mailModeBadge.text }} {{ scoreBadge.text }} {{ summaryLatencyLabel }} TTL {{ mxTTL }} s {{ summaryResolverLabel }}

Domain:

Enter a domain, URL host, or mailbox such as example.com, mail.example.org, or admin@example.net.

Resolver strategy:

Auto tries Cloudflare first, then Google if Cloudflare fails; compare mode samples both.

Validation depth:

Quick limits expansion; Standard fits routine checks; Deep covers larger cutovers.

Resolve MX hosts:

Leave on for readiness checks; turn off for MX row evidence only.

Detect CNAME targets:

Keep on for production reviews and provider migrations.

Compare resolvers:

Enable when a recent MX change may still be cached differently.

Strict RFC scoring:

Leave on for compliance checks; disable only for softer migration notes.

Related TXT signals:

Looks for SPF, DMARC, MTA-STS, and TLS-RPT version markers.

Max expanded targets:

targets

Use 0 for the selected depth default, or set 1-120 targets.

Request timeout:

Set 0 for browser defaults; 3500 ms suits normal public DoH checks.

Priority	Exchange	Null MX	CNAME	A	AAAA	Routing notes	Copy
{{ row.priority === null ? '-' : row.priority }}	{{ row.exchange }}	{{ row.isNullMx ? 'Yes' : 'No' }}	{{ row.cname.length }}	{{ row.a.length }}	{{ row.aaaa.length }}	{{ row.note \|\| '-' }}
No MX routing rows available Run a lookup for a domain with active MX, Null MX, or fallback A/AAAA evidence to populate this matrix.

Check	Status	Evidence	Recommendation	Copy
{{ check.label }}	{{ check.status }}	{{ check.note \|\| '-' }}	{{ check.recommendation \|\| '-' }}
No compliance checks available Complete a DNS lookup before exporting MX readiness, Null MX, CNAME, and related TXT checks.

Resolver	Status	Code	AD	Time (ms)	Answer fingerprint	Copy
{{ row.resolver }}	{{ row.status }}	{{ row.code }}	{{ row.ad ? 'Yes' : 'No' }}	{{ row.timeMs }}	{{ row.answers \|\| '-' }}
No resolver evidence available Run a lookup to capture resolver status, latency, AD bit, answer count, and route fingerprint evidence.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Email delivery starts with a routing question. Before a sending mail system can open an SMTP connection, it has to find the mail exchangers for the domain after the @ sign. DNS answers that question with MX records, and those records decide which hosts should receive inbound mail for the domain.

An MX answer contains a preference number and an exchange host name. Lower preference numbers are tried before higher ones, and equal preference values may be treated as peers. The rule looks simple, but it carries most of the practical risk in provider migrations, parked-domain cleanup, backup-mail routing, and delivery incident reviews.

Common MX routing situations
Situation	DNS evidence	What it usually means
Active mail domain	One or more MX records name exchange hosts.	Inbound mail should be delivered through the listed mail provider or servers.
Backup route	Multiple exchange hosts use different preference values.	Lower numbers are primary routes; higher numbers are usually backup or secondary routes.
Peer route	Several MX records share the same preference value.	Senders can distribute attempts across equivalent mail hosts.
No explicit MX	No MX exists, but the domain has A or AAAA records.	SMTP may try the domain host as an implicit fallback, which can surprise web-only domains.
Null MX	A single `MX 0 .` record is published.	The domain intentionally declares that it accepts no inbound mail.

Two mistakes account for many bad readings. Removing every MX record does not always stop delivery attempts because SMTP can fall back to the domain address records. Publishing MX 0 . beside normal exchange hosts sends a contradictory signal because Null MX is meant to stand alone.

MX routing is DNS evidence, not a complete mail-delivery proof. A domain can publish clean MX records while SMTP port reachability, TLS negotiation, mailbox acceptance, provider account state, or spam filtering still fails later. The DNS result is the right first checkpoint because a wrong route makes every later mail test harder to interpret.

How to Use This Tool:

Start with the domain that should receive mail, then expand the checks only as far as the situation needs.

Enter one Domain. A bare domain, URL host, or mailbox such as admin@example.net is accepted. An IP address is rejected because MX records belong to DNS names.
Leave Resolver strategy on Auto for a normal first pass. Select Cloudflare only or Google only when a support case needs one resolver's visible answer.
Choose Validation depth. Quick triage limits expansion for outage checks, Standard fits routine production reviews, and Deep audit covers more exchange hosts during larger cutovers.
Keep Resolve MX hosts enabled when readiness matters. The Routing Matrix then shows A and AAAA evidence for expanded exchange hosts, and unresolved targets appear in the Compliance Scorecard.
Keep Detect CNAME targets enabled for production DNS. If CNAME evidence appears in routing notes, publish the canonical host name directly as the MX exchange value.
Enable Compare resolvers after a recent DNS change or when different users report different mail behavior. The Resolver Evidence Log shows resolver name, response code, authenticated-data flag, response time, answer count, and MX fingerprint.
Use Related TXT signals for nearby SPF, DMARC, MTA-STS, and TLS-RPT marker checks. Treat those rows as presence checks, not full policy validation.
If the summary reports No SMTP route, confirm that the entered name is the receiving domain. Then decide whether the domain needs active MX records or a single Null MX record.

Interpreting Results:

The summary gives the fastest read. Route count shows how much routing evidence was produced, the mail-mode badge names the domain's routing posture, the P/W/F badge totals pass, warning, and failure rows, and the resolver and TTL badges explain which sampled DNS view was used.

MX result states and follow-up checks
Mail mode	What it means	What to check next
Active MX mode	At least one non-null MX exchange was found.	Review priority order, host A/AAAA evidence, and CNAME notes in Routing Matrix.
Null MX mode	The domain appears to declare no inbound mail service.	Confirm Null MX isolation (RFC 7505) passes and no active exchanges are mixed in.
Implicit A/AAAA fallback	No explicit MX was found, but the domain has address records that SMTP may try.	Add explicit MX records if the domain should reliably receive mail through a provider.
Mixed Null MX state	A no-mail signal appears beside active MX targets.	Treat it as a configuration conflict, especially while Strict RFC scoring is enabled.
No SMTP route	No MX and no fallback address route were detected.	Publish active MX records for a receiving domain, or publish one Null MX for a no-mail domain.

A healthy Compliance Scorecard does not guarantee that a message will be accepted. DNS can point to the right hosts while a firewall blocks port 25, a provider account is not provisioned, a mailbox does not exist, or filtering rejects the message. Use DNS results to prove the route first, then test SMTP and provider settings separately.

The chart tabs help with comparison. MX Preference Ladder should show the hosts you expect senders to try first at lower preference values. Resolver Drift is most useful during propagation because different public caches can temporarily show different answer sets.

Technical Details:

An MX record's preference field is an unsigned integer, and its exchange field is a domain name for a host that can accept mail for the owner domain. SMTP clients sort MX records by preference before attempting delivery. Equal preferences are not a fixed text order, so administrators should not rely on the visual order returned by one resolver when several MX hosts share the same preference.

The implicit fallback rule applies only when the MX answer set is empty. In that case, SMTP can treat the domain as if it had an MX record with preference 0 pointing back to itself. If MX records exist but point to bad hosts, the apex A or AAAA records do not automatically repair the route.

Rule Core:

MX routing rule core
DNS condition	Reported state	Technical consequence
One or more active MX rows exist	Active MX mode	Rows are sorted by parsed preference, with lower values preferred first.
A single `MX 0 .` answer exists	Null MX mode	The domain declares that inbound mail should fail immediately.
`MX 0 .` appears with active exchanges	Mixed Null MX state	The no-mail declaration conflicts with active routing and is scored as a failure or warning.
No MX, but apex A or AAAA records exist	Implicit A/AAAA fallback	SMTP may attempt delivery to the domain host.
No MX and no apex A or AAAA records exist	No SMTP route	No visible DNS answer points senders to an inbound SMTP destination.

Validation Core:

MX validation checks and boundaries
Check	Pass condition	Warning or failure cue
Explicit route	MX answers exist, or fallback A/AAAA evidence is visible.	No MX plus no fallback address produces No SMTP route.
Null MX isolation	Null MX appears alone, or no Null MX appears.	Null MX beside active exchanges becomes fail-grade when Strict RFC scoring is on.
Canonical exchange hosts	Expanded MX hosts do not return CNAME evidence.	Alias evidence suggests the MX value should be replaced with the canonical host name.
Host address resolution	Expanded active exchanges return A or AAAA answers.	Unresolved exchange hosts can break delivery even when the MX row exists.
Priority parsing	Preference values parse as integer priorities.	Non-standard preference formatting is reported as a warning.
Active-host redundancy	At least two active MX hosts are found.	A single active exchange is treated as a resilience warning.
Resolver agreement	Compared public resolvers return equivalent MX fingerprints.	Different fingerprints point to propagation, cache, validation, or configuration differences.

Validation depth changes the expansion cap and request concurrency. With Max expanded targets set to 0, Quick triage expands up to 8 active exchange hosts, Standard expands up to 20, and Deep audit expands up to 40. A manual cap can be set from 1 to 120 targets. If the active MX set is larger than the cap, the routing matrix includes an omitted-host line so partial coverage remains visible.

Related TXT Signal Checks:

Related mail-policy TXT markers
Signal	Marker checked	Interpretation boundary
SPF	`v=spf1` at the domain apex	Presence does not evaluate mechanisms, includes, lookup limits, or alignment.
DMARC	`v=DMARC1` below the DMARC owner name	Presence does not prove policy strength, reporting coverage, or SPF/DKIM alignment.
MTA-STS	`v=STSv1` at the MTA-STS TXT name	The marker does not verify the HTTPS policy file, certificate health, or MX match rules.
TLS-RPT	`v=TLSRPTv1` at the SMTP TLS reporting name	The marker does not prove that report destinations receive or review reports.

Resolver evidence records status code, authenticated-data flag, response time, answer count, and a compact MX fingerprint. That makes repeated checks easier to compare, but it is still a sampled public-resolver view rather than an authoritative-zone transfer or direct SMTP probe.

Privacy and Accuracy Notes:

The lookup sends DNS-over-HTTPS questions from the browser to the selected public resolver view. Resolver comparison sends comparable MX questions to both public resolvers, and related TXT signals add mail-policy marker questions for the same domain.

DNS-over-HTTPS encrypts the DNS exchange in transit to the resolver, but the resolver still receives the queried name and record type.
Public resolver answers can be affected by cache timing, DNSSEC validation policy, temporary network errors, and resolver-specific behavior.
Settings and the queried name may appear in the page address when a result is shared.
A healthy DNS route does not verify SMTP port reachability, TLS negotiation, mailbox existence, spam-filter acceptance, or provider account status.

Worked Examples:

Provider migration review

Enter admin@example.net, keep Resolver strategy on Auto, enable Compare resolvers, and use Standard depth. A good first result shows Active MX mode, expected provider hosts in Routing Matrix, and matching fingerprints in Resolver Evidence Log. If Cloudflare and Google disagree, wait for TTL expiry or check the authoritative DNS before closing the migration.

Parked no-mail domain

For a domain that should never receive mail, the expected result is Null MX mode with one MX 0 . row. Compliance Scorecard should show Null MX isolation (RFC 7505) as pass. If Mixed Null MX state appears, remove either the Null MX or the active exchanges so DNS sends one clear signal.

Legacy fallback domain

A small legacy domain may have no explicit MX but still return apex A or AAAA records. The summary then reports Implicit A/AAAA fallback. That is valid SMTP behavior, but explicit MX records make routing easier to audit and avoid accidental delivery to a web host that was not meant to receive mail.

No-route troubleshooting

If No SMTP route appears after entering an IP address, replace it with the receiving domain. If the error remains for the correct domain, publish active MX records for a mail-receiving domain or publish a single Null MX for a domain that should reject inbound mail.

FAQ:

Does no MX always mean the domain cannot receive mail?

No. SMTP can use an implicit fallback to the domain's A or AAAA records when the MX set is empty. The summary reports Implicit A/AAAA fallback when that route is visible.

What does a Null MX result mean?

A Null MX result means DNS returned MX 0 ., the standard signal for a domain that accepts no inbound mail. It should appear alone, not beside active exchange hosts.

Why are CNAME targets flagged?

MX exchange values are expected to name canonical hosts that have address records. If Detect CNAME targets finds alias evidence, publish the canonical mail host directly in the MX record.

Why do Cloudflare and Google show different answers?

Different public resolvers can have different cache ages, validation results, or temporary network outcomes. Compare Resolver Evidence Log, especially response code, time, answer count, and answer fingerprint.

Does this check whether a mailbox exists?

No. The result is DNS evidence only. It does not connect to a mail server, test SMTP commands, verify a mailbox, or confirm that a provider will accept a message.

Why was my IP address rejected?

MX records are looked up for domain names, not IP literals. Enter the mail domain, a URL host, or a mailbox address so the DNS owner name can be extracted.

Glossary:

MX record: A DNS mail exchanger record that names where inbound mail for a domain should be sent.
Preference: The MX priority number; lower values are preferred before higher values.
Exchange host: The DNS host name published as a mail exchanger for the owner domain.
Null MX: A single MX 0 . answer that declares no inbound mail service for the domain.
Implicit fallback: The SMTP rule that can treat a domain with no MX as if the domain itself were the mail host.
TTL: Time to live, the caching lifetime reported with a DNS answer when available.
AD flag: The authenticated-data flag returned by a validating resolver when DNSSEC validation supports the answer.
Resolver drift: A sampled difference between resolver answer sets, often caused by cache timing or validation differences.

References:

RFC 5321: Simple Mail Transfer Protocol, RFC Editor, October 2008.
RFC 7505: A "Null MX" No Service Resource Record, RFC Editor, June 2015.
RFC 8484: DNS Queries over HTTPS, RFC Editor, October 2018.
RFC 7208: Sender Policy Framework (SPF), RFC Editor, April 2014.
RFC 7489: Domain-based Message Authentication, Reporting, and Conformance, RFC Editor, March 2015.
RFC 8461: SMTP MTA Strict Transport Security, RFC Editor, September 2018.
RFC 8460: SMTP TLS Reporting, RFC Editor, September 2018.
How to add and configure MX records in cPanel, Simplified Guide.
How to query DNS records in Windows, Simplified Guide.