Sender Policy Framework (SPF) is one of the three pillars of email authentication, alongside DKIM and DMARC. It lets a domain owner declare, in DNS, which servers are permitted to send mail using that domain. The framework is simple and effective, but it carries one rule that trips up a surprising number of teams: a domain may publish exactly one SPF record. The moment a second appears, SPF stops working entirely.
For the site owner (plain English)
This means your domain has two separate SPF lines in its DNS, and the rule is strict: you are only allowed one. Having two cancels both out, so email providers stop trusting your mail — which is worth fixing promptly, even though it is a quick change. It almost always happens innocently: each new email tool told you to “add this SPF record,” so a second one got created alongside the first. The fix is to combine them into a single line. Log in to your DNS provider, take the include: part from each record, put them together in one TXT record that starts with v=spf1 and ends with a single -all or ~all, and delete the leftover. One record in, one record out.
Can a domain have more than one SPF record?
RFC 7208, the specification that defines SPF, is unambiguous on this point. A domain that wishes to publish an SPF policy does so with a single DNS TXT record beginning with v=spf1.
If a receiving mail server performing an SPF check finds two or more records that start with v=spf1 on the same name, the result is a permerror — a permanent error. The specification states that records that have a version of spf1 but appear more than once mean the check must return permerror.
A permerror is not a soft failure. It tells the receiver that your published policy is broken, and most receivers treat that as though no usable SPF policy exists.
Worse, because DMARC relies on SPF (or DKIM) passing and aligning, an SPF permerror removes one of the two ways your mail can satisfy DMARC. If your DKIM is also misconfigured, a single duplicate SPF record can be enough to push legitimate mail into spam folders or outright rejection.
The fix is always the same in shape: there must be one, and only one, v=spf1 record, and it must list every legitimate sender for the domain.
Why does this keep happening?
Almost nobody sets out to publish two SPF records. It happens by accretion. The pattern is so consistent it is worth naming: each new email-sending service you adopt hands you a setup wizard, and that wizard tells you to “add this SPF record to your DNS.”
Imagine the timeline of a growing business. First you adopt Google Workspace for company mail, and you add the record Google suggests:
v=spf1 include:_spf.google.com ~allSix months later marketing signs up for an email platform — say a newsletter or CRM tool — and its onboarding screen says to add its SPF record. Following the instructions literally, someone creates a second TXT record:
v=spf1 include:mail.marketingtool.example ~allEach instruction was correct in isolation. The provider does not know what other records you already have, so its wizard describes the simplest possible case: a domain with no existing SPF.
The result is two v=spf1 records living side by side on the same domain — and an instant permerror. The mail that worked yesterday may keep flowing for a while because some receivers cache or tolerate, but the policy is now formally invalid and will fail at strict receivers.
The same thing happens with transactional senders, helpdesk tools, invoicing systems, and any service that sends on your behalf. The more tools a team adopts, the more likely a duplicate creeps in.
How do I merge them into a single record?
The cure is to combine every sender’s mechanisms into one coherent record. An SPF record is just a version tag, followed by a space-separated list of mechanisms (such as include:, ip4:, ip6:, a, and mx), ending in a single all mechanism with a qualifier. To merge, you keep v=spf1 once at the start, gather all the mechanisms from every record, and keep exactly one trailing all.
Worked example: merging Google and a marketing tool
Start with the two conflicting records:
; Record 1 (Google Workspace)
v=spf1 include:_spf.google.com ~all
; Record 2 (marketing platform) — INVALID as a second record
v=spf1 include:mail.marketingtool.example ~allTo merge them, take the include: mechanism from each, place them in a single record, and keep one closing qualifier. Delete both old records and publish this one instead:
v=spf1 include:_spf.google.com include:mail.marketingtool.example ~allThe order of mechanisms does not change the result for include: and ip4: entries, so you can list them in whatever order is easiest to maintain. If you also send from a fixed server IP address, you add it as an ip4: (or ip6:) mechanism in the same record:
v=spf1 ip4:198.51.100.25 include:_spf.google.com include:mail.marketingtool.example ~allTwo details matter when you merge. First, the version tag v=spf1 appears once, at the very beginning, and never again inside the record. Second, the record ends with a single all mechanism carrying one qualifier — -all for a hard fail or ~all for a soft fail. You do not keep the all from each original record; you choose one and use it once, at the end.
Common gotcha: merging can push you over SPF’s 10 DNS-lookup limit, which is a different permerror. Each include:, a, mx, ptr, and exists mechanism counts toward a hard ceiling of ten lookups during evaluation. After you combine records, count the lookups your single record triggers — if you are over ten, see the too-many-lookups guide for how to flatten or consolidate. A second, related trap: pasting a space-separated second v=spf1 inside one TXT value (for example v=spf1 include:a ~all v=spf1 include:b ~all) is still invalid. It must be one coherent record with the version tag stated only once.
How do I verify the fix?
After publishing the merged record, give DNS time to propagate — a few minutes for most providers, longer if your old record had a high TTL. Then re-check the domain. A correct configuration shows exactly one v=spf1 TXT record and resolves to a clean result rather than permerror.
Confirm three things during verification. One: there is a single v=spf1 record on the domain and the duplicate is gone. Two: the record ends in one all mechanism with one qualifier. Three: the record evaluates within the 10-lookup limit, so you have not traded a duplicate-record permerror for a too-many-lookups one. If you cross the lookup ceiling, work through the SPF too-many-lookups guide before considering the job done.
See your SPF, DKIM, and DMARC status in one pass — including whether a duplicate record is breaking authentication.
Check your SPF record →Frequently asked questions
Can I have two SPF records?
No. RFC 7208 requires a domain to publish exactly one SPF record, and a receiving server that finds two or more v=spf1 TXT records on the same name must return a permerror. A permerror means your policy is treated as broken: SPF effectively does not work, and one of the two paths your mail can use to pass DMARC disappears. This is true even if each record looks correct on its own. The limitation exists because SPF evaluation is meant to be deterministic — a receiver should be able to read one unambiguous policy, not guess which of several conflicting records to trust. If you have adopted multiple sending services, the answer is never to add a second record; it is to merge every sender into the single record you already publish.
How do I merge multiple SPF records?
Take every mechanism from each of your existing v=spf1 records — the include:, ip4:, ip6:, a, and mx entries — and place them into a single record. Keep the version tag v=spf1 once at the start, list all the gathered mechanisms separated by spaces, and finish with one all mechanism and one qualifier. For example, Google plus a marketing tool becomes v=spf1 include:_spf.google.com include:mail.marketingtool.example ~all. Delete the old separate records so only the merged one remains. Order does not affect the outcome, so arrange mechanisms for readability. After merging, count the DNS lookups the combined record triggers to make sure you stay at or under ten, and re-check the domain to confirm a clean result.
Why did adding a new email service break SPF?
Almost always because the new service’s setup wizard told you to “add this SPF record,” and someone followed that literally by creating a brand-new TXT record alongside the one you already had. The provider’s instructions assume a domain with no existing SPF policy, because that is the simplest case to document — it cannot know what other records you maintain. The result is two v=spf1 records on one domain, which produces a permerror and invalidates the whole policy. The mail may keep flowing briefly because some receivers are lenient or rely on cached data, but strict receivers will start failing your mail. The correct action was to add the new service’s include: mechanism into your existing record, not to publish a second one.
What qualifier should the merged record end with?
End the merged record with one all mechanism carrying a single qualifier — either -all (hard fail) or ~all (soft fail). -all tells receivers to treat mail from any source not listed in the record as unauthorized, which is the stronger, more protective stance. ~all marks such mail as suspicious but not definitively unauthorized, which is gentler and useful while you are still confirming that every legitimate sender is listed. A common, cautious approach is to deploy with ~all first, watch your DMARC reports until you are confident no real sender is missing, then tighten to -all. Whichever you choose, the record must end in exactly one all: do not keep a separate all from each record you merged.
Next steps
For the full picture of how SPF, DKIM, and DMARC fit together, read the email authentication guide. If your newly merged record now triggers more than ten DNS lookups, work through the SPF too-many-lookups guide to bring it back under the limit. For step-by-step DNS entry, see setting up SPF, DKIM and DMARC on GoDaddy, and for the bigger picture read how to prevent email spoofing. For the official rules, the specification is RFC 7208.