Multiple SPF records — how to fix the error

What causes multiple SPF records

Multiple SPF records are almost always created by accident. The most common cause is adding a new email provider without realising that an SPF record already exists.

For example, a domain migrating from one provider to another may end up with two separate TXT records:

v=spf1 include:_spf.google.com -all

v=spf1 include:sendgrid.net -all

Both records look valid in isolation, but publishing two v=spf1 records at the same domain is against the SPF specification. The correct fix is to merge all mechanisms into one record and delete the duplicate.

Why SPF PermError breaks deliverability

When a receiving mail server finds more than one TXT record starting with v=spf1, it returns an SPF PermError instead of a pass or fail result.

PermError means the SPF policy is permanently invalid. The receiving server cannot determine which record to evaluate, so it treats the message as unauthenticated.

Many receiving servers treat SPF PermError as an SPF failure. This can cause DMARC alignment to break — because DMARC relies on either SPF or DKIM passing with alignment — increasing the chance of spam placement or outright rejection.

How to merge SPF records safely

Merging SPF records requires combining all include mechanisms and IP ranges into a single v=spf1 TXT record, then deleting all duplicate records.

Example before merging:

v=spf1 include:_spf.google.com -all

v=spf1 include:sendgrid.net ~all

Example after merging:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Once merged, verify that only one v=spf1 TXT record exists. Verify the merged record immediately using MXFend's SPF Checker.

SPF include pitfalls

When merging, watch the SPF DNS lookup limit. SPF allows a maximum of 10 DNS lookups. The mechanisms include, a, mx, ptr, and exists each count, as does the redirect= modifier.

Each include statement triggers at least one lookup, and nested includes inside provider records also count. Adding multiple providers quickly approaches or exceeds the 10 lookup limit.

If the merged record exceeds the limit, SPF will fail with a PermError even after removing the duplicate. Remove unused senders and obsolete includes before publishing the merged record.

How to verify the fix

After merging and deleting the duplicate SPF record, wait for DNS propagation (typically up to 48 hours, but usually faster).

Then use MXFend's SPF Checker to confirm that only one SPF record exists, that the record has no PermError, and that the total DNS lookup count is below 10.

Also run the MXFend Email Security Score to confirm that SPF, DMARC, and all other authentication checks pass correctly.

Common SPF mistakes

Adding a new provider without checking for an existing SPF record. Always audit the current DNS before publishing a new v=spf1 record.

Keeping the old record when migrating. After moving to a new email provider, remove the previous include from the SPF record.

Using +all or ?all at the end. These mechanisms allow all senders or define no policy, which disables SPF protection. Use -all or ~all.

Forgetting DKIM. SPF alone is not sufficient for DMARC enforcement. Ensure DKIM is also configured so DMARC can pass even when SPF breaks during email forwarding.