Incoming email and MX diagnostics
Email delivery delayed or rejected after a DNS migration
A DNS migration can leave a domain publishing MX records for the wrong receiving service. Compare the public targets with the provider you intended to use before editing records or assuming every mixed MX set is broken.
Messages stopped reaching domain mailboxes after DNS records or nameservers changed.
Email delivery delayed or rejected after a DNS migration. Expected receiving provider: Microsoft 365 Public MX target: aspmx.l.google.com.
Run this automated test on my domain
Enter your domain. MailFixIt checks the relevant DNS records automatically and shows the evidence.
What an MX provider conflict means
MX records tell sending servers where to deliver incoming mail. If every recognized public MX target belongs to a different provider than the one you explicitly selected, the domain may have retained an old zone, imported stale records or switched nameservers without recreating its current mail route.
MailFixIt currently performs conservative provider comparison for clearly recognized Google Workspace, Microsoft 365 and Zoho target sets. It does not turn an unknown or mixed set into a confident provider-conflict warning.
What the check does and does not prove
The diagnostic resolves the domain's public MX records and compares an unambiguous recognized set with the receiving provider you specify. It can expose a strong routing mismatch, but it cannot confirm mailbox licensing, tenant ownership, gateway forwarding or the provider's internal routing.
Possible diagnostic results
Provider matches
The recognized MX targets agree with the selected receiver. Continue with tenant, mailbox and provider-side delivery investigation.
Clear provider conflict
All recognized targets point to another supported provider. Confirm the intended service and obtain its exact MX values before changing DNS.
Mixed or gateway routing
The target set is not classified as a conflict. A filtering gateway, staged migration or split architecture may be intentional.
Provider unknown
The public targets are shown as evidence without a guessed vendor. Compare them with authoritative setup instructions from your receiver.
How to repair email after a DNS change
- Confirm the active authoritative nameservers and the receiving provider that should handle new mail.
- Export or record every existing MX value and priority before editing anything.
- Get the exact domain-specific MX target from the intended provider's admin console.
- If a security gateway is used, verify its documented inbound and downstream route instead of bypassing it.
- Change only the confirmed stale records, then recheck public DNS and test a real mailbox.
These domains are fictional; never derive a production MX target from this example.
Before: example.com. MX 10 aspmx.l.google.com. After: example.com. MX 0 example-com.mail.protection.outlook.com.
Rollback means restoring the recorded prior MX set if the intended tenant is not ready. Lower TTL in advance when a planned migration permits it.
Verify the repair
Resolve MX from multiple public resolvers, confirm the selected provider receives the SMTP connection, and send a controlled external test to a known mailbox. Preserve the full rejection text if it still fails; it will narrow the next diagnostic step.
Frequently asked questions
Can a correct-looking MX record still interrupt incoming email?
Yes. It can point to the wrong tenant, an unconfigured provider target or an intentional gateway whose downstream route is broken. Public DNS confirms routing data, not mailbox or tenant readiness.
Should mixed MX providers always be replaced?
No. Mixed targets can represent an intentional security gateway or migration. Confirm the mail architecture before replacing them; MailFixIt avoids a provider-conflict warning when the target set is mixed or ambiguous.
Related email diagnostics
Primary sources: RFC 5321: address resolution and mail routing, Cloudflare: troubleshooting email issues.