What this symptom usually tells you
Microsoft 365 custom-domain mail depends on tenant-specific DNS records. The MX destination commonly contains tenant/domain-derived information, so a value copied from another organization will not route correctly. SPF and autodiscover/verification records address different functions and should not be treated as substitutes for MX.
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.
- Check MX — 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.
- Check SPF — Inspect the single public v=spf1 policy, validate its terms and count DNS-query-causing mechanisms; duplicate policies or excessive lookups can invalidate SPF.
- Check autodiscover/verification as applicable — Verify check autodiscover/verification as applicable 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 check MX, check SPF, check autodiscover/verification as applicable 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
Open the domain’s DNS requirements in Microsoft 365 Admin Center and compare each assigned value with authoritative DNS. Correct the MX first for inbound delivery, merge Microsoft authorization into the single SPF policy, and repair autodiscover or verification records only when those checks are failing.
How to confirm this specific repair
The MX checker should show the exact Microsoft 365 destination assigned to the tenant and mail delivery should reach Exchange Online. SPF should remain a single valid policy, and client-discovery/verification records should resolve as Microsoft expects.
A common wrong turn
Do not publish a second SPF record containing only include:spf.protection.outlook.com. Microsoft’s include needs to be integrated into the domain’s one existing SPF policy together with other legitimate senders.
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.