On this page
  1. Why a domain can have only one SPF record
  2. Other TXT records and subdomains
  3. How to merge two SPF records
  4. Worked example on example.com
  5. Check the lookup count after merging
  6. Publish the merged record and check it
  7. Sources

No. A domain publishes one SPF record, and if the lookup for a name returns more than one TXT record that begins with v=spf1, the SPF check returns a permerror (RFC 7208 section 4.5 (opens in a new tab)). The fix is to merge them into one record that lists every service (SPF lookup), then remove the extra record so only one is left (SPF record generator).

Why a domain can have only one SPF record

Sender Policy Framework (SPF) (opens in a new tab) lets a domain publish, in the Domain Name System (DNS), which hosts may send mail using its name, and receivers test the sending server against that list.

The standard forbids publishing more than one: a domain name must not have multiple records that would make an authorization check select more than one (RFC 7208 section 3.2 (opens in a new tab)). When a receiver checks SPF, it takes the TXT records returned for the name and discards every one that does not begin with exactly v=spf1. If none is left, the result is none; if more than one is left, the result is a permerror (section 4.5 (opens in a new tab)).

A permerror means the domain's published records could not be correctly interpreted, and fixing it needs a change by whoever runs the domain's DNS (section 2.6.7 (opens in a new tab)). Microsoft (opens in a new tab) gives the reason in plain terms: with two SPF records, the receiving system can't determine which one to evaluate.

Each domain can have one SPF record, and that record can list additional servers and third parties allowed to send for the domain (Google Workspace (opens in a new tab)). So when a new service asks you to add its SPF record, add its services to the record you already have instead of creating a second one (SPF record generator).

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Other TXT records and subdomains

The one-record rule covers SPF records only. Because SPF discards every TXT record that doesn't begin with v=spf1 (RFC 7208 section 4.5 (opens in a new tab)), other TXT records at the same name are not a second SPF record. A common example is domain verification: when you set up Google Workspace, Google gives you a TXT record to add to your domain to confirm you own it (Google Workspace (opens in a new tab)). That record can stay where it is.

Subdomains are separate names with separate records. Each subdomain that sends email needs its own SPF TXT record, and only one SPF record is allowed per domain or subdomain (Microsoft (opens in a new tab)). The record on example.com doesn't cover marketing.example.com. Google (opens in a new tab) gives the same instruction: if you use subdomains, add an SPF record for each one.

How to merge two SPF records

  1. Copy both records. In your DNS provider, look for the TXT records on the root of your domain that start with v=spf1 (SPF record generator).
  2. Combine the mechanisms. Start one record with a single v=spf1, then add every mechanism from both records except their all endings, so the new record lists every service (SPF lookup).
  3. Keep one all, at the end. The all mechanism always matches, so it belongs last in the record as its default, and mechanisms after it are never tested (RFC 7208 section 5.1 (opens in a new tab)). Receivers read the record left to right and stop at the first mechanism that matches (section 4.6.2 (opens in a new tab)), so an all left in the middle hides every mechanism after it.
  4. Keep redirect and exp once at most. Each may appear in a record no more than once; a second copy gives a permerror (section 6 (opens in a new tab)). A redirect is also ignored when the record has an all mechanism anywhere in it (section 5.1).

If the two records end differently, you have to pick one ending. DemiSignal's generator describes ~all as the usual ending when DMARC (Domain-based Message Authentication, Reporting, and Conformance) is in place, and -all as stricter, with some receivers then rejecting forwarded email before checking DKIM (DomainKeys Identified Mail). The hard fail guide covers what Google and Microsoft each recommend.

Worked example on example.com

Say example.com has two SPF records, one added for its mail provider and one added later for a newsletter tool and the web server:

v=spf1 include:_spf.example.net ~all
v=spf1 include:mail.example.org ip4:192.0.2.10 -all

The merged record keeps one v=spf1, every mechanism from both, and one ending:

v=spf1 include:_spf.example.net include:mail.example.org ip4:192.0.2.10 ~all

Pasting the second record onto the end of the first doesn't work. In v=spf1 include:_spf.example.net ~all include:mail.example.org -all, every mechanism after the first ~all is never tested, so include:mail.example.org is ignored.

Check the lookup count after merging

The include, a, mx, ptr and exists mechanisms and the redirect modifier each cause DNS queries, the total per evaluation is capped at 10, and going over returns a permerror (RFC 7208 section 4.6.4 (opens in a new tab)). The all, ip4 and ip6 mechanisms don't count.

Each include also evaluates the included domain's own record (section 5.2 (opens in a new tab)), and the 10-lookup limit is tracked as one global limit across all those evaluations, not per included record (section 4.1 (opens in a new tab)). So the lookup terms inside an included record count toward your total too. In the example above, the two includes cost two lookups plus whatever their records hold, and ip4:192.0.2.10 costs nothing.

If the merged record goes over 10, the SPF too many DNS lookups guide covers which terms count and how to bring the total down. One option Microsoft (opens in a new tab) gives is moving a service to a subdomain with its own SPF record, since each subdomain has its own 10-lookup budget.

Publish the merged record and check it

DemiSignal's SPF record generator sums up publishing as replace, don't add:

  1. In your DNS provider, find the TXT record on the root of your domain that starts with v=spf1.
  2. Change that record to the merged value and delete the other SPF record. "Never keep two."
  3. Wait for DNS. Changes usually show within an hour; some providers take up to 48 hours.
  4. Run the free check to confirm the record and see the real lookup count.

The SPF lookup tool looks up a domain's SPF record and counts its DNS lookups against the limit of 10. It reads public DNS only: nothing is changed and no email is sent.

Sources

Tools for this

Frequently asked questions

Can you have more than one SPF record?

No. A domain or subdomain publishes one SPF record. If the lookup returns more than one record that begins with v=spf1, the SPF check returns a permerror. Merge the services from both into one record and remove the other.

Can I keep other TXT records, such as verification codes, next to my SPF record?

Yes. SPF discards TXT records that do not begin with v=spf1, so a domain verification TXT record at the same name does not count as a second SPF record.

Does a subdomain use the SPF record of the main domain?

No. Each subdomain that sends email needs its own SPF record, and only one SPF record is allowed per subdomain, just as on the main domain.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.