# How many SPF records per domain?

> A domain or subdomain can have one SPF policy. Multiple v=spf1 records cause PermError, so merge authorized senders into one record.

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.

## Quick takeaways

- Use one `v=spf1` policy for each exact domain or subdomain that SPF evaluates.
- Two selected SPF policies at one name cause `permerror`.
- Other TXT records, such as verification tokens, can coexist with the SPF policy.
- A subdomain is a separate name and can publish its own one-record SPF policy.
- Consolidating policies can still create a lookup-limit problem, so test the final value.

## Why one SPF policy is allowed at one name

[RFC 7208 section 4.5](https://www.rfc-editor.org/rfc/rfc7208.html#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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) 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?](/learning/spf-record-for-subdomains).

## 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](https://www.rfc-editor.org/rfc/rfc7208.html#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](/learning/spf-record-syntax-explained-mechanisms-qualifiers) 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:

```text
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:

```text
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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) 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](/learning/what-is-spf).

### 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](https://www.rfc-editor.org/rfc/rfc7208.html#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](/learning/spf-checking-tool) or the [SPF record checker](/tools/spf) 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) that duplicate policies return `permerror` and that nested `include:` values can push a record over the lookup limit.

## Sources and further reading

- [RFC 7208, Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 7208 section 4.5, SPF record selection](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5)
- [RFC 7208 section 4.6.4, DNS lookup limits](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4)
- [Microsoft guidance for SPF TXT records](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)

## Frequently asked questions

### Can a domain have several TXT records?

Yes. A DNS name can have several TXT values. The SPF restriction applies only to selected records that begin with `v=spf1`, so a verification token is not an extra SPF policy.

### Can a subdomain have its own SPF record?

Yes. A subdomain is a separate DNS owner name and can publish one SPF policy for its own envelope or HELO identity. It does not inherit the parent domain's SPF policy automatically.

### Will receivers merge two SPF records?

No. RFC 7208 says that two or more selected SPF records produce `permerror`. Consolidate the legitimate mechanisms into one policy instead of relying on a receiver to choose.

### Should I wait before removing the duplicate SPF record?

Only long enough to prepare and review the single replacement policy. Do not deliberately leave two `v=spf1` policies in DNS as a staged deployment, because duplicate selection itself produces `permerror`.

### Does one valid SPF record guarantee an SPF pass?

No. The connecting sender must still match an authorized mechanism, and evaluation must complete without errors such as exceeding the DNS-querying-term limit.