Your app's welcome emails are bouncing, users aren't receiving password resets, and the application logs only show a vague delivery failure. Before changing application code or inspecting every SMTP setting, check the domain's MX record. That DNS entry tells sending mail servers where they should deliver messages, so it's often the fastest way to separate a routing problem from an application problem.
Knowing how to check MX record results also helps you avoid a common mistake: treating a successful lookup as proof that a mailbox exists. An MX check confirms the published mail route. Reliable deliverability requires additional checks after that route has been confirmed.
Table of Contents
- Why Checking MX Records Is Your First Step in Email Troubleshooting
- The Quickest Method Using an Online MX Record Checker
- Checking MX Records from the Command Line
- How to Interpret Your MX Record Results
- Troubleshooting Common MX Record Problems
- Beyond MX The Next Step in Email Verification
Why Checking MX Records Is Your First Step in Email Troubleshooting
An MX, or Mail Exchange, record is the DNS record that identifies the mail servers responsible for receiving email for a domain. In practical terms, it works like the postal address for a domain's email. When another mail server needs to deliver a message to user@example.com, it looks up the MX records for example.com, selects an eligible mail host, and starts the delivery process there.
MX records also include a preference value, commonly called priority. Each entry pairs the domain with a 16-bit preference value, and lower numbers are tried first. RFC 974 formally introduced this priority-based MX model in January 1986, creating a standard way for domains to publish multiple mail servers with ordered delivery preferences. RFC 974 documents the original MX design.
That design still matters. A domain might publish one primary mail server and one or more alternatives. If the preferred server can't accept delivery, the sending system can try another published host. This gives administrators a basic mechanism for redundancy without putting the receiving server's address directly into application configuration.
Start with the route, not the symptom
Suppose your application reports that an email was sent, but the recipient never receives it. Several systems sit between that application event and the final inbox. Your app may hand the message to an SMTP provider, that provider may query DNS, and the recipient domain may direct mail to a hosted platform rather than its website server.
An MX lookup answers the first important infrastructure question: does the recipient domain publish a mail route, and does that route point where you expect?
Use an MX record glossary entry when you need a concise reference for the record's structure. Then compare the published mail hosts with the provider configured for the domain. If the result is empty, points to an old provider, or contains a hostname that doesn't resolve, deeper application debugging won't fix the delivery path.
Practical rule: Confirm the domain's published mail route before investigating message content, templates, or retry logic.
An MX check isn't a complete deliverability test, but it's a high-value first diagnostic. It establishes whether DNS is directing mail toward a real receiving system and gives you the hostnames needed for the next checks.
The Quickest Method Using an Online MX Record Checker
A customer may report that messages are missing while the domain appears correctly configured in the application. An online MX checker gives you a fast way to inspect the receiving route before spending time on templates, authentication, or application logs. It works well for product managers validating a setup, support engineers checking a customer domain, and developers reviewing a provider migration.
Open an online MX lookup tool and enter the domain name only. Do not enter a complete email address unless the tool explicitly requests one. The result should show the mail-server hostnames, their priority values, and often the TTL, or Time To Live. TTL indicates how long recursive resolvers may cache the response, so it can help explain why two tools temporarily show different results.
Read the result as a configuration check
Use the output to answer four practical questions:
- Did the domain return any MX records?
- Which hostnames receive mail?
- What priority does each hostname have?
- Does the TTL explain different answers from different tools?
Compare every returned hostname with the provider's documented configuration. Do not inspect only the first row. If several MX records are published, the complete set expresses the domain's delivery order and fallback behavior. Operational guidance from Prospeo for MX lookups recommends starting with a raw query and verifying every returned host and priority.
An online checker is convenient, but its result normally comes through the service's selected recursive resolver. That answer may differ from a local resolver, an authoritative nameserver, or the resolver used by a recipient system during a DNS change. Use the web result for a quick review, then switch to the command line when you need resolver control, repeatable output, or automation.
| Factor | Online Checker | Command Line (dig/nslookup) |
|---|---|---|
| Setup | No installation required | Requires terminal access and installed DNS utilities |
| Readability | Formatted for quick review | Raw output requires interpretation |
| Resolver control | Often limited to the tool's options | Can query a chosen DNS server |
| Automation | Usually limited | Easy to place in scripts and monitoring |
| Best use | Fast diagnosis and sharing results | Deep troubleshooting and repeatable checks |
The trade-off is speed versus control. An online checker can show whether a record appears to exist, but it cannot confirm why networks receive different answers or whether the mail host accepts SMTP connections.
Use the result as the start of the diagnosis. Check that the hostnames and priorities match the intended provider, record the resolver and lookup time, then test the returned host's SMTP behavior if delivery still fails.
Checking MX Records from the Command Line
A command-line lookup shows the DNS response directly, which makes it useful when email delivery works in one environment but fails in another. Use it to investigate propagation, compare resolver answers, automate deployment checks, or verify that a DNS change is visible where it needs to be.
On Linux and macOS, run:
dig example.com MX
On Windows, run:
nslookup -type=mx example.com
Replace example.com with the domain under test. Start with the raw query, then compare every returned mail host and preference value with the provider's intended configuration. If the provider publishes multiple records, inspect all of them rather than stopping at the first result.
Break down the response
With dig, begin with the ANSWER SECTION. An MX entry normally shows the queried domain, record type, TTL, preference value, and mail-server hostname. The preference controls delivery order, while the hostname identifies the destination that a sending server will contact.
Check the response status and resolver details as well. They help separate a valid empty answer from a failed lookup. An empty answer means the resolver completed the query but returned no MX record. A DNS error points to another issue, such as an unavailable or misconfigured zone.
nslookup presents the same information in a more conversational format. Find the listed mail exchangers, their preference values, and any message indicating that the query failed. The layout differs from dig, but the diagnostic questions remain the same: which hosts were returned, what order do they have, and did the lookup complete successfully?
Query a specific resolver
Cached answers can differ between recursive resolvers during a DNS change. Query a resolver directly with dig:
dig @resolver.example example.com MX
With nslookup, enter interactive mode, select the resolver, and request the MX record:
nslookup
server resolver.example
set type=mx
example.com
Query the authoritative nameserver to inspect the zone's currently published data. Query several public resolvers to see what different networks may receive. Differences can indicate caching, propagation, split-brain DNS, or regional inconsistency. Record which resolver produced each answer so the comparison remains useful.
Continue beyond the MX answer
An MX record only identifies where mail should go. Resolve each returned hostname to its address records, then test SMTP reachability on port 25 when your environment and the receiving server allow it.
Keep each check distinct:
- DNS lookup: Does the domain publish mail exchangers?
- Hostname resolution: Does each exchanger resolve to an address?
- Network reachability: Can an SMTP connection reach the host?
- SMTP behavior: Does the server respond appropriately to delivery attempts?
A successful DNS query proves only that the resolver returned data. It does not prove that the mail host is reachable, configured to accept mail for the domain, or willing to accept a particular recipient. That distinction prevents teams from treating an intact MX record as proof that delivery should work.
How to Interpret Your MX Record Results
An MX response has two parts that matter most: the priority value and the mail-server hostname. Read them together, not as unrelated fields. The priority tells a sending server which destination to try first, while the hostname identifies the system responsible for receiving mail.
A lower preference number means higher priority. If one record has a lower value than another, senders generally try the lower-valued record first and use the other when delivery to the preferred host isn't possible. Multiple records can therefore create an ordered fallback path, while records with equal preference can support distributed handling depending on the provider's design.
Recognize hosted mail routing
Many domains outsource email to a hosted provider. The MX hostname may therefore look unrelated to the domain's website infrastructure. For example, a Google Workspace setup can return a hostname such as aspmx.l.google.com, while Microsoft 365 commonly uses a mail.protection.outlook.com destination containing a domain-specific prefix.
This distinction matters during troubleshooting. A domain's A record may point to a web host, but its MX records can point to an external mail platform. Sending mail to the web server because the website works would be the wrong route.
A sample of 1,200 domains from the Tranco top 100,000, measured on 13 August 2026, found that 28.2% of domains with working mail servers used Google Workspace and 17.0% used Microsoft 365. Together, those providers represented 45.2% of the working-mail-server domains in that sample. The MX infrastructure benchmark from 1Lookup illustrates why lookup results often reveal a large hosted provider behind a domain.
Use TTL as troubleshooting evidence
TTL tells recursive resolvers how long they may cache a DNS response. It doesn't mean that every resolver will refresh at exactly the same moment, but it gives you useful context when a recent change appears in one lookup and not another.
If the authoritative response shows the new provider while a public resolver still shows the old one, compare the TTL and query again later. Don't repeatedly edit records to force a change that may already be correct at the source. Record the resolver, timestamp, returned hosts, and priorities so your team can tell whether the answer is changing or merely being viewed from different caches.
A missing MX answer deserves a separate interpretation. It may mean the domain has no published mail route, the lookup targeted the wrong domain, or the DNS zone is not serving the expected data. It doesn't automatically identify the cause, so validate the zone and authoritative response before declaring the domain unable to receive mail.
For signup and list workflows, an MX result is one input among several. The email verification check guide is useful context because domain routing doesn't establish that a specific mailbox exists. Treat the MX response as permission to continue validation, not as the final verdict.
Troubleshooting Common MX Record Problems
An MX problem usually becomes easier when you classify the failure by layer. First inspect the DNS answer, then resolve the mail host, then test the network and SMTP behavior. This order keeps you from changing records when the cause is a firewall, stale cache, or inactive mailbox.
Start with the visible symptom
No MX records found means the lookup returned no mail exchanger for the queried domain. Confirm that you entered the correct domain, query the authoritative nameserver, and check the DNS zone at the provider that hosts it. If the authoritative zone also lacks MX data, the domain has no published delivery destination until an administrator adds the intended records.
The wrong provider appears after a migration when old records remain in the zone. Compare the complete answer with the current provider's setup instructions, remove obsolete destinations, and allow caches to expire before judging the result from a single public resolver.
A hostname is misspelled when the MX answer looks plausible but the target doesn't resolve. Copy the provider's hostname exactly, then resolve it independently. An MX record should point to a hostname that has address resolution. It should not contain a literal IP address, and it should not point to a CNAME target.
Separate DNS from network failure
A valid MX record can coexist with a delivery failure. The mail host may resolve correctly while a firewall blocks inbound SMTP connections, a server refuses connections, or the service isn't configured to accept mail for the domain. Test the target's address resolution and SMTP reachability instead of editing the MX record again.
The most important diagnostic distinction is this: DNS can be correct while mail service is unavailable.
Priority mistakes can also change behavior without making the lookup appear broken. Review every record, confirm that the preferred host has the intended lower value, and check whether a backup host is still active. Sending systems may contact a stale high-priority destination before trying the functioning fallback.
Finally, don't treat “MX found” as “mailbox deliverable.” MXToolbox separates MX presence from fuller validation and recommends SMTP-level follow-up because a domain may have catch-all behavior, inactive mailboxes, or nonresponsive servers. That distinction prevents teams from accepting every syntactically valid address or blaming the application for recipient-level failures.
Beyond MX The Next Step in Email Verification
An MX record confirms that a domain publishes a destination for incoming mail. It doesn't confirm that user@domain.com exists, that the mailbox is active, or that the receiving server will accept the message.
The logical next check is SMTP verification, performed carefully against the receiving mail server. It can provide evidence about recipient existence and server behavior, although providers may limit or obscure those responses. For signup flows and list hygiene, combine syntax, domain, MX, SMTP, disposable-domain, role-address, and catch-all signals rather than relying on one DNS result.
Mailbeam's MX record verification API is one option for connecting domain checks with broader email validation in an application workflow. The practical principle remains the same: use MX to confirm the route, then validate whether the address is likely to receive mail before you rely on it.
Use Mailbeam to check MX records and connect DNS results with real-time email verification for signup flows or list maintenance. Start with the domain route, inspect the returned result, and add the next validation step when your product needs stronger deliverability signals.