Managed service providers operate at the intersection of scale and complexity.

An SPF configuration mistake affecting one domain can create a deliverability problem. The same mistake embedded in a shared MSP configuration can affect dozens or hundreds of client domains at once.

A new sending service can push domains beyond SPF’s DNS lookup limit. A migration can leave legitimate sending IPs unauthorized. A forgotten third-party dependency can turn into an SPF permerror. And a manually flattened SPF record can quietly become stale as vendors change their infrastructure.

For MSPs and MSSPs, SPF therefore isn’t simply a DNS record to configure during onboarding. It is a dependency that needs to remain accurate as client environments change.

This guide examines five SPF configuration failures MSPs should detect before they become client-wide deliverability incidents.

SPF passing does not automatically mean DMARC passes.

SPF authenticates the RFC5321.MailFrom domain — commonly represented by the Return-Path. For SPF to satisfy DMARC, the authenticated SPF domain must also align with the domain in the visible RFC5322.From header. Alternatively, a valid and aligned DKIM signature can satisfy DMARC even when SPF does not pass.

I. 1. Exceeding SPF’s 10-Lookup Limit

What happens

SPF places a hard limit on DNS-query-causing terms evaluated during an SPF check.

Under RFC 7208, the following mechanisms and modifiers count toward the limit:

• include
• a
• mx
• ptr
• exists
• redirect

Nested evaluations count as well.

If SPF evaluation exceeds 10 DNS-query-causing terms, the SPF implementation must return permerror.

This becomes particularly dangerous in MSP environments because an SPF record that appears simple can depend on multiple nested records.

A client might authorize:

v=spf1 include:spf.msp-example.com include:marketing.example.net include:crm.example.net ~all

Those three visible includes do not necessarily represent only three SPF lookups. Each included record may contain additional DNS-query-causing mechanisms.

Why MSPs run into this

The lookup budget often grows gradually as clients add:

• Microsoft 365 or Google Workspace
• marketing platforms
• CRM systems
• help-desk platforms
• transactional email providers
• security gateways
• ERP or invoicing systems
• legacy services that were never removed

A domain may operate safely for years and then exceed the SPF limit immediately after one additional sender is authorized.

Deliverability impact

An SPF permerror means SPF cannot provide a successful authenticated result for that message.

If there is no valid aligned DKIM signature to satisfy DMARC instead, the message can fail DMARC.

The practical impact can include:

• SPF permerror appearing in authentication results
• DMARC failures where DKIM does not provide an aligned pass
• spam-folder placement
• rejection depending on receiver policy and other signals
• inconsistent delivery across mailbox providers

How MSPs should detect it

Do not count only the include: statements visible in the top-level SPF record.

Evaluate the complete SPF dependency tree, including nested:

include
a
mx
exists
redirect

The ptr mechanism also counts toward the limit, although RFC 7208 explicitly discourages its use.

For MSPs managing large portfolios, lookup validation should happen before every SPF change, not after delivery problems appear.

Example failure scenario

An MSP adds a new email security gateway to a shared SPF configuration.

The gateway introduces several additional DNS-query-causing terms through its own SPF dependencies.

Domains already close to the 10-term limit cross the threshold immediately.

Nothing about the clients’ applications changed. Their email continues to leave normally. But receiving systems evaluating SPF now return permerror.

One shared configuration change has become a multi-client authentication problem.

II. 2. The Sending Infrastructure No Longer Matches SPF

What happens

MSPs frequently centralize outbound email through:

• SMTP relays
• cloud email gateways
• security platforms
• transactional email infrastructure
• shared sending services

A client SPF record might authorize that infrastructure through an include:

v=spf1 include:spf.msp-example.com ~all

Problems begin when the infrastructure changes but the SPF authorization does not.

Typical causes include:

1. migrating to new sending IP addresses;
2. moving between data centers or cloud regions;
3. replacing an SMTP relay or security gateway;
4. introducing a new outbound provider;
5. routing only part of the client’s traffic through the new infrastructure; or
6. leaving old infrastructure authorized after migration.

Failure mode

SPF evaluates whether the connecting IP is authorized for the RFC5321.MailFrom domain.

If the current sending IP is not authorized by that domain’s SPF policy, SPF will not pass.

If there is also no aligned DKIM pass, DMARC fails.

That distinction matters:

SPF failure does not automatically equal DMARC failure.

DMARC can pass through either an aligned SPF pass or an aligned DKIM pass.

Deliverability impact

Infrastructure drift can create:

• SPF failures from otherwise legitimate senders
• DMARC failures when DKIM is unavailable, broken, or misaligned
• inconsistent delivery across different sending systems
• increased filtering
• rejection by some receiving systems
• client reports that only certain applications or message types are failing

How MSPs should detect it

Compare:

Observed sending IPs

against:

IP addresses currently authorized by SPF

DMARC aggregate reports are particularly useful here because they reveal infrastructure that is actually sending mail using the client’s domain.

For an MSP, the question should not simply be:

“Is the SPF record syntactically valid?”

It should also be:

“Does the SPF record authorize the infrastructure actually sending mail today?”

III. 3. The Subdomain Authentication Gap

What happens

One of the most persistent SPF misconceptions is that a parent domain’s SPF policy automatically applies to its subdomains.

It does not.

An SPF record published at:

example.com

is not automatically the SPF policy for:

bounce.example.com
support.example.com
billing.example.com

SPF policy is evaluated for the domain used as the SPF identity — normally the RFC5321.MailFrom domain.

For example, if a service sends using:

Return-Path: [email protected]

SPF evaluation concerns billing.example.com.

The SPF policy at example.com is not automatically inherited.

Failure mode

If the RFC5321.MailFrom domain has no applicable SPF record, SPF normally returns none.

That is different from fail, softfail, or permerror.

Because SPF has not produced an authenticated identifier, it cannot provide the aligned SPF pass required for DMARC.

DMARC may still pass if the message carries a valid DKIM signature whose signing domain aligns with the visible From domain.

Why MSPs encounter this

Subdomains are frequently introduced by third-party systems:

bounce.client.com
mail.client.com
billing.client.com
support.client.com
notifications.client.com

These may be used by:

• customer support platforms
• CRMs
• marketing platforms
• invoicing systems
• AWS SES
• transactional email providers
• application notification services

The root domain can therefore have perfectly valid SPF, DKIM, and DMARC while a separate sending path using a subdomain is incorrectly authenticated.

How MSPs should detect it

First identify the domains actually being used as RFC5321.MailFrom / Return-Path domains.

Then verify SPF for those domains.

For example:

dig TXT bounce.client.com
dig TXT billing.client.com
dig TXT notifications.client.com

The important question is not simply whether a subdomain exists.

It is whether that subdomain is being used as an SPF identity for outbound email and, if so, whether the corresponding SPF policy correctly authorizes the sender.

Example failure scenario

A client introduces a new transactional platform using:

bounce.client.com

as its Return-Path domain.

The MSP verifies SPF on:

client.com

and assumes the configuration is complete.

But bounce.client.com has no SPF policy.

SPF therefore cannot authenticate that sending identity. If the platform’s DKIM configuration is also missing or misaligned, DMARC fails.

The root-domain configuration was correct.

The sending identity was not.

IV. 4. The Third-Party SPF Dependency That Breaks

What happens

Modern SPF records commonly depend on third-party services:

v=spf1 include:spf.provider-a.example include:spf.provider-b.example ~all

Every include: creates an external dependency.

The domain owner is effectively relying on another organization to maintain valid SPF infrastructure.

Problems arise when:

1. a vendor retires an old SPF include;
2. an organization migrates between products;
3. the referenced domain disappears;
4. the vendor publishes an invalid SPF record;
5. a legacy service is shut down without the client’s SPF record being updated.

Failure mode

RFC 7208 defines specific behavior for include:.

If evaluation of the included domain produces none — for example because no SPF record exists there — the include evaluation produces permerror.

That means a broken third-party dependency can affect the SPF evaluation of the client’s domain even though nobody changed the client’s DNS record.

Deliverability impact

A broken dependency can cause:

• SPF permerror
• loss of an aligned SPF pass for DMARC
• DMARC failure when aligned DKIM does not pass
• inconsistent authentication across client portfolios
• sudden delivery problems with no obvious local DNS change

This is especially important for MSPs because the same third-party include may appear across many customer domains.

One external dependency can therefore create a correlated failure across the portfolio.

How MSPs should detect it

SPF dependencies should be monitored continuously.

MSPs should know:

• which vendors appear in client SPF records;
• which domains those vendors require;
• which clients depend on each vendor;
• whether those dependencies still resolve correctly; and
• whether their SPF contents have changed.

A DNS record being unchanged does not mean the effective SPF policy is unchanged.

Its dependencies may have changed underneath it.

V. 5. Static SPF Flattening Becomes Stale

What happens

SPF flattening is sometimes used to reduce DNS lookups.

Instead of keeping a third-party include:

v=spf1 include:spf.vendor.example ~all

the current IP addresses behind that include are resolved and placed directly into the SPF record:

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.0/24 ~all

Because ip4 and ip6 mechanisms do not count toward SPF’s 10-term DNS lookup limit, flattening can reduce lookup pressure.

But static flattening transfers responsibility for keeping those addresses current from the vendor to the domain administrator.

The problem

Third-party email providers can change their sending infrastructure.

They may:

• add IP ranges;
• remove IP ranges;
• expand into new regions;
• move infrastructure; or
• change underlying providers.

If the MSP copied the vendor’s IP addresses six months ago and never updates them, the flattened SPF record becomes a stale snapshot.

Failure mode

Mail originating from a newly introduced vendor IP may no longer match the flattened SPF record.

SPF then fails to authenticate that sending path.

Again, DMARC does not necessarily fail: a valid aligned DKIM signature can still produce a DMARC pass.

But the domain has lost one of its authentication paths.

Why this matters for MSPs

Static flattening can convert one operational problem — excessive DNS lookups — into another:

continuous synchronization of third-party sending infrastructure.

Across a large client portfolio, manually maintaining flattened records quickly becomes impractical.

Better operational approach

If flattening is used, it should be accompanied by continuous monitoring and automated synchronization.

The MSP should be able to detect when the authoritative SPF policy of an upstream provider changes and update the effective authorization accordingly.

Flattening should be treated as an actively managed process, not a one-time DNS change.

Why SPF Problems Become More Dangerous at MSP Scale

The underlying SPF protocol is the same whether an organization manages one domain or one thousand.

The operational risk is not.

MSPs introduce shared dependencies:

Shared SPF templates
        ↓
Shared sending infrastructure
        ↓
Shared third-party services
        ↓
Shared DNS automation
        ↓
Hundreds of managed domains

A mistake at the top of that chain can propagate across the portfolio.

That makes SPF governance as important as SPF configuration.

VI. What MSPs Should Document

1. SPF Dependency Inventory

Maintain a record of:

• every outbound email provider;
• its required SPF authorization;
• clients using that provider;
• associated Return-Path domains;
• nested SPF dependencies; and
• current DNS lookup consumption.

This makes it possible to understand the blast radius of a provider change.

2. Actual Sending Sources

DNS configuration alone does not show everything using a client’s domain.

Compare SPF authorization against observed sending infrastructure from authentication telemetry and DMARC aggregate reports.

Unknown sources should be investigated.

Legitimate sources may need authorization.

Unauthorized sources may indicate spoofing or an unapproved service.

3. Return-Path and Subdomain Mapping

Document the actual SPF identities used by each sending service.

For example:

Microsoft 365
From: client.com
Return-Path: client.com

Transactional Platform
From: client.com
Return-Path: bounce.client.com

Marketing Platform
From: client.com
Return-Path: marketing.client.com

This makes authentication and DMARC alignment issues much easier to diagnose.

4. SPF Change Control

Before deploying an SPF change, validate:

• total DNS-query-causing terms;
• nested includes;
• sending IP authorization;
• Return-Path domains;
• third-party dependencies;
• SPF syntax; and
• expected DMARC alignment.

For shared configurations, calculate which client domains will be affected before deployment.

5. Removal of Legacy Senders

SPF records tend to accumulate old services.

Every unnecessary authorization:

• increases complexity;
• can consume DNS lookups;
• expands the set of infrastructure authorized to send; and
• makes future troubleshooting harder.

Decommissioning a service should include removing its SPF authorization.

SPF Is Only One Part of DMARC

SPF should not be evaluated in isolation.

Under DMARC, the visible From domain must align with at least one successfully authenticated identifier.

In practical terms:

Aligned SPF PASS
        OR
Aligned DKIM PASS
        ↓
     DMARC PASS

If neither produces an aligned pass:

No aligned SPF PASS
        +
No aligned DKIM PASS
        ↓
     DMARC FAIL

This distinction is critical when troubleshooting deliverability.

An SPF error does not automatically mean DMARC failed.

Likewise, an SPF pass does not automatically mean DMARC passed if the authenticated SPF domain does not align with the visible From domain.

Current DMARC requirements are defined by RFC 9989, published in May 2026, which supersedes the original DMARC specification in RFC 7489.

How Skysnag Helps MSPs Manage SPF at Scale

Managing SPF manually becomes increasingly difficult as the number of clients, sending services, and DNS dependencies grows.

Skysnag’s MSP platform is designed to centralize and automate email authentication management across client environments.

VII. Multi-Tenant Management

Manage client domains through a centralized MSP environment rather than troubleshooting each domain independently.

This provides MSP teams with portfolio-level visibility into authentication configuration and sending activity.

VIII. Automated Sender Discovery

Skysnag identifies outbound sending sources so MSPs can understand which infrastructure is actually using client domains.

This helps distinguish legitimate but undocumented senders from unauthorized sources.

IX. SPF Hosting and Optimization

Skysnag provides automated SPF management and optimization designed to prevent DNS failures and reduce the operational risks associated with manually maintaining complex SPF configurations.

X. SPF Flattening and Drift Prevention

Where SPF optimization requires flattening, continuous management is critical.

Skysnag’s SPF hosting and optimization capabilities include automated flattening and drift prevention, reducing the risk that static authorization becomes stale as sending infrastructure changes.

XI. Centralized DMARC Analysis

DMARC aggregate data provides visibility into authentication results across sending sources.

Combined with centralized management, this allows MSPs to identify authentication problems without manually investigating individual mail systems.

XII. Complete Email Authentication Management

SPF is only one component of modern email authentication.

Skysnag allows MSPs to manage:

• DMARC
• SPF
• DKIM
• MTA-STS
• TLS-RPT
• BIMI

from a unified environment.

Key Takeaways

SPF has a hard 10-term DNS lookup limit.
Exceeding it results in permerror. Nested SPF dependencies count toward that limit.

SPF policies do not automatically inherit from parent domains.
MSPs need to understand the actual RFC5321.MailFrom domains used by their clients’ sending services.

A valid SPF record can still authorize the wrong infrastructure.
Configuration should be compared against actual sending sources.

Third-party SPF includes are external dependencies.
A vendor-side DNS change can affect client authentication without any change to the client’s own SPF record.

Static SPF flattening requires continuous maintenance.
Vendor infrastructure changes can make previously correct IP authorizations stale.

SPF failure is not automatically DMARC failure.
Aligned DKIM can independently satisfy DMARC.

At MSP scale, visibility matters as much as configuration.
Shared templates and infrastructure turn individual DNS mistakes into portfolio-wide operational risks.

XIII. Manage SPF Across Your Client Portfolio

SPF problems become harder to detect — and more expensive to correct — as the number of managed domains grows.

Skysnag gives MSPs and MSSPs centralized email authentication management, automated sender discovery, SPF optimization, DMARC visibility, and multi-tenant management designed for scale.

Prevent authentication drift before it becomes a client deliverability incident.

Explore Skysnag for MSPs