Why two SPF TXT records break mail after an email provider migration

The migration mistake is easy to make

Provider onboarding screens usually show the SPF value that would be correct for a domain with no existing sender. They cannot know which other systems your business already authorizes. During migration, an operator may therefore add the new provider’s suggested TXT record beside the old v=spf1 record. DNS happily stores both. SPF does not treat them as additive policies. RFC 7208 describes selection of the SPF record and treats multiple applicable SPF records at one name as a permanent error. This is why a migration can look successful in the provider dashboard while recipient-side authentication is broken.

Query the exact hostname before merging anything

Do not assume the problem lives at the root domain. Find the envelope identity from a real message and query that hostname for TXT records. If two separate answers begin with v=spf1, capture both before editing. Other TXT values such as site-verification tokens are unrelated and can remain. The goal is not to reduce the domain to one TXT record; it is to reduce each SPF-evaluated hostname to one SPF policy. This distinction prevents accidental deletion of unrelated DNS data during a hurried migration.

dig TXT example.com +short

Build an inventory of active senders

Before merging the strings, identify which services still send. A migration often leaves temporary overlap: old provider for a few shared mailboxes, new provider for most users, a form service, and perhaps an outbound platform. Mark each source as active, retiring, or unknown. Only active senders should survive into the final policy. If you simply concatenate every historical include, you may fix the multiple-record error but create a lookup-limit problem. Authentication repair is a good moment to remove infrastructure that no longer belongs in the mail path.

Merge mechanisms, not entire SPF records

A valid merge keeps one version marker and one terminal all mechanism. For example, two policies that separately authorize Provider A and Provider B should become one v=spf1 policy containing the necessary mechanisms for both, followed by the chosen all qualifier. Do not paste one complete v=spf1 string inside another. After merging, count nested DNS lookups because a syntactically valid combined policy can still exceed SPF processing limits. The final record should be something another operator can read and map back to real systems.

v=spf1 include:_spf.provider-a.example include:_spf.provider-b.example -all

Do not remove the old provider until traffic is actually gone

A clean DNS design is not the same as a rushed cutover. If some users, aliases, automated forms, or queued messages still leave through the old provider, removing its authorization too early can turn a configuration cleanup into delivery failures. Use message headers and provider logs to prove which paths still send. Once the old path has been quiet for the agreed window, remove its mechanism from the single SPF record and retest. The safe sequence is one valid policy throughout the transition, not a period with two policies followed by a sudden deletion.

Check DKIM and DMARC at the same time

SPF is only one part of migration. The visible From domain may continue to pass DMARC through DKIM even while SPF is broken, which can hide the issue until a message is unsigned or routed differently. Conversely, a perfect SPF merge can still leave DMARC failing if the new provider uses an unaligned Return-Path and DKIM has not been enabled. Send a controlled test through every remaining route and inspect SPF result, DKIM result, and the domains that authenticated. Migration QA should prove the complete identity chain, not merely that the new provider’s dashboard displays a green check.

Use DNS change logs as part of deliverability operations

Record the old values, the new value, TTL, change time, and the sending systems each mechanism represents. If deliverability drops later, this log lets you correlate authentication changes with recipient responses. It also reduces the chance that a future contractor or setup wizard reintroduces a second SPF record because nobody knows why the current line contains multiple providers. For small teams, simple documentation is a reliability control: a one-page DNS inventory often prevents more incidents than another monitoring dashboard.

Verify after caches have had time to converge

Different resolvers may hold the previous answer until TTL expiry, so test from multiple networks or public resolvers after the change. Then send new mail rather than re-reading an old header. If one recipient still reports PermError while others pass, compare DNS answers and timestamps before editing again. Repeated DNS changes during propagation create more uncertainty. The desired end state is stable: one SPF record at the evaluated hostname, active senders authorized, lookup budget within limits, and at least one aligned SPF or DKIM path satisfying DMARC.

Use a migration window that preserves one policy at every step

A safer migration can be expressed as a sequence of DNS states. State one is the existing single SPF policy. State two is still one policy, but it temporarily authorizes both old and new sending systems while test traffic is moved. State three removes the old mechanism only after logs show the old path is quiet. At no point should the same hostname publish two independent v=spf1 records. This sequence matters because DNS propagation and provider cutovers happen on different clocks: the new record may be visible to one receiver while a queued message still leaves through the previous provider. Keeping one combined policy through the overlap prevents the migration itself from creating an SPF permanent error.

Before the final cleanup, sample messages from every class of sender rather than only a user mailbox. Contact forms, password-reset mail, invoices, calendar systems, and outbound campaigns may use different Return-Path domains even when the visible From address looks identical. Record the authentication result and envelope domain for each class. If an unexpected path remains on the old provider, decide whether it should migrate or stay authorized; do not silently keep a stale include forever. The completion criterion is therefore stronger than “the new provider says SPF is set”: one SPF record remains at each evaluated name, every active route is accounted for, and each route produces the expected receiver-side result.

Field checklist

• Query the exact envelope-domain hostname for all TXT answers.
• Keep only one v=spf1 policy per hostname.
• Inventory active and retiring senders before merging mechanisms.
• Count lookup-expanding mechanisms after the merge.
• Test SPF, DKIM and DMARC through every remaining provider.
• Save a DNS change log so the duplicate record is not reintroduced later.