MX Record Lookup

#	Priority	Exchange	Null MX	CNAME	A	AAAA	Notes
{{ idx + 1 }}	{{ row.priority === null ? '-' : row.priority }}	{{ row.exchange }}	{{ row.isNullMx ? 'Yes' : 'No' }}	{{ row.cname && row.cname.length ? row.cname.join(', ') : '-' }}	{{ row.a.join(', ') \|\| '-' }}	{{ row.aaaa.join(', ') \|\| '-' }}	{{ row.note \|\| '-' }}

Resolver	Status	Code	Time	Answers
{{ e.resolver }}	{{ e.status }}	{{ e.code }}	{{ e.timeMs }} ms	{{ e.answers \|\| '-' }}

#	Check	Status	Notes
{{ idx + 1 }}	{{ c.label }}	{{ c.status }}	{{ c.note \|\| '-' }}

Mail routing records for a domain are the signposts that tell sending systems which mail servers should receive messages and the order they should be tried. They are often checked during email deliverability troubleshooting, provider migrations, and bounce investigations, because small changes can redirect mail in surprising ways.

This checker looks up those records for the domain you provide and summarizes what was found, including preference values and a few sanity checks that highlight common routing pitfalls. If you paste a website address or an email address, the input is normalized to just the hostname before the lookup runs. You can also compare results from different public resolvers when you suspect caching or propagation is involved.

Imagine you are moving a team mailbox to a new provider and you publish two mail servers with different preference numbers for redundancy. A clean result shows both targets, while warnings point out missing address records, alias chains, or a special no mail signal. Treat the checks as guidance rather than a verdict, since real delivery also depends on the sender, retry behavior, and network conditions. If the domain name itself is sensitive, consider whether policy allows you to query it using third party resolvers.

Recheck after changes and keep snapshots for comparison, because many systems cache routing answers for a while. Once the records look right, confirm with a real test message or your mail provider’s diagnostic logs.

Features:

Lists mail routing targets and their preference order for a domain.
Detects the special no mail record used to signal that a domain rejects email.
Optionally resolves each target hostname to IPv4 and IPv6 addresses.
Optionally checks whether a target depends on an alias chain.
Can compare answers from two public resolvers to spot inconsistencies.
Also checks for related policy records that influence authentication and transport.
Provides a structured JSON summary for copying or downloading.

Step-by-Step Guide:

Mail routing records show where email for a domain is expected to land, and a careful lookup helps you spot configuration gaps before they turn into delivery failures.

Enter the Domain as an apex name, or paste a URL or email address to extract it.
Pick a Resolver when you want a specific viewpoint, or leave it on Auto.
Enable Resolve MX hosts if you need to see the target IP addresses.
Enable Detect CNAME targets to catch targets that resolve through aliases.
Use Compare resolvers when results seem inconsistent across networks.
Adjust Max targets to cap how many targets are expanded for host checks.
Set Timeout if requests stall, or set it to 0 for no extra timeout.
Run the lookup, then review the record list first and the check results second.

Compact example

If you enter example.com and you see two targets with different preference values, that supports redundancy. If you see a no mail signal, treat it as an intentional configuration and do not publish other mail targets with it.

When you are diagnosing a delivery failure, prioritize FAIL items, then revisit WARN items that mention missing address records.

Recheck after changes to confirm caches have cleared.
If you are migrating providers, compare two resolvers to reduce false alarms.
If you only need the published targets, disable host resolution to reduce extra lookups.
Use the JSON summary when you need to paste exact results into a ticket.

Pro tip: when cutovers are time sensitive, validate the new targets first, then lower TTLs, then switch, and finally recheck from two resolvers.

The goal is a stable target set, clean parsing, and checks that match the story you expect about how mail should flow.

Technical Details:

Mail Exchanger (MX) records are Domain Name System (DNS) entries that advertise where email for a domain should be delivered. They are a routing hint for mail transfer agents that need to decide which hostnames to contact.

Each MX answer includes a numeric preference value, commonly called priority, and a target hostname. Senders generally try the lowest priority first, and move to higher priorities when delivery fails or a host is unreachable.

Null MX is a special MX form defined by RFC 7505 where the target is a single dot. It is an explicit signal that the domain does not accept email, and it must not be published alongside other MX targets.

Because delivery depends on both the MX set and the reachability of the target hosts, the tool can optionally resolve each target to IPv4 address records (A) and IPv6 address records (AAAA). It can also detect when a target resolves through a Canonical Name (CNAME) alias, which is discouraged for MX targets.

For quick mail security triage, the tool can also probe related TXT records that indicate the presence of Sender Policy Framework (SPF) at the apex, Domain-based Message Authentication, Reporting, and Conformance (DMARC) at _dmarc, Mail Transfer Agent Strict Transport Security (MTA-STS) at _mta-sts, and TLS Reporting (TLS-RPT) at _smtp._tls. These are presence checks based on version prefixes, not full policy validation.

Processing pipeline

Extract a hostname from a domain, URL, mailto link, or email address.
Convert the hostname to ASCII form and remove trailing dots.
Reject empty input and reject values that look like IPv4 or IPv6.
Query a DNS over HTTPS resolver for MX answers.
If enabled, query Cloudflare and Google and record both answer sets.
Parse each MX answer into priority and exchange, then deduplicate case insensitively.
Sort the set by priority ascending, then by exchange name.
If a Null MX is present, validate that it is not combined with other targets.
For each non-null target up to Max targets, optionally query A, AAAA, and CNAME.
Summarize checks and optionally probe TXT records for related mail signals.
Render tables and a JSON payload that captures the full lookup state.

Symbols and units used in the explanation
Symbol	Meaning	Unit/Datatype	Source
`D`	Domain name queried after normalization	string	Input
`R`	Resolver selection used for the primary MX query	enum	Input
`p`	MX preference value, often called priority	integer	Derived
`TTL`	Time to live value reported by the resolver for the answer set	seconds	Derived
`t`	Measured query duration for the primary lookup	milliseconds	Derived
`N_max`	Maximum number of MX targets expanded for host checks	integer	Input
`T`	Record type queried for expansion and related signals	string	Constant

Worked example

Suppose you enter admin@example.com. The tool extracts D as example.com, then queries for MX answers and parses each row into (p, exchange).

10 mx1.example.net.
20 mx2.example.net.

After parsing and normalization, the priorities and count might look like this.

p = 10

p = 20

n = 2

A typical interpretation is that mail delivery has at least two advertised targets, and the checker would report redundancy as a PASS if both are non-null.

If the resolver returns a single dot as the MX target, the tool treats it as Null MX and labels the domain as intentionally not accepting email.

.

Meaning of check statuses
Status	Meaning	Typical action cue
PASS	The observed records satisfy the checker’s rule for that item.	Keep as baseline and recheck after changes.
WARN	The result is missing data or suggests a potential issue worth investigating.	Confirm intent, then inspect addresses, aliases, and propagation.
FAIL	The observed records violate a rule that commonly breaks routing or interoperability.	Fix configuration, then requery and compare resolvers.
INFO	The tool is providing context rather than a pass or fail judgment.	Use as a pointer for deeper, selector specific checks.

Variables and parameters

Parameters and options used by the lookup
Parameter	Meaning	Unit/Datatype	Typical range	Sensitivity	Notes
`domain`	Domain, URL, mailto URI, or email address to normalize	string	Non-empty hostname	High	IP addresses are rejected.
`resolver`	Resolver preference for the primary MX query	enum	auto, cloudflare, google	Medium	Auto tries Cloudflare first, then Google on hard failure.
`resolve_hosts`	Whether to resolve MX targets to A and AAAA	boolean	true or false	Medium	If disabled, host reachability checks are skipped.
`detect_cname_targets`	Whether to query CNAME for each MX target	boolean	true or false	Medium	If disabled, CNAME related checks become WARN.
`compare_resolvers`	Whether to query Cloudflare and Google for MX and compare sets	boolean	true or false	Medium	Adds evidence rows and a resolver agreement check.
`run_related_checks`	Whether to probe TXT records for related mail policy signals	boolean	true or false	Low	Checks version prefixes only.
`max_targets`	Cap on how many MX targets are expanded for host checks	integer	0 to N	Low	0 means no limit; remaining targets are summarized, not expanded.
`timeout_ms`	Abort a single resolver request after this duration	milliseconds	0 to N	Medium	0 means no extra timeout beyond the network stack.

Constants and request shape

Constants used by the resolver queries
Constant	Value	Unit	Source	Notes
Answer content type	`application/dns-json`	MIME	Constant	Set as both the `accept` header and a `ct` query parameter.
Query parameter names	`name`, `type`, `ct`	string	Constant	`type` is uppercased before sending.
Record types queried	`MX`, `A`, `AAAA`, `CNAME`, `TXT`	string	Constant	Used for the main lookup, expansion, and related policy probes.
Expansion concurrency	6	workers	Constant	Limits parallel expansion of target checks to stay responsive.

Units, precision, and rounding

Resolver timing is rounded to the nearest millisecond and reported as an integer.
TTL is reported in seconds when provided by the resolver’s first answer record.
MX priorities are parsed as base 10 integers when formatted as priority exchange.
Exchange hostnames are normalized by removing a trailing dot and lowercasing for set comparison.
Boolean options accept true and false values and common string forms like 1 and 0.

Validation and bounds

Input validation rules and bounds
Field	Type	Min	Max	Step/Pattern	Error Text	Placeholder
Domain	string	—	—	Hostname extracted from URL or email	`Domain is required.`	`example.com`
Domain must not be IP	string	—	—	IPv4 or IPv6 patterns rejected	`MX lookups require a domain, not an IP address.`	—
Max targets	number	0	—	Step 1	—	—
Timeout	number	0	—	Step 100	—	—

Inputs and outputs

Accepted inputs and produced outputs
Input	Accepted families	Output	Encoding/Precision	Rounding
Domain text	Hostname, URL, mailto URI, email address	Normalized ASCII hostname	URL parser hostname rules	Trailing dot removed
MX lookup	Resolver JSON answer set	Rows with priority, exchange, and optional host details	Strings, arrays	Query duration rounded
Related signals	TXT answers for specific names	Presence status based on version prefixes	String prefix checks	Not applicable
Exports	Result tables and state	CSV, DOCX, and JSON downloads	UTF-8 text for CSV and JSON	Not applicable

Networking and storage behavior

The lookup is performed with cross origin HTTPS requests from the page to the selected public DNS over HTTPS resolver endpoint, using query parameters for name and type and requesting application/dns-json responses. A per request timeout can abort slow requests, and the related signal probes perform additional TXT queries at the expected policy names.

Privacy and compliance

Because the queried domain name is sent to a third party resolver as part of the request, treat internal domains as potentially sensitive in regulated environments.

Performance and complexity

Parsing and sorting the MX set is roughly O(n log n) for n answers.
Expansion work is bounded by N_max and by which checks you enable.
Time is dominated by network latency and resolver response time.
Expansion runs with a small fixed concurrency limit to reduce UI stalls.

Diagnostics and determinism

Given the same resolver answers, the normalization, sorting, and check outcomes are deterministic. Differences across resolvers, caches, and timing can produce different answer sets, which is why the resolver comparison option focuses on set level agreement rather than a single snapshot.

Security considerations

Queries are built with a URL constructor and query parameters, reducing injection risk in request URLs.
Cross origin requests use default fetch credentials, which do not include cookies for other origins.
The JSON view is rendered as highlighted markup, so unusual inputs can affect display if escaping is imperfect.
Do not treat policy presence checks as proof of correct authentication or transport enforcement.

Assumptions and limitations

Heads-up TTL is taken from the first answer record when present, not averaged across answers.
Auto resolver selection falls back only when the first resolver request fails completely.
MX answer sets are deduplicated and normalized by lowercasing exchange names for comparison.
When Max targets is below the number of targets, unexpanded targets are summarized but not host checked.
CNAME detection depends on whether the resolver returns CNAME answers for the target name.
Host resolution checks only whether A and AAAA answers exist, not whether a mail port is reachable.
Related signal checks look for version prefixes, not full record parsing or policy evaluation.
DKIM selector discovery is not automated, because selectors are deployment specific.
Some domains rely on implicit mail fallback behavior, which is only noted as a warning when MX is missing.
Internationalized domain names depend on the platform URL parser for ASCII conversion behavior.

Edge cases and error sources

Trailing dots in hostnames are removed before querying, which can change how you compare to zone files.
IPv6 inputs containing :: are treated as likely IP addresses and rejected even if malformed.
Resolvers can return MX data in unexpected formatting, which can lead to a missing or null priority.
Quoted segments in TXT answers are concatenated, which can hide segment boundaries in long records.
DNS answers can differ by geography, network, or split horizon configurations.
Propagation delays can cause Cloudflare and Google to disagree for minutes or hours after changes.
Timeout aborts can surface as empty answers with a failed status and no TTL.
Unicode domain input may normalize differently across platforms, affecting punycode conversion.
Very large MX sets can produce long tables and increase expansion time when Max targets is unlimited.
Records that resolve through multiple aliases can yield different CNAME visibility across resolvers.
Stale caches can make a fixed snapshot look correct even when authoritative data has changed.
Race conditions between parallel expansion queries can reorder notes, even when the underlying data matches.

Standards and references

The DNS concepts used here are defined in RFC 1035, SMTP delivery behavior is specified in RFC 5321, Null MX is defined in RFC 7505, and DMARC is defined in RFC 7489.

Troubleshooting:

You get No MX records found. and a WARN check, confirm whether the domain should receive mail at all.
The tool warns that mail fallback may apply, check whether the apex has usable address records if you rely on fallback.
Resolver agreement is WARN, rerun with Compare resolvers and wait for propagation to settle.
MX targets are flagged as CNAME, update the MX to point at the canonical hostname instead of an alias.
MX targets lack A or AAAA, add the missing address records or confirm you are querying the right hostname.
Only one active target is found, add a second target if you require redundancy.
Requests time out, increase the timeout or try a different resolver and network path.

If the input is an IP address, the lookup is blocked because MX records are published for domains, not for IP literals.

Advanced Tips:

Tip Use resolver comparison when a change looks correct on one network but not another.
Tip Keep Max targets small for quick triage, then increase it only when you need deeper host checks.
Tip When you see a CNAME warning, aim to publish MX targets as direct canonical hostnames.
Tip If A is empty but AAAA exists, confirm that your mail infrastructure supports IPv6 end to end.
Tip Treat related policy signals as a checklist for next steps, not a compliance report.
Tip If you rely on fallback behavior, document it, because many senders treat it differently.
Tip Requery after lowering TTLs during migrations to reduce the window of inconsistent answers.
Tip Copy the JSON state into tickets to preserve the exact resolver, timing, and options used.

FAQ:

Is my data stored?

The script performs resolver queries from your device and renders the results in the page. The provided logic does not write results to local or session storage. Queried domain names are sent to the selected public resolver as part of the request.

Why do results differ?

Different resolvers can have different cache states, different upstream paths, or different views of split horizon DNS. Enable resolver comparison to see whether the returned MX sets actually disagree, then wait for propagation or verify authoritative data if needed.

What does WARN mean?

WARN indicates a potential issue or missing evidence, such as no MX records, only one active target, a target without A or AAAA, or a check that was disabled. It is a prompt to investigate intent and reachability, not a guarantee of failure.

What inputs are accepted?

You can enter a plain domain, paste a URL, paste an email address, or use a mailto URI. The tool extracts the hostname, trims trailing dots, converts it to ASCII when possible, and rejects values that look like IPv4 or IPv6 addresses.

Does it work without network?

No. The lookup relies on HTTPS requests to the selected public resolver to fetch DNS JSON answers, so it needs network connectivity and outbound HTTPS access.

What does TTL represent?

TTL is the time to live value in seconds returned by the resolver for the answer set. The tool displays the TTL from the first answer record when present, which is helpful for estimating how long caches may keep the current view.

How do I validate MX records?

Start by confirming at least one MX target exists and that priorities parse cleanly. If the domain should receive mail, avoid a Null MX dot target. Then resolve each target to A or AAAA to catch missing addresses, and compare two resolvers when you suspect propagation.

Is there a cost or license?

No pricing or licensing terms are included in the provided files. Any terms come from the site that hosts this page.

Glossary:

MX record: DNS record that advertises mail delivery targets for a domain.
Priority: Preference number where lower values are typically tried first.
Exchange: Hostname named as the mail delivery target in an MX record.
Null MX: A dot target indicating the domain does not accept email.
Resolver: Service that answers DNS questions using its cache and upstream sources.
TTL: Cache lifetime hint for a DNS answer, measured in seconds.
A record: DNS address record that maps a hostname to an IPv4 address.
AAAA record: DNS address record that maps a hostname to an IPv6 address.
CNAME: Alias record that maps a hostname to another canonical hostname.
TXT record: Free form DNS text record often used for email policy signals.