MX Record Propagation Check: Fix Mail Routing

Check MX propagation before blaming the inbox

A stale MX answer can make a new mailbox look broken. One resolver may send mail to Google Workspace while another still sends it to Microsoft 365, Zoho, or your old host.

MX records tell the world where to deliver mail for a domain. They live in DNS, so changes spread on the schedule set by your TTL and by the recursive resolvers that cached the old answer. Many changes appear within minutes. Some take longer because a resolver already cached the previous MX set before you changed it.

Do the check from more than one place before you blame Gmail, Outlook, or the mail host. Query the authoritative nameservers first. That shows what your DNS provider is publishing now. Then query public recursive resolvers such as Google, Cloudflare, Quad9, and your office or server resolver. If the authoritative answer is right but some recursive resolvers still show the old host, you are waiting on cache expiry.

• Find the authoritative nameservers with dig NS example.com.
• Ask one directly with dig @ns1.provider.example example.com MX.
• Compare public resolvers with dig @8.8.8.8 example.com MX, dig @1.1.1.1 example.com MX, and dig @9.9.9.9 example.com MX.
• Read the TTL carefully. An authoritative answer shows the published TTL. A recursive answer usually shows the time left in that resolver's cache.
• Send a small test only after the resolver you care about returns the new MX set.

What a correct MX answer looks like

A good MX set is boring. It has the hosts your provider gave you, the right priority numbers, and no leftovers from the old mailbox provider.

MX priority is lower number first. If your provider says to publish 10 mx1.examplemail.com and 20 mx2.examplemail.com, keep those exact hostnames and priorities. Do not mix Google and Microsoft MX records during a cutover unless both systems are designed to accept mail for the same domain. Most failed migrations come from one old record left behind.

Also check that each MX hostname resolves. An MX record points to a host name, and that host should have A or AAAA records. RFC 2181 says the host named by an MX record must not be a CNAME alias. Many receivers tolerate strange DNS, but mail routing is old infrastructure. Boring DNS wins.

If your new provider uses verification records, publish those too. They do not replace MX. They only prove that you control the domain.

MX only proves where mail goes

Once mail reaches the right host, Gmail and Outlook still decide whether they trust it.

MX records are about receiving mail. SPF, DKIM, and DMARC are about proving that outbound mail using your domain is allowed. A domain can have perfect MX records and still land in spam if authentication is missing or broken.

• SPF is a TXT record that lists allowed senders. Use your provider's include values, publish only one v=spf1 record for each hostname, and stay under the SPF 10 DNS lookup limit from RFC 7208.
• ~all is a soft fail. It tells receivers that other senders are probably not allowed. -all is a hard fail. Use it only when you know every real sender is covered.
• DKIM signs outbound mail with a selector such as selector1._domainkey. The selector in the message must match a public key in DNS.
• The DMARC TXT record lives at _dmarc. Start with p=none and a rua address so you can read aggregate reports, then move to quarantine or reject when real mail passes SPF or DKIM alignment.
• Check blocklists after authentication. A bad IP or domain reputation can still push mail to junk.

The free InboxRadar domain scorecard is useful here because it reads live MX, SPF, DKIM, and DMARC records together instead of making you chase each record by hand. If DMARC aggregate reports are hard to read, use the DMARC report reader before tightening policy.

When propagation is done but mail still fails

If every resolver returns the new MX records, stop waiting and test the mail path.

Send from an outside mailbox to a fresh address on the domain. If it bounces, read the SMTP error. A 5xx error usually means the destination host rejected the message. A timeout points to network, firewall, or provider routing trouble. If the message arrives in spam, read the headers and look for SPF, DKIM, and DMARC results.

For Google and Microsoft senders, current sender rules put real weight on authentication, alignment, low spam complaints, working DNS, and sane sending behavior. Bulk senders have stricter requirements. A mailbox provider may route mail to spam when the message passes MX routing but fails identity checks, comes from a poor reputation source, or looks like abuse.

Keep one more split in mind. Email DNS and AI search visibility are different checks. For AI answers, allow OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Disallowing those in robots.txt removes you from that engine. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls, and blocking them does not remove you from live AI search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. robots.txt is a stated policy, not proof of what happened. Perplexity-User and Bytespider have been reported to ignore it, so use logs carefully. Only Googlebot documents JavaScript rendering. Client-side-only content may be a risk for other AI crawlers. You can check that with the AI visibility checker.