Why Multiple SPF Records Are A Problem

It is easy to create multiple SPF records by accident. A marketing platform asks for an SPF entry, Microsoft 365 already has one, and somebody adds the new value as another TXT record rather than amending the existing one.

That looks reasonable in a DNS control panel. DNS can hold several TXT records at the same hostname, after all. SPF is different: a domain may have many kinds of TXT record, but it must have only one TXT record that begins with v=spf1.

Two SPF records are not evaluated as a helpful combined list of authorised senders. They create an SPF permerror (permanent error). That means a receiving system cannot produce a valid SPF pass for the domain in question, even where the sending IP address appears in one of the records.

What SPF is checking

Sender Policy Framework (SPF) is a DNS-based method for declaring which mail servers may use a domain in the SMTP MAIL FROM address, often called the envelope sender or return-path. It can also be used to check the sending server’s HELO/EHLO identity.

This distinction matters because SPF does not directly authenticate the address a recipient sees in the visible From: header. For example, a message may display offers@example.co.uk in its From address while using bounce@example.co.uk as its envelope sender. SPF normally evaluates the latter. The SPF specification defines SPF as authorisation for the domains used in these HELO and MAIL FROM identities.

A basic record might look like this:

example.co.uk. TXT "v=spf1 include:spf.mail-provider.example -all"

The record tells receivers to consult the specified provider’s SPF policy and reject other sources for the envelope-sender domain. The precise mechanisms vary, but the important structural rule does not: SPF evaluation expects one policy record for each domain or subdomain being checked.

Why two SPF records cause a permanent error

Consider this configuration:

example.co.uk. TXT "v=spf1 include:spf.office-mail.example -all"
example.co.uk. TXT "v=spf1 include:spf.marketing-platform.example -all"

Both records begin with v=spf1. A receiver finds two candidate SPF policies for example.co.uk. It must not choose one arbitrarily, evaluate them in order, or join them together. Under section 4.5 of the SPF standard, more than one selected SPF record produces permerror. Microsoft’s current SPF guidance makes the same operational point: multiple SPF TXT records for a domain or subdomain cause a permanent error because the receiver cannot determine which record to evaluate.

This is deliberate. SPF is an authorisation policy, and silently merging separate policies could produce unexpected permissions. It would also make authentication results dependent on the way a particular receiver happens to process DNS responses.

A permanent error is different from an ordinary SPF fail. A fail means the receiver successfully evaluated a valid policy and the sending host was not authorised by it. A permanent error means the published policy itself cannot be used correctly. The error is therefore a configuration problem at the sending domain, not a transient connectivity issue that should resolve on its own.

Why this affects deliverability and DMARC

SPF failure alone does not dictate one universal delivery outcome. Mailbox providers apply their own filtering and enforcement decisions, taking account of authentication, sending reputation, recipient engagement and other signals. Still, a broken SPF configuration removes an authentication signal that legitimate senders should be able to provide consistently.

The bigger operational risk is often DMARC. DMARC can pass if either SPF or DKIM passes and the successful identifier aligns with the visible From domain. Therefore, a message with an SPF permanent error can still pass DMARC through a valid, aligned DKIM signature. It cannot, however, rely on SPF to achieve that DMARC pass.

That distinction is especially important where an organisation assumes “DKIM is in place somewhere” but has not tested each sending stream. A transactional platform may sign with an aligned domain while a helpdesk, finance system or legacy marketing tool does not. For those messages, an SPF permerror may leave neither aligned SPF nor aligned DKIM available.

Google’s sender guidelines require bulk senders to personal Gmail accounts to use SPF, DKIM and DMARC, and explain that an SPF or DKIM result must authenticate an aligned domain for DMARC. A duplicate SPF record is therefore not a cosmetic DNS tidy-up; it can weaken the authentication position of a live mail stream.

Multiple TXT strings are not necessarily multiple SPF records

This is a common source of false alarms. DNS TXT records may be displayed differently by different providers and diagnostic tools.

A single TXT record can contain several quoted character strings. DNS joins those strings without adding a space. This is permitted and is sometimes necessary because an individual DNS TXT character string has a size limit. The SPF standard expressly distinguishes this from publishing multiple SPF records.

For example, the following is one SPF record split into two strings:

example.co.uk. TXT "v=spf1 include:spf.provider.example " "include:_spf.other-provider.example -all"

It is evaluated as:

v=spf1 include:spf.provider.example include:_spf.other-provider.example -all

By contrast, these are two separate SPF records and will cause a permanent error:

example.co.uk. TXT "v=spf1 include:spf.provider.example -all"
example.co.uk. TXT "v=spf1 include:_spf.other-provider.example -all"

Likewise, non-SPF TXT records at the same hostname are normal. Domain-verification tokens, site-verification values and other TXT data do not create an SPF error unless they also start with the exact SPF version marker, v=spf1.

How duplicate SPF records are usually created

The underlying cause is usually a change process rather than an attempt to misconfigure email deliberately. Typical examples include:

• A new email service provider supplies a ready-made SPF record, and it is pasted into DNS alongside the existing policy.
• Different teams manage corporate email, customer marketing, support and transactional mail without a shared inventory of domains and sending platforms.
• A new subdomain is correctly configured, but a similar-looking record is also mistakenly added at the organisational domain.
• A previous provider is removed from the sending stack, but its SPF entry remains; later, a new entry is added as a second full policy.
• A DNS management tool labels every TXT value as a separate “record”, making it unclear whether an administrator is editing the SPF policy or creating another one.

These mistakes become more likely as a business adds platforms. A permission-based sender may legitimately use separate services for corporate mail, receipts, account notices, support tickets and newsletters. Each needs to be considered, but adding a whole SPF record for each one is the wrong model.

How to fix the configuration safely

The answer is usually to consolidate the valid authorisations into one SPF policy. Do this as a mail-flow review, rather than blindly joining every value found in DNS.

Identify the domain actually being evaluated

Start with message headers from each active sending stream. Look for the envelope sender or return-path, then identify the domain after the @. This may be the visible From domain, a subdomain such as bounce.example.co.uk, or a provider-managed domain.

One SPF record at example.co.uk and another at news.example.co.uk are not duplicates: they belong to different DNS names. Each may be correct if each is used as an envelope-sender domain. The “one record” rule applies per domain or subdomain, not across the whole organisation.

Inventory genuine sending sources

List the systems that send mail using that envelope domain: mailboxes, marketing platforms, transactional providers, helpdesk software, billing systems and on-premise relays if any remain. Establish whether the service sends through its own infrastructure, requires an include: mechanism, uses fixed IP addresses, or provides a custom return-path subdomain.

Do not retain a supplier simply because an old SPF include exists. Equally, do not remove one because it seems unfamiliar. Check recent sending records, platform ownership and message headers first. Removing a valid authorisation can turn a duplicate-record problem into a straightforward SPF fail for a live service.

Build one policy, with one ending

Suppose the two earlier records represented two active, valid providers. Their authorisations would normally be brought into one record:

example.co.uk. TXT "v=spf1 include:spf.office-mail.example include:spf.marketing-platform.example -all"

The record has one v=spf1 marker and one final policy mechanism. The existing mechanisms are preserved in a single evaluation path. Do not copy a second v=spf1 marker into the merged value, and do not leave an all mechanism in the middle of the record: all matches everything, so any terms after it are ineffective.

Vendor instructions should be read in context. Some providers use mechanisms other than a simple include, and a policy containing redirect=, macros or exceptions warrants closer review. The goal is an accurate policy for the sending sources actually in use, rather than a mechanically concatenated record.

Check the SPF DNS lookup budget

Combining several providers fixes the duplicate-record error, but it can reveal a second SPF problem. Mechanisms such as include, a, mx, exists and redirect can trigger DNS lookups during SPF evaluation. The SPF standard sets a limit of ten such DNS-lookup-causing terms; exceeding it also produces permerror.

That limit includes lookups reached inside included records. An SPF record can look short while its provider includes lead to a much longer chain. Check the highest-lookup path after every change, and periodically after providers alter their own SPF structures. Microsoft also highlights the ten-lookup limit in its SPF configuration guidance.

Flattening SPF into IP ranges is sometimes proposed as the immediate answer. It can reduce DNS lookups, but it transfers maintenance responsibility to the domain owner. If a provider changes its sending ranges, a static flattened entry can become stale and lead to SPF failures. Use it only with a reliable process for provider changes, validation and rollback.

Publish, then verify real mail

Delete the duplicate SPF record and publish the consolidated value at the correct hostname. Allow for DNS caching according to the record’s TTL, then query public DNS and inspect fresh messages from every sending platform. The message headers should show an SPF pass for the intended envelope domain where the platform and path support it.

Also inspect DKIM and DMARC results. SPF passing for an unrelated bounce domain may be useful, but it does not create an SPF-aligned DMARC pass for the visible From domain. The current DMARC specification defines alignment using an SPF-authenticated identifier only where SPF has passed.

Preventing the issue from returning

SPF is best treated as controlled production infrastructure. Maintain an owner for every sending domain, a record of each approved platform and its required authentication settings, and a change process that asks one basic question: “Which existing SPF record must this new service be added to?”

Use separate envelope-sender subdomains where a platform supports them and the separation serves a real operational purpose. For instance, bounce.marketing.example.co.uk can have its own SPF policy while corporate mail continues to use example.co.uk. This can keep policies simpler and make ownership clearer. It is not a substitute for correct DMARC alignment and DKIM configuration.

Authentication reviews should include DNS records, live message headers and DMARC aggregate reporting. Reports can help reveal unexpected sources and identify streams that cannot achieve aligned SPF. For organisations recovering from poor inbox placement or preparing for DMARC enforcement, this is a useful point for an independent authentication and infrastructure review. Email Foundry’s work in this area focuses on permission-based sending and checks authentication alongside the mail streams and sending practices that determine whether a corrected DNS record is working in production.

Multiple SPF records have a simple rule and a potentially wide impact: one domain or subdomain being checked by SPF needs one valid SPF policy. Consolidate authorised sources carefully, keep within the lookup limit, and verify the authentication results on actual messages rather than relying on the DNS control panel alone.

Frequently asked questions

Can a domain have more than one TXT record?

Yes. TXT records are used for many purposes, including domain verification and other email authentication methods. The restriction is specifically that there must be only one TXT record beginning with v=spf1 for any one domain or subdomain evaluated by SPF.

Can I have separate SPF records for example.co.uk and mail.example.co.uk?

Yes. They are different DNS names. Each may have one SPF policy if each is used in a MAIL FROM or HELO identity. Check the envelope-sender domain used by each platform before deciding where a record belongs.

Will merging two SPF records always solve the problem?

It solves the duplicate-policy problem only if the merged record is valid. You must also verify that every authorised source is still required, that the syntax is correct and that the complete evaluation stays within SPF’s ten-DNS-lookup limit.

If DKIM passes, do multiple SPF records still matter?

An aligned DKIM pass can allow DMARC to pass even when SPF has a permanent error. However, the duplicate SPF configuration still removes SPF as a reliable authentication result and creates avoidable risk for streams that depend on SPF alignment.

Sources and further reading

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 — IETF
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF
• Email sender guidelines — Google
• Set up SPF to identify valid email sources for your Microsoft 365 domain — Microsoft Learn