Multiple SPF records

The specification requires a receiver finding more than one record to return a permanent error rather than choosing or merging.

That is deliberate: merging would require guessing the author's intent, and choosing would make the outcome depend on DNS answer ordering.

A permanent error is treated as no policy, so the domain authenticates nothing and refuses nothing.

Which means the effect is identical to deleting both records, and it is reached by adding one.

The same rule applies to DMARC, and for the same reason.

A platform's setup guide says to add a TXT record, and the person following it adds one rather than editing the existing record.

A migration where the new mail platform's record is added before the old one is removed, and the removal never happens.

Two teams configuring two different sending tools, neither aware the other touched DNS.

A DNS provider interface that presents TXT records as a list and makes adding easier than editing.

None of these produces an error message, because both records are individually well-formed.

Take the include and address mechanisms from both records and put them in one, preserving order where a provider's documentation specifies it.

Keep exactly one version tag, at the start, and exactly one ending qualifier, at the end.

Choose the more restrictive of the two endings only after confirming the merged record covers every sender from both.

Re-count the lookups after merging: combining two records frequently pushes the expansion over the ten-lookup limit, which is the same total failure by another route.

Delete the second record only after the merged one is published and verified, so there is no window with no policy at all.

Mail continues to be delivered, because most receivers do not reject on a missing SPF alone.

More of it lands in spam folders, gradually, without a change anyone can point at.

DMARC enforcement stops working through the SPF path, so a domain with a strict DMARC policy can start rejecting its own legitimate mail if DKIM is not also passing.

That last case is the one that becomes urgent quickly, and it is frequently diagnosed as a DMARC problem when the cause is a duplicated SPF record.

`dig +short TXT example.com` lists every TXT record at the apex.

Count the ones beginning with the SPF version tag. More than one is the defect, regardless of what each contains.

Check subdomains that send mail separately, since each name has its own record set and the rule applies per name.

Read the authentication results in the raw headers of a message you sent: a permanent error is reported explicitly rather than as a failure.

After merging, query again from a resolver that was not cached, or wait out the previous record's lifetime before concluding.

`email.spf.single` reports whether exactly one record is published, which is the check this problem corresponds to directly.

`email.spf.present` and `email.spf.syntax` report existence and parseability, so a duplicate is distinguished from an absent or malformed record.

`email.spf.lookups` is reported alongside because merging two records is the change most likely to exceed the limit.

`email.spoofing_exposure` reflects the combined outcome, which for a duplicated record is the same as for no record.

SPF is evaluated per name, so a subdomain that sends mail needs its own record — it does not inherit the apex record.

Which means a domain with one apex record and no subdomain record has no SPF for mail sent from that subdomain, and that is not a duplicate problem but a missing one.

Conversely a subdomain with two records has the same permanent error as an apex with two.

A wildcard record covering subdomains exists and is rarely a good idea, because it authorises the same senders for names nobody has created yet.

The practical approach is an explicit record on the apex and on each subdomain that really sends, and nothing on the ones that do not.