What this symptom usually tells you
Recreating a DNS zone during a migration often copies the obvious web records first and leaves the MX set behind. With no usable MX, other mail systems cannot discover the domain’s intended inbound mail exchangers even though the website migration itself may be successful.
Evidence that narrows the cause
Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the business-email DNS and mail authentication diagnosis rather than as a standalone health score.
- Identify mail provider — Verify identify mail provider from the public Internet and compare it with the value the responsible provider says should be live.
- Restore MX priorities/targets — Read the public MX priorities and targets, then verify that each target itself resolves. A visible MX record is not enough if its mail hostname is broken.
- Retest mail hosts — Verify retest mail hosts from the public Internet and compare it with the value the responsible provider says should be live.
Record the current state before editing
Before changing business-email DNS and mail authentication settings, save the exact public values for identify mail provider, restore MX priorities/targets, retest mail hosts and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.
Safest repair path
Determine which service hosts the mailboxes and use that tenant’s current official MX values, including priorities where the provider specifies them. Publish only the provider set that is still active, and ensure each hostname resolves. Restore related authentication records as a separate step.
How to confirm this specific repair
Public MX lookup should return the expected provider set and no stale competing exchanger. Resolve each target and test inbound mail. If mail is accepted but sender authentication is weak, continue with SPF/DKIM/DMARC rather than changing MX again.
A common wrong turn
Do not guess MX values from another customer or copy old examples from a blog. Microsoft, Zoho and other services can use tenant/region-specific targets, and priorities are part of the published routing configuration.
When to escalate with evidence
If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed business-email DNS and mail authentication result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.