Why do some ESPs recommend SPF records when they are not needed?
Updated on 19 Oct 2026: We clarified when ESP SPF includes are needed and how to remove unused includes without disrupting authentication.
ESPs can recommend unnecessary SPF includes when their documentation repeats legacy setup advice or covers a different sending mode. Sender Policy Framework (SPF) does not authenticate the visible From domain by itself. SPF checks whether the sending server's IP address is authorized for the SMTP MAIL FROM domain, also called the bounce domain or envelope sender domain. The delivered message normally records that address in Return-Path.
If the ESP sends with its own bounce domain and your visible From domain has a passing, aligned DKIM signature, adding that ESP to the SPF record at your main domain does not help that message pass DMARC. The unnecessary include can add DNS lookups for other mail streams that use your main domain's SPF policy. Publishing a separate SPF record for the ESP also creates a duplicate-record error.
- Publish an ESP include at the MAIL FROM domain only when its current setup instructions require a direct SPF TXT record there.
- Leave the ESP out of your root SPF record when it uses its own bounce domain and no other sending path needs that include.
- Use a passing, aligned DKIM signature for DMARC when the ESP uses an unrelated bounce domain. SPF must still pass wherever the receiver requires it.
- Keep one SPF TXT record at each domain that publishes SPF, with every required sender in that record.
Why ESPs recommend unnecessary SPF includes
Legacy documentation is one source of unnecessary SPF instructions. A platform can move to CNAME-based domain authentication, add custom DKIM, change how bounce domains work, and still have old articles copied across blogs, help centers, and sales enablement pages. Once a short instruction such as "add this SPF include" gets repeated enough times, customers treat it as a permanent requirement.
Another source is confusion between SPF authentication and DMARC alignment. A non-technical user sees their brand in the From address and assumes SPF must be placed on that same brand domain. In many ESP setups, the actual SPF check happens against an ESP-controlled bounce domain. The visible From domain can pass DMARC through aligned DKIM without adding every ESP include to the root SPF record.
Mailchimp domain authentication settings with DKIM CNAME records.
Generic DNS checklists also reduce support time because every customer receives the same instruction. That approach breaks down when the platform has several sending modes or lets customers choose between an ESP-controlled Return-Path and a custom Return-Path. The required DNS then depends on the selected sending path.
The key misunderstanding
SPF checks whether the sending server's IP address is authorized for the SMTP MAIL FROM domain. It does not authenticate the visible From address by itself. DMARC uses an SPF pass only when that authenticated domain meets the configured relaxed or strict alignment mode for the visible From domain.
How Sender ID created outdated SPF advice
Some legacy ESP instructions were written to satisfy both SPF and Sender ID. Sender ID evaluated a message-header identity associated with the apparent sender, while SPF evaluates the SMTP envelope identity. Sender ID is obsolete, but the customer-domain SPF steps written for it survived in setup articles and support scripts.
For years, publishing an ESP include at the visible From domain appeared to cover both systems. Under current SPF and DMARC processing, that include does not create SPF alignment when the ESP still uses an unrelated Return-Path domain. A custom Return-Path under your domain can provide relaxed SPF alignment, while aligned DKIM can pass DMARC without it.
How SPF actually gets checked
Every email has more than one domain in play. The visible From domain is what the recipient sees. The SMTP Mail From domain is the envelope sender used during the SMTP transaction and becomes the Return-Path after delivery. DKIM has its own signing domain, shown as the d= domain in the signature. DMARC uses the SPF result for the MAIL FROM identity. When MAIL FROM is empty, SPF derives that identity as postmaster at the HELO domain.
Visible From domain
This is the brand domain a recipient sees in the email client. It is the domain DMARC protects.
- newsletter@example.com is the address shown in the inbox.
- A passing SPF or DKIM domain must meet DMARC identifier alignment with this domain.
SMTP Mail From domain
This is the bounce domain checked by SPF. It is often owned by the ESP or delegated through a subdomain.
- bounces.esp-domain.example is an example bounce domain that handles delivery errors.
- The receiving server checks this domain's SPF policy against the sending IP address.
Adding an ESP include to the root SPF record does not affect mail checked against an unrelated ESP bounce domain. SPF does not automatically inherit a parent domain's record. A subdomain can reference another policy explicitly with include or redirect. An unnecessary root include adds lookup cost only on evaluation paths that reach it, including other mail streams using the root policy.
Header clues to inspect
From: Brand Newsletter <news@example.com> Return-Path: <bounce@esp-bounces.example> Authentication-Results: mx.example; spf=pass smtp.mailfrom=esp-bounces.example; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
In that example, SPF passed for the ESP bounce domain. DKIM passed and aligned for example.com, so DMARC passed for the visible From domain. Adding the ESP to example.com's SPF record would not improve that message. Use the Authentication-Results added by the receiving mailbox, and test direct delivery before forwarding changes the envelope sender.
Decision path for adding an ESP SPF include based on the Return-Path domain.
Why bulk senders still need SPF
Passing DMARC through aligned DKIM does not remove a receiver's separate SPF requirement. Gmail's bulk sender requirements require both SPF and DKIM authentication for senders sending at least 5,000 messages a day to personal Gmail accounts. Only one authenticated domain needs DMARC alignment.
With an ESP-controlled Return-Path, the ESP can provide an SPF pass using its own domain while your DKIM signature provides DMARC alignment. A root-domain include cannot repair an SPF failure for an unrelated ESP MAIL FROM domain.
- Check that a directly delivered message has spf=pass for the actual smtp.mailfrom domain and a passing DKIM signature that meets DMARC alignment.
- If SPF fails for the ESP's bounce domain, check the sending mode with the ESP. If a custom MAIL FROM domain fails, check the DNS setup at that exact hostname.
When an ESP SPF include is needed
SPF authorizes sending servers for a specific envelope sender domain. Place authorization at the domain the ESP actually uses, following its current custom MAIL FROM instructions.
|
|
|
|---|---|---|
ESP-controlled Return-Path | ESP's bounce domain | Verify SPF passes there; no customer root include. |
Custom Return-Path | Exact bounce subdomain | Use the specified TXT record or CNAME. |
Own relay | Actual MAIL FROM domain | Authorize the sending IPs or required include. |
Non-sending SPF identity | Exact domain | Use v=spf1 -all after checking MAIL FROM and HELO use. |
SPF placement by sending setup
A custom bounce subdomain changes the answer. If an ESP specifies a CNAME for a bounce hostname such as bounce.example.com, do not also publish an SPF TXT record at that name. The ESP publishes the SPF policy at the CNAME target, and receivers follow that alias. If the ESP instead asks for a direct TXT record, publish it at the custom bounce subdomain it specifies. A DKIM CNAME at a selector._domainkey hostname does not configure a custom Return-Path. Keep subdomain SPF records separate from root-domain SPF. With default aspf=r, bounce.example.com and example.com have relaxed SPF alignment; aspf=s requires an exact domain match.
Transactional and marketing products from the same company can use different authentication flows. One product can keep an ESP-controlled Return-Path, while another requires a custom MAIL FROM domain. Some platforms use CNAME-based domain authentication so they can manage the SPF target. The right answer follows the sending path, not the vendor name.
SPF at a non-sending domain
v=spf1 -all
SPF at a custom bounce subdomain
v=spf1 include:esp-bounces.example -all
These records are illustrative; replace the example include with the ESP's documented value. The -all mechanism produces SPF fail for unmatched IPs; the receiving server decides message handling. It does not disable incoming mail, and a root-domain policy does not automatically cover subdomains.
If you are unsure whether an include is active, send a real message and read the headers before touching DNS. SPF should be changed because the message path requires it, not because a generic setup article says every customer needs the same include.
Duplicate SPF records and DNS lookup limits
Adding a second SPF TXT record for one ESP makes the domain's SPF policy invalid. Receivers that find more than one v=spf1 record at the same name return permerror. Other TXT records are allowed. Multiple quoted strings inside one TXT record still form one SPF record; the 255-octet limit applies to each string, not the whole policy.
Bad: two SPF records at the same domain
example.com TXT v=spf1 include:_spf.mailbox-provider.example -all example.com TXT v=spf1 include:_spf.esp-provider.example ?all
Merging the records is not automatically the fix. If the ESP include is unnecessary, merging it into the main record hides the visible error but keeps the unneeded authorization and extra lookups. This commonly happens when old setup guidance makes an include look required for the visible From domain.
Better: keep only required senders
example.com TXT v=spf1 include:_spf.mailbox-provider.example -all
The SPF lookup limit is another reason to remove unnecessary ESP includes. The SPF evaluator permits at most 10 evaluated DNS-querying terms across include, a, mx, ptr, exists, and redirect. If evaluation reaches an eleventh term, SPF returns permerror. Terms after an earlier match are not evaluated. The initial SPF TXT lookup is outside this 10-term budget; ip4, ip6 and all add no DNS-querying terms.
SPF lookup budget
The 0-5 and 6-9 bands are review suggestions; 10 is the protocol limit. Nested evaluated terms share that budget.
Healthy
0-5
Simple evaluation with room for a real sender change.
Tight
6-9
Changes need testing before publication.
Limit
10
The maximum permitted during evaluation.
Failing
11th
The eleventh evaluated term returns permerror.
SPF receivers should also limit void lookups to two. A void lookup returns NXDOMAIN or a successful DNS response with no answers. Broken or stale includes can therefore produce permerror before evaluation reaches the 10-term limit.
If a needed include pushes the record near the limit, use SPF flattening carefully, with refreshes when provider IP ranges change, or move to hosted SPF management. If an include is not needed, delete it instead of flattening around it. The cleanest record authorizes only the senders that actually use that domain in SPF.
Do not exceed 10 evaluated terms
The 10-term limit is mandatory. If SPF processing reaches more than 10 DNS-querying mechanisms or modifiers, the receiver returns permerror. An unnecessary ESP include can also contain nested includes that consume the same shared budget.
How to decide what to remove
Use message headers and reports covering a full sending cycle before removing an ESP SPF include. Confirm which domain SPF checks and whether DKIM passes with DMARC alignment. Check that another mail stream, including one whose SPF policy references this record, does not need the include.
- Send representative messages from every active sending mode, including infrequent transactional mail.
- Read the MAIL FROM domain in Return-Path and the receiving mailbox's trusted Authentication-Results. Start with direct delivery.
- Confirm dkim=pass and check the signing domain against the visible From domain using the configured DMARC alignment mode.
- Map every SPF include to a real sender, and check documented include or redirect references to the policy you plan to edit.
- Save the original SPF value and TTL, then remove only includes confirmed unnecessary across the affected sending paths.
After each change, validate the record syntax and lookup count. A focused SPF checker is useful here because it catches multiple SPF records, lookup overflow, syntax mistakes, and weak mechanisms before the change causes live mail failures.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If the record already sits close to the 10-term limit, do not treat a vendor's include as harmless. A single include can hide several nested terms. That is how a record that looked fine in a DNS editor turns into a receiver-side SPF failure.
For a broader check across SPF, DKIM, DMARC, and DNS health, run a domain health check after the SPF cleanup. Check DKIM with selectors taken from real messages; a domain-only lookup cannot establish whether every sending service has a working DKIM key.
Save the original record before removing an include. After the previous DNS TTL expires, test every affected sending mode and review subsequent DMARC aggregate reports over a full sending cycle, including infrequent mail. Check SPF as well as DMARC, and restore the saved record if legitimate mail loses required authorization.
How Suped supports SPF cleanup
Manual header checks work for one sender. They do not scale well once a domain uses marketing mail, transactional mail, helpdesk mail, finance systems, and employee mail. Suped is our DMARC and email authentication platform for keeping that setup visible over time.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
In Suped, compare each sending source's SPF and DKIM results before and after an SPF change. DMARC aggregate reports show receiver-reported authentication results, but do not identify which individual SPF include matched.
When SPF is required and DNS access is slow or split across teams, Suped's Hosted SPF gives teams a managed record and a controlled way to add or remove senders without opening a DNS change every time. That is useful when an old ESP include needs to come out but another sender still needs authorization.
Monitor after SPF changes
- Review authentication failures by sending source and confirm which domain SPF checked.
- Allow for DMARC report delivery delays; aggregate reports do not show every message immediately.
- Record who owns each SPF policy and which active sender needs each include.
- Keep the existing DMARC enforcement policy while validating SPF cleanup; assess policy changes separately.
Common ESP setups
The confusing part is that the same ESP category contains several valid setups. Marketing email often uses an ESP-controlled Return-Path by default. A transactional product can use a different flow with a custom MAIL FROM domain. Some platforms use CNAME-based domain authentication that lets the platform manage target record changes. The right SPF decision depends on the configured sending mode.
|
|
|
|---|---|---|
Marketing ESP | Often no root | Return-Path |
Transactional ESP | Sometimes custom | MAIL FROM |
Dedicated IP | Depends | Bounce domain |
No-send domain | SPF fail for all IPs | Any mail |
Examples of why advice differs
The provider name is not enough evidence. The message headers tell you whether SPF was checked against your domain, a subdomain, or the ESP's own domain. For cleanup work, pair that evidence with DMARC aggregate data so an include used by another legitimate sender does not get removed.
If the argument is only "the ESP says to add it," check whether the article covers the exact product, sending mode, and bounce-domain configuration. Also check whether the SPF lookup limit already leaves no room for an include that is not doing work.
How to explain the SPF decision
A client explanation
SPF checks whether a sending server is authorized for the bounce domain. If the ESP uses its own bounce domain, it manages SPF there. Our domain can pass DMARC through a passing, aligned DKIM signature. Adding the ESP to our root SPF record does not improve that message and can consume lookup budget for our other mail.
