Multiple SPF Records: Why Two Break Your Email (and How to Merge Them)

Introduction

You added a second email service to your domain, followed its setup guide, pasted the SPF record it gave you, and now email that used to work is landing in spam.

The cause is almost always the same: your domain now has two SPF records, and having two is worse than having none.

This guide covers how to spot it, how to merge them correctly, and the mistake that sends most people down the wrong path — putting a service in SPF that has no business being there.

One Record Per Domain. No Exceptions.

RFC 7208 is unambiguous: a domain publishes exactly one TXT record starting with v=spf1.

When a receiving mail server finds two, it does not pick the better one, merge them, or fall back to the first. It returns permerror and the SPF check fails — even if the sending server was listed correctly in one of them.

This is what makes the problem so confusing. Adding a valid record for your new provider breaks the provider that was already working.

Broken — two separate TXT records:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.brevo.com ~all

Correct — one record, both includes:

v=spf1 include:_spf.google.com include:spf.brevo.com ~all

How to Check What You Actually Have

DNS panels make this easy to miss, because each record looks fine on its own row. You have to look at the domain as a whole.

dig +short TXT yourdomain.com | grep spf1

If more than one line comes back, that is your problem.

Check your SPF record →

Merging Two Records Into One

The mechanics are simple. The care goes into what you keep.

1. Collect every include: and ip4:/ip6: from both records.

2. Write a single record, starting with v=spf1 and ending with one all mechanism:

v=spf1 include:_spf.google.com include:spf.brevo.com ip4:203.0.113.10 ~all

3. Keep only one all. Two records means two all mechanisms, and everything after the first one is ignored. If they disagreed (~all in one, -all in the other), decide deliberately: ~all (softfail) while you verify, -all (hardfail) once you are sure the list is complete.

4. Delete the second TXT record. Do not leave it disabled or renamed — remove it.

5. Verify after propagation, usually within the hour.

Order does not matter for correctness, but keep your highest-volume sender first: SPF evaluation stops at the first match, which saves lookups.

The Mistake Almost Everyone Makes

Here is the one that costs people days, and the reason a generic "merge your records" answer is not enough.

SPF only authorises servers that send mail as your domain. Services that only receive or forward mail do not belong in it.

The setup that trips people up looks like this:

• A domain registered somewhere like GoDaddy or 123-reg
• A forwarding service — ImprovMX, for example — so you@yourdomain.com arrives in Gmail
• A marketing or transactional platform such as Brevo, Mailchimp or SendGrid for outbound campaigns

The forwarding service publishes SPF instructions in its docs, so it gets added. But if it only delivers mail to you, it never sends anything as your domain, and its include does nothing except consume one of your ten DNS lookups.

Ask one question about every include: does this service send email that shows my domain in the From address?

• Sends as your domain → belongs in SPF
• Only receives or forwards to you → does not
• Sends only to you (alerts, notifications) → does not

Getting this wrong is expensive twice over: it wastes lookups you may need later, and it hides the real reason your mail is failing.

Watch the Lookup Budget

Merging records solves the permerror, but it can walk you straight into the next limit. SPF allows 10 DNS lookups, and each include: counts — plus every include nested inside it.

Two providers merged into one record is usually fine. Four or five is where it gets tight: Google Workspace alone consumes several.

If you were already close to the limit, read SPF Record: Too Many DNS Lookups before adding anything else.

What This Does to DMARC

A failing SPF check does not always mean failing DMARC, and understanding why saves unnecessary panic.

DMARC passes if either SPF or DKIM passes with alignment. So a domain with broken SPF and correctly configured DKIM can still pass DMARC — which is exactly why the problem goes unnoticed for months. Your mail mostly arrives, deliverability quietly degrades, and nothing points at the duplicate record.

It surfaces the day you raise your policy from p=none to quarantine or reject, or when a receiver weighs SPF more heavily than usual.

The aggregate reports show it before your users do: they list what passed SPF, what passed DKIM, and what aligned, per source. That is the difference between guessing and knowing.

Checklist

• dig +short TXT yourdomain.com | grep spf1 returns exactly one line
• The record starts with v=spf1 and has exactly one all
• Every include: belongs to a service that sends as your domain
• Forwarding and receiving-only services have been removed
• Total DNS lookups stay at 10 or under
• Test mail from every provider passes SPF

Next Steps

1. Check for duplicates and count lookups: SPF Checker →
2. Build a clean merged record: SPF Record Generator →
3. Verify the whole setup: Domain Score →
4. See what is actually failing in the wild: Start free → — aggregate reports show SPF and DKIM results per sending source, so you find a broken record before your recipients do.

---

Related Articles:

• SPF Record: Too Many DNS Lookups (How to Fix)
• SPF, DKIM, and DMARC: The Complete Guide
• Why Your Emails Are Going to Spam
• DMARC Alignment Failed: How to Fix It