MX record lookup sounds simple until email starts failing and the team is not sure whether the problem is DNS, sender authentication, mailbox hosting, or the application itself.
That confusion happens because MX records affect only one part of the mail path. They control where inbound email for a domain should go. They do not solve every delivery issue, but when they are wrong, email routing can break fast.
This guide explains what MX records do, how to look them up, how to verify propagation, and how to connect DNS checks with the real email flows your product depends on.
Quick answer
If you need to verify MX records quickly:
- run
- confirm the expected mail hosts and priority numbers appear
- repeat from more than one resolver if a DNS change is recent
- make sure the target hosts themselves resolve correctly
- after DNS changes, send a real test message and verify the inbox outcome
MX lookup tells you where mail should go. It does not prove the right email reached the right inbox. For release-critical flows, you still need inbox-level validation after DNS work is done.
What an MX record does
An MX record, or Mail Exchange record, tells other mail servers which host should receive inbound email for a domain.
For example, if your domain is , the MX record may point to a mailbox provider such as Google Workspace, Microsoft 365, or another hosted mail service.
A typical result looks like this:
The lower number has higher priority. In most cases, sending servers try the lowest-numbered MX target first and only fall back to higher values if needed.
How to run an MX record lookup with
The fastest command-line check is:
If you want the full answer section and DNS metadata:
Useful things to inspect:
- are the expected MX hosts present?
- are the priorities correct?
- did the answer come from the resolver you expected?
- are you checking the correct domain or subdomain?
How to run an MX record lookup with
If is unavailable, still works:
The output is usually less comfortable to read than , but it is enough to confirm the receiving mail hosts.
How to read MX lookup results
There are three things that matter most:
1. Hostnames
The hosts should belong to the mailbox provider you expect to receive inbound mail.
2. Priority values
Lower number means higher priority. If the provider gives you a recommended order, keep it.
3. Consistency
The results should be stable across queries once the DNS change has propagated.
If you recently updated DNS and still see mixed answers, propagation may still be in flight.
Common MX lookup mistakes
Looking up the wrong domain
Teams often check the root domain when the mailbox configuration is actually on a subdomain, or the reverse.
Expecting MX to control outbound mail
MX records control inbound routing. They do not define which SMTP service your application uses to send outbound email.
Pointing MX at the wrong provider
This happens during migrations when the DNS zone is updated partially or copied from old infrastructure.
Forgetting to validate the target hosts
An MX lookup can show a host, but that host still needs to resolve and belong to a working mailbox provider.
Confusing mailbox hosting with domain authentication
Inbound routing is not the same as SPF, DKIM, or DMARC configuration.
MX records vs SPF, DKIM, and DMARC
These records solve different problems:
- MX decides where inbound email should be received
- SPF helps receivers validate authorized sending infrastructure
- DKIM helps receivers validate message signing
- DMARC defines alignment and policy for failing messages
A domain can have correct MX records and still fail sender authentication. The reverse is also true: SPF, DKIM, and DMARC can be perfect while inbound routing is still broken.
Related reading:
How to verify propagation after an MX change
DNS problems often come from timing rather than configuration syntax.
After a change:
- query the record more than once
- check from a second resolver if needed
- confirm the provider-specific targets are exactly correct
- wait out TTL if old answers are still cached
If the infrastructure looks right but mail behavior is still suspicious, move from DNS inspection to workflow testing.
Verify routing with a real inbox workflow
MX lookup tells you the route the internet should use. It does not prove that your product email flow still behaves correctly after DNS changes.
That distinction matters when the user journey depends on email:
- account verification
- magic links
- password resets
- billing notifications
MailSlurp fits after the DNS check, not instead of it. A practical workflow is:
- confirm MX records are correct
- trigger the real product email flow
- capture the message in a controlled inbox
- verify sender, subject, links, and timing
That gives you operational confidence that the routing change did not silently break the experience users depend on.
Useful routes:
When an MX lookup is not enough
Use an MX lookup when you need to answer:
- where is inbound mail supposed to go?
- did DNS update correctly?
- are the provider hostnames correct?
Use broader troubleshooting when you need to answer:
- is outbound email authenticated correctly?
- is the message landing in spam?
- did the user-facing workflow actually complete?
That is why good email operations rarely stop at DNS tools alone.
FAQ
Do MX records affect outgoing email?
No. MX records are for inbound routing. Outbound email typically depends on your application sender, SMTP provider, and sender authentication setup.
What does the priority number mean?
Lower number means higher priority. Sending servers usually try the lowest-numbered target first.
Why do I see old MX results after a change?
DNS propagation and caching can delay what different resolvers return.
Should I test email after changing MX records?
Yes. DNS correctness is necessary, but you should still verify the real inbox outcome for important product flows.