What MX records do
MX (mail exchanger) records answer one question: where should email for this domain be delivered? When a customer writes to support@yourdomain, their mail server looks up the MX records for yourdomain, picks the one with the lowest priority number, connects to it, and hands over the message. If that server doesn’t answer, it tries the next one.
Each record has two parts: a priority (lower is tried first) and a host name, which must have its own address record (A for IPv4, AAAA for IPv6). For example:
10 in1-smtp.messagingengine.com20 in2-smtp.messagingengine.com
Only the order of the numbers matters. Records with the same priority share the load, which is how providers spread mail across many servers.
How to read the results
The checker lists every MX record in priority order, names the provider when the host is recognizable (Google Workspace, Microsoft 365, Zoho, Fastmail, Proton, Cloudflare Email Routing and others), and looks up the A and AAAA records of each mail server to make sure it actually exists.
- Pass: at least one MX record, and every mail server resolves to an IP address.
- Warning: mail can be delivered, but something is off. Some hosts don’t resolve, or a host is an alias (CNAME), which RFC 2181 (section 10.3) says an MX target must never be.
- Fail: there are no MX records; none of the hosts resolve; a record points at an IP address instead of a host name; or the domain publishes a null MX, meaning it accepts no email.
When a domain receives no mail at all, the checker also shows the three records that lock it down against spoofing.
Null MX: saying “no email here” on purpose
RFC 7505 defines a special record for domains that never receive email: a single MX with priority 0 and a target of just a dot, written MX 0 .. Senders that see it fail straight away instead of retrying for days, and the RFC says it must be the only MX record on the domain. It’s the right choice for parked domains, redirect-only domains and domains used only for a website.
The checker marks a null MX as a fail, because a support address on that domain can’t receive anything. If that’s intended, the lock-down panel under the results tells you whether SPF and DMARC are set to match.
What if there are no MX records?
The original SMTP rules include a fallback. When a domain has no MX records, a sender may treat the domain itself as an implicit mail server with priority 0 and try to deliver to its address record (RFC 5321, section 5.1). In practice that address usually belongs to a web host that doesn’t accept mail, so the message hangs in a retry queue and then bounces. Don’t rely on the fallback: publish real MX records for a domain that should receive mail, or a null MX for one that shouldn’t.
What a good setup looks like
- All MX records point to the same provider. Mixing two providers splits your mail unpredictably between them.
- Every host resolves, and none is an IP address or a CNAME.
- The values match exactly what your provider’s setup page shows. Providers change their recommended records from time to time, so check theirs rather than copying an old guide.
- A TTL of an hour or more once things are stable, so a brief DNS hiccup doesn’t stop your mail.
Common mistakes, and how to fix each
- Leftover records from an old provider. After moving to a new provider, an old MX left in place still receives some of your mail. Delete every MX that isn’t on your current provider’s list.
- An IP address as the target. MX records need a host name. Create an A record for the server (for example
mail.yourdomain) and point the MX at that. - The domain typed twice. Some DNS panels add the domain to the value, turning
mx.provider.comintomx.provider.com.yourdomain. The checker shows this as a host that doesn’t resolve. Add a trailing dot, or follow your DNS host’s instructions. - MX on the wrong host. Records for the main domain belong on
@(the root). If you put them onwwwor a subdomain, mail to the main domain has nowhere to go. - A null MX on a domain that should receive mail. It’s often left over from when the domain was parked. Remove it before adding real MX records; RFC 7505 forbids mixing the two.
- Pointing at a forwarding service you forgot about. Registrars often set up free forwarding by default. That’s fine if it delivers where you expect, but check the provider name in the results.
Why MX matters for support email
MX decides whether a customer’s message reaches you at all. A broken MX doesn’t look like an error from your side. It looks like a quiet week, while customers get bounce messages or nothing. It’s also the first thing to check when you move support to a new tool: you can either keep your MX records at your current provider and forward support@ onward, or point the MX records at a service that receives for you, depending on whether anyone else uses mailboxes on the domain.
Receiving is only half of it. Replies need SPF, DKIM and DMARC to pass the checks Gmail, Yahoo and Outlook run on incoming mail (Gmail sender guidelines). The support email checker covers all four at once.