What error does having two SPF records cause?

It causes a PermError (permanent error). Under RFC 7208, a receiving server that finds more than one v=spf1 record must return PermError instead of choosing one. Many receivers treat that as an authentication failure, which can send legitimate mail to spam or cause it to bounce.

Can I have an SPF record and a DKIM record on the same domain?

Yes. The one-record rule only applies to SPF records (those starting with v=spf1). DKIM keys, DMARC policies, and other TXT records live at different names or are distinct record types, so they coexist with SPF without any conflict.

How many DNS lookups can an SPF record use?

A maximum of 10. Each include, a, mx, ptr, and redirect mechanism costs a lookup, and nested includes count too. Going over 10 produces a PermError, so keep merged records lean and remove senders you no longer use.

Why You Can't Have Two SPF Records (and How to Merge Them)

VigilDog Team · September 7, 2026 · 6 min read

Add a new email provider, and it's easy to end up with two SPF records on the same domain, one for your old sender, one for the new one. It feels harmless, but the SPF specification treats it as a hard error, and the result is that legitimate mail can start failing authentication. Here's why two SPF records break things, how to confirm it's your problem, and how to merge them into one valid record.

Why two SPF records is an error, not just untidy

SPF is published as a single TXT record at the root of your domain, starting with v=spf1. The specification (RFC 7208) is explicit: if a domain publishes more than one record that begins with v=spf1, receiving servers must return a PermError, a permanent failure. They are not allowed to pick one, merge them, or guess your intent.

A PermError is worse than no SPF at all. Many receivers treat a PermError as an authentication failure, and under a DMARC policy of quarantine or reject, that can send your genuine mail to spam or bounce it outright. So two records don't just fail to help, they can actively break delivery for a domain that was working fine before the second record was added.

How SPF, DKIM and DMARC verify an email

How to confirm you actually have two

Before changing anything, verify the conflict. From a terminal you can list every TXT record on the domain and count the ones that start with v=spf1:

dig +short TXT example.com (or nslookup -type=TXT example.com on Windows).

Look through the output for lines beginning with "v=spf1". If you see two or more, that's the problem. Note that this only applies to full SPF records, having one SPF record plus unrelated TXT records (DKIM keys, domain verification strings, DMARC lives on a subdomain) is completely normal. It's specifically multiple v=spf1 records that trigger the error. Our DMARC checker will also flag a duplicate SPF record while it inspects your wider email authentication setup.

How to merge them into one record

The fix is to combine the mechanisms from both records into a single v=spf1 record, then delete the extras. Say you have these two:

v=spf1 include:_spf.google.com ~all and v=spf1 include:sendgrid.net ~all. You merge them by keeping one v=spf1 at the start, listing every include and mechanism from both, and ending with a single "all" mechanism: v=spf1 include:_spf.google.com include:sendgrid.net ~all.

Two rules make this safe. There must be exactly one all mechanism, and it goes at the very end, anything after it is ignored. And keep your qualifier consistent: ~all (softfail) is the common, forgiving choice, while -all (hardfail) is stricter. Don't mix a -all from one record with a ~all from another without deciding which policy you actually want.

Watch the 10-lookup limit while you merge

Merging records solves the PermError, but it can walk you straight into a second SPF limit. RFC 7208 caps an SPF evaluation at 10 DNS lookups, and mechanisms like include, a, mx, ptr, and redirect each consume one (nested includes count too). Exceed 10 and you get, ironically, another PermError.

Every provider you add to a merged record brings its own includes, so a domain sending through Google, a marketing platform, a helpdesk, and a payment provider can blow past 10 quickly. If you're near the limit, trim senders you no longer use, prefer providers with lean include chains, or use SPF flattening (replacing an include with the IP addresses it resolves to), while accepting that flattened records need maintenance when those IPs change.

Count include, a, mx, ptr, and redirect, they each cost a lookup.
Remove providers you've stopped using before adding new ones.
Stay comfortably under 10 to leave room for providers changing their chains.

Publish, then verify the result

Replace both old records with your single merged record at the domain root, then delete the leftover one, don't just edit one and leave the other in place. DNS changes take time to propagate, so wait for your TTL to pass before testing.

Then re-check: run the dig command again to confirm exactly one v=spf1 record exists, and re-test with a DMARC checker to confirm the PermError is gone and lookups are under the limit. SPF is only one leg of email authentication, if you're tightening this up, it's worth aligning DKIM and DMARC at the same time, covered in fixing SPF, DKIM, and DMARC.