MX record checker for all your domains

An MX (mail exchanger) record tells other mail servers which host accepts mail for a hostname. Each one pairs a priority number with a hostname, and senders try the lowest number first. MX is looked up per hostname, so updates.yourdomain.com can have its own MX records and receive mail somewhere else while yourdomain.com keeps Google Workspace. Our guide to email on a subdomain sets that up on a live domain.

A hostname with no MX at all doesn't simply refuse mail: senders fall back to its A record, as RFC 5321 section 5.1 describes, and that usually points at a web server, not a mail server.

Each domain gets one verdict pill:

• Receives mail (green): the domain has MX hosts, and every one we checked resolves to an address.
• Receives mail, with a warning (amber): mail gets through, but something needs a look, like a backup host that no longer resolves, an MX that points at an alias (CNAME), or hosts from two different providers.
• Can't receive mail (red): no MX record while the domain has an A record, MX records that point at IP addresses, no MX host that resolves, a null MX next to other MX records, or a domain that doesn't exist in DNS. It's amber when the domain has no MX and no address either, which is fine if it never takes mail.
• Accepts no mail (null MX) (green): the domain says on purpose that it takes no mail.
• Couldn't check (grey): DNS didn't answer in time. Try again in a minute.

Next to the pill you get the provider when the hostname makes it clear, or else the host itself, plus a one-line verdict. Open a domain to see its MX table: each host in priority order, the cached TTL, and whether the host resolves over IPv4 and IPv6.

Lower priority numbers are tried first, and hosts with equal numbers share the load. A single host is normal, so we don't flag a missing backup. The TTL is how long resolvers may cache the records, which is how long a change can take to reach everyone. The TTL (cached) column shows the time left in the public resolver's cache, so it can be lower than the value you set. Each MX lookup reads live public DNS, so you see what senders see right now.

If the provider label looks wrong, compare your records with what your provider asks for:

Google's MX setup page lists the single smtp.google.com host. Setups from before 2023 may still use the legacy aspmx.l.google.com set, which still works. Personal Gmail addresses run on Google's own gmail-smtp-in.l.google.com hosts, which the checker labels Gmail. For Microsoft 365, External DNS records for Microsoft 365 explains where to find your MX token in the admin center. Zoho's values above are for the US data center, and other data centers use other hosts, so copy the ones your Zoho admin console shows. Cloudflare Email Routing assigns its own priorities, so copy what the dashboard shows.

The usual causes:

• No MX record. Senders fall back to the A record, which usually points at a web server. If the domain never takes mail, publish a null MX instead: a single MX record of 0 ., as RFC 7505 defines.
• An MX host that no longer resolves. Usually the old provider's host after a move, or a typo. Senders skip it and try the next host, and when none resolve, mail bounces.
• A null MX left on from parking. A null MX has to be the only MX record, so one left next to your real hosts can make senders refuse mail for the domain.
• A CNAME on the same name. A hostname with a CNAME can't hold an MX record too, so a leftover CNAME on a subdomain blocks the MX you add.
• An MX that points at an alias or an IP address. RFC 2181 section 10.3 says an MX must name a host with its own address, not an alias. Most senders cope with an alias, some don't. An IP address isn't a valid MX value at all.

Replies to mail you send from a domain like that bounce, so the customer who answers your receipt never reaches you. Our guide to replying from a custom domain covers getting those replies back.

• Lower the TTL a day ahead, to something like 300 seconds, so the switch reaches resolvers in minutes instead of hours.
• Add the new MX before removing the old. Remove the old records once the new hosts show up here and resolve.
• Don't mix two providers on the same name for long. Senders pick by priority and fall back on any failure, so mail ends up split between the two in ways you can't predict.
• Leave a working mailbox alone. If the domain already receives mail in Gmail or Outlook, put new mail on a subdomain like updates.yourdomain.com instead of replacing the root MX.

Also check what the new MX gives you. A forwarding MX like Cloudflare Email Routing only receives: it passes mail on to a mailbox you already have, so you still need something else to reply from your domain.

MX covers receiving. For sending, run the same domains through the DMARC checker, which reads DMARC and SPF. And if you're choosing email hosting for several domains, that guide compares the options.