How to Update an SPF Record When One Already Exists

If you need to update SPF record when one already exists, the safe answer is almost never “add another SPF record.” SPF permits one policy record per domain, so you must identify the current record, preserve every valid sender it authorizes, merge in the new sender, and publish one final TXT value.

This is a common DNS problem when a team adds a transactional email API, SMTP relay, marketing platform, help desk, CRM, or workspace mail service. Each vendor may provide an SPF snippet, but those snippets are instructions to incorporate into your existing policy—not usually standalone records to publish alongside it.

The short answer: edit and merge the existing SPF policy

An SPF policy is published as a DNS TXT record whose value begins with v=spf1. Your domain can have many TXT records for unrelated uses—domain verification, DMARC, site ownership, and other services—but it must not publish multiple SPF policies for the same name.

For example, suppose your existing domain record is:

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

A new email service tells you to add:

v=spf1 include:spf.example-sender.net -all

Do not create a second TXT record with that second full value. Instead, merge the mechanisms into one policy:

v=spf1 include:_spf.google.com include:spf.example-sender.net -all

The final -all belongs at the end of the combined policy. There should be only one v=spf1 at the beginning and only one terminal all mechanism.

RFC 7208 says a domain name must not have multiple SPF records that make an authorization check select more than one record. Receivers that discover multiple SPF policies return an SPF permerror rather than choosing one arbitrarily. (datatracker.ietf.org)

Why a second SPF record breaks authentication

SPF is a DNS-based authorization check. When a receiving mail server evaluates a message, it checks the domain used in the SMTP envelope sender—also called MAIL FROM or the return-path domain—or, when necessary, the SMTP HELO/EHLO identity. It then looks up that domain’s SPF policy and determines whether the connecting IP address is authorized.

That logic depends on an unambiguous policy. If DNS returns two separate TXT records that both begin with v=spf1, the receiver cannot safely assume the records should be combined. One policy might end in -all, while another might authorize a different set of systems. The standard therefore treats the situation as a permanent configuration error.

What SPF permerror means

A permerror indicates that the SPF policy cannot be evaluated correctly because of a durable configuration problem. Multiple SPF records are one cause. Other common causes include malformed syntax, invalid mechanism arguments, and exceeding the SPF DNS-query limit.

A permanent error is not an SPF pass. That matters because many mailbox providers use authentication results as one signal among many when filtering mail. It can also affect DMARC: an SPF result helps DMARC only when SPF passes and the SPF-authenticated domain aligns with the visible From: domain, unless DKIM provides an aligned pass instead. (rfc-editor.org)

Multiple TXT records are fine; multiple SPF policies are not

This distinction causes much of the confusion:

• Allowed: several DNS TXT records at example.com for different purposes.
• Allowed: one SPF policy plus a TXT verification token, a DMARC record at _dmarc.example.com, and other verification records.
• Not allowed: two or more TXT values at the same hostname that begin with v=spf1.
• Not the same thing: a long SPF value split into quoted DNS character strings by your DNS provider. That may still be one DNS record and one SPF policy.

For example, these two records can coexist at the root domain:

example.com. TXT "v=spf1 include:_spf.google.com include:spf.example-sender.net -all"
example.com. TXT "service-verification=abc123"

But this configuration is broken:

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

The fact that both are TXT records does not make them a single SPF policy.

Find the SPF record that already exists

Before editing DNS, find every current SPF policy at the exact hostname you plan to send from. For most organizations, that is the organizational domain, such as example.com. But a platform may send using a dedicated subdomain such as mail.example.com, notify.example.com, or mg.example.com, which is a separate DNS name with its own SPF policy.

Check with command-line DNS tools

On macOS, Linux, and many developer environments, run:

dig +short TXT example.com

On Windows PowerShell, use:

Resolve-DnsName -Name example.com -Type TXT

Look for every returned value that begins with v=spf1. Ignore TXT records that are clearly unrelated, such as ownership-verification tokens.

A result like this indicates one SPF policy:

"v=spf1 include:_spf.google.com include:spf.example-sender.net -all"

A result like this indicates a multiple-record problem:

"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.example-sender.net -all"

If you use dig, remember that it displays public authoritative DNS results, not necessarily the draft state in a DNS control panel. That makes it useful both before and after a change.

Check the correct domain, not just the visible From domain

A message that appears to come from billing@example.com may use a different envelope sender, such as bounce@mailer.example.com. SPF is evaluated against that envelope identity, not automatically against the human-visible From: address.

Inspect a delivered message’s full headers and look for lines similar to:

Return-Path: <bounce@mailer.example.com>
Authentication-Results: mx.receiver.net;
    spf=pass smtp.mailfrom=mailer.example.com;
    dkim=pass header.d=example.com;
    dmarc=pass header.from=example.com

In that example, mailer.example.com needs an SPF policy that authorizes the sending infrastructure. example.com may need a policy too if other mail uses it as the envelope sender, but it is not automatically the SPF domain for every message.

Inventory every system that sends mail

Do not update SPF from memory. Build a quick sender inventory first, especially for established domains. Ask which systems can originate messages with a return-path or MAIL FROM domain under your domain.

Typical candidates include:

1. Employee mailbox providers, such as a hosted workspace or Microsoft 365 tenant.
2. Transactional platforms used by applications through a REST API or SMTP relay.
3. Marketing and newsletter platforms.
4. Customer support, ticketing, chat, and CRM systems.
5. Billing, invoicing, document-signing, and appointment tools.
6. Servers or applications sending directly from fixed public IPv4 or IPv6 addresses.
7. Legacy systems that send alerts, reports, or password-reset messages.

The purpose of the inventory is not to authorize every tool that can display your brand name. It is to authorize only systems that truly send using your domain’s SMTP envelope identity. Some services use their own return-path domain and rely on DKIM instead, so their setup may not require an addition to your root-domain SPF record.

Understand SPF syntax before you merge records

An SPF record is a space-separated sequence that starts with a version marker:

v=spf1 mechanism mechanism modifier

The mechanisms are evaluated from left to right. A matching mechanism produces the result associated with its qualifier. In ordinary production records, the important mechanisms are include, ip4, ip6, a, mx, and all.

Common mechanisms

An include does not simply paste another record’s text into yours. It instructs the evaluator to check the referenced domain’s SPF policy; the include matches only if that nested evaluation returns SPF pass.

Qualifiers and the final all

A mechanism can have a qualifier:

• + means pass. It is the default and is usually omitted.
• - means fail.
• ~ means softfail.
• ? means neutral.

The all mechanism normally appears once, at the end:

v=spf1 include:spf.example.net -all

The ending is important. SPF evaluation stops at the first mechanism that matches. If you put -all before a later include, the later include is unreachable:

v=spf1 -all include:spf.example.net

That record will fail every sender because all always matches. Likewise, merging two vendor examples verbatim creates an invalid structure:

v=spf1 include:vendor-a.example -all include:vendor-b.example -all

The correct merged form is:

v=spf1 include:vendor-a.example include:vendor-b.example -all

include versus redirect

Do not replace several includes with redirect unless you understand the implications. redirect= hands SPF evaluation to another domain only if no mechanism in the current record matched. It is useful when one domain’s SPF policy is intended to be entirely defined elsewhere.

For example:

v=spf1 redirect=_spf.example.net

That is different from:

v=spf1 include:_spf.example.net -all

In a typical multi-sender policy, use the specific include: values or IP mechanisms given by each sender. A redirect is not a generic way to append another provider’s authorization.

How to merge an existing SPF record safely

The practical task is straightforward, but it deserves a controlled change because one small typo can affect every system that sends mail for the domain.

Step 1: Copy the current record exactly

Export or copy the existing SPF value before you change anything. Preserve the original in your ticket, change log, password manager note, or infrastructure repository.

For example, assume the current record is:

v=spf1 include:_spf.google.com ip4:198.51.100.24 ~all

This means the domain currently authorizes the mailbox provider represented by _spf.google.com and a server at 198.51.100.24.

Step 2: Obtain the new sender’s exact authorization mechanism

Use the email provider’s official domain-authentication documentation. A transactional platform might provide an include: domain; another service might require a dedicated subdomain, a custom return-path domain, or no root-domain SPF update at all.

Do not guess an include hostname, adapt a value from an old blog post, or use a provider’s display domain as an SPF include. An include value is DNS syntax with a specific operational meaning.

If you are configuring application mail through a REST API or SMTP relay, consult the provider’s email API setup guides for the exact domain-authentication instructions. The fact that an application uses SMTP rather than HTTP does not change SPF: the receiving server still evaluates the envelope sender and connecting infrastructure.

Step 3: Remove the vendor’s wrapper text

Documentation often presents an entire sample SPF policy beginning with v=spf1 and ending with -all or ~all. When you already have SPF, keep only the new mechanism or mechanisms from that example.

If the new service provides:

v=spf1 include:spf.example-sender.net -all

The portion you are adding is:

include:spf.example-sender.net

Do not copy its second v=spf1 marker or terminal all mechanism into the existing policy.

Step 4: Build one combined candidate record

Starting with:

v=spf1 include:_spf.google.com ip4:198.51.100.24 ~all

Add the new include before the final ~all:

v=spf1 include:_spf.google.com ip4:198.51.100.24 include:spf.example-sender.net ~all

If the existing record uses -all, preserve that posture unless you have an intentional reason to change it:

v=spf1 include:_spf.google.com ip4:198.51.100.24 include:spf.example-sender.net -all

Changing ~all to -all is not required merely because you are adding a sender. Treat it as a separate policy decision after confirming that every legitimate sender has been accounted for.

Step 5: Replace, do not append

In your DNS provider, update the existing TXT record that contains v=spf1. If the interface only permits deleting and recreating a record, remove the old SPF TXT record and create one replacement TXT record with the complete combined value.

Do not leave the old SPF record in place while adding a new one. A brief overlap can create an SPF permerror for resolvers that see both values.

Step 6: Verify public DNS and send a controlled test

After publishing, query DNS again:

dig +short TXT example.com

Confirm that exactly one returned TXT value starts with v=spf1. Then send a test message through the newly authorized platform and inspect the delivered headers. You want to see an SPF pass for the envelope sender actually used by that message.

If the platform supports both SMTP relay and HTTP API delivery, test the sending path your application will use in production. Different configurations can use different envelope identities or routing behavior.

Real-world merge examples

Examples make the merge pattern easier to recognize, but only use provider-specific include values that you have verified in that provider’s current documentation.

Example: add a transactional sender to an existing workspace policy

Existing record:

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

New sender’s documented mechanism:

include:spf.transactional-provider.example

Combined record:

v=spf1 include:_spf.google.com include:spf.transactional-provider.example -all

Example: preserve direct application-server authorization

Existing record:

v=spf1 ip4:203.0.113.17 include:mail.example-workspace.net ~all

New marketing system mechanism:

include:spf.marketing-platform.example

Combined record:

v=spf1 ip4:203.0.113.17 include:mail.example-workspace.net include:spf.marketing-platform.example ~all

Do not remove ip4:203.0.113.17 unless you have verified that the server no longer sends mail using this domain. It could be a scheduled-report system, monitoring service, or legacy application that will begin failing authentication after removal.

Example: separate subdomain instead of an overloaded root record

Suppose a transactional service supports a custom bounce domain at mail.example.com. You may be able to publish its SPF policy on that subdomain:

mail.example.com. TXT "v=spf1 include:spf.transactional-provider.example -all"

Your root domain can retain its existing workspace SPF record:

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

This is not “two SPF records for one domain.” These are policies for two different DNS names. Separating mail streams this way can make sender ownership clearer and reduce pressure on the root-domain SPF record, provided the provider supports the envelope-sender subdomain configuration.

Avoid the SPF 10-DNS-lookup limit

Merging records solves the multiple-SPF-record problem, but it can reveal another issue: SPF has a strict limit on DNS-querying terms during evaluation.

RFC 7208 requires SPF evaluators to limit DNS lookups to 10. include, a, mx, exists, ptr, and redirect can cause DNS queries; ip4, ip6, and all do not. Nested includes count too. If evaluation needs more than 10 lookups, the result is permerror. (datatracker.ietf.org)

Why counting visible includes is not enough

This record visibly has only three includes:

v=spf1 include:service-a.example include:service-b.example include:service-c.example -all

But each included policy may include other domains. One service could use several levels of nested includes, so the real lookup count can exceed 10 even when your own record looks short.

This is why blindly appending a new include each time a department buys another SaaS platform eventually creates deliverability risk. An SPF policy is shared infrastructure, not a collection of unrelated vendor snippets.

Practical ways to reduce lookup pressure

Use these options in roughly this order:

• Remove authorizations for retired services after confirming they no longer send.
• Move a service to a dedicated envelope-sender subdomain if it supports that model.
• Replace unnecessarily broad mechanisms such as a or mx with stable ip4 or ip6 mechanisms only when you operate and can maintain those IP addresses.
• Ask a provider whether it can use an authenticated custom return-path subdomain or aligned DKIM configuration instead of adding another root-domain include.
• Use an SPF-management or flattening approach only with an explicit process to keep IP changes current; stale flattened IP addresses can break mail when a provider changes its infrastructure.

Avoid the deprecated ptr mechanism. It is expensive to evaluate and discouraged by the SPF specification.

DNS formatting and publishing pitfalls

Many SPF incidents come from DNS editing details rather than the policy logic itself.

Do not add extra quotation marks unless your DNS editor requires them

Some DNS control panels display TXT values surrounded by quotes. Others expect you to type only the raw value. Follow the input convention of your DNS host.

The intended data is:

v=spf1 include:spf.example-sender.net -all

If the DNS host automatically adds quotes in its display, that is normal. Do not try to escape or duplicate those display quotes unless the interface documents that behavior.

Long TXT values may be split without becoming multiple SPF records

A DNS TXT character string is limited to 255 characters. DNS providers may automatically split a longer value into adjacent quoted strings while serving it as one TXT record, such as:

"v=spf1 include:one.example include:two.example include:three.example "
"include:four.example -all"

That can still represent one SPF policy. The important test is whether DNS returns one logical SPF TXT record beginning with v=spf1, not whether a dashboard visually wraps or splits the text.

However, do not manually create separate TXT records merely to divide an SPF policy into chunks. If each chunk begins with v=spf1, you have created the exact multiple-record condition SPF forbids.

Use the correct hostname

DNS dashboards represent the root domain in different ways: blank host, @, or the full domain name. A subdomain might be entered as mail, mail.example.com, or another variation based on the provider.

Verify the resulting public hostname with dig after publishing. A valid SPF value at the wrong hostname does not authorize the sender that needs it.

TTL affects change timing, but caching is normal

DNS changes do not update every resolver instantly. The TTL controls how long resolvers may cache a response, while some systems may also cache prior data until its existing TTL expires.

For a planned change, publish during a period when you can test sending, retain the previous policy for rollback, and avoid making unrelated DNS edits at the same time. Do not keep two SPF records during a transition in an attempt to avoid caching; that introduces an immediate standards error rather than a safe migration path.

Test the change from DNS through delivery

DNS syntax validation is necessary but not sufficient. The goal is to ensure a real receiver sees the intended authentication results.

DNS-level checks

Start with these checks:

1. Query TXT records for the exact envelope-sender domain.
2. Confirm only one result starts with v=spf1.
3. Confirm every required include and IP mechanism appears in the combined value.
4. Check that all appears at the end.
5. Evaluate the policy’s DNS lookup count, including nested includes.

MXToolbox can help identify multiple SPF records and syntax issues. For a broader message-quality test, mail-tester.com provides a recipient address that you can send a test message to and then review authentication and content signals. Treat third-party test tools as diagnostic aids, not as substitutes for checking the actual headers received by your target mailbox providers.

Message-level checks

Send a test from each active source: employee mailbox, application, support platform, marketing system, and any direct server still in use. In each received message, inspect Authentication-Results.

A successful result may resemble:

Authentication-Results: receiver.example;
    spf=pass smtp.mailfrom=mail.example.com;
    dkim=pass header.d=example.com;
    dmarc=pass header.from=example.com

A broken SPF policy may show:

Authentication-Results: receiver.example;
    spf=permerror smtp.mailfrom=example.com

or:

Authentication-Results: receiver.example;
    spf=fail smtp.mailfrom=example.com

spf=fail generally means the sending IP was not authorized by the published record. spf=permerror points to a policy-evaluation issue such as multiple SPF records, malformed syntax, or too many DNS lookups.

SMTP and HTTP delivery status codes are not SPF results

A successful API response such as HTTP 202 Accepted, or a successful SMTP submission response such as 250 2.0.0, normally means the sending platform accepted your message for processing. It does not prove that the final receiving mailbox evaluated SPF as a pass.

Similarly, an SMTP 550 5.7.23 or comparable authentication-related rejection can indicate that a receiver declined a message because of policy or authentication concerns, but the exact meaning varies by receiver. Always inspect the response text, delivery event details, and the message headers where a message is delivered.

SPF, DKIM, and DMARC: do not treat SPF as the only control

SPF is valuable, but it is only one part of modern email authentication. It authorizes sending infrastructure for the envelope identity; it does not directly validate the visible From: header users see in their inbox.

DMARC evaluates whether SPF and/or DKIM passed with an identifier aligned to the visible author domain. Under the current DMARC standard, a DMARC pass requires an aligned SPF pass or an aligned DKIM pass. (datatracker.ietf.org)

Why forwarding can make SPF fail

Mail forwarding often changes the connecting IP address. The original sender may have been authorized, but the forwarding server is usually not listed in the original sender’s SPF record. That can cause SPF to fail after forwarding.

DKIM is often more resilient in that scenario because a valid cryptographic signature can survive forwarding if the message is not altered in a way that breaks the signature. For reliable deliverability, configure DKIM alongside SPF and publish DMARC only after you understand how your legitimate streams authenticate.

Use aligned subdomains deliberately

A sensible arrangement may look like this:

• example.com for employee and corporate mail.
• mail.example.com for transactional application mail.
• news.example.com for marketing messages.
• A DKIM signing domain aligned with the visible From: domain or its organizational domain, according to your DMARC alignment mode.

This does not eliminate the need to manage SPF. It does make ownership, troubleshooting, and retirement of individual sending streams easier. It can also prevent the root-domain SPF policy from growing into a fragile list of every vendor the business has ever tried.

A safe SPF change checklist

Before you save DNS, use this checklist:

• I queried public DNS for the exact domain or subdomain used in MAIL FROM.
• I found every existing TXT value beginning with v=spf1.
• I identified all systems that still send using this domain’s envelope identity.
• I obtained the new sender’s SPF instruction from its current official documentation.
• I added only the needed mechanism, such as include:provider.example, rather than a second complete SPF record.
• My final policy has one v=spf1 marker.
• My final policy has one terminal all mechanism at the end.
• I checked the likely DNS lookup count, including nested includes.
• I replaced the prior SPF TXT record instead of adding another SPF TXT record.
• I verified public DNS and sent a real test message after the change.
• I checked delivered message headers for SPF, DKIM, and DMARC outcomes.

When to remove an SPF include instead of adding one

SPF policies tend to accumulate stale entries. Each time you add a sender, check whether another authorization can be safely retired.

Remove an include or IP mechanism only after confirming all of the following:

• The related vendor account, integration, or mail stream is no longer active.
• No application, automation, support rule, or scheduled job still routes mail through it.
• Recent message headers and provider logs show no legitimate use.
• The service’s custom envelope domain, if any, is no longer needed.
• You have a rollback plan if an overlooked sender is discovered.

A good operational habit is to store SPF ownership alongside your other email infrastructure documentation. Note which team owns each mechanism, why it exists, what sender it authorizes, and when it was last reviewed.

Conclusion

When an SPF record already exists, do not publish a second one. Retrieve the current v=spf1 policy, inventory legitimate mail sources, merge the new authorization mechanism before the final all, and replace the old SPF record with one tested policy.

The key is to think of SPF as a single shared authorization policy per sending domain. Careful merging protects existing mail streams, avoids SPF permerror, and gives DKIM and DMARC a stronger foundation for reliable delivery.

FAQ

Can I have two SPF TXT records for the same domain?

You can have multiple TXT records for a domain, but only one SPF policy record beginning with v=spf1. Two SPF records can cause a permerror during receiver evaluation.

How do I add a new email provider to an existing SPF record?

Take the provider’s required mechanism—commonly an include: value—and insert it into your existing SPF policy before the final -all or ~all. Replace the existing SPF record with the combined value rather than adding another record.

Should I use -all or ~all when updating SPF?

Preserve the existing ending unless you are intentionally changing your enforcement posture. -all is a hard fail for unauthorized sources; ~all is softfail. Either way, every legitimate sender must appear before that terminal mechanism.

Why does SPF still fail after I added the provider include?

Check the actual envelope-sender domain, confirm the include is in the policy for that hostname, ensure there is only one SPF record, check for more than 10 DNS lookups, and inspect the receiving message’s Authentication-Results header.

Does a successful SMTP or API send mean SPF is correct?

No. SMTP 250 or an API acceptance response such as HTTP 202 only confirms that the sending service accepted the message for processing. Confirm SPF by inspecting authentication results on a message received by a mailbox.