SPF include lets one SPF record reference another domain’s authorised sending sources. It is used when a service sends mail on behalf of a domain owner. Defenders must control every included domain, because too many includes can make records complex, exceed lookup limits and cause legitimate mail to fail SPF checks.
How SPF include works in practice
spf include is a delegation mechanism, not a blanket trust grant. A domain owner publishes an spf record that names other domains or services allowed to send mail on its behalf. When a receiver evaluates spf, it follows each include and checks the included domain’s SPF policy as part of the same authorization decision.
The practical benefit is delegation. A marketing platform, ticketing system, or cloud mail service can publish its own sender list, and the customer domain can reference it without copying every IP address into one record. That keeps SPF maintainable when the sending infrastructure changes, but it also means the domain owner inherits the hygiene of every included policy.
SPF include only helps if the referenced domain is authoritative and tightly controlled. If an included domain changes hands, drifts from the service actually in use, or accumulates too many nested lookups, SPF evaluation can become unreliable. The question is not just whether the include is syntactically valid, but whether it still represents the real set of approved senders for your domain.
Why SPF include is easy to mismanage
The main failure mode is policy sprawl. Each include can add more DNS lookups, and complex chains make it easier to hit SPF evaluation limits or to lose track of which service is actually authorised. In the worst case, a legitimate message fails authentication because the record is too deep, too nested, or simply no longer reflects the sending path.
Another common issue is overbroad delegation. If the included domain is shared across many customers, a mistake in that provider’s SPF record can affect everyone who references it. That is why DMARC, SPF and DKIM Guide is useful context: SPF include should be treated as part of a larger email authentication posture, not as a standalone configuration checkbox.
Misuse also shows up when teams add includes to solve a short-term delivery issue and never revisit them. Over time, those records become a dependency map of old vendors, pilot services, and forgotten subdomains. That creates avoidable fragility and makes later troubleshooting harder, especially when mail starts failing after an infrastructure change.
What defenders should check before relying on include
First, confirm that every included domain is owned, approved, or contractually governed in a way that matches the mail flow. SPF include is only as trustworthy as the sender governance behind it. If a service can send on your behalf, you should know which business process uses it, which domain it represents, and who owns that relationship.
Second, keep the record simple enough to survive operational change. Where possible, use a small number of well-understood includes rather than a long chain of delegated policies. If a vendor or platform offers a flatter SPF design, that is usually easier to maintain than a deeply nested structure, especially when multiple teams manage mail.
Third, validate the full authentication path after every sender change. Mail delivery problems often appear first as policy failures, but the root cause may be a new service, a changed envelope sender, or an include that no longer covers the actual outbound host. The point is to verify alignment between the record and the sending system, not just the record itself.
Risk and Threat Considerations
SPF include can create dependency risk because one domain’s mail permission now depends on another domain’s accuracy and stability. If the included policy is stale, overly broad, or nested too deeply, legitimate mail can fail or an unintended sender can remain authorised longer than intended.
Failure mechanism: An attacker or misconfigured service abuses an overprivileged or poorly maintained included policy, or defenders exceed SPF lookup limits and lose reliable enforcement, which weakens message authentication and can disrupt legitimate delivery.
Impact: Email spoofing resistance drops, trusted business mail may be rejected, and teams may lose confidence in SPF results when troubleshooting delivery problems or impersonation attempts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | SPF include governs which sending sources are authorised for mail flow. |
| Recommendation — Enforce approved mail-sending paths and revoke unauthorised relay routes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | SPF include is an access control decision for message-sending authority. |
| Recommendation — Define and maintain authorised senders for each domain. | ||
| CIS Controls v8 | CIS-5 — Account Management | SPF include depends on accurate ownership of services that can send as the domain. |
| Recommendation — Review and remove stale service senders and delegated mail paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SPF include grants sending authority to external mail services. |
| Recommendation — Apply formal approval and review for any delegated mail-sending authority. | ||
Practitioner Guidance
What to verify: Check that every include maps to a current, known sender relationship and that the resulting SPF evaluation stays comfortably within lookup limits after all nesting is resolved. If you cannot explain why a domain is included, remove or replace it.
Decision rule: If a service sends on behalf of the domain but does not need ongoing broad delegation, prefer the narrowest workable policy and revisit it whenever the service architecture changes. If a sender is temporary, treat the include as temporary too.
Practitioner takeaway: SPF include is useful when it reflects a real, governed sending dependency, but it becomes a liability when it is used to hide complexity or outsource policy ownership.