MX Lookup

About the MX Lookup

An MX lookup queries a domain's DNS for its MX (Mail Exchanger) records and returns every mail server responsible for receiving that domain's email, ordered by priority. This tool does exactly that, then goes a step further by resolving each mail server hostname to its A (IPv4) and AAAA (IPv6) addresses in the same pass, so a single query tells you both where mail is routed and where those hosts actually live on the network.

You reach for an MX lookup when you set up a new mailbox provider and need to confirm the records propagated correctly, when mail to a domain starts bouncing and you need to see whether the domain has any mail servers at all, or when you inherit a domain and need to figure out who is currently hosting its email before you touch anything. It is also the fastest way to spot a half-finished migration, where an old provider's host is still listed alongside a new one and mail gets split between two systems.

The domain you enter is sent to our server to run the live DNS query, since browsers cannot perform arbitrary DNS resolution on their own. Nothing about the lookup is logged, stored or handed to a third party beyond that one query against public DNS resolvers, the same records anyone can already look up with dig or nslookup. What is different is that this tool sorts the results by priority, resolves every host's IP addresses automatically, and surfaces plain-language warnings instead of leaving you to parse raw resource records or wade through an ad-heavy toolbox site.

What sets this MX lookup apart from a bare dig command is the automatic follow-through: no MX records at all is flagged immediately as a reason mail cannot be delivered, and any mail host that itself has no A or AAAA record is called out, since a dangling MX hostname is a delivery dead end that plain DNS output would otherwise hide in a wall of text.

How to use it

1. Enter the domain name you want to check, for example invoker.tools or example.com.
2. Run the lookup to query the domain's MX records over live DNS.
3. Read the results in priority order; the lowest priority number is the most preferred mail server.
4. Check the IPv4/IPv6 addresses resolved for each mail host to confirm they point where you expect.
5. Watch for a no-MX-records warning, which means the domain cannot currently receive mail.
6. Watch for a per-host warning that a mail server has no A/AAAA record, which means that host cannot be reached.
7. Re-run the lookup after a DNS change to confirm the new records are live before you rely on them.

Examples

• example.com typically returns a single low-priority MX host if it is configured to receive mail, alongside its resolved IPv4 address.
• A Google Workspace domain usually shows one MX record at priority 1 pointing to a host under the google.com mail infrastructure.
• A Microsoft 365 domain usually shows one MX record at priority 0 pointing to a tenant-specific *.mail.protection.outlook.com host.
• A domain sending through Mailgun typically shows two MX records at equal priority pointing to mxa and mxb hosts, used interchangeably for redundancy.
• A domain that has never had email configured returns an empty host list and the no-MX-records warning, explaining why mail to that address always bounces.
• A domain mid-migration can show two unrelated mail hosts at the same priority, one from the old provider and one from the new, which the tool surfaces as-is so you can spot the overlap.

How MX priority works

Every MX record carries a priority number alongside the mail server hostname, and lower numbers mean higher preference. A sending server always tries the mail host with the lowest priority first; if that host refuses the connection or times out, it falls back to the next-lowest priority, and so on down the list. This is why a domain with only one MX record is not automatically fragile, it just has one path in, while a domain listing several hosts at different priorities has explicit primary and backup mail servers.

When two or more MX records share the exact same priority number, sending servers are free to pick between them, typically at random or round robin, which spreads load across the hosts rather than establishing a strict order. This is the normal pattern for providers that front their mail infrastructure with multiple, interchangeable servers rather than a single primary plus a fallback.

• Lower priority number = tried first (priority 0 or 1 beats priority 10).
• Equal priority across multiple records = load-balanced, not ordered.
• A single MX record at any priority is valid; it just means there is no fallback host.
• A backup MX at a higher priority only helps if it is a real, monitored mailbox host, not a dead placeholder.

Recognizing common MX setups

Most domains you look up will match one of a handful of well-known hosting patterns, and being able to read the MX host names tells you who handles a domain's mail before you even open a support ticket with them.

• Google Workspace: a single MX record at priority 1 pointing to a host under Google's mail infrastructure (historically several ASPMX hosts at priorities 1, 5 and 10; current Workspace domains are usually consolidated to one).
• Microsoft 365: one MX record at priority 0 pointing to a tenant-specific host ending in mail.protection.outlook.com, unique per tenant.
• Mailgun: typically two MX records at the same priority (mxa and mxb, or their EU-region equivalents), used interchangeably rather than as primary/backup.
• Self-hosted or DirectAdmin/cPanel mail: one MX record at priority 0 or 10 pointing directly at the domain's own mail.<domain> or the server's hostname.
• Split or transitional setups: an old provider's host still listed alongside a new one, usually a leftover from an incomplete migration rather than an intentional backup.

Troubleshooting mail delivery via MX

When mail to a domain bounces or never arrives, the MX record is almost always the first thing worth checking, because it is the one piece of DNS that has to be both present and reachable for delivery to succeed at all.

• No MX records: the domain cannot receive mail at all; this is common on domains bought only for a website, or where the mail setup step was skipped.
• MX host with no A/AAAA record: the mail server name resolves to nothing, so connections fail even though the MX record itself looks fine.
• Stale MX after a provider switch: DNS still lists the old host, either because the change was never made or because of DNS caching during propagation.
• Wrong priority ordering: a slower or decommissioned backup host is accidentally set to a lower priority than the primary, so senders try the wrong server first.
• TTL too high: a correct new MX record is set but old resolvers keep returning the cached, previous record until the old TTL expires.
• Mismatched expectations: the MX record is correct but SPF, DKIM or DMARC on the sending side is misconfigured, which is a separate failure this tool does not diagnose; use the SPF, DKIM and DMARC checkers for that half of the picture.

MX vs A record fallback

Older parts of the SMTP standard describe an implicit MX fallback: if a domain has no MX record, a sending server is permitted to fall back to the domain's own A record and attempt delivery there instead. In practice this fallback is unreliable, many modern mail transfer agents either do not implement it or treat a missing MX as a hard failure rather than trying the A record, so a domain that depends on this behavior can see inconsistent delivery depending on which sender it is talking to.

This lookup only reports what is actually published as MX data, plus the resolved addresses of those hosts. It will not tell you that a domain's A record could theoretically catch mail in the absence of MX records, because relying on that fallback is a fragile substitute for simply publishing a correct MX record. If your domain currently has no MX records and is somehow still receiving mail, treat that as a temporary accident of a permissive sender, not a configuration to keep.

Frequently asked questions