Two SPF records on one domain

Updated 2026-08-05 · Troubleshooting

Multiple SPF records are the one thing SPF will not tolerate: a domain may publish exactly one SPF record. Not one per sender, not one per department — one, total.

Publish a second and the result is not "both apply". It is an SPF PermError, which most receivers treat as no usable SPF at all. Both records stop working, including the one that was correct. RFC 7208 is deliberate about this: receivers must not guess which record you meant.

This happens constantly, and almost always the same way. A new platform's setup wizard says "add this TXT record to your DNS", somebody adds it, and now there are two.

What it looks like

example.com  TXT  "v=spf1 include:_spf.google.com ~all"
example.com  TXT  "v=spf1 include:sendgrid.net ~all"

Both are valid records in isolation. Together they authorise nothing.

The symptom is distinctive: SPF fails for every sender at once, including senders that worked yesterday and were not touched. If one platform broke you would expect one platform to fail. Everything failing simultaneously points at the record itself.

Multiple records vs multiple strings

These look similar in a DNS control panel and are completely different.

Two records — invalid:

example.com  TXT  "v=spf1 include:a.example ~all"
example.com  TXT  "v=spf1 include:b.example ~all"

One record split into two strings — valid and required:

example.com  TXT  "v=spf1 include:a.example include:b.example "
                  "include:c.example include:d.example ~all"

A single DNS string cannot exceed 255 characters, so long SPF records must be split into several quoted strings. Receivers concatenate the strings of one record before parsing, which is why this is fine — and why it is not a second record.

If your DNS provider offers one text box per record, a long record is entered as one value and the provider handles the chunking. If it offers a list of strings, they belong to the same record.

How to merge SPF records into one

The mechanical part is easy; the discipline is in not losing a sender.

1. Collect every existing record. Look at all of them, not just the two you know about. Some panels hide a record that was added at a different level.
2. Take the mechanisms from each, dropping the v=spf1 prefix and the trailing all from all but the final result.
3. Concatenate, then de-duplicate. Identical includes appear more than once surprisingly often.
4. Add one all at the end. During a rollout that means ~all — see SPF softfail vs hardfail.
5. Count the lookups before publishing. Merging two records is the classic way to discover the ten-lookup limit, because each record was comfortably inside it alone.
6. Publish the merged record, then delete the others. In that order, and never with a gap where the domain has zero records.

Applied to the example above:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Where the duplicate came from

Worth finding, because it tends to recur:

• A platform's DNS wizard that adds rather than edits.
• Two teams administering the same zone.
• A migration where the old record was left in place "temporarily".
• A subdomain that inherited a record it did not need.

That last one is a different bug with the same look. SPF is not inherited — a record on example.com does not cover mail.example.com. If a subdomain sends mail, it needs its own record; if it does not, v=spf1 -all is the correct thing to publish there.

After the fix

DNS caches the old answer for the length of its TTL, so both records may still be visible to receivers for a while. Verify from outside your network, then confirm from the next reports that SPF results have returned to pass — How to read a DMARC report shows the per-source result, so you can see each sender recover rather than trusting a single spot check.

The syntax reference for the merged record is SPF record syntax.