How many SPF records per domain?

One exact domain or subdomain can have one SPF policy record. When an SPF lookup finds two or more v=spf1 records for the same DNS name, it returns permerror; receivers do not merge them or choose one. Put every legitimate sender in one SPF policy at that name, remove duplicate SPF values, and then check that the combined policy stays within SPF processing limits. Other non-SPF TXT records can remain.

Why one SPF policy is allowed at one name

RFC 7208 section 4.5 defines SPF record selection for the exact name being checked. One matching SPF record is evaluated. Two or more matching records return permerror, so a receiver has no standards-based basis to combine separate policies or pick the newest-looking one.

The count applies to an exact DNS owner name, not to an entire company namespace. A policy for example.com and one for mail.example.com are different records at different names. Microsoft's current SPF guidance makes the same operational distinction: each defined domain or subdomain that sends mail needs its own SPF record, with only one SPF record at each name. For the decision about whether a subdomain needs a policy at all, see does a subdomain need its own SPF record?.

What can coexist with an SPF record

The rule is not "one TXT record only." SPF selection looks for a record whose version begins with v=spf1, as RFC 7208 section 4.5 describes. A domain can also publish TXT values for domain ownership checks, service verification, or other purposes. Those values are not a second SPF policy if they do not begin with v=spf1.

This is the distinction to make before changing DNS: two unrelated TXT values are normal, but two values that each declare an SPF policy are a configuration error. The SPF syntax guide explains the mechanisms you may need when combining legitimate sources.

How to merge duplicate SPF policies safely

Start with the public TXT answers at the affected exact name. Inventory every v=spf1 value and map each mechanism or include: to a service that still sends mail for that envelope domain. Do not concatenate policies automatically. Remove authorization for retired services rather than carrying it into the replacement record.

For example, these two SPF policy records at example.com are invalid together:

v=spf1 include:mail.example.net -all
v=spf1 ip4:192.0.2.44 -all

If both sources are legitimate, publish one reviewed policy instead:

v=spf1 include:mail.example.net ip4:192.0.2.44 -all

The IP address and service name above are illustrative only. Do not copy them into production. Use the sender's current documentation and your own authorization inventory. Microsoft's SPF configuration guidance shows the same pattern: put the authorized include: values and IP mechanisms into one record, then use one terminal all mechanism.

1. Identify the exact owner name

Use the envelope domain or HELO name that SPF evaluates. A visible From address can differ from that identity, as explained in what SPF checks.

2. List active senders before editing DNS

Match each existing mechanism to a current sender. Keep only sources that are intentionally authorized for that exact owner name.

3. Build one candidate record

Combine valid mechanisms into one v=spf1 policy. Keep a single terminal all mechanism and retain unrelated TXT records.

4. Count the resulting DNS-querying terms

RFC 7208 section 4.6.4 requires SPF implementations to limit DNS-querying terms to 10 and return permerror when the limit is exceeded. A policy with only a few visible include: mechanisms can still exceed the limit through nested records.

5. Replace duplicate policies in one DNS change

Publish the reviewed single SPF value and remove the other v=spf1 values at that exact name. Do not delete unrelated TXT records. DNS caching can briefly show older answers, but leaving duplicate SPF policies as a transition state is not a safe consolidation method.

Check the published result before changing mail flow

After DNS has updated, use the SPF checking tool or the SPF record checker to confirm that public DNS returns one policy and to inspect its lookup path. That check is useful evidence of the published configuration, not proof that each sender is using the expected envelope domain.

Send a test message through every active platform. Confirm the SPF result for the expected envelope identity in receiver-added authentication results, then review DMARC aggregate reports where available for missed or newly failing sources. Microsoft also notes in its SPF troubleshooting guidance that duplicate policies return permerror and that nested include: values can push a record over the lookup limit.