What this symptom usually tells you
A website migration should be independent of mailbox hosting, but DNS edits made during the move can accidentally replace MX records or the mail hostname. This is especially common when a host provides a “replace DNS” workflow that imports only records needed for the website.
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.
- Compare MX before/after — 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.
- Do not point MX to web host unless intended — 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.
- Restore auth records — Verify restore auth records 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 compare MX before/after, do not point MX to web host unless intended, restore auth records 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
Keep the existing mail provider unless a mail migration was intentionally planned. Restore its MX records and any mail/autodiscover hostnames while leaving the new website A/CNAME records in place. Compare SPF/DKIM/DMARC with the pre-migration configuration so legitimate senders remain authorized.
How to confirm this specific repair
Website DNS should identify the new host while MX still identifies the intended mail service. Incoming and outgoing tests should succeed, and the email health check should not show unresolved MX targets or duplicate authentication policies.
A common wrong turn
Avoid “fixing” mail by reverting the whole website DNS migration. Web and mail records can point to different providers and should be repaired independently.
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.