How to fix multiple SPF records without breaking email

Can you have multiple SPF records?

No: multiple SPF policies at the same DNS name produce an SPF permerror. Other TXT records, such as domain verification tokens, can coexist with SPF. One TXT record can also contain multiple quoted character strings that DNS joins together; that is different from publishing two SPF policies. Inspect the returned records rather than counting rows in a hosting dashboard.

Check the domain used by the sender

Start with the domain in the message envelope sender, also called MAIL FROM or Return-Path. It may differ from the address people see in the From field. Query that exact name. An SPF record on a bounce subdomain and another on the main domain are not automatically duplicates. For a support handover, save the query output, the affected sender and the time of the check.

nslookup -type=TXT example.com
# Look for separate TXT records beginning with v=spf1.

Inventory every legitimate sending service

Before changing DNS, list the systems that send mail: staff mailboxes, website forms, invoices, newsletters and support software. Ask each service owner for its current SPF instructions. Keep the existing DNS values and a rollback copy. A record that looks redundant may authorise an infrequently used service, so a quiet inbox is not evidence that it can be removed.

1. Record each sender, its owner and the domain it uses for the envelope sender.
2. Obtain the provider-required mechanisms rather than guessing from the visible From address.
3. Identify stale services with their owners before removing their authorisation.

Publish one policy, not two concatenated policies

Combine the required mechanisms under one v=spf1 prefix and one ending policy. Do not paste a second complete record after the first: an all mechanism ends evaluation. The example below is an illustration using placeholder providers, not a record to deploy. Preserve the approved ending policy while resolving duplicates; changing softfail to fail is a separate decision. SPF also limits DNS-querying terms to ten during evaluation, including nested includes, so validate the resulting policy.

# Before: two separate TXT records at the same name
v=spf1 include:sender-a.example ~all
v=spf1 include:sender-b.example ~all

# Illustrative structure after combining approved senders
v=spf1 include:sender-a.example include:sender-b.example ~all

Verify DNS and send real test messages

Retrieve the authoritative DNS response after the edit and compare it with the intended single policy. Allow cached answers to expire according to the relevant TTL; avoid promising a fixed propagation time. Then send a representative message through each inventoried service and examine its Authentication-Results header. A successful test from the staff mailbox does not test a separate newsletter or invoicing platform.

1. Check that exactly one SPF policy remains at the affected name.
2. Validate the mechanisms, syntax and DNS lookup budget.
3. Test every retained sender and record its authentication result.
4. Investigate any failure using the actual sending IP and envelope domain.

Separate SPF repair from DMARC alignment

SPF authenticates the envelope domain; DMARC also considers alignment with the visible From domain and can pass through aligned DKIM. A duplicate-record repair is therefore not proof that every message passes DMARC or reaches the inbox. Keep the DNS evidence and message headers together so the next investigation starts with what was actually observed.

Frequently asked questions

See where your website stands

Start with a public-signal screening report in about 60 seconds. No signup or card. Quick Scan samples the website; it does not test every topic in this guide.