MX Lookup
Find your domain's mail servers, inspect priorities and see whether each MX target resolves to a usable public host. DNS records alone do not verify SMTP delivery.
Run MX records
No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.
What an MX record is
An MX (mail exchange) record names a host that accepts inbound email for a domain, together with a preference number. A sending server looks up the MX records of the recipient's domain, sorts them by preference and tries the lowest number first, moving on to higher numbers if the earlier hosts cannot be reached. Equal preferences share the load in no fixed proportion.
The MX target must be a host name, not an IP address, and that name needs its own A or AAAA record. This tool reads the MX set from the system resolver and from the zone's authoritative servers, then checks each target name for addresses.
How do MX priorities work?
Lower MX preference numbers are preferred. A server with preference 10 is normally attempted before one with preference 20, and equal preferences can be used to spread load. Several MX records only improve resilience if each listed server is actually configured to accept mail for the domain.
How to read the result
The table lists preference, mail server name and the addresses found for that name. The findings underneath describe what the pattern means for inbound mail.
- Records with all targets resolving: the routing is complete as far as DNS goes. This says nothing about whether those servers accept your mail.
- A target with no address: a sender that picks that host cannot connect. If every target is unresolved the domain is effectively unreachable and is shown as a risk; if only some are, it is shown as something to improve.
- Only one MX host: the page marks a lack of redundancy. A single mail host is valid, but an outage there means senders queue and retry rather than deliver.
- Equal preferences: shown as informational. This is a deliberate way to spread load, but make sure every listed host is configured identically.
- Null MX (a single record with preference 0 and target '.'): the domain states that it accepts no mail, as defined in RFC 7505. This is reported as correct. Mixing a null MX with real MX records contradicts itself and is flagged.
- No MX at all: senders then fall back to the domain's own A or AAAA record (the implicit MX rule in RFC 5321). The tool reports whether that fallback address exists, because many domains that never intended to receive mail are accidentally open to it.
- Alias or non-public targets: MX targets that are CNAMEs are not allowed by RFC 2181 and cause trouble for some senders. Targets that resolve only to private addresses are unreachable from the internet.
Common MX problems
- Leftover records after a provider migration: old MX entries at a lower number keep receiving some of your mail at the previous provider. Remove them once the new setup is verified.
- Typos in the host name, or a trailing-dot mistake: some DNS panels append the zone name to a value ending without a dot, producing mx1.example.com.example.com.
- MX pointing at an IP address: it cannot be a valid target, so the lookup shows no usable host.
- Provider hosts mixed together: combining the MX hosts of two providers sends part of the mail to each, which usually surprises people.
- A subdomain used as a mail domain without its own MX: the MX of the parent does not apply to a subdomain. Each mail domain needs its own set.
How to change MX records safely
Mail is the least forgiving record type to get wrong, because a failed delivery may bounce or sit in a remote queue for days. Take the exact host names and preferences from your mail provider's setup page, and keep the previous values in writing.
Lowering the TTL a day or two before a planned cut-over limits how long senders keep using the old hosts. Add the new records first, confirm the new provider is ready to accept the domain, and only then remove the old ones.
- Copy the existing MX set and TTL somewhere safe.
- Confirm with the new provider that the domain is added and mailboxes exist.
- Publish the new MX records, with the intended preferences.
- Run this lookup and confirm the authoritative servers and the resolver agree.
- Send test messages from an outside mailbox and watch for bounces.
- Remove old MX entries after mail flows correctly. To roll back, restore the saved set; senders move over as their caches expire.
What this lookup does not prove
The check reads DNS only. It does not open an SMTP connection, test STARTTLS, confirm that a mailbox exists, or look at SPF, DKIM and DMARC. A clean MX result therefore means the routing records are consistent, not that mail is delivered. Use the mail server diagnostics and SMTP tools for the connection itself. The result is also one measurement from one scanner, so recently changed records may still be cached elsewhere.
Frequently asked questions
Does a lower MX number mean higher priority?
Yes. The lowest preference value is tried first. The numbers only matter relative to each other, so 10 and 20 behave like 1 and 2.
Can I have only one MX record?
Yes. It is valid, but without a second host there is no fallback during an outage, and senders will queue messages and retry for a while.
What is a null MX?
A single MX record with preference 0 and the target '.' tells senders the domain never receives mail, so they can bounce immediately instead of retrying.
What happens if a domain has no MX?
Senders try the domain's own A or AAAA record as an implicit mail host. If that does not exist either, mail cannot be delivered.
Can an MX target be a CNAME?
It should not be. The standards require MX targets to be canonical names with address records, and some mail servers refuse aliased targets.
Does this tool test whether mail is accepted?
No. It reads DNS records and resolves the targets. SMTP behaviour is tested by the email tools.
Scope of this tool
- SMTP reachability, STARTTLS and mailbox existence are not tested (see the Email tools).
Written by DNS Tools editorial · Last updated 2026-10-09