More than one SPF record breaks SPF

SPF is supposed to tell receiving mail systems which servers may send on behalf of your domain. But publishing more than one SPF record does not create a stronger or broader policy. It creates an SPF permanent error, commonly shown as permerror, because receivers cannot determine which record to evaluate.

In OrangeStealth’s monthly refresh generated on 2026-10-01, multiple SPF records appeared in 1.5% of the US B2B SaaS 5-50 population, with N = 1098 and n=17. That is a small share, but the affected domains have a configuration that can prevent SPF from producing the intended authentication result.

Why two SPF records do not combine

An SPF policy is published in DNS as a TXT record beginning with v=spf1. A domain may need to authorize several legitimate senders, such as its primary mail provider, support platform, billing system, or marketing service. Those authorizations belong in one valid SPF record.

If a receiver finds multiple records that claim to be the domain’s SPF policy, it must return a permanent error instead of merging them or choosing one. The receiver then applies its own local handling rules. Some systems may treat the error as suspicious, some may rely more heavily on DKIM and DMARC, and others may still accept the message under separate filtering policies.

This is why calling the condition “fail open” needs care. The SPF control fails to deliver a usable pass or fail result, but that does not guarantee delivery. It also does not guarantee rejection. The practical problem is uncertainty: a domain owner has published an authentication control that receivers cannot evaluate as intended.

A common hypothetical mistake

Imagine a domain already has an SPF record for its main mail provider. Later, someone adds a new TXT record for a customer communications platform:

v=spf1 include:mail-provider.example -all
v=spf1 include:customer-platform.example -all

Both senders may be legitimate, but the records conflict at the policy level. The correct structure is generally one SPF record containing the required authorization mechanisms:

v=spf1 include:mail-provider.example include:customer-platform.example -all

This example is hypothetical. The exact repair depends on the domain’s real sending services, DNS provider, lookup behavior, and desired policy. Public DNS observations can identify the conflicting records, but they are not proof that anyone abused the domain or that messages were compromised.

How this affects DMARC

DMARC can pass when either SPF passes with alignment or DKIM passes with alignment. It does not require both mechanisms to pass. A multiple-record SPF error may therefore be partly masked when aligned DKIM continues to work, but that does not make the SPF configuration healthy.

A DMARC policy of p=none requests no DMARC-based enforcement. Receivers may still block messages under their own spam, reputation, or security policies. DMARC reports also require a configured reporting destination; publishing p=none by itself does not request reports. Before changing to a quarantine or reject policy, confirm every legitimate sender and verify alignment. Quarantine and reject express the domain owner’s requested policy, not a guarantee of what every receiver will do.

What to actually do about it

• Inspect the domain’s TXT records. Look for every record beginning with v=spf1. The free public checker at https://orangestealth.com/check can provide an initial external view.
• Inventory legitimate sending services. Include ordinary mail, billing notices, support tools, marketing platforms, and any vendor authorized to send using the domain.
• Consolidate the policy carefully. Build one SPF record that covers confirmed senders, while checking syntax and DNS lookup behavior. Do not simply delete a record because it looks unfamiliar.
• Verify SPF, DKIM, and DMARC alignment. Test representative messages from each legitimate sender before considering any DMARC enforcement-policy change.
• Keep ownership clear. Record who may change DNS and how new mail vendors are added. An External Security Posture Assessment can help identify this and other externally visible configuration gaps, while remaining passive and external-only.

Methodology: OrangeStealth used passive, public-data-only observations from the 2026-10-01 monthly refresh of the US B2B SaaS 5-50 population, with N = 1098. Results are reported only in k-anonymised aggregate form, and no company is named. These observations describe public configuration, not backend conditions, compromise, or abuse.

If your domain exposes multiple SPF records, start by confirming every real sender and consolidating the records into one tested policy.