Two SPF policies at the same DNS name do not combine into a larger authorised sender list. When SPF record selection returns more than one applicable record, evaluation ends with permerror under RFC 7208 §4.5. The repair is one coherent policy, not a third TXT entry.
The difficult part is deciding which permissions still belong. Copying every mechanism into a single line may remove the syntax failure while preserving obsolete vendors, excessive networks and a lookup-limit problem.
Confirm what is actually duplicated
Query TXT records at the exact domain used for the SPF check. Other TXT records, such as domain-verification tokens, are not automatically SPF records and should not be deleted as part of this repair. Distinguish multiple resource records from multiple quoted character-strings within one TXT record. Under RFC 7208 §3.3, strings inside one record are concatenated; separate SPF records are not.
Save the full DNS answer, TTL and authoritative server information. Confirm the relevant zone and owner name before changing anything. A provider may automatically append the zone name to a host field, making an apparently correct editor entry land at the wrong name.
Reconstruct the intended sender set
Create one row per mechanism with four fields: the business service, accountable owner, supporting provider configuration, and evidence of current sending. For explicit IP ranges, identify who operates the addresses and why that range is needed. For includes, inspect the vendor's current instructions and recursive policy dependencies. Treat an unknown mechanism as a question to resolve, not a permission to retain forever.
Separate senders using this envelope domain from services using their own envelope domain. A vendor's visible From address is not enough to prove that its traffic needs an SPF include here. Likewise, absence from a short observation period does not establish retirement: invoices or seasonal campaigns may run infrequently.
Build one ordered policy
Preserve the chosen authorisations and one intentional final policy. Do not concatenate entire records, leaving a second v=spf1 token or an all mechanism in the middle. Under RFC 7208 §5.1, an early all matches every remaining source, so later mechanisms are unreachable.
Illustrative starting state: one record is v=spf1 ip4:192.0.2.10 -all; another is v=spf1 ip4:198.51.100.20 ~all. If both documentation-only addresses represent confirmed, current senders, a possible merged policy is v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 ~all. Choosing the final qualifier requires its own routing review. If the second sender was retired, merging it would preserve unnecessary authority.
Evaluate the full policy, including nested includes and redirects. Under RFC 7208 §4.6.4, RFC 7208 imposes a limit of ten lookup-causing terms during evaluation; counting only visible include statements is insufficient. Explicit ip4 and ip6 mechanisms do not themselves consume that term budget, but replacing managed includes with copied IP lists creates a maintenance obligation.
Deploy without a prolonged ambiguous state
Prefer an atomic DNS record-set update when the provider supports it: replace the competing policies with the approved single record in one change. If the interface requires separate edits, plan the sequence and acknowledge the transient risk of missing or duplicate policy. Do not create a “temporary” extra SPF record and leave it for propagation.
Verify authoritative answers, then relevant recursive responses. Cached old answers retain their prior freshness intervals; RFC 8767 §4 also permits qualifying stale-answer use after expiration. TTL is not a guaranteed global revocation deadline. Send representative messages from every retained service and confirm the evaluated identity and result at a trusted receiver. Test an unmatched source under your control as well, so an accidental universal pass is not mistaken for success.
Keep the cleanup evidence
The change record should explain each retained and removed mechanism, the lookup evaluation, the before-and-after DNS state and the test results. A duplicate-record alert is closed only when there is one selected SPF record and the policy expresses the reviewed sender set. This turns a one-off DNS repair into a maintainable authorisation inventory.
Record the decision and its limits
For the two-address example, a permission worksheet should retain each owner decision and expected match separately from the final qualifier. The merged ~all example still returns softfail for an unmatched address; it is not a recommendation to weaken a previous -all policy. Changing that qualifier needs an explicit decision. No DNS update or delivery test has been performed for this illustration.