Primary use
MX record lookup
Check the live inbound mail-routing state for any domain before assuming a migration is complete.
Run a free lookup
Check the live MX routing for a domain
Enter the root domain. This MX checker returns the advertised exchanges, their priority ordering, and any warnings that deserve review before the next mail-dependent launch.
Best fit
Use this after DNS edits and mail-provider cutovers
MX lookup is strongest when the inbound routing state matters immediately: after migrations, while debugging missing inbound mail, or before relying on a support or sender domain in production.
- Validate inbound routing after provider migrations
- Check priority order before switching traffic
- Confirm support and reply domains still accept mail publicly
Upgrade path
Connect routing checks to sender-domain reviews
MX lookup answers the inbound DNS question. Production teams usually combine it with SPF, DKIM, DMARC, domain-health checks, and real inbox tests when mail reliability needs named ownership.
- Review routing and sender auth in one workflow
- Monitor domain health before launch windows
- Shorten incident triage when mail paths change
Key details
Routing signal
Priority order
Review whether primary and fallback exchanges are published the way the team expects.
Operational fit
Post-change validation
Use it after DNS edits, provider cutovers, or incident mitigation to confirm public state.
Output
Hosts + warnings
See the live exchange set and any issues worth reviewing before traffic depends on it.
When to use this tool
Confirm live routing
See the public MX state instead of relying on what a DNS console says was published.
Review priority order
Make sure primary and fallback exchanges are exposed in the order the provider expects.
Catch post-migration drift
Use the lookup after provider changes so support or product email does not quietly route to the wrong infrastructure.
What this returns
An MX lookup should answer the inbound routing question quickly
The useful output is not only the raw record. It is whether the expected exchanges are live, how they are prioritized, and whether there are warnings that suggest routing or migration follow-up.
Exchanges
Live hosts
See which mail exchanges receivers can actually resolve for the domain.
Priority
Routing order
Confirm primary and fallback exchange order instead of guessing after DNS edits.
Warnings
Review notes
Catch issues that deserve review before support or reply flows depend on the route.
Workflow
Post-change check
Use it immediately after migrations or provider cutovers as part of change review.
Email DNS workflow
Use MX checks with authentication, propagation, and inbox validation
MX records prove where inbound mail should go. Pair that with auth checks and real message tests when a domain is used for support, replies, parsing, aliases, or product workflows.
MX
Receive route
Confirm inbound mail servers and priority order for the domain.
SPF/DKIM
Sender trust
Validate outbound authorization and message signing before judging delivery.
DMARC
Alignment
Check sender policy and alignment with the visible From domain.
Inbox test
Real outcome
Send a message through the workflow and verify receipt, headers, and timing.
Operational use
Best used during migrations, support-route validation, and incident triage
Searchers usually need an MX lookup because mail is changing or already failing. Treat this page as part of change control and diagnosis, not as a static DNS reference.
After provider migration
Re-run the lookup after cutover so the team knows the public route now points at the intended provider.
Support and reply domains
Confirm customer-facing domains still advertise a healthy inbound route before support traffic or replies are affected.
Mail-flow incidents
Use the live record set as a shared starting point before escalating to provider-specific delivery logs or transport checks.
MailSlurp workflow
Turn an MX record check into a receive-email validation flow
After the public MX state is correct, use MailSlurp to create controlled inboxes, route inbound mail, capture replies, trigger webhooks, and assert that the real message workflow behaves correctly.
Custom domains
Verify routing before attaching domains to inbox, alias, support, or parsing workflows.
Inbound automation
Pair MX readiness with webhooks and receive-email APIs so messages reach the application path that depends on them.
Release checks
Test signup, reply, support, and notification flows after DNS changes so teams catch routing mistakes early.
Related tools
MX lookup guide
Use the broader MX routing guide when you need migration, priority, and receive-workflow context beyond the raw lookup.
Open toolDNS lookup
Inspect other DNS records alongside MX when the domain needs a broader routing or auth review.
Open toolDomain monitor
Pair MX routing with sender-domain posture when production mail needs a fuller health check.
Open toolMTA-STS checker
Review SMTP transport security policy alongside inbound routing state.
Open toolTLS reporting checker
Confirm report visibility when transport policy changes need follow-through.
Open toolFAQ
What does an MX lookup tool check?
An MX lookup fetches the public mail-exchange records for a domain so you can confirm which inbound mail servers are advertised, what priorities they use, and whether the routing looks consistent with the provider you expect.
Why should teams run an MX record check after migrations?
MX changes often look complete in a DNS console before the live routing state is fully validated. A lookup confirms the public result after provider cutovers, tenant moves, or recovery changes.
What if no MX record is found?
Some domains intentionally do not receive email, but for production sender or support domains this usually means inbound routing is incomplete or published on the wrong zone.
Does MX lookup replace SPF, DKIM, or DMARC checks?
No. MX lookup answers the inbound routing question. Sender trust still depends on SPF, DKIM, and DMARC when outbound delivery reliability matters.
When should I run an MX record check?
Run MX checks after mailbox migrations, support-domain changes, inbound routing cutovers, DNS edits, and before relying on a custom domain for receive-email workflows.
How does MX lookup fit with MailSlurp?
Use MX lookup to confirm public routing, then use MailSlurp inboxes, webhooks, aliases, and integration tests to verify that the real inbound workflow receives and handles messages correctly.