Troubleshooting guideReviewed 2026-08-07By HostWithShery technical editorial

Multiple SPF records found

A domain should publish one SPF policy. Multiple v=spf1 records create an invalid evaluation state; merge the legitimate mechanisms into a single record.

Start with evidence from your own domain before changing DNS, SSL or mail settings.
Check your own configuration

Email Health Check

This page is preconfigured with the Email Health Check that best matches this problem.

No accountPublic evidence only
Live public check

Checks MX routing plus SPF, DKIM discovery, DMARC, BIMI, MTA-STS and TLS-RPT public signals.

No account · Public configuration only
On this page

What this symptom usually tells you

Two or more TXT strings beginning with v=spf1 at the same owner name do not form two independent valid policies. The evaluator encounters multiple SPF records and returns a permanent error, so even individually sensible vendor records must be consolidated.

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.

  • Collect existing policiesVerify collect existing policies from the public Internet and compare it with the value the responsible provider says should be live.
  • Remove duplicatesVerify remove duplicates from the public Internet and compare it with the value the responsible provider says should be live.
  • Merge legitimate sendersVerify merge legitimate senders from the public Internet and compare it with the value the responsible provider says should be live.
  • Check lookup countVerify check lookup count 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 collect existing policies, remove duplicates, merge legitimate senders, check lookup count 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

List every current SPF record and identify which mechanisms authorize real senders. Build one combined policy, removing duplicated mechanisms and obsolete services. Check the DNS lookup cost of includes, a, mx, exists and redirect before publishing the merged record.

How to confirm this specific repair

A public TXT lookup should expose only one v=spf1 policy for the domain, the checker should parse it without a multiple-record error, and legitimate sending services should pass SPF where alignment is expected. Monitor DMARC reports for unexpected sources before tightening policy.

A common wrong turn

Concatenating two complete records including two v=spf1 prefixes or multiple all mechanisms is not a valid merge. The result must be one coherent SPF grammar, not two strings pasted together.

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.