An MX lookup shows which mail servers receive inbound mail for a domain and in what priority order remote mail systems should try them.
If you are searching for , , , or , the practical goal is usually one of three things: confirm the domain can receive mail, verify a provider migration, or troubleshoot why inbound mail is going to the wrong place.
Executive summary
- Use an MX lookup after mailbox migrations, support escalations, and DNS edits to confirm the live inbound route instead of trusting what the admin console says.
- Lower MX priority numbers are tried first, so a single reversed priority can send mail into an old provider or dead environment.
- MX records only answer the inbound routing question. You still need SPF, DKIM, and DMARC checks for outbound trust.
- A successful MX record check should confirm three things: the right provider hostnames are present, the order is correct, and the target hosts still resolve.
Quick answer
An MX lookup should tell you:
- whether the domain publishes MX records at all
- which hostnames receive inbound mail
- which server is preferred based on priority
- whether the published targets match the provider you expect
If MX records are missing or wrong, the domain may stop receiving email even when SPF, DKIM, and DMARC are configured correctly.
What an MX lookup result means
MX stands for Mail Exchanger. These records tell sending systems where to deliver mail for the domain.
A typical result looks like this:
That means:
is the preferred inbound targetis the lower-priority backup
Lower numbers mean higher priority.
What to check in an MX lookup
Do not stop at "records found." Review all of these:
- at least one MX record exists
- priority values make sense
- every MX hostname resolves correctly
- the published hostnames belong to the intended provider
- old provider targets are not still present after migration
This matters because a record can be syntactically valid while still routing mail to the wrong place.
What an MX record check is really for
The highest-value MX checks usually happen during change windows, not routine documentation review.
Use an MX lookup when you need to answer questions like:
- did the domain cut over to the new provider yet?
- is support mail still pointed at the old tenant?
- are reply addresses routed to the environment we think is live?
- did a DNS edit publish correctly after the change request closed?
This is why MX record checks are operational. The page is not just about understanding DNS. It is about proving that inbound mail should still work after a risky change.
How to run an MX lookup
Use this workflow:
- query the domain for MX records
- list the target hostnames and priority values
- confirm the highest-priority server matches your intended provider
- verify all target hostnames resolve
- compare the result with live inbound behavior
If you need the broader reference guide behind the DNS concepts, use MX records guide.
If you want the live interactive tool first, use the MX record checker.
How MX priority works
Priority numbers determine the order in which remote mail systems should try the listed destinations.
| Priority value | Meaning |
|---|---|
| Lower number | Higher preference |
| Higher number | Lower preference |
| Equal numbers | Usually load sharing or provider-specific behavior |
Priority does not reflect trust or reputation. It only reflects routing preference.
If the backup server has the lower number by mistake, mail can be routed into the wrong environment even though the domain technically has valid MX records.
MX lookup after migrations and provider cutovers
Mailbox-provider migrations are where MX lookups earn their keep.
The common failure pattern looks like this:
- the admin console shows the new provider records
- the DNS zone publishes partially or with the wrong priority order
- some inbound mail still routes to the old provider
- support teams only notice after messages disappear or bounce replies fail
Run an MX lookup immediately after:
- Google Workspace or Microsoft 365 migrations
- support mailbox platform moves
- inbound parsing or forwarding cutovers
- domain onboarding for new products or tenants
- recovery changes after an outage
Do not stop when the expected hostname appears once. Confirm the full set and the exact order.
When to use an MX lookup
An MX check is especially useful during:
- new domain setup
- mailbox-provider migration
- support incidents involving missed inbound email
- verification and signup workflow testing
- catch-all and alias troubleshooting
Teams also use MX lookups before enabling email verification or inbound routing features to confirm the domain is configured to receive mail at all.
How to tell if the result matches the provider you expect
An MX lookup is only useful if you compare the result to the provider you meant to publish.
Review:
- whether all published MX hosts belong to the intended provider
- whether any legacy provider hosts are still in the result
- whether the priority pattern matches the provider's documented order
- whether the domain is mixing two providers accidentally
If the hostname set looks unfamiliar, treat that as a routing problem until proven otherwise.
MX lookup vs SPF, DKIM, and DMARC
These are related but different controls.
| Record type | Main purpose |
|---|---|
| MX | Inbound mail routing |
| SPF | Outbound sender authorization |
| DKIM | Message signing and domain integrity |
| DMARC | Alignment and receiver policy |
A domain can have perfect SPF and DKIM and still fail to receive email if MX records are wrong. Likewise, clean MX records do not guarantee outbound trust.
Use MX checks with:
Common MX record problems
No MX records published
If a domain has no MX records, many systems treat it as not properly configured for mail reception.
Wrong provider after migration
The domain still points to the previous mailbox provider, or only part of the migration completed.
Priority order is reversed
A backup or legacy system is accidentally preferred over the primary destination.
Target hostname does not resolve
The MX record exists, but the hostname it points to has broader DNS issues or was decommissioned.
Mixed-provider configuration
Two different providers appear in the MX set without a deliberate design, which can create inconsistent routing and hard-to-debug support issues.
MX troubleshooting matrix
| Symptom | Likely cause | Next checks |
|---|---|---|
| Inbound mail stopped after migration | old provider MX hosts still published or preferred | compare published MX set to provider docs, then check priority order |
| Some replies arrive, others disappear | mixed-provider routing or partial cutover | review all MX targets, not just the first one |
| Domain looks valid but cannot receive email | no MX record or broken target hostname | run MX lookup, then verify target host resolution |
| Support inbox works in one environment only | stale DNS in a subdomain or split route by tenant | compare MX results across all receiving domains and subdomains |
| Verification emails send but replies fail | outbound auth is fine but inbound path is broken | pair MX lookup with SPF/DKIM/DMARC review and live send tests |
MX troubleshooting workflow
When inbound mail is not arriving as expected:
- run an MX lookup
- confirm the intended provider hostnames are present
- verify every target resolves
- send test mail and compare observed routing
- check whether support issues align with DNS-change timing
If the domain is used for reply handling, support intake, forwarding, or inbound parsing, pair routing checks with Inbound email API, Receive email API, and Email webhooks so you validate the actual receive-side workflow, not only the DNS answer.
For identity-path debugging after an infrastructure move, also review Reverse DNS lookup.
MX lookups in receive-email workflows
MX checks are useful because they help answer a simple but important question: can this domain receive mail in a sane way right now?
That is relevant for:
- support inbox routing
- inbound parsing and reply handling
- catch-all or alias routing
- contact-form and workflow intake
- receive-side automation during onboarding or migration
Supporting pages:
Use MailSlurp for MX-dependent email checks
MX lookup sits in the Messaging foundation: it tells you whether a domain is ready to receive mail before you layer on verification, parsing, or automated tests.
MailSlurp turns MX lookups into a broader implementation workflow instead of a one-off DNS check.
Use:
- MX record checker for the live DNS answer
- DNS lookup to inspect related records
- Inbound email API when the mailbox needs to feed an application workflow
- Receive email API when your team needs programmatic inbox access after routing is fixed
- Email webhooks when MX readiness needs to connect directly to automation
- Email integration testing when inbound and outbound message flows need automated assertions
Create an account at app.mailslurp.com to start wiring MX checks into receive-email automation and routing validation workflows.
FAQ
What is an MX lookup?
It is a DNS lookup that shows which mail servers receive email for a domain and what order remote systems should try them in.
What does MX stand for?
MX stands for Mail Exchanger.
What is the difference between MX lookup and SPF check?
MX is about inbound routing. SPF is about who is allowed to send outbound mail for the domain.
Can a domain receive email without MX records?
Sometimes mail systems fall back to the A record, but that is not a reliable production setup. A proper mail-receiving domain should publish explicit MX records.
When should I run an MX record check?
Run one after provider migrations, DNS edits, tenant onboarding, inbound routing changes, and any incident where replies or support mail are not landing where they should.
Does an MX lookup confirm inbox placement?
No. It confirms the inbound route. Inbox placement and sender trust still depend on SPF, DKIM, DMARC, content posture, and provider reputation.
Final take
An MX lookup is one of the fastest ways to verify whether a domain is actually ready to receive mail. It is especially valuable during migrations, onboarding, and troubleshooting because routing mistakes are easy to publish and easy to miss until users stop receiving messages.