When mail to a domain bounces, queues for hours or lands at the wrong provider after a migration, the first thing to check is the MX record. It is the single DNS entry every sending server consults to decide where your email goes, and a typo, a stale record left over from an old provider or a target name without an address is enough to break inbound mail completely.
The MX Lookup lists a domain's MX records in priority order, resolves every mail server to its IPv4 and IPv6 addresses, checks reverse DNS for each one and explains what it finds in plain language. Use it after changing email providers, when users report missing mail, or before you debug anything deeper such as SMTP or TLS.
What is an MX record?
In simple terms
An MX record is the postal routing instruction for a domain. When someone sends a message to [email protected], their mail server asks DNS "which server accepts mail for example.com?" The answer is a list of host names with priority numbers. The sender connects to the preferred one and hands over the message; if that host is unreachable it tries the next.
Technical background
MX records are defined in RFC 1035 and their use for mail routing in RFC 5321 (SMTP), section 5. Each record has two fields:
- Preference (priority): a 16-bit number. Lower values are preferred. Records with the same value are equally preferred, and senders should randomize among them to spread load.
- Exchange: a fully qualified host name. It must resolve to A and/or AAAA records. It must not be an IP address, and RFC 2181 (section 10.3) forbids it from being an alias (CNAME).
If a domain has no MX records at all, RFC 5321 section 5.1 defines an "implicit MX": the sender treats the domain's own A/AAAA address as the mail server. RFC 7505 adds the null MX (0 .), which explicitly says "this domain accepts no mail" and lets senders fail fast instead of queuing.
A typical zone entry looks like this:
example.com. 3600 IN MX 10 mx1.example.com.
example.com. 3600 IN MX 20 mx2.example.com.On the command line, dig MX example.com +short or nslookup -type=mx example.com returns the same data without the follow-up address and reverse DNS checks.
Why use an MX lookup?
- Inbound mail is missing or bouncing. Confirm the domain publishes MX records and that each target has an address.
- Migration to a new provider. Verify that the old provider's MX hosts are gone and the new ones are published with the priorities the provider documents.
- Unexpected fallback delivery. A domain without MX records receives mail on its web server's address; the lookup makes that visible.
- Reverse DNS problems. MX hosts that also send bounces or forwarded mail need a PTR record to be trusted by other receivers.
- Single point of failure. See at a glance whether there is only one mail server.
- Groundwork for other checks. The MX host name is what you test next with the SMTP Test and what an MTA-STS policy must list.
Who should use it?
- System administrators and mail administrators running their own mail servers or managing a hosted mail service.
- DNS administrators reviewing a zone after changes.
- Help-desk and MSP staff troubleshooting "we are not getting email" tickets.
- DevOps engineers automating domain setups who want a quick external confirmation.
How MX lookup works
A sending mail server performs these steps for every recipient domain:
- Query DNS for the MX records of the domain.
- Sort them by preference, randomizing equal values.
- Resolve each exchange host to A/AAAA addresses.
- Connect to port 25 of the first reachable address and deliver; fall back to the next host on failure.
The NetTools.tech implementation mirrors the DNS part of this process on the server:
- The domain is validated first. Only public domain names are accepted; internal or reserved names such as
.local,.internal,.lanor.testare rejected. - The MX query goes from the NetTools.tech server to the public resolvers 1.1.1.1 and 8.8.8.8 (3-second timeout, two tries). Internal DNS is never used.
- A non-existent domain (NXDOMAIN) is reported as an error, not as "no MX".
- Records are sorted by priority. Up to 20 MX hosts are processed.
- Each host is resolved to its A and AAAA records (up to 16 addresses per host).
- The first address of each host is looked up in reverse DNS (PTR).
- If there are no MX records, the domain's own A/AAAA addresses are resolved to show where implicit delivery would go.
- The whole operation has a 15-second limit and is subject to per-client rate limiting.
The lookup does not connect to the mail servers. Whether they accept connections and offer STARTTLS is the job of the SMTP Test.
How to use the NetTools.tech MX Lookup
- Open MX Lookup.
- Enter the domain in the Domain field, for example
example.com. Enter the domain part of an email address, not the full address and not a URL. - Press Run MX Lookup. You can also click the example chip below the form to fill it in.
- Read the table and the status lines below it. Use Copy to copy the result into a ticket.
- Optionally use Open in terminal to run the same check as
/mx example.comin the web terminal.
Understanding the results
The result is a table of mail servers followed by colored findings.
| Result | Meaning | What to look for |
|---|---|---|
| Priority | MX preference value; lower is tried first | The provider's documented values; a backup host with a lower number than the primary |
| Mail server | The exchange host name from the MX record | Typos, old provider names, an IP address instead of a name |
| Addresses | A and AAAA records of the host | "— (none)" means senders skip this host |
| Reverse DNS | PTR record of the host's first address | "—" means no PTR; a generic ISP name may hurt outbound reputation |
| "N mail servers." (pass) | More than one MX host exists | Hosts that all sit in the same network still share failure modes |
| "Only one mail server" (info) | A single MX host | Senders queue and retry if it is down; acceptable for hosted services |
| No reverse DNS (warning) | An MX address has no PTR | Fix in the IP owner's reverse zone if the host also sends mail |
| MX host has no address (error) | The exchange name does not resolve | Add the A/AAAA record or correct the MX target |
| MX points to an IP address (error) | The record's target is a literal IP | Replace with a host name that has an A/AAAA record |
| No MX records (warning) | Implicit delivery to the domain's own address | Publish MX records, or a null MX if the domain sends no mail |
| No MX and no address (error) | The domain cannot receive email | Expected only for domains that should not receive mail |
| Null MX (info) | 0 . published, RFC 7505 | Correct for parked or send-only domains; a mistake for active mail domains |
Example: checking a domain after a provider change
Illustrative output for a hypothetical domain example.net with two mail servers (all names and addresses are documentation values):
| Priority | Mail server | Addresses | Reverse DNS |
|---|---|---|---|
| 10 | mx1.example.net | 192.0.2.25, 2001:db8::25 | mx1.example.net |
| 20 | mx2.example.net | 198.51.100.25 | — |
Findings shown below the table:
- Pass: "2 mail servers."
- Warning: "mx2.example.net (198.51.100.25) has no reverse DNS; some receivers distrust such servers if they also send mail."
Reading it: delivery goes to mx1 first, mx2 is the backup. Both resolve, so routing works. The backup host lacks a PTR record; that does not stop inbound mail, but if mx2 also sends bounces, ask the owner of 198.51.100.0/24 to add a PTR record that matches the host name.
Common use cases
- Confirming a cut-over to Microsoft 365, Google Workspace or another hosted provider.
- Finding a forgotten MX record that still points to a decommissioned server.
- Checking whether a parked domain correctly publishes a null MX.
- Collecting the MX host names needed for an MTA-STS policy or a firewall rule.
- First step of a full audit with the Email Health Check.
Troubleshooting
"does not exist (NXDOMAIN)"
The domain itself is not in DNS. Check the spelling, whether the domain is registered and delegated (use WHOIS), and whether its name servers answer.
"No MX records. Senders fall back to the domain's own address"
No MX is published, so senders use the A/AAAA record of the domain, typically the web server. Add the MX records from your mail provider. If the domain should never receive mail, publish 0 . as a null MX instead.
A mail server shows "— (none)" as address
The MX target name has no A or AAAA record. Often the record was created with a typo, or the target zone was deleted. Look up the host with DNS Lookup and fix either the MX target or the missing address record.
The result does not show the record I just added
The public resolvers may still cache the old answer until its TTL expires. Check the record across many resolvers with DNS Propagation, or compare the authoritative name servers directly.
"MX lookup failed" or a timeout
The domain's name servers failed to answer or were too slow. Query them directly with dig @ns1.example.com MX example.com to see whether they are reachable and authoritative.
Common mistakes
- Pointing MX to an IP address. Many DNS panels accept it; mail servers do not.
- Pointing MX to a CNAME. It may appear to work with some senders but violates RFC 2181 and breaks others.
- Forgetting the trailing dot in zone files, which turns
mx1.example.com.intomx1.example.com.example.com. - Leaving the old provider's MX records in place after a migration, so part of the mail goes to the old system.
- Giving the backup host the lowest number, which makes it the primary.
- Entering an email address or URL in the field instead of the bare domain.
Limitations
- Results reflect what 1.1.1.1 and 8.8.8.8 return at that moment, including their caches. Split-horizon or internal DNS views are not visible.
- Only the first address of each mail server is checked for reverse DNS, and the PTR is not verified to resolve back (forward-confirmed reverse DNS) by this tool.
- The tool does not check whether an MX target is a CNAME.
- It does not connect to the mail servers, so it cannot tell whether they accept mail, are blocked by a firewall or offer TLS.
- At most 20 MX hosts and 16 addresses per host are shown.
Security & privacy
The domain you enter is sent to the NetTools.tech server, which queries public resolvers; the resolvers and the domain's name servers see the server's address, not yours. Results are returned to your browser and not stored. The server keeps a short tool log entry (tool name, the domain you entered, your IP address shortened to its /24 or /48 network) for 30 days, as described in the privacy policy. Only public domain names are accepted. Nothing else is needed: never enter mailbox passwords or other credentials into any lookup.
Related tools
- SMTP Test – connect to an MX host and check its banner and STARTTLS (guide).
- Reverse DNS Lookup – inspect the PTR record of a mail server address (guide).
- SPF Lookup – check which servers may send mail for the domain (guide).
- MTA-STS Lookup – verify that the policy covers every MX host (guide).
- Email Health Check – MX, SPF, DMARC, DKIM, MTA-STS, TLS-RPT and SMTP in one report (guide).
- Email Tools overview – which email tool fits which problem.
Summary
MX records decide where every message for a domain is delivered, so they are the first thing to check when inbound mail fails. The NetTools.tech MX Lookup shows the records in priority order, resolves each mail server, checks reverse DNS and flags null MX, implicit MX, unresolvable targets and IP targets. It reads public DNS only; use the SMTP Test to confirm the servers actually accept connections.
Frequently asked questions
What is an MX record?
An MX (mail exchanger) record is a DNS record that names the server that accepts email for a domain, together with a priority number. Sending mail servers look it up for the part of the address after the @ before they deliver a message.
What does MX priority mean?
Senders try the MX host with the lowest priority number first and move to higher numbers only if it cannot be reached. Hosts with equal priority share the load, because senders pick among them at random.
What happens if a domain has no MX record?
RFC 5321 says senders then fall back to the domain's own A or AAAA address and try to deliver there, which is rarely what the owner intended. The NetTools.tech MX Lookup reports this as a warning and shows the fallback addresses; if there are none, the domain cannot receive email.
What is a null MX record?
A null MX is a single MX record with priority 0 and the target "." defined in RFC 7505. It states that the domain accepts no email at all, so senders can bounce mail immediately instead of retrying for days.
Can an MX record point to an IP address or a CNAME?
No. An MX target must be a host name that has its own A or AAAA record; an IP address in the MX field is invalid, and RFC 2181 forbids pointing MX at an alias (CNAME). The NetTools.tech lookup flags MX targets that are IP addresses or have no address at all.
Why does my MX lookup differ from what I see locally?
NetTools.tech queries the public resolvers 1.1.1.1 and 8.8.8.8, which may still cache an older answer until the record's TTL expires. Your local or company resolver may cache a different version, or use split-horizon DNS that the public internet never sees.
Do I need reverse DNS on my MX servers?
Receiving mail does not strictly require reverse DNS, but many MX hosts also send mail (bounces, forwarding), and receivers often distrust senders without a PTR record. That is why the lookup warns when an MX address has no reverse DNS.