emailmetry
All guides

Multiple SPF records: how to combine them safely

By EmailmetryReviewed 5 min read

A new email service asks you to add an SPF record, but your domain already has one. Publishing both does not combine their permissions. You need one policy that deliberately covers the services using that sending domain.

SummaryMerge the required sending rules into one SPF policy at the correct DNS name. Preserve other TXT records, review the final all rule, and validate both DNS and real messages.

In this guide

What counts as multiple SPF records?

The problem is two or more SPF TXT records at the same DNS name. Other TXT records, such as domain-verification tokens, can coexist with SPF. An SPF record at studio.example and another at bounce.studio.example are separate policies for separate names.

A TXT record can also contain several quoted text strings that DNS software joins into one value. That is not the same as publishing two separate SPF records. The distinction is defined in RFC 7208, multiple strings in a single record. Inspect the DNS record entries rather than counting lines in a screenshot.

When SPF selects more than one policy at the same name, it returns permerror. Receivers do not pick the newest record or automatically merge the permissions. Your goal is one intentional policy, with all required sending rules understood.

Collect the information before merging

Export the original records, their DNS names and TTLs. Identify the owner of each service and confirm that it still sends email. Keep non-SPF TXT records out of the edit.

Check the service’s actual envelope-sender domain. A billing platform using bounce.studio.example may require changes there, while a mailbox uses studio.example. Rules intended for different identities should not be combined simply because both emails display the same From address.

For each candidate rule, record the provider’s current instructions and whether it still belongs in the policy. Our sender-inventory template has space for the visible From, envelope sender and DKIM domain.

A simple before-and-after example

Suppose a fictional studio has two TXT records at studio.example. One authorises its mailbox and the other authorises its newsletter service:

v=spf1 include:mail.example -all
v=spf1 include:news.example -all
Incorrect: two separate SPF policies at the same DNS name. These placeholder domains must not be copied into production.

If both services require authorisation at that name, both remain active, and their referenced policies are valid, the intended combined policy could be:

v=spf1 include:mail.example include:news.example -all
One version marker, the two required positive includes, and one final rule.

This constructed example uses uncomplicated positive includes with the same final policy. It illustrates the shape of a merge. It does not prove that any two real records can be concatenated safely or that the resulting lookup count is acceptable.

Do not merge complex policies by string concatenation

If you paste the original strings together, the first all mechanism matches before the later service can be reached. The second version marker is also not a new start inside a policy. Write and review the final policy as a whole.

Watch for these cases:

  • Different final qualifiers. Choosing between -all and ~all is a policy decision about unlisted senders. Preserve the intended result and account for all legitimate routes before tightening it.
  • Negative or neutral mechanisms. A rule such as -ip4: or ?include: has different behaviour from a positive authorisation. Moving it can change which result wins.
  • A redirect modifier. It delegates evaluation when no mechanism matches. Adding an all mechanism prevents that fallback from being used; a redirect is not just another positive include.
  • Macros or dynamic mechanisms. Rules that depend on information from a particular message need evaluation in context. Ask the policy owner to review their meaning.

Google’s SPF record reference is useful when reading mechanisms and qualifiers. For an unfamiliar policy, understanding what it authorises matters more than making the string shorter.

Check the combined lookup count

Fixing the duplicate-record error can reveal a lookup-limit error in the merged policy. Follow nested includes as well as the ones visible at the top level. Our lookup-limit walkthrough shows why three visible includes can require more than ten evaluated terms.

Use the SPF checker for an initial record inspection. Review any uncertainty it reports; a potential count is not the same as a sender-specific SPF evaluation. If a sender is moved to a separate return-path domain, configure and test that change at the provider too.

Publish the correction and test each service

  1. Prepare the single final TXT value. Save it with a short explanation of the services retained and any deliberately changed rule.
  2. Update the DNS record set. Finish with one SPF TXT record at the target name. Use a combined record-set change if the DNS host supports it; otherwise keep the edit window short and avoid leaving a duplicate or missing policy behind.
  3. Read the result back. Confirm the full name and value in public DNS, allowing for cached answers. Check that unrelated verification records remain present.
  4. Send from every affected service. Test a mailbox message, newsletter and invoice where relevant. Inspect the recipient’s authentication results and the domain beside each result.
  5. Keep the outcome with the baseline. Record what passed and what remains untested. If recovery is necessary, use a reviewed working policy; restoring a known duplicate configuration would restore the original defect.

For the next addition, update the existing policy instead of creating another one. Follow our provider-change checklist so the new service and the existing workflows are both covered.