You added a marketing platform, so you followed its setup guide and pasted its SPF snippet into a new TXT record at your domain's root. Now legitimate mail from your primary provider is landing in spam, or bouncing outright, even though nothing about that provider's setup changed. The DNS lookup shows two records starting with v=spf1, and receiving servers do not know which one to trust — so they trust neither.
EmailControl is a monitoring service that checks a domain's SPF, DKIM, and DMARC records on a schedule and alerts you the moment one of them fails. Multiple SPF records is one of the most common failures it flags, because the mistake is easy to make and invisible until mail starts disappearing.
What Is a Multiple SPF Records Error?
SPF is a DNS TXT record that lists every server allowed to send mail for a domain, and a domain is only permitted to publish one of them. A multiple SPF records error happens when a second TXT record starting with v=spf1 exists alongside the first, usually added by a well-meaning setup guide that told you to "add this TXT record" without checking whether one already existed.
RFC 7208, the spec that defines SPF, states plainly that a domain must have at most one SPF record. When a receiving mail server finds two, it cannot determine which one is authoritative, so it treats the lookup as a permanent error rather than guessing.
Why Do Multiple SPF Records Break Authentication?
SPF evaluation does not merge conflicting records the way a person reading them might. The moment a DNS query for TXT records returns more than one string beginning with v=spf1, the SPF check ends in permerror — a permanent error, distinct from a soft fail or hard fail. A permerror does not mean this sender is unauthorized; it means this record could not be evaluated at all.
That distinction matters because a permerror applies to every sender on the domain, not just the one that caused it. If your primary provider was correctly listed in the original record, it still fails, because the receiving server never gets far enough to check who is listed. This is why the symptom looks unrelated to the actual change — you added a new tool, and an old, correctly configured sender starts bouncing.
How Do You Merge Multiple SPF Records Into One?
The fix is combining every authorized sender into a single record and deleting the rest. There is no DNS-level way to have SPF read two records as one; the merge has to happen in the text of the record itself.
- List every service that sends mail for the domain — your mail provider, marketing platform, helpdesk, CRM, and any transactional email API.
- Collect each service's SPF
include:mechanism from its own setup documentation (for exampleinclude:_spf.google.com). - Write one record combining every include:
v=spf1 include:_spf.google.com include:sendgrid.net ~all. - Delete every existing SPF TXT record at the domain's root, including the ones you are replacing.
- Publish the single merged record in its place.
- Query the domain's TXT records again and confirm exactly one string starts with
v=spf1. - Send a test message through each listed sender and check the received message's authentication headers for an SPF pass.
This is the point where a manual fix becomes tedious if you manage more than one domain: every new tool your team adopts is another potential duplicate record, and nobody remembers to check DNS before pasting a setup snippet. EmailControl's SPF and DMARC check reads the domain's current record on your plan's schedule and tells you in plain language when a second record has appeared, before it silently breaks a sender you were not even thinking about.
How Many DNS Lookups Can One SPF Record Have?
Merging records into one does not mean you can add senders without limit. RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS lookups per check, and mechanisms like include, a, mx, ptr, and exists each count toward that limit — some of them recursively, since an include can itself contain more includes.
A merged record with six or seven include mechanisms is not unusual once you count a mail provider, a marketing platform, a support desk, and a payroll or invoicing tool. Cross the limit and the record fails with a different permerror, too many DNS lookups, even though it looks syntactically correct. The practical takeaway: merge duplicates first, then count lookups before adding the next sender.
You can count lookups manually by walking each include and counting every nested include, a, mx, and redirect mechanism it resolves to, but this gets tedious past three or four services and easy to miscount. If a provider's own SPF include already nests two or three lookups deep, adding it can push a record from 8 lookups to 11 without a single visible change to your own record text. When a provider offers a choice between an include mechanism and a flat list of IP addresses, the IP list costs zero lookups and is worth using once a domain sends through more than four or five services.
| Symptom | Likely cause | Fix |
|---|---|---|
| Old provider suddenly fails SPF | A second v=spf1 record was added for a new tool | Merge both into one record, delete the duplicate |
| New provider fails, old one still works | New provider's include was never added | Add its include mechanism to the existing record |
| Everything fails after merging | Merged record exceeds 10 DNS lookups | Remove an unused include or flatten one to static IPs |
What Happens If You Ignore a Multiple SPF Records Error?
Mailbox providers do not treat a permerror as a pass. Google and Microsoft's receiving servers weigh a permerror heavily toward spam placement, and if the domain enforces DMARC at p=quarantine or p=reject, a failed SPF check that also fails DKIM alignment gets the message quarantined or rejected outright. The longer two records sit in DNS, the more senders accumulate on the wrong side of that line as your organization adds tools.
The failure is also inconsistent in a way that delays diagnosis. Some receiving servers reject a permerror outright, others fold it into a spam score alongside dozens of other signals, so a domain with a broken SPF record can look fine to Gmail recipients for weeks while Outlook.com or a corporate mail gateway silently drops the same messages. Support teams often chase this as a delivery problem with the destination mailbox before anyone checks DNS, because the sending side reports the message as sent successfully every time.
Some teams assume a free online SPF checker is enough, and for a one-time check it is — tools like this catch a duplicate record the moment you run them. The gap is that nobody runs them again next month when a different team adds a different tool. EmailControl runs the same class of check on a schedule (weekly on the free plan, daily on Pro, hourly on Agency) and emails you when the record changes shape, so the fix happens before a customer mentions a missing invoice.
Fixing the Record Is Only Half the Job
Once the merged record is published and verified, the remaining risk is regression: the next contractor, marketing hire, or SaaS trial that asks you to add just one more TXT record can reintroduce the exact same duplicate. Treat SPF like a shared file, not a one-time setup step — anyone touching it should check what already exists first.
Add the domain to EmailControl and it checks the SPF, DKIM, and DMARC records on your plan's schedule, so a second SPF record gets caught the same day it appears instead of the next time someone happens to notice bounced mail. Start free monitoring on one domain — no credit card required, and the first check runs within minutes of adding the domain.