| 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 || '-' }} |
| Check | Status | Evidence | Recommendation | Copy |
|---|---|---|---|---|
| {{ check.label }} | {{ check.status }} | {{ check.note || '-' }} | {{ check.recommendation || '-' }} |
| Resolver | Status | Code | AD | Time (ms) | Answer fingerprint |
|---|---|---|---|---|---|
| {{ row.resolver }} | {{ row.status }} | {{ row.code }} | {{ row.ad ? 'Yes' : 'No' }} | {{ row.timeMs }} | {{ row.answers || '-' }} |
Mail exchanger records tell other mail systems which hostnames should accept incoming mail for a domain and which one should be tried first. When they are missing, contradictory, or pointing at unreachable hosts, delivery can queue, bounce, or end up on the wrong provider.
This lookup turns that routing story into a readable summary for the domain you enter. It accepts a plain hostname, URL, mailto link, or email address, normalizes the host portion, converts internationalized names to their ASCII form, and then checks the published MX answers.
The tool also separates several states that are easy to blur together in conversation but have different SMTP meaning. A domain can publish active MX hosts, publish no MX and rely on implicit A or AAAA fallback, explicitly reject inbound mail with Null MX, or drift into an invalid mixed state where Null MX appears beside active targets.
Use the output as a routing and hygiene check, not as proof that end-to-end delivery will succeed. The page does not send a test message or parse every mail policy in depth, and its DNS queries go from your browser to public DNS-over-HTTPS resolvers, so the queried domain should be treated as data you are deliberately disclosing.
Start with the default path when the question is simple: "If another mail system looks this domain up right now, what route will it probably try?" The Routing Matrix shows the targets, while the Compliance Scorecard turns the main failure modes into pass, warn, and fail rows.
Quick triage is enough when you only need to confirm that a route exists and whether the obvious hosts resolve. Standard mode suits most support and change-review work. Deep mode is better when a migration is close to production, because it expands more targets and runs the stricter RFC-oriented checks against a wider set of evidence.
Resolver comparison matters when someone reports inconsistent results across networks or you have just changed records and expect cache drift. In that situation the Evidence Log and Resolver Drift chart show whether Cloudflare and Google saw the same answer set and how long each lookup took.
The related TXT checks are ecosystem context, not full policy parsing. They look only for the standard version markers that identify SPF at the zone apex, DMARC at _dmarc, MTA-STS at _mta-sts, and TLS-RPT at _smtp._tls.
MX lookup is an SMTP routing step, not a full delivery simulation. A sender asks DNS for MX records, sorts the returned exchanges by preference, and normally tries the lowest-numbered host first. If no MX exists, delivery can fall back to the domain's A or AAAA record.
Null MX changes that interpretation. A single dot advertised as the exchange is an explicit statement that the domain does not accept inbound mail. Publishing that special form beside live MX hosts is contradictory, so this tool breaks Null MX out as its own scorecard rule and can escalate the mixed case to FAIL when strict RFC scoring is enabled.
The page runs these checks in the browser by sending DNS-over-HTTPS requests to Cloudflare and Google. In Auto mode it tries Cloudflare first and only falls back to Google on a hard failure. When resolver comparison is enabled, both resolvers are queried for MX so the tool can fingerprint the answer sets side by side.
Raw answers are normalized before they become table rows. The host extractor accepts a bare domain, URL, mailto link, or email address, removes trailing dots, converts internationalized names to ASCII, rejects IP literals, and parses each MX answer into a numeric preference plus exchange name. The rows are then sorted by preference and hostname for stable repeat runs.
Expansion and scoring happen after the primary MX parse. Non-null targets can be checked for A records, AAAA records, and CNAME answers. If no MX exists, the tool separately queries the apex A and AAAA records so it can distinguish implicit SMTP fallback from a true no-route condition.
The validation-depth selector changes how aggressively the page expands MX hosts. The default expansion caps are built into the client logic and can then be lowered or raised with the Max expanded targets control, up to a hard ceiling of 120 targets.
| Mode | Default expansion cap | Parallel host checks | Typical use |
|---|---|---|---|
| Quick triage | 8 | 3 | Fast confirmation of route presence and basic host resolution. |
| Standard | 20 | 5 | Routine troubleshooting and change review. |
| Deep audit | 40 | 8 | Pre-cutover checks and larger MX sets. |
| Output | Derived from | What it tells you |
|---|---|---|
| Routing Matrix | Parsed MX rows plus optional A, AAAA, and CNAME expansion | The advertised route set and any host-level notes. |
| Compliance Scorecard | Rule checks built from MX presence, Null MX state, CNAME evidence, host resolution, redundancy, related TXT markers, and optional resolver comparison | The pass, warn, and fail findings built from the observed data. |
| Preference Ladder | Non-placeholder rows and their parsed preference values | A quick view of route ordering. |
| Resolver Drift | Per-resolver timing and answer counts | Whether the sampled resolvers are returning the same routing picture. |
| Evidence Log | Resolver name, HTTP-style DoH status, authenticated-data flag, timing, answer count, and compact answer fingerprint | The side-by-side evidence used for drift review. |
| JSON export | Normalized inputs plus rows, checks, resolver_evidence, and related_signals |
A structured snapshot you can archive or compare later. |
The scorecard focuses on a small set of operational rules: whether explicit MX exists, whether Null MX is isolated correctly, whether expanded targets resolve and avoid CNAME aliases, whether priorities parse cleanly, whether there is any redundancy, and whether sampled resolvers agree. The related TXT rows sit beside those findings as context rather than as a substitute for full mail-policy validation.
The SPF, DMARC, MTA-STS, and TLS-RPT rows are marker checks only. They confirm that a recognizable version string is present at the expected DNS name, not that the record syntax, policy content, HTTPS endpoint, or report destination has been fully validated.
If the page shows Domain is required. or MX lookup requires a domain name, not an IP literal., correct the input before changing any of the advanced options.
Domain as a hostname, or paste a URL or email address and let the page extract the host portion for you.Auto for a normal check, or pin Cloudflare or Google when you need a specific resolver view.Quick triage, Standard, or Deep audit based on how much host-expansion evidence you need.Resolve MX hosts enabled when deliverability matters, because unresolved exchanges are one of the first causes of misleading "looks fine on paper" DNS setups.Detect CNAME targets enabled during production review so alias chains are surfaced instead of silently ignored.Compare resolvers when records have just changed or you suspect different networks are seeing different answers.Strict RFC scoring if you want the mixed Null MX case treated as a fail-grade issue, and adjust Max expanded targets or Request timeout when the zone is large.If the result lands in No SMTP route, pause before treating it as an outage. Some domains intentionally reject mail, and others rely on implicit fallback even though explicit MX would be clearer.
The summary badges combine route count, mail mode, score distribution, lookup time, TTL, and resolver choice into one compact status line. The mail-mode badge is the most important of those fields because it tells you which SMTP story the rest of the page is describing.
| Mail mode badge | Meaning | Typical next step |
|---|---|---|
| Active MX mode | One or more explicit MX records were found and expanded. | Check priority ordering, redundancy, host resolution, and resolver agreement. |
| Null MX mode | A single dot is published as the MX exchange and no active MX hosts were combined with it. | Confirm that the domain is intentionally configured to reject inbound mail. |
| Implicit A/AAAA fallback | No MX record was found, but the apex domain resolved to A or AAAA records. | Treat it as a reachable but weakly signaled mail route and consider publishing explicit MX. |
| Mixed Null MX state | Null MX appeared beside active MX hosts. | Correct the zone so it advertises one clear policy instead of both. |
| No SMTP route | No MX was found and no apex A/AAAA fallback was detected. | Decide whether the domain should reject mail or whether routing records are simply missing. |
The pass-warn-fail badge is a triage shortcut, not a delivery guarantee. A green score does not prove that remote senders can negotiate TLS, reach port 25, or pass the receiving provider's own policy checks.
The Evidence Log is the best place to validate a resolver-drift warning. Compare the answer fingerprints, answer counts, status codes, and timing rows directly. If the resolver sets differ, rerun after the reported TTL window or check the authoritative zone before deciding that the page has found a durable misconfiguration.
Treat the related-signal rows with the most caution. A PASS for DMARC, MTA-STS, or TLS-RPT means only that the expected version token was present at the expected DNS name.
A domain is moving mail to a new provider and publishes two exchanges, one at preference 10 and one at preference 20. The page returns Active MX mode, both hosts resolve to A or AAAA records, no CNAME aliases are found, and the redundancy rule passes.
A documentation or parked domain should never accept inbound mail, so the zone publishes a single Null MX. The tool reports Null MX mode, the isolation rule passes, and there are no active routes in the matrix. In that case the correct action is usually to keep the result as a baseline rather than "fix" it by adding ordinary MX records.
You update MX records and one colleague still sees the old provider while another sees the new one. With resolver comparison enabled, the scorecard warns on resolver agreement and the Evidence Log shows different answer fingerprints between Cloudflare and Google. That points to propagation or split-view behavior. The corrective path is to compare authoritative answers, wait through the TTL window, and rerun the check.
SMTP can fall back to the domain's A or AAAA record when no MX is published. This tool checks that fallback path and labels it separately as Implicit A/AAAA fallback so you can distinguish a weak route from a complete lack of route.
Not immediately. Different public resolvers can hold different cached answers during propagation, and some environments use split-view DNS. Check the Evidence Log, compare the answer fingerprints, and then verify the authoritative zone before deciding whether there is a lasting fault.
No. The page only checks for the expected version markers, such as v=DMARC1 or v=TLSRPTv1. It does not parse the entire policy, test HTTPS hosting, or confirm report destinations.
The lookup needs a domain name. Blank input triggers Domain is required., and IP literals trigger MX lookup requires a domain name, not an IP literal. Paste the hostname itself, or let the page extract it from a URL or email address.