What this symptom usually tells you
SPF is a sender-authorization policy published as a TXT record beginning with v=spf1. Its absence does not necessarily stop mail delivery, but receivers lose one authentication signal and DMARC cannot rely on aligned SPF for messages from that domain.
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.
- Inventory senders — Verify inventory senders from the public Internet and compare it with the value the responsible provider says should be live.
- Publish one v=spf1 TXT — Inspect the single public v=spf1 policy, validate its terms and count DNS-query-causing mechanisms; duplicate policies or excessive lookups can invalidate SPF.
- Validate — Verify validate 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 inventory senders, publish one v=spf1 TXT, validate 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
Inventory every legitimate service that sends with the domain before publishing a policy. Use the mechanisms documented by those services and publish one SPF record at the domain used for the envelope sender. Choose the final qualifier deliberately rather than copying a strict policy before the sender inventory is complete.
How to confirm this specific repair
The SPF checker should find exactly one syntactically valid v=spf1 policy and its DNS-query-causing mechanisms should stay within the RFC evaluation limit. Send test messages from each legitimate platform and inspect Authentication-Results rather than assuming publication alone proves a pass.
A common wrong turn
Do not create one SPF TXT record per vendor. SPF evaluators expect a single policy for a given owner name; multiple v=spf1 records create a permanent-error condition instead of combining automatically.
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.