MX Record Lookup

MX (mail exchanger) records tell the world which servers accept email for a domain. When someone sends a message to jane@example.com, their server looks up the MX records for example.com, picks the preferred host and delivers the message there.

If the MX setup is wrong, incoming mail bounces, and so do the replies and bounce notifications your campaigns depend on. This lookup shows the whole picture in one view.

What the lookup shows

• Priority and host for every MX record, sorted from most to least preferred.
• IPv4 addresses each host resolves to.
• Detected provider, such as Google Workspace, Microsoft 365, Zoho Mail, Proofpoint, Mimecast, Fastmail, Yahoo, iCloud or Barracuda.
• Redundancy check, confirming you have more than one MX host (or a provider whose single hostname is itself load-balanced).
• Warnings for hosts that do not resolve, MX targets that are IP addresses or CNAMEs, and missing records.

How MX priority works

example.com.   3600   IN   MX   10  mx1.mailhost.example.
example.com.   3600   IN   MX   10  mx2.mailhost.example.
example.com.   3600   IN   MX   20  backup.mailhost.example.

Lower numbers win. A sender tries the two hosts at priority 10 first, spreading load between them. Only if both fail does it try priority 20. The actual values do not matter, only their order: 1 and 5 behave the same as 10 and 50.

If a sender cannot reach any MX host, it queues the message and retries for several days before giving up, so a short outage delays mail rather than losing it.

Recognising your provider

If a security gateway like Proofpoint or Mimecast appears, your actual mailboxes sit behind it, often at Microsoft 365 or Google. That matters when troubleshooting: the gateway, not the mailbox provider, is the first system to accept or reject mail.

Reading your results

Healthy. Two or more hosts (or a provider’s managed hostname), each resolving to an IP, from a single provider.

Single host. One MX record on your own server means any outage or maintenance delays all inbound mail. Add a second host or move to a hosted provider.

Mixed providers. Records for both Google and Microsoft, often left over from a migration. Senders will split mail between them, and some messages will land in mailboxes nobody reads. Remove the old records.

Host does not resolve. The MX target has no A record, so senders cannot deliver there. This commonly follows a server decommission.

Common MX mistakes

• Leftover records after a migration. Old provider MX entries at a lower priority number than the new ones silently capture mail.
• Wrong hostname format. Entering mx.provider.com in a panel that appends your domain produces mx.provider.com.example.com. Add a trailing dot or follow the panel’s format.
• No MX at all. Senders fall back to your A record, which usually points at a web server that does not accept mail.
• Third-party backup MX with weak filtering. Spammers target the backup deliberately because it often skips the primary’s checks.
• Priority reversed. The backup is set to 10 and the primary to 20, sending everything to the backup first.

Changing MX records during a migration

Moving mailboxes between providers is where most MX problems start. A safe sequence looks like this:

1. A day before: lower the TTL on your existing MX records to 300 seconds so the change spreads quickly.
2. Set up the new provider first: create mailboxes and verify the domain, but do not switch MX yet.
3. Switch: delete the old MX records and add the new ones in a single edit, so there is no window where both sets are live.
4. Verify: run this lookup and confirm only the new provider’s hosts appear. Send test messages from an outside account.
5. Keep the old mailboxes for 48 hours: some senders cache the old records and will keep delivering there briefly.
6. Raise the TTL again to an hour or more once everything is stable.

Remember that SPF, DKIM and DMARC usually need updating at the same time, since the new provider sends from different servers.

MX records and your sending reputation

MX records are about receiving, but they touch reputation in three ways. Bounces and replies to your campaigns arrive through them, so a broken MX means you miss hard bounces and keep mailing dead addresses, which our guide on bounce rates explains. The mx mechanism in SPF authorises those same hosts to send, and each use costs a DNS lookup. And some receivers treat a From domain that cannot receive mail as suspicious.

Your MX hosts’ IPs also appear in the sender reputation checker, which tests them against public blocklists and checks their reverse DNS. You can check an individual MX IP with the reverse DNS checker or the blacklist checker.

Best practice checklist

1. Use at least two MX hosts, or a provider whose managed hostname is redundant.
2. Point MX records only at hostnames with valid A (or AAAA) records.
3. Keep one provider’s records at a time, and delete old ones after a migration.
4. Lower the TTL to 300 seconds before changes, then raise it back to an hour or more.
5. For domains that never receive mail, publish a null MX (0 .), v=spf1 -all and a DMARC reject policy.
6. Add MTA-STS and TLS-RPT so senders are required to use TLS when delivering to you.

For the full set of records a sending domain needs, see DNS records for email.