Can I not just have one SPF record per sender?

No. The limit is one record per domain, not one per sender. Multiple senders are expressed as multiple mechanisms inside a single record, which is what include exists for.

DNS allows several TXT records on the same name. Why is this different?

DNS does allow it, and you will often have several TXT records at the apex for domain verification and similar purposes. That is fine. The restriction is specific to SPF: only one of those TXT records may begin with v=spf1.

Which record does the receiver use if there are two?

Neither. It is a permanent error, not a tie broken in favour of one. Receivers do not merge them, prefer the longer one, or fall back to the first.

Does a subdomain having its own SPF record cause this?

No. Each DNS name is evaluated separately, so example.com and mail.example.com may each have one SPF record. The error only arises when a single name carries two.

Can I use redirect to keep records separate?

The redirect modifier hands evaluation to another domain's record entirely, which is useful for keeping one canonical record across many domains. It does not let you publish two records on one name, and it replaces rather than supplements your mechanisms.

CriticalAuthentication

More than one SPF record published

A domain must publish exactly one SPF record. When a receiver finds two or more TXT records beginning v=spf1 it returns permerror and stops. It does not merge them, and it does not pick the more permissive or the more recent one. The practical result is that SPF fails for all of your mail, including senders correctly listed in both records.

Check your own domainSPF checker

What causes this

RFC 7208 allows exactly one SPF record per domain. When a receiver finds two, it does not merge them or pick the more permissive one. It returns permerror and stops. This almost always happens when a second sending service is onboarded and its setup guide says to 'add this TXT record', so a new record is created alongside the existing one instead of the include being merged into it.

What it breaks

SPF evaluates to permerror for every message you send, which most receivers treat as a failure. Any DMARC policy that relies on SPF alignment stops working. This is the single most common self-inflicted email authentication fault.

What the receiving server does

RFC 7208 is explicit: if the lookup returns more than one record starting with the version tag, the evaluation is a permanent error. Receivers implement this literally. The failure is total rather than partial, which is what makes it worse than most misconfigurations: a record with one wrong mechanism still authorises everything else, while two valid records authorise nothing at all. Under DMARC, SPF stops contributing, so alignment falls to DKIM alone.

Two valid records, merged into one

This almost always happens during onboarding: a new sending service asks you to add an SPF record, and it gets added alongside the one already there rather than merged into it. Both records are individually correct. Together they are a permanent error. The fix is to combine the mechanisms into a single record and delete the other.

oldv=spf1 include:_spf.google.com ~allthe record already published

newv=spf1 include:sendgrid.net ~alladded by the new provider (this is the break)

fixv=spf1 include:_spf.google.com include:sendgrid.net ~allone record, both senders, one policy at the end

How to fix it

Merge every record into one, keeping all mechanisms, then delete the extras.

Copy every mechanism (include:, a, mx, ip4:, ip6:) from all of the SPF records you have.
Build a single record beginning with v=spf1, containing each of those mechanisms once, ending with a single all mechanism.
Publish that one record.
Delete the other SPF records. Only TXT records starting with v=spf1 count. Other TXT records are unaffected and must be left alone.
Re-check the domain to confirm exactly one record is now returned.

If you send with

When a provider gives you a record to add: Read it as a set of mechanisms rather than as a record to publish. Take the part between v=spf1 and the trailing all (usually a single include) and add just that to your existing record, before the all. Never publish their record as a second TXT entry.
DNS panels that hide the problem: Some interfaces list TXT records separately enough that two SPF records are not obviously adjacent, particularly where one was added years earlier. Search the full TXT set for the string v=spf1 rather than scanning visually, because this is a problem you can look straight at without seeing.

Confirming the fix worked

List every TXT record at the apex and count how many begin with v=spf1. The answer must be exactly one.
Merge the mechanisms into a single record, keeping only one trailing all: a record may contain only one.
Delete the redundant record rather than blanking its value, since an empty TXT record can linger and confuse later audits.
Re-check after the TTL expires, and confirm the merged record has not pushed you over the ten lookup limit.

Common questions

Can I not just have one SPF record per sender?: No. The limit is one record per domain, not one per sender. Multiple senders are expressed as multiple mechanisms inside a single record, which is what include exists for.
DNS allows several TXT records on the same name. Why is this different?: DNS does allow it, and you will often have several TXT records at the apex for domain verification and similar purposes. That is fine. The restriction is specific to SPF: only one of those TXT records may begin with v=spf1.
Which record does the receiver use if there are two?: Neither. It is a permanent error, not a tie broken in favour of one. Receivers do not merge them, prefer the longer one, or fall back to the first.
Does a subdomain having its own SPF record cause this?: No. Each DNS name is evaluated separately, so example.com and mail.example.com may each have one SPF record. The error only arises when a single name carries two.
Can I use redirect to keep records separate?: The redirect modifier hands evaluation to another domain's record entirely, which is useful for keeping one canonical record across many domains. It does not let you publish two records on one name, and it replaces rather than supplements your mechanisms.