What this symptom usually tells you
A working website confirms the web endpoint, not the mail route. Incoming mail depends on MX and the resolution/reachability of its targets; sending reputation and authentication depend on SPF, DKIM and DMARC. These can be absent or invalid while the site continues to load normally.
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 first — 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.
- Identify provider — Verify identify provider from the public Internet and compare it with the value the responsible provider says should be live.
- Validate SPF/DMARC/DKIM — Inspect the single public v=spf1 policy, validate its terms and count DNS-query-causing mechanisms; duplicate policies or excessive lookups can invalidate SPF.
Record the current state before editing
Before changing business-email DNS and mail authentication settings, save the exact public values for check MX first, identify provider, validate SPF/DMARC/DKIM 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
Start with MX because missing or wrong MX can prevent delivery entirely. Identify the intended provider and make its targets authoritative. Then validate one SPF policy, the actual DKIM selector and DMARC. Treat authentication as separate from basic receiving so changes are made in the right order.
How to confirm this specific repair
MX targets should resolve to the expected provider and inbound delivery should work. SPF/DKIM/DMARC should then return valid public records for the services that actually send. Website A/AAAA/CNAME and HTTPS should remain untouched and healthy.
A common wrong turn
Do not replace website A records with mail-server addresses or create an MX record pointing at the web host merely because the website is working. MX must represent the mailbox service.
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.