Can You Have Two SPF Records on One Domain? (No — Here's Why)

Can you have two SPF records on one domain? No — and the reason matters, because the failure is quiet. A domain is allowed exactly one SPF record. Publish a second one and SPF does not combine the two; it stops working entirely and returns a permanent error. Mail that used to pass can start failing authentication, and nothing in your own inbox tells you why.

This guide explains why a second SPF record breaks the check instead of merging, how to spot the duplicate, and the merge recipe most guides leave out — how to fold two vendors' requirements into a single valid record. It is host-agnostic: the exact values come from your mail providers, and the job here is getting them into one record correctly.

The short answer#

A domain must publish one SPF record, and only one. The SPF standard, RFC 7208, defines how a receiver selects your record: it gathers the TXT records at your domain, keeps only those that begin with exactly v=spf1, and if that set holds more than one record, the check returns permerror — a permanent error. It does not pick the first record, and it does not merge their mechanisms.

So if Google Workspace and a second sender both need to be authorised, you do not publish one SPF record for each. You publish a single v=spf1 record that lists both, with each include: mechanism appearing once and a single qualifier at the end.

• One SPF record per domain — and one per subdomain that sends mail.
• Two or more v=spf1 records return permerror, and SPF stops authenticating.
• The fix is to merge, not to choose: one record containing every sender's mechanism.
• A single record still has a limit — no more than 10 DNS-lookup mechanisms, a separate cause of the same permerror.

Why a second SPF record breaks the check instead of merging#

It is tempting to assume a receiver reads every SPF record and combines them — if a sender matches any record, it passes. SPF does not work that way. Record selection happens before any mechanism is evaluated, and it is where two records fail.

RFC 7208 section 3.2 states plainly that a domain name must not have multiple records that would cause an authorisation check to select more than one record. The selection rule in section 4.5 enforces it: after discarding every TXT record that does not start with exactly v=spf1, if the remaining set holds more than one record, the check produces the permerror result.

permerror is a permanent error. To the receiver it means your SPF policy could not be evaluated at all — the same practical outcome as having no usable policy. It will not fall back to one of the two records. And because DMARC treats an SPF permerror as an SPF failure, a message that would have passed SPF cleanly can now fail DMARC alignment and be quarantined or rejected, depending on your DMARC policy.

Before you start#

Before you touch DNS, take stock of every service that sends mail as your domain. A merge only works if you have every piece; a dropped include: silently breaks one sender's mail while the rest keeps working, which is hard to notice.

• Every sending service — Google Workspace or Microsoft 365 for mailboxes, plus any ESP, CRM, help desk or transactional service (SendGrid, Amazon SES, Mailchimp, Brevo, a billing tool).
• Each vendor's required SPF mechanism — usually an include: value, sometimes an ip4: or ip6: range — taken from that vendor's own documentation.
• Access to the DNS host or registrar that serves your domain's records.
• A way to read your live records — dig, nslookup or an online SPF lookup tool — so you can see exactly what is published now.
• One qualifier decision for the end of the record: ~all (soft fail) or -all (hard fail).

How to merge two SPF records into one#

Work through these in order. The goal is a single v=spf1 record that authorises every legitimate sender, published in place of the two you have now.

1. 1

   List every SPF record you already publish

   Query the TXT records at your root domain — for example, dig TXT example.com. Note every value that begins with v=spf1. If you see two or more, that is the cause of the permerror.

2. 2

   Pull the mechanisms out of each record

   From each record, take the mechanisms — the include:, ip4:, ip6:, a and mx tokens. Ignore the repeated v=spf1 prefix and the trailing all on each; you will add a single qualifier back at the very end.

3. 3

   Combine them into one v=spf1 record

   Write a single record: one v=spf1, then every mechanism once (remove duplicates), then one qualifier. For Google Workspace plus SendGrid this is v=spf1 include:_spf.google.com include:sendgrid.net -all.

4. 4

   Count the DNS lookups before you publish

   Add up the mechanisms that trigger a DNS query: include, a, mx, exists and redirect. The record must stay within 10, or it fails with a permerror for a different reason. ip4:, ip6: and all do not count toward the limit.

5. 5

   Publish the one record and delete the others

   Save the merged record, then remove every other v=spf1 record on the domain. When you finish, a TXT query for the domain must return exactly one SPF record.

6. 6

   Verify against a checker

   Re-query the domain and run the value through an SPF validation tool. Confirm it reports one record, valid syntax and lookups within the limit. Allow for DNS caching — receivers keep the old answer until the previous record's TTL expires.

How different setups fit into one record#

The single-record rule does not change when you add senders — you extend the one record. Below are common two-provider setups and the shape of the merged record. Confirm each include: against the vendor's current documentation before you publish, because vendors change them and an include: that points to a domain with no SPF record returns its own permerror.

What to do when it doesn't work#

Most SPF failures after a merge trace to a short list of causes. Query your record, compare what returns to what you meant to publish, and match the symptom below.

Where a mail client fits — and where it doesn't#

Merging SPF records is DNS work, and it is a one-time job per change rather than something to automate. AI Emaily is a mail client, not a DNS host, an SPF flattening service, or a deliverability tester — it will not publish or merge these records for you. For the merge itself, use your DNS provider; for watching whether your mail keeps passing SPF and DMARC over time, use an SPF checker or a DMARC monitoring service. If that is the task in front of you, those are the right tools, not us.

What we do sits on the receiving side. SPF, DKIM and DMARC are how a receiving server decides whether a message truly came from the domain it claims, and AI Emaily reads those same results on the mail arriving in your inbox — so its spam and phishing protection can flag a spoofed sender that failed authentication. Connecting a Gmail, Outlook or IMAP mailbox needs no new DNS records, since your outbound still flows through your provider's authenticated servers. We build AI Emaily, and it comes with a 7-day free trial on the Pro and Autopilot plans.