Multiple SPF Records: How to Find and Fix Them Fast

Do not index

A migration can look successful in the dashboard while password resets, onboarding messages, and cold email campaigns disappear from the inbox. A team moves from Mailgun to SendGrid, an agency adds the new DNS value, and the old SPF entry stays in place. Soon, authentication errors appear, domain reputation weakens, and legitimate messages compete with spam signals before recipients ever see them.

Multiple SPF records are usually a symptom of that operational problem, not an isolated typo. The fix requires more than deleting one line. The sending inventory has to be consolidated, the final record has to stay within SPF processing limits, and real messages must be tested at the receiving mail server.

Table of Contents

Quick Answer Why Multiple SPF Records Break Email Authentication The migration pattern behind the error How SPF Records Actually Work in DNS Reading qualifiers and mechanisms Detecting Multiple SPF Records Step by Step Step one, query the hostname Step two, inspect delegated senders Step three, check legacy records Step four, count mechanically and confirm remotely Merging Senders into a Single SPF Record Build the policy deliberately Staying Under the 10 DNS Lookup Limit Count the complete evaluation path Validating and Testing the Final Record Use a release checklist Common Mistakes and What to Do Next Frequently Asked Questions Can a domain have multiple SPF records?How can duplicate SPF records be found?Does merging SPF records solve all deliverability problems?What happens when SPF exceeds the DNS lookup limit?Can SPF be split across subdomains?Can AI agents check SPF automatically?

Quick Answer

A domain can't have multiple SPF records for the same hostname. SPF must be published as one DNS TXT record beginning with v=spf1. If a DNS query returns more than one SPF policy for that hostname, receiving systems can return a permanent SPF error instead of evaluating the authorized senders.

The practical fix is:

Find every TXT value beginning with v=spf1.

List every legitimate sender, including mailbox providers, marketing platforms, CRMs, help desks, and transactional services.

Merge those senders into one SPF record.

Remove the duplicate SPF entries.

Count all DNS-triggering mechanisms and nested lookups.

Test SPF, DKIM, DMARC, DNS, blacklist status, and mail infrastructure after publishing.

RFC 7208 defines the one-record rule and limits SPF evaluation to 10 DNS lookups. A merged record can still fail if its includes and other DNS mechanisms make evaluation too complex.

Why Multiple SPF Records Break Email Authentication

A growth team moves from Mailgun to SendGrid during a product launch. The old DNS entry still authorizes Mailgun, while a contractor adds a second TXT record for SendGrid instead of updating the first. Password resets continue leaving the application, but receiving servers now see conflicting SPF policies for the same domain.

SPF requires one policy for a hostname. RFC 7208 specifies that the policy belongs in a single DNS TXT resource record. If a receiver finds multiple SPF records, it cannot select one authorization list reliably. The evaluation can therefore return a permanent error instead of a pass.

The failure is also a migration warning. Duplicate records usually mean several SaaS providers were added over time without a current sender inventory. Consolidating those senders into one production-ready record fixes the syntax, but the audit must also account for SPF's 10 DNS-lookup ceiling. A record with one visible line can still fail if its include mechanisms trigger too many nested DNS queries.

The business impact extends beyond one failed check. If DMARC depends on SPF alignment and SPF produces no usable result, the visible From domain loses one authentication path. Mailbox providers then have fewer positive signals when assessing password resets, invoices, newsletters, and outbound sequences.

The migration pattern behind the error

SaaS sprawl makes the mistake easy. Each provider may supply an SPF value containing an include mechanism, and an administrator can append it without checking the existing zone. Duplicate instructions also appear when separate teams manage the registrar, DNS host, marketing platform, and application infrastructure.

A DNS audit should answer four questions:

Which services send mail? List corporate mail, transactional systems, CRM notifications, support platforms, and campaign tools.

Which services were retired? Remove stale includes left behind after provider migrations.

Which hostname is being checked? SPF applies to the envelope sender domain, which may differ from the visible From domain.

Who owns DNS changes? Clear ownership prevents competing updates from accumulating.

How SPF Records Actually Work in DNS

SPF is published in DNS as a TXT record. At the root of a domain, the record usually begins with v=spf1, followed by mechanisms that describe authorized senders. Receiving servers evaluate those mechanisms from left to right until one matches, then apply its qualifier.

A simple valid example is:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

The IPv4 range authorizes a defined sending network, the include delegates authorization to another domain's SPF policy, and -all applies a hard fail to senders that match nothing earlier.

An invalid duplicate configuration looks like this:

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

v=spf1 include:_spf.mailgun.org -all

Both values may be individually sensible, but publishing them as separate SPF TXT records for the same hostname creates a conflict. The correct approach is to combine the authorized mechanisms into one logical policy.

Reading qualifiers and mechanisms

The qualifier before a mechanism controls the result:

+ pass: The default qualifier, so +include:example.com is equivalent to include:example.com.

- fail: A hard fail, commonly used with -all once the sender inventory is complete.

~ softfail: A weaker result, often used while a policy is still being verified.

? neutral: No authorization opinion, which usually provides little enforcement value.

The ending matters. -all is restrictive, while ~all leaves receiving systems more room to accept or classify unauthorized mail. A trailing +all would authorize every sender and undermine the purpose of SPF.

Some older DNS configurations also contain an obsolete SPF resource record type. Modern SPF uses TXT, so a legacy SPF RRtype can create confusion when an administrator searches for a policy that resolvers and receiving systems don't use. For a plain explanation of the DNS record type involved, see how TXT records work.

Configuration	TXT Record	RFC 7208 Result
Valid single policy	`v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all`	One policy can be evaluated
Invalid duplicate policies	`v=spf1 include:_spf.sendgrid.net -all` and `v=spf1 include:_spf.mailgun.org -all`	Multiple SPF records create a permanent error
No SPF TXT policy	No value beginning with `v=spf1`	SPF has no published policy

Detecting Multiple SPF Records Step by Step

A DNS control panel may show records in a way that hides the conflict. A direct query gives clearer evidence of what the public DNS system returns.

Step one, query the hostname

On Linux or macOS, run:

dig TXT example.com +short

On Windows, run:

nslookup -type=txt example.com

Replace example.com with the actual domain. The output may include TXT values for verification, policies, or other services. Count only the values that begin with v=spf1.

If the result contains two or more SPF values, the domain has the core problem. If it contains none, SPF may be published on a different envelope sender hostname, or the record may not have propagated from the authoritative DNS provider.

Step two, inspect delegated senders

An SPF record can reference other domains through include. Query each suspected include separately:

dig TXT _spf.google.com +short

A missing or malformed include can create a second authentication problem even after duplicate SPF records are removed. The result should show the provider's published policy, which then needs to be included in the lookup count for the parent domain.

Step three, check legacy records

Run:

dig SPF example.com

A result suggests that an obsolete SPF RRtype exists in the zone. It isn't a substitute for a TXT record, so the DNS administrator should document it and remove or replace it according to the organization's change process.

Step four, count mechanically and confirm remotely

A simple count can flag duplicate values:

dig TXT example.com +short | grep -c "v=spf1"

A result greater than 1 requires correction. A remote checker is still useful because local resolver caches, split DNS, and authoritative-server differences can make a workstation view incomplete. A live mailX check can fetch the public record from a remote probe and show the configuration in the same diagnostic context as DKIM, DMARC, blacklist, and infrastructure checks.

Merging Senders into a Single SPF Record

The safest merge starts with an inventory, not with copy and paste. List every service that sends on behalf of the domain, then confirm whether each provider requires an include, a fixed IP range, a subdomain arrangement, or another authentication method.

Suppose the DNS zone contains separate entries for Google Workspace and SendGrid, while the organization also uses Postmark and a corporate mail server. The final record might look like:

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

That is one SPF TXT record containing several authorization mechanisms. The IP mechanism costs no DNS lookup, while each included policy must be evaluated and may introduce nested lookups.

Build the policy deliberately

Use this order as a practical construction pattern:

Direct IP mechanisms first. Add stable ip4 and ip6 ranges when the organization controls them and the provider's ranges are documented.

Host-based mechanisms next. Add a or mx only when the domain's A or MX records represent authorized senders.

Provider includes after that. Add only active services, and inspect each provider's nested policy.

Use one ending qualifier. Place ~all or -all at the end. Anything after all won't be evaluated.

redirect can make sense when one upstream policy should control the entire evaluation and the local domain doesn't need additional mechanisms. include is more appropriate when the local policy must combine several senders. The choice affects maintenance, readability, and lookup consumption.

A DNS TXT record can be displayed as multiple quoted strings because of DNS presentation and length handling, but those strings must form one logical SPF record. They shouldn't become separate values that each begin with v=spf1.

Mechanism	DNS Lookups	When to Use
`ip4` or `ip6`	None	Stable, documented sending ranges
`a`	One per evaluation path	The domain's address records are intentional senders
`mx`	One per evaluation path	Mail exchangers also send outbound mail
`ptr`	One per evaluation path	Rarely justified, because reverse-DNS dependence adds complexity
`include`	One plus nested lookups	A third-party provider publishes authorization
`redirect`	One plus the redirected policy	A single upstream policy should govern evaluation

Teams comparing syntax patterns can use SPF record examples while keeping the provider's official authorization values as the source of truth.

Staying Under the 10 DNS Lookup Limit

A single SPF record can be syntactically correct and still fail in production. RFC 4408 describes the hard processing cap of 10 DNS lookups for DNS-triggering SPF mechanisms. When evaluation exceeds that ceiling, SPF returns PermError.

The count includes include, a, mx, ptr, exists, and redirect. Nested lookups inside an included policy count toward the same total. Direct ip4, ip6, and the all qualifier don't create DNS lookups.

Count the complete evaluation path

Consider a policy containing:

include:_spf.google.com, one direct lookup

include:mail.zendesk.com, one direct lookup

include:sendgrid.net, one direct lookup

include:postmarkapp.com, one direct lookup

mx, one lookup

ptr, one lookup

That visible list already consumes several lookups, before nested records are counted. Each provider may delegate authorization to additional domains, so the final evaluation can exceed the ceiling even though the parent record looks short.

When the count is too high, the repair should preserve legitimate sending while reducing DNS dependency:

Remove retired services. An unused include adds risk without authorizing a needed sender.

Drop ptr in most configurations. It consumes lookup capacity and is rarely necessary for a modern sender inventory.

Use direct ranges carefully. Stable vendor IP ranges can be represented with ip4 or ip6, but they must be maintained when the provider changes infrastructure.

Move distinct sending streams to subdomains. A transactional envelope sender such as em.example.com can have its own SPF policy, provided the sending architecture and DMARC alignment are designed around that hostname.

Review quarterly. Vendor changes, new SaaS tools, and abandoned integrations can alter the lookup path.

Flattening can create headroom, but it trades flexibility for maintenance. A provider that changes its sending ranges can make a manually flattened record stale, so every flattened policy needs ownership and review.

Validating and Testing the Final Record

A DNS editor accepting a TXT value doesn't prove that mail will authenticate. Validation should be a hard gate before the change reaches production because a record can compile cleanly while still authorizing the wrong sender, exceeding the lookup ceiling, or failing alignment with the visible From domain.

Use a release checklist

Parse the policy. Confirm it begins with v=spf1, contains only intended mechanisms, and ends with a deliberate qualifier.

Compare live DNS. Query the published TXT value with dig TXT or nslookup and compare it with the approved change.

Check the complete lookup path. Include nested mechanisms, not just the visible include count.

Publish through the authoritative provider. Confirm that the change was made in the DNS system serving the domain.

Send from every source. Test Google Workspace, the transactional provider, the CRM, and any application server that claims to send for the domain.

Read full headers. Inspect Authentication-Results for the SPF result and the receiving IP that was evaluated.

The useful results aren't limited to pass and fail. temperror points toward a temporary DNS or resolver problem, permerror indicates a persistent policy problem, and neutral means the policy expresses no authorization opinion. A softfail is also not the same as a pass. If the final policy uses -all, an unauthorized sender is expected to produce a fail result.

DNS caching can make a correct change appear inconsistent while different resolvers refresh. Teams should understand DNS propagation behavior, then verify the authoritative result and the recipient-side headers rather than assuming that a successful dashboard save means the entire mail system has updated.

Common Mistakes and What to Do Next

SPF is only one part of the authentication chain. SPF authorizes the sending path, DKIM signs the message, and DMARC evaluates alignment and policy. A clean SPF record can improve the authentication foundation, but it can't compensate for a broken DKIM selector, an unaligned envelope sender, poor sender reputation, blacklist problems, or SMTP and IMAP failures.

The recurring audit mistakes are operational:

Old provider left behind: Remove the retired ESP authorization after confirming no workflow still uses it.

Nested includes ignored: Trace every include and count its downstream DNS activity.

IP ranges hardcoded without ownership: Use direct ranges only when someone will monitor provider changes.

IPv6 overlooked: Add ip6 authorization when a legitimate sender delivers over IPv6.

TTL assumptions differ: Record the actual DNS provider, TTL, and authoritative result during a change.

SPF published on the wrong hostname: Check the envelope sender and DMARC alignment instead of assuming the apex domain is always queried.

DMARC policy choices also need a controlled rollout. p=none supports monitoring, p=quarantine asks receivers to treat failures suspiciously, and p=reject requests rejection of failing messages. The right progression depends on whether every legitimate sender has been identified and whether DKIM and SPF alignment have been tested.

SPF Mistake	Correct Fix
Two TXT values begin with `v=spf1`	Merge authorized mechanisms into one policy
The record exceeds the lookup ceiling	Remove unused paths, reduce nested dependencies, or restructure senders
A retired ESP remains authorized	Confirm retirement, then remove its mechanism
A provider's IP ranges are copied without review	Assign ownership and revisit ranges when infrastructure changes
SPF passes but DMARC fails	Check envelope sender alignment, visible From domain, and DKIM alignment
A policy is published on the wrong hostname	Query the actual envelope sender domain used by the application

A practical final checklist is short: confirm one SPF TXT record, count the full evaluation path, validate syntax, send a probe from each source, inspect Authentication-Results, review DKIM and DMARC, and check blacklist and mail-server health. For a live audit, mailX checks SPF, DKIM, DMARC, DNS, blacklist status, SMTP and IMAP connectivity, and related infrastructure signals, then presents remediation steps instead of raw DNS output.

Frequently Asked Questions

Can a domain have multiple SPF records?

No. The same hostname should publish one SPF policy in one DNS TXT record. Multiple values beginning with v=spf1 create an invalid configuration for SPF evaluation.

How can duplicate SPF records be found?

Query the domain with dig TXT on Linux or macOS, or nslookup -type=txt on Windows. Count the returned values beginning with v=spf1, then confirm the public result with a remote DNS or deliverability check.

Does merging SPF records solve all deliverability problems?

No. Merging removes one authentication risk, but inbox placement also depends on DKIM, DMARC alignment, sender reputation, blacklist status, message behavior, and mail infrastructure.

What happens when SPF exceeds the DNS lookup limit?

SPF returns PermError when evaluation requires more than the permitted lookup count. The final policy must be simplified by removing unused mechanisms, reducing nested dependencies, or restructuring sending across appropriate subdomains.

Can SPF be split across subdomains?

Yes, separate hostnames can have separate SPF policies. Each hostname still needs only one SPF record, and the sending architecture must preserve the intended SPF and DMARC alignment.

Can AI agents check SPF automatically?

Yes, an agent can query DNS and evaluate configuration when it has access to live deliverability tools. It shouldn't send campaigns blindly. Authentication, blacklist status, domain health, and infrastructure checks belong inside the sending workflow.

Use mailX to run a live deliverability audit, inspect duplicate SPF records and lookup risks, and get plain-English remediation steps across SPF, DKIM, DMARC, DNS, blacklist status, SMTP, and IMAP. The free check requires no signup and gives the team a practical next step before another migration or campaign harms inbox placement.