Multiple SPF records? Fix the policy safely.

An SPF policy is a DNS TXT record that begins with v=spf1. For a particular queried domain name, SPF expects one selected policy. If two separate TXT records at that name both begin with v=spf1, a receiver does not merge their sender lists; the SPF check returns a permanent error. That can make SPF fail to provide a useful authorization result for messages using that identity.

First confirm the warning is about separate DNS records at the same exact name. A root domain and a subdomain are different names and can each have their own SPF policy. Also distinguish SPF from other TXT records: verification tokens, DKIM keys, and DMARC policy are different data and should not be deleted just because they are TXT records.

• Query the exact envelope/MAIL FROM domain used by the sending service.
• Count separate TXT answers that begin with v=spf1 at that name.
• Keep unrelated verification, DKIM, and DMARC TXT records intact.

DNS permits one TXT record to contain multiple quoted character-strings. Resolvers concatenate the strings in that same record exactly, without inserting a space. This can help a DNS interface represent a long value, but it does not create extra room for an additional SPF policy. By contrast, two separate TXT records at the same name remain two records even if the control panel displays them together.

The two chunks below form one syntactically complete example policy. The space at the end of the first string matters. The address is reserved for documentation; this example is not a policy to publish on your domain:

example.test. TXT "v=spf1 ip4:192.0.2.10 " "-all"

Concatenated: v=spf1 ip4:192.0.2.10 -all

Do not blindly copy each visible SPF value into a longer policy. Make a list of systems authorized to send for the relevant domain: employee mail, newsletters, billing notifications, support platforms, website forms, and any gateways or on-premises servers. Ask the person responsible for each service for its current SPF instructions and confirm which domain appears in its SMTP MAIL FROM identity. SPF does not directly authorize the human-readable From header.

A policy evaluates terms in order and stops when a mechanism matches; an all term is terminal. If you put a broad all before later mechanisms, those later terms are never reached. Keep only senders that are still approved, preserve provider-required include or address mechanisms, and coordinate removals with the system owner. A sample policy is not a safe recipe for a different domain.

example.test TXT "v=spf1 include:spf.sender.example ip4:192.0.2.10 ~all"

The example domain and documentation address are not a live configuration.

SPF allows at most ten DNS-querying terms during one evaluation. Count terms reached inside nested include policies as well as those in the visible record. include, a, mx, ptr, and exists mechanisms and the redirect modifier can cause lookups; mechanisms such as ip4, ip6, and all do not count toward this limit. Exceeding the limit can produce permerror. Provider policies can change, so a previously acceptable include tree may need review later.

Bare.io’s standalone SPF syntax check reviews the text you enter; it does not fully recurse through provider includes or calculate the complete nested lookup budget. A result there is not proof that a real message passes SPF. Avoid flattening includes into copied IP addresses or changing ~all to -all as a blanket fix: doing so can leave out legitimate senders or reject their mail. Ask providers and administrators to confirm the policy, then test real messages and inspect receiver-added authentication results.

• After editing, query DNS and confirm exactly one SPF record at the intended name.
• Review nested lookup terms with each sending provider; do not rely only on a visible-term count.
• Test messages from every authorized system and check SPF results on received headers.
• Assess DKIM and DMARC separately; a valid SPF declaration alone does not prove delivery or alignment.