The SPF includes a mechanism that is an SPF authorization method that delegates sender validation to another domain’s SPF record. When an SPF record contains an include: statement, receiving mail servers query the referenced domain’s SPF record during SPF evaluation to verify whether the sending IP address is authorized. This is commonly used in environments where multiple platforms, such as email service providers, CRMs, ticketing systems, and cloud communication tools, send mail from the same domain.
What Is the SPF Include Mechanism?
In SPF syntax, the include: mechanism delegates sender validation to a referenced domain’s SPF record. When a receiving mail server encounters an include: statement, it performs an additional DNS lookup against that domain’s published SPF policy and evaluates whether the sending IP address is authorized there.
For example:
v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all
In this case, the domain owner authorizes Microsoft 365 and Google Workspace to send email on behalf of the domain by referencing their SPF records directly.
If the sending IP address matches the SPF policy published by the included domain, the include evaluation returns a pass result. If no match is found, SPF evaluation continues with the remaining mechanisms in the record.
The include: mechanism does not copy or merge another SPF record into the current one. Instead, it instructs the receiving mail server to recursively evaluate the referenced SPF policy during authentication.
How the SPF Include Mechanism Works Step by Step
When a receiving mail server processes an SPF record, it evaluates every mechanism in sequence to determine whether the sending IP address is authorized to send mail for the domain. If the record contains one or more include: statements, the server must recursively query additional SPF records as part of the evaluation process. This lookup chain continues until SPF returns a final authentication result or reaches the lookup limit defined in RFC 7208.
1. A receiving mail server initiates an SPF check
When an email message is received, the destination mail server starts SPF evaluation by retrieving the sender domain’s SPF record from DNS.
For example:
v=spf1 include:_spf.examplevendor.com ip4:192.0.2.10 ~all
The server evaluates each mechanism in sequence to determine whether the sending IP address is authorized to send mail for the domain.
2. The server encounters an include: mechanism
When the SPF evaluator reaches an include: statement, it performs an additional lookup against the referenced domain’s SPF record.
For example:
include:_spf.examplevendor.com
This tells the receiving server to retrieve and evaluate the SPF policy published by _spf.examplevendor.com.
3. The referenced SPF record is evaluated
The receiving server checks whether the sending IP address matches any authorized mechanism inside the included SPF record.
Example referenced record:
v=spf1 ip4:198.51.100.0/24 include:_spf.mailprovider.net -all
If the sending IP matches one of the authorized ranges or mechanisms, the include evaluation returns a pass.
If the sending IP does not match, SPF processing continues with the remaining mechanisms in the original SPF record.
4. Nested include: statements trigger additional lookups
Included SPF records can contain their own include: mechanisms. This creates a recursive DNS lookup chain during SPF evaluation.
Example:
v=spf1 include:_spf.vendor-a.com include:_spf.vendor-b.com ~all
If either referenced record contains additional nested includes, the receiving server must continue querying those domains as part of SPF processing.
Each include: mechanism counts toward the SPF DNS lookup limit defined in RFC 7208.
5. SPF evaluation stops after a final result
SPF evaluation ends when a mechanism produces a final result or when processing returns an error, such as PermError.
When to Use Include in an SPF Record
Organizations use the include: mechanism when multiple third-party platforms send email on behalf of the same domain. This commonly includes email marketing providers, CRMs, customer support platforms, ticketing systems, cloud communication services, and internal business applications.
Instead of manually maintaining large lists of IP addresses, administrators can reference the SPF policies published by those providers directly within their own SPF record. This allows authorized sending infrastructure to stay aligned with the provider’s published SPF configuration as their infrastructure changes over time.
A typical enterprise SPF record may include several authorized sending sources simultaneously:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net ~all
In multi-sender environments, SPF configuration becomes an operational governance task rather than a one-time DNS update. Each additional sender increases SPF evaluation complexity and contributes to the total DNS lookup count.
Before adding a new include: statement, administrators should review the existing SPF record structure, nested lookup depth, and overall lookup usage to avoid authentication failures caused by exceeding SPF processing limits.
Platforms such as EasyDMARC help surface observed sending sources from aggregate DMARC reporting data, so administrators can compare active mail sources against their SPF configuration.
SPF Record Multiple Include: Managing More Than One Sending Source
Most enterprise SPF records contain multiple include: statements because organizations rely on several platforms to send email from the same domain. Marketing automation systems, cloud email providers, customer support platforms, and transactional email services often all require SPF authorization simultaneously.
Example:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net ~all
Each include: is a mechanism that triggers at least one DNS lookup during SPF evaluation. In many cases, SPF records include additional nested includes, redirects, or DNS-resolving mechanisms that increase the total lookup count further.
RFC 7208 enforces a hard limit of 10 DNS-resolving mechanisms during SPF processing. This includes:
- include
- a
- mx
- ptr
- exists
- redirect
If SPF evaluation exceeds this limit, the receiving mail server returns a PermError result. Depending on the recipient infrastructure and mail policy enforcement, legitimate email may fail SPF authentication as a result.
This is not an uncommon edge case in modern email environments. Organizations frequently accumulate additional sending services over time without restructuring existing SPF policies, which can create deeply nested SPF lookup chains.
Administrators managing complex SPF records should regularly audit all active sending sources, remove unused include chains, and validate lookup depth before onboarding additional email platforms.
SPF PermError and the Invalid include: Mechanism Warning
In SPF evaluation, a PermError indicates that the receiving mail server encountered a permanent error while processing the SPF record. One common example is an SPF PermError triggered by an invalid or unresolvable include: mechanism.
This error typically appears when an include: statement references a domain that:
- does not exist
- has no valid SPF record
- contains invalid SPF syntax
- publishes a malformed SPF policy
Example:
v=spf1 include:invalid-domain.example ~all
In this scenario, the receiving server cannot successfully evaluate the referenced SPF policy, which causes SPF processing to return a permanent error.
This issue is different from the PermError triggered by exceeding the 10 DNS lookup limit. The lookup-limit error occurs during SPF recursion depth evaluation, while this type of PermError is usually tied to invalid SPF syntax or broken include targets.
Before publishing SPF changes, administrators should validate every referenced include: domain to confirm that the target SPF record exists and can be resolved correctly.
Using an SPF checker helps identify invalid include chains, syntax issues, and SPF evaluation errors before deployment.
How EasyDMARC Helps You Manage SPF Include at Scale
Managing SPF includes chains across multiple business systems becomes increasingly difficult as organizations add new sending sources over time. Marketing platforms, internal applications, cloud email providers, and support tools can all contribute to SPF complexity and DNS lookup growth.
EasyDMARC provides visibility into how these sending sources interact with SPF authentication policies. The platform analyzes aggregate DMARC reporting data to surface active sending services associated with a domain. Administrators can then compare observed sending sources against their SPF configuration to identify gaps or unauthorized senders.
The dashboard displays observed sending sources and SPF alignment results from aggregate DMARC report data.
EasyDMARC also provides tools that support SPF configuration review and validation workflows:
- SPF Lookup helps validate SPF records, inspect include chains, and identify syntax or lookup-related issues.
- SPF Record Generator helps administrators build and structure SPF records for multiple authorized sending sources.
For organizations managing complex email ecosystems, the platform provides centralized reporting and configuration visibility that supports ongoing SPF governance and maintenance.
Frequently Asked Questions
The include: mechanism in an SPF record delegates SPF authorization to another domain’s SPF policy. When a receiving mail server encounters include:domain.com, it performs a DNS lookup against that domain’s SPF record and evaluates whether the sending IP address is authorized there. This approach is commonly used when third party services such as email marketing platforms, CRMs, or support systems send emails on behalf of your domain. The include: mechanism does not copy another SPF record into your own. Instead, it tells the receiving server to recursively evaluate the referenced SPF policy during SPF authentication.
There is no fixed limit on the number of include: statements allowed in an SPF record itself. However, RFC 7208 limits SPF evaluation to a maximum of 10 DNS-resolving lookups during processing. Each include: mechanism counts toward that limit, and nested includes inside referenced SPF records also contribute to the total. If SPF evaluation exceeds the lookup threshold, the receiving server returns a PermError result. Organizations using multiple third party email platforms should regularly audit SPF lookup depth to avoid authentication issues caused by excessive include chains and recursive DNS lookups.
The spf permerror illegal mechanism include warning that usually appears when an include: statement references a domain with an invalid or unusable SPF configuration. This can happen if the referenced domain does not exist, publishes no SPF record, contains malformed SPF syntax, or returns an invalid response during evaluation. This issue differs from the PermError caused by exceeding the 10 DNS lookup limit. In this case, the receiving mail server cannot properly interpret or evaluate the included SPF policy. Administrators should validate all included targets before publishing SPF changes to avoid permanent SPF evaluation failures.
Using include: is typically recommended when third party services manage their own sending infrastructure and publish SPF records for customers to reference. This allows providers to update authorized IP addresses without requiring manual SPF changes on your side. Direct IP entries may be appropriate for internally managed mail servers or static sending infrastructure that rarely changes. In enterprise environments, SPF records often contain a combination of direct IP mechanisms and include: statements. Administrators should balance operational flexibility, DNS lookup usage, and long-term SPF maintainability when deciding how to structure SPF authorization policies.
Start by auditing your current SPF record to count all DNS-resolving mechanisms, including nested includes inside referenced third-party SPF records. Remove any include: statements for sending services your organization no longer uses. Where possible, consolidate multiple include: references from the same provider into a single authorized entry. For remaining services, check whether the provider offers a flattened or optimized SPF record that resolves fewer lookups. If lookup depth remains a concern after cleanup, SPF flattening tools can reduce recursive evaluation by substituting include chains with resolved IP ranges, though this requires ongoing maintenance as provider infrastructure changes. EasyDMARC’s SPF checker surfaces lookup depth and chain structure so administrators can identify which include: references are contributing most to the total count.
We’re glad you joined EasyDMARC newsletter! Get ready for valuable email security knowledge every week.
You’re already subscribed to EasyDMARC newsletter. Continue learning more about email security with us
