Email breaks in ways that look unrelated. A mailbox stops receiving messages, a provider rejects mail for your domain, or a migration finishes but inbound delivery still goes to the old server. In each case, knowing how to verify MX records quickly saves time and usually points you to the actual fault.<\/p>\n
MX records tell senders which mail servers accept mail for a domain. Verifying them is not just checking whether a record exists. You need to confirm the hostname is correct, the priority values make sense, the target host resolves, and the answer you see matches what authoritative DNS is serving.<\/p>\n
An MX record maps a domain to one or more mail exchanger hostnames, each with a preference value. Lower numbers have higher priority. If your domain uses multiple mail servers, the sending system usually tries the lowest value first and falls back to higher values if needed.<\/p>\n
When you verify MX records, you are checking several things at once. First, the domain must return valid MX answers. Second, each MX target should be a hostname, not a raw IP address. Third, those hostnames should resolve to A or AAAA records. Fourth, the record set should be visible from the DNS you expect, especially after a recent change.<\/p>\n
This is where many simple checks fall short. A domain can appear to have MX records and still fail mail delivery because the targets no longer resolve, the values are stale in recursive caches, or the zone is split between providers.<\/p>\n
For admins and engineers, command-line checks are still the fastest path. The main goal is to compare what recursive DNS returns against what the authoritative name servers return.<\/p>\n
Run a basic MX lookup against the domain:<\/p>\n
“`bash dig example.com MX “`<\/p>\n
The answer section should list one or more MX entries with priority and hostname, such as `10 mail.example.com.` If you get `NOERROR` with no answer, the domain exists but has no MX records. In practice, some senders may then fall back to the domain’s A record, but you should not rely on that behavior for production mail.<\/p>\n
To see what the authoritative servers say, query them directly. Start by identifying the NS records:<\/p>\n
“`bash dig example.com NS “`<\/p>\n
Then query one of those name servers for MX:<\/p>\n
“`bash dig @ns1.provider-dns.com example.com MX “`<\/p>\n
If the authoritative response differs from what a public resolver gives you, you are likely looking at propagation delay, stale cache, or a DNS delegation issue.<\/p>\n
Next, resolve each MX target:<\/p>\n
“`bash dig mail.example.com A dig mail.example.com AAAA “`<\/p>\n
If the MX hostname does not resolve, mail delivery will fail even though the MX record itself exists.<\/p>\n
If `dig` is not available, `nslookup` works well enough for basic checks:<\/p>\n
“`bash nslookup -type=mx example.com “`<\/p>\n
This shows the mail exchangers and their preference values. Then test each target hostname separately:<\/p>\n
“`bash nslookup mail.example.com “`<\/p>\n
`nslookup` is less detailed than `dig`, but for quick field checks it is often enough.<\/p>\n
Browser-based DNS lookup tools are useful when you need a fast answer without shell access, or when you want to test from a different network path. A good DNS lookup tool should show the MX records, the returned TTL, and ideally related records so you can verify the MX hostnames also resolve.<\/p>\n
This is where a tool-first workflow helps. If you use a browser utility such as the DNS lookup<\/a> on Ping Tool Net, the useful output is not just the MX line itself. You want to confirm the domain returns the expected mail exchangers, check whether multiple servers are ordered correctly, and then inspect A, AAAA, and sometimes TXT records for the same domain in the same session.<\/p>\n That matters during migrations. If your new provider says mail is pointed correctly but external senders still hit the old platform, a browser-based check from a public resolver can show whether the problem is the zone, propagation, or a local cache that has not expired.<\/p>\n A healthy MX setup usually has predictable characteristics. The MX targets are fully qualified hostnames. They are not bare IP addresses. The priority values are intentional, not random leftovers from old providers. And each hostname resolves to at least one usable address.<\/p>\n For example, this is structurally valid:<\/p>\n “`text example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com. “`<\/p>\n Then both `mail1.example.com` and `mail2.example.com` should return A and or AAAA records.<\/p>\n One detail that catches people: the MX target should not be a CNAME. Some DNS control panels allow confusing configurations, but the mail exchanger named in MX should resolve directly as a hostname with address records. If your target chains through a CNAME, some systems will tolerate it, but it is bad practice and can cause inconsistent behavior.<\/p>\n The most common failure is simple drift. The MX records still point to an old mail provider after a tenant migration or DNS cutover. You verify the domain, see the old provider’s hostnames, and immediately know inbound mail is being routed to the wrong place.<\/p>\n Another common issue is missing resolution on the MX target. The domain returns an MX record, but the target hostname has no A or AAAA record. This often happens after a cleanup in the zone file where someone removes what looks like an unused host entry.<\/p>\n Priority mistakes also matter. If the backup server has a lower preference value than the primary server, senders will try the backup first. That may be acceptable, but in most environments it is accidental.<\/p>\n You will also run into partial propagation. One resolver returns the new MX set while another still serves the previous values. This is normal after a change, especially if the prior TTL was high. The fix is usually patience, but you still need to verify that the authoritative servers are already correct.<\/p>\n A more subtle issue is querying the wrong domain. Mail for `user@subdomain.example.com` depends on MX records for `subdomain.example.com`, not necessarily `example.com`. During troubleshooting, verify the exact domain in the recipient address.<\/p>\n MX records alone do not prove the mail stack is healthy. They only tell you where mail should go. If delivery is failing, check the related DNS and service layers in sequence.<\/p>\n Start with A and AAAA records for each MX target. Then look at the SMTP service itself. If you can, test TCP port 25<\/a> on the MX host to confirm it is reachable. A correct MX answer pointing to a server with blocked or closed SMTP is still a broken mail path.<\/p>\n For sending reputation and authentication, TXT records also matter. SPF, DKIM, and DMARC do not affect whether MX records are valid, but they often become part of the same ticket. If you are already in DNS, it makes sense to verify them before handing the issue off.<\/p>\n Reverse DNS is another dependency that shows up later. It does not validate inbound routing through MX, but it does affect how your outbound mail is treated. If users report both send and receive problems, separate the inbound MX check from outbound hostname and PTR validation.<\/p>\n The fastest method is to work from the outside in. Query the domain’s MX records from a public resolver. Query the authoritative name server directly. Resolve each MX target to A and AAAA. Then test SMTP reachability on the returned hosts.<\/p>\n If the public and authoritative answers differ, you are dealing with caching or propagation. If the MX target does not resolve, fix the zone. If the target resolves but SMTP is down, the issue is on the mail host or network path<\/a>. If all of those checks pass and mail still fails, move up the stack to provider policy, TLS, filtering, or mailbox-level routing.<\/p>\n This sequence matters because it prevents wasted effort. Teams often start in the mail platform, only to find the MX records still point somewhere else.<\/p>\n A missing MX record does not always mean the domain is dead, but it is usually a configuration problem. Some mail transfer agents may fall back to the domain’s A record when no MX exists. Others may behave differently depending on policy and validation. For anything business-critical, publish explicit MX records and verify they match your intended provider.<\/p>\n If a domain should not receive mail, some admins intentionally point MX to a null or non-routable target pattern supported by their environment. That is a separate design decision. For normal business domains, no MX is almost always the wrong answer.<\/p>\n When you verify MX records, do not stop at the first correct-looking response. Check the authoritative answer, the target host resolution, and whether the returned servers are actually reachable for SMTP. That extra minute is usually the difference between finding the root cause and chasing symptoms for the next hour.<\/p>\n If the record looks right but mail still fails, that is progress. You have ruled out DNS routing and narrowed the problem to the mail service, network path, or policy layer, which is exactly where the next check should start.<\/p>\n","protected":false},"excerpt":{"rendered":" Learn how to verify MX records using DNS lookups, dig, nslookup, and online tools. Check priority, hostnames, and propagation fast. … <\/p>\nWhat a valid MX result should look like<\/h2>\n
Common problems found when you verify MX records<\/h2>\n
Related records you should check at the same time<\/h2>\n
A practical workflow for verifying MX records<\/h2>\n
When no MX record exists<\/h2>\n
Final check before you close the ticket<\/h2>\n