MX Records Not Updating

Changed email providers and mail is still going to the wrong server? Check MX records across 14 public resolvers and find stale or mixed answers.

Mail migrations fail quietly when MX is stale

When you move email to Google Workspace, Microsoft 365, Fastmail, or another provider, old MX records can stay cached after the dashboard looks correct. Sending mail servers use the resolver they trust, so one sender can deliver to the new host while another still reaches the old one.

Use the form above with type MX. Full propagation looks like every resolver returning the same mail exchanger hosts and priorities.

What to verify

• Priorities: lower numbers are tried first. Mixed old and new priorities can split delivery.
• Old hosts removed: adding new MX records without deleting old ones can send mail to both providers.
• SPF and DMARC: inbound MX may be correct while outbound authentication is still missing.
• Nameservers: stale delegation can make the wrong provider authoritative.

FAQ

How long do MX changes take?

They take as long as the previous MX TTL at each resolver. Many domains use 1-hour to 24-hour TTLs for mail records, so a transition can look mixed for a while.

Can old MX records break delivery?

Yes. If old and new providers are both published, senders may randomly deliver to the wrong system depending on priority and availability.

What should I check after MX?

Check SPF, DKIM and DMARC. MX controls where inbound mail goes; SPF, DKIM and DMARC control whether outbound mail is trusted.