Multiple SPF Records: Why They Break Email Authentication

Multiple SPF records means a domain has published more than one SPF TXT record where receivers expect a single SPF policy. That usually breaks SPF evaluation. The fix is not to delete records blindly. Agencies need to identify every legitimate sender, consolidate the mechanisms into one SPF record, check the SPF 10 DNS lookup limit, and avoid removing active services by accident.

This matters because SPF is often edited by many teams over time. A client adds Google Workspace, then a newsletter platform, then a CRM, then a helpdesk, then a transactional email provider. During a DNS migration, old records may be copied forward and new records may be added beside them. The result is two or three TXT records that begin with v=spf1, and receiving mail systems do not know which policy is authoritative.

Use Inbox Pulse to surface SPF configuration risks across client domains. Use the broader 10-domain agency audit when you also need SSL, DNS, and domain expiry context. For how CertPilot checks public DNS records, see how CertPilot checks domains.

What SPF is

Sender Policy Framework, or SPF, is a DNS-based way for a domain owner to say which mail servers or services are allowed to send mail for that domain. A basic SPF record is a TXT record that starts with v=spf1.

Example:

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

That record tells receivers to evaluate the listed mechanisms. If the sending server matches the allowed sources, SPF can pass. If it does not, SPF can fail or soft-fail depending on the record.

SPF does not guarantee inbox placement. It is one authentication signal, and DMARC alignment determines how SPF contributes to DMARC. For the broader relationship between SPF, DKIM, and DMARC, read DMARC, SPF, and DKIM explained for agencies.

Can You Have More Than One SPF Record?

A domain should publish one SPF TXT record for each hostname that sends mail. For the root domain, that usually means one TXT record at example.com that begins with v=spf1.

Multiple separate SPF records for one domain are not a stronger setup. They can cause SPF PermError behavior because receivers expect one policy to evaluate. If a client has one SPF record for Google Workspace and another SPF record for a CRM, receivers do not combine those policies into a single safe answer.

Multiple include mechanisms inside one SPF record are different. This can be valid:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -all

The risk is that each include can trigger DNS lookups, including nested lookups inside the included domain. That is why duplicate-record cleanup should be paired with the SPF 10 lookup limit agency debugging guide. Agencies should consolidate carefully, not blindly delete whichever record looks older.

Why only one SPF record should exist

A domain should publish one SPF record at a given hostname. For most business email, that means one SPF TXT record at the root domain, such as example.com.

The problem looks like this:

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

Those are multiple SPF records. They are not two valid policies that get merged by receivers. SPF evaluation expects one SPF policy. Multiple SPF records commonly produce a permanent error style result, often described operationally as PermError. That can make SPF unusable for the domain until the records are consolidated.

Multiple SPF records vs multiple includes

Do not confuse multiple SPF records with multiple include mechanisms inside one SPF record.

| Pattern | Example | Usually valid? | |---|---|---| | One SPF record with multiple includes | v=spf1 include:_spf.google.com include:sendgrid.net -all | Yes, if lookup limit is respected | | Two SPF records at same hostname | Two TXT records that both start v=spf1 | No | | SPF on root and subdomain | Root has SPF, mail.example.com has separate SPF | Can be valid if both hostnames send mail | | TXT records that are not SPF | Verification TXT plus one SPF TXT | Usually valid |

Agencies often see confusion here. A client may be told "add this SPF record" by a SaaS platform. The platform means "add this include to your existing SPF record," but the client or vendor adds a second full record instead.

Common causes of multiple SPF records

Multiple SPF records are usually a process problem, not a technical mystery.

| Cause | What happens | |---|---| | Old platforms | A retired newsletter, CRM, or helpdesk remains in DNS | | DNS migration | Records are copied from one provider and re-added manually | | Vendor instructions | A SaaS platform says "add this SPF record" and a second record is created | | Marketing ownership | Marketing adds a sender without checking existing DNS | | Duplicated records | Same SPF value appears twice after import | | Root vs subdomain confusion | A sender meant to use a subdomain but was added to the root |

This is why agencies should document senders before changing SPF. If nobody knows which platforms send mail, SPF cleanup can break legitimate email.

Why SaaS senders cause SPF bloat

SaaS-heavy clients often send mail from many places:

• Google Workspace or Microsoft 365.
• CRM platforms.
• Marketing automation tools.
• Helpdesks.
• Ecommerce platforms.
• Invoicing tools.
• Transactional email providers.
• Scheduling and form tools.

Each platform may ask for SPF authorization. Over time, the SPF record grows. Teams then add another SPF record because editing the existing one feels risky. This creates both multiple-record problems and lookup-limit problems.

The related issue is the SPF 10 lookup limit. Even after consolidating multiple SPF records into one, the final record may still fail if it triggers too many DNS lookups.

Why SPF flattening can be risky

SPF flattening replaces include mechanisms with a list of IP addresses. It can reduce DNS lookups, but it creates maintenance risk.

Flattening is risky because SaaS providers change their sending infrastructure. If an agency copies today's IP addresses into a client's SPF record and never updates them, legitimate email can fail later. Flattening can also make records long, hard to audit, and more fragile during vendor changes.

Flattening may be appropriate in some controlled environments, but agencies should treat it as an operational commitment. If nobody owns updates, it is often safer to reduce senders, move some senders to subdomains, or use the platform's recommended include mechanisms.

How to Merge SPF Records Without Breaking Mail

Use this workflow before editing DNS:

1. List all current SPF TXT records.
2. Identify every sender or vendor behind each mechanism.
3. Build one combined v=spf1 record with confirmed senders only.
4. Keep only one final all mechanism, such as -all or ~all.
5. Check the SPF 10 DNS lookup limit before publishing.
6. Test with Inbox Pulse or another DNS checker.
7. Confirm with the client's mail platform or admin console when available.
8. Document the change, owner, and rollback values.

Avoid making SPF changes late on a Friday or during a client campaign. SPF mistakes can affect legitimate outbound mail.

| Problem | What it usually means | Safer fix | What to avoid | |---|---|---|---| | Two v=spf1 records | Two vendors or migrations added full SPF policies | Merge confirmed senders into one SPF record | Keeping both records live | | One record with many includes | Several SaaS platforms send for the domain | Count lookups and remove stale vendors | Assuming every include is still needed | | Unknown vendor include | Nobody knows whether the platform still sends mail | Ask the client or platform owner before removal | Deleting unknown senders during a live campaign | | Duplicated include | Same vendor appears twice after migration or import | Keep one copy if the sender is active | Leaving duplicate mechanisms because they look harmless | | Multiple final mechanisms like -all and ~all | Records were pasted together without cleanup | Keep one intentional final mechanism at the end | Publishing a malformed combined record |

Example consolidation

Before:

v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net include:mailgun.org -all

After:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -all

That example shows the shape, not a universal recommendation. The agency still needs to confirm Google, SendGrid, and Mailgun are legitimate senders for the client domain. If Mailgun was retired two years ago, copying it into the final record preserves unnecessary risk.

What not to do

Do not:

• Delete the first record and assume the second is correct.
• Merge includes without checking active senders.
• Add a third SPF record from a vendor setup screen.
• Flatten SPF without an owner for future updates.
• Ignore DMARC alignment.
• Assume SPF fixes deliverability by itself.

SPF is a configuration control. It needs ownership and review.

When to use Inbox Pulse

Use Inbox Pulse when you need to identify domains with SPF, DMARC, DKIM, MX, MTA-STS, TLS-RPT, and BIMI configuration risks across a client list. It is useful for onboarding and recurring audits. It is not a full DMARC RUA aggregator and does not guarantee deliverability.

For a broader email-authentication workflow across many domains, see bulk DMARC checks for client domains.

SPF consolidation decision tree

Use this decision tree before editing a client domain:

| Question | If yes | If no | |---|---|---| | Are there two or more v=spf1 TXT records at the same hostname? | Consolidation is needed | Check lookup-limit and sender inventory instead | | Can every include or IP be mapped to a sender? | Keep legitimate senders in one record | Ask the client before removing unknown mechanisms | | Are any senders retired? | Remove only after confirmation | Leave in place until ownership is clear | | Does the final record exceed lookup limits? | Reduce senders, use subdomains, or consider maintained flattening | Publish the consolidated record carefully | | Does DMARC rely on SPF alignment for any sender? | Test that sender after changes | Still verify DKIM alignment |

This is a better workflow than asking "which SPF record should we keep?" The real question is "which services are allowed to send mail for this domain?"

Example client-safe change plan

For client work, write the change plan before touching DNS:

1. Current state: two SPF records exist at example.com.
2. Known senders: Microsoft 365, HubSpot, and Postmark.
3. Unknown sender: one old include from a previous newsletter platform.
4. Client confirmation needed: whether the old newsletter platform still sends.
5. Proposed final record: one SPF TXT record containing only confirmed senders.
6. Validation: run SPF syntax and lookup checks, then send test messages from active platforms.
7. Rollback: keep the old record values in the ticket.

This protects the agency. It also gives the client a clear reason to respond quickly when an unknown sender appears.

How multiple SPF records affect DMARC

DMARC can pass if either aligned SPF or aligned DKIM passes. If multiple SPF records cause SPF evaluation errors, then DMARC may need to rely on DKIM. That may be fine for some senders and a problem for others.

For example, a newsletter platform may have working DKIM alignment, while a CRM relies on SPF alignment because DKIM was never configured. If SPF breaks because of multiple records, the CRM messages may fail DMARC even though the newsletter still passes.

This is why SPF cleanup should be part of a combined SPF, DKIM, and DMARC review, not a single-record edit.

Implementation notes for common DNS hosts

Most DNS providers let you publish multiple TXT records at the root. That is normal. The issue is publishing multiple TXT records that both begin with v=spf1. Verification records for Google, Microsoft, website platforms, or SaaS tools can coexist with SPF because they are not SPF policies.

When editing DNS, agencies should be careful with host/name fields:

| Provider pattern | Root host may appear as | Agency risk | |---|---|---| | @ for root | @ | Adding SPF to mail by accident does not fix root mail | | Blank host for root | Empty field | Easy to create duplicate if UI hides existing TXT values | | Full domain accepted | example.com | Some providers append the zone again if used incorrectly | | Imported records | Multiple TXT rows | Duplicate SPF can be hidden among verification records |

After publishing the consolidated SPF record, check the authoritative answer. Do not rely only on what the DNS dashboard displays. The dashboard can show a saved record that is not yet live, or the domain may use different nameservers than expected.

Handling subdomains and dedicated sending domains

Agencies do not always need to authorize every sender at the root domain. Sometimes a dedicated sending subdomain is cleaner.

Examples:

• Marketing mail from news.example.com.
• Transactional mail from mail.example.com.
• Helpdesk mail from support.example.com.

Each hostname can have its own SPF policy if that hostname is used in the relevant return-path or sending setup. This can reduce root-domain SPF complexity, but it only works when the platform is configured to use the subdomain correctly. Do not move includes to a subdomain unless the sender is actually using it.

Subdomains also need DMARC and DKIM review. A clean root SPF record does not automatically authenticate every subdomain workflow.

Agency handoff format

When the agency does not control DNS, send a precise request:

Please replace the existing SPF TXT records at example.com with one TXT record:

Host: @
Type: TXT
Value: v=spf1 include:_spf.google.com include:sendgrid.net -all

Do not add this as a second SPF record. It must replace the existing SPF records that begin with v=spf1.

Also include the reason:

The domain currently has multiple SPF records. Mail receivers expect one SPF policy, so the duplicate records can cause SPF evaluation errors.

This reduces the chance that a client or vendor adds another record and leaves the problem in place.

Related resources

• SPF 10 lookup limit agency debugging guide
• DMARC, SPF, and DKIM explained for agencies
• Bulk DMARC check for client domains
• DNS drift agency guide

Frequently Asked Questions

What are multiple SPF records?

Multiple SPF records are two or more TXT records at the same hostname that begin with v=spf1. SPF expects one policy for a hostname. When more than one SPF record exists, receivers can treat SPF evaluation as a permanent error. The right fix is usually to consolidate legitimate mechanisms into one SPF record, not to choose one record at random.

Can you have more than one SPF record?

No. A hostname should have one SPF TXT record that starts with v=spf1. A domain can have many TXT records for verification, DMARC, or other services, but only one SPF policy for the same hostname. If a root domain has two separate SPF records, agencies should merge confirmed senders into one record and remove the duplicates after validation.

What is the difference between multiple SPF records and multiple SPF includes?

Yes. One SPF record can contain multiple include mechanisms, such as Google Workspace plus a transactional email provider. That is different from publishing multiple SPF records. The final record still needs to stay within SPF evaluation rules, especially the 10 DNS lookup limit. Agencies should count includes and nested lookups before assuming a consolidated record is safe.

How do you merge SPF records?

List every existing v=spf1 record, identify the sender behind each mechanism, remove duplicates and retired vendors, then build one combined SPF record with a single final all mechanism. Check syntax and DNS lookup count before publishing. After the change, test active mail platforms rather than assuming the DNS edit solved every authentication path.

Can one SPF record include multiple domains?

Yes. One SPF record can include multiple vendor domains with include: mechanisms. That is common for clients using Google Workspace, a CRM, and a transactional email provider. The includes should map to active senders and stay within the SPF 10 DNS lookup limit. If the record becomes too complex, consider sender cleanup or dedicated subdomains.

Why do SaaS tools create SPF problems?

SaaS tools create SPF problems because many platforms ask to be authorized as senders for the same domain. Over time, clients add CRMs, newsletter tools, helpdesks, ecommerce systems, and transactional platforms. Old vendors often remain in DNS after they stop being used. This creates bloated SPF records, multiple SPF records, and lookup-limit failures unless someone owns sender inventory.

Is SPF flattening a good fix for multiple SPF records?

Not by itself. SPF flattening can reduce DNS lookups, but it does not solve poor sender ownership. It can also become stale when SaaS providers change IP addresses. Agencies should first remove abandoned senders and consolidate records. Flattening should only be used when someone will maintain it and understands the provider's infrastructure changes.

Can changing SPF break client email?

Yes. Changing SPF can break legitimate email if the agency removes an active sender or publishes a malformed record. This is why SPF cleanup should start with a sender inventory. Confirm business email, marketing email, transactional systems, support tools, and any client-owned systems before editing the final SPF record.

Will fixing multiple SPF records guarantee deliverability?

No. Fixing multiple SPF records can remove an authentication failure, but it does not guarantee deliverability or inbox placement. Mailbox providers consider reputation, content, engagement, complaints, sending patterns, DKIM, DMARC alignment, and other signals. Treat SPF cleanup as one part of a broader email-authentication audit.