Why two SPF records are worse than none

dig +short TXT example.com

"google-site-verification=abc123..."
"v=spf1 include:_spf.workspace.example ~all"
"v=spf1 include:spf.sender.example ~all"

Merging records correctly#

The fix is a single record that contains every mechanism from both, with one all at the end.

Two broken records:

v=spf1 include:_spf.workspace.example ip4:192.0.2.10 ~all
v=spf1 include:spf.sender.example -all

One merged record:

v=spf1 include:_spf.workspace.example include:spf.sender.example ip4:192.0.2.10 ~all

Work through these steps when merging:

1. Collect every mechanism from each record, removing exact duplicates.
2. Pick one all qualifier. If the two records disagree (~all versus -all), choose deliberately. While you are unsure that every sender is listed, ~all is the safer choice.
3. Put all last. Anything after it is ignored.
4. Recount lookups. Merging two records that were each within limits can push the combined record over ten DNS-querying terms. Count includes recursively before publishing.
5. Check for redirect=. A record with redirect= hands evaluation to another domain when nothing matches. It cannot meaningfully coexist with an all mechanism, since all always matches first. If one of the records used redirect=, decide which model you want.
6. Delete the old records in the same change window you publish the new one.

Publishing the change safely#

The order of operations matters a little, because resolvers cache records for the TTL.

• If possible, lower the TTL on the existing records first and wait for the old TTL to expire.
• Publish the merged record and delete the duplicates in one edit, if your DNS provider supports atomic changes.
• If it does not, delete one duplicate first. A brief window with one incomplete record is better than any window with two.
• Verify from an outside resolver, not just your provider's dashboard:

dig +short TXT example.com @1.1.1.1
dig +short TXT example.com @8.8.8.8

Then send a test message to a mailbox you control at a major provider and read the Authentication-Results header to confirm spf=pass.

Preventing it from happening again#

The root cause is almost always process, not knowledge. A few habits help:

• Keep DNS in version control. Whether you use infrastructure-as-code or simply a reviewed zone file, a pull request makes a second v=spf1 line visible to a reviewer.
• Add a CI check. A tiny script that fails if any name has more than one TXT value starting with v=spf1 catches the mistake before it ships.
• Name an owner for email DNS. One person or team approves changes to SPF, DKIM and DMARC records.
• Rewrite vendor instructions. When a vendor says "add this TXT record," translate that internally to "add this include to our existing SPF record."
• Watch DMARC reports. A sudden jump in SPF permerrors across all sources is the signature of a duplicate record.

Here is a minimal check you can run in CI or a cron job:

for name in example.com bounce.example.com news.example.com; do
  n=$(dig +short TXT "$name" | grep -ci '"v=spf1')
  if [ "$n" -gt 1 ]; then
    echo "ERROR: $name has $n SPF records"; exit 1
  fi
done

Key takeaways#

• More than one v=spf1 TXT record on the same name is a permerror for every message, worse than having no record.
• It usually comes from vendor instructions taken literally, DNS migrations or uncoordinated teams.
• Merge into one record with every mechanism and a single all at the end, then recount DNS lookups.
• Verify from public resolvers and a real test message.
• Version control and a simple automated check stop it from recurring.