What Is SPF Include? How to Use It Safely in Your SPF Record
by
Last Updated: 12 min read
Key Takeaways
- The SPF include mechanism authorizes third-party senders by referencing their domain’s SPF record inside your own, eliminating the need to manually list every sending IP address.
- Every include statement triggers at least one additional DNS lookup. Exceeding the 10-lookup limit causes a PermError that fails SPF for all senders, including legitimate ones.
- SPF include supports DMARC only when the envelope domain also aligns with the From domain. A passing SPF check does not automatically satisfy DMARC alignment requirements.
- Enterprise IT and security teams managing multiple SaaS platforms, regions, and domains need a structured review workflow to keep SPF records within lookup limits as new senders are onboarded.
- For MSPs and MSSPs, SPF INCLUDE problems scale quickly across client environments, so centralized monitoring is what catches broken records before they cause delivery failures.
Quick answer: The SPF include mechanism lets a domain owner authorize a third-party sender by referencing that sender’s SPF record within their own DNS TXT record. When a receiving server evaluates your SPF record and encounters an include statement, it fetches and evaluates the referenced domain’s SPF record as part of the check. Because each include triggers at least one additional DNS lookup, you must keep the total number of DNS-querying mechanisms at or below 10 to avoid a PermError.
Your SPF record tells receiving mail servers which sources are allowed to send email on behalf of your domain. Once your organization starts using third-party platforms for marketing, transactional messages, CRM updates, or support emails, SPF management becomes harder to maintain manually. That is where the SPF include mechanism helps.
This guide breaks down what SPF include is, how it works, and how to handle multiple includes without breaking your record. It also covers how to keep everything aligned with DMARC, so your emails consistently reach the inbox.
Who Needs to Understand SPF Include?
SPF include matters most for IT teams, system administrators, cybersecurity advisors, and MSPs managing domains that send email through multiple third-party services. If your organization uses platforms such as a CRM, helpdesk, marketing automation tool, transactional email provider, or cloud mail service, your SPF record likely depends on one or more include mechanisms.
- Enterprise IT and security teams managing multiple SaaS platforms, regional senders, or domain portfolios
- System administrators responsible for DNS records and email deliverability
- MSPs and MSSPs managing SPF and DMARC across multiple client domains
- Cybersecurity advisors in regulated industries such as finance, healthcare, retail, and the public sector
What Is an SPF Record?
An SPF record, or Sender Policy Framework record, is a DNS TXT record that lists all the servers and IP addresses authorized to send email on behalf of a particular domain. When an email arrives, the receiving mail server checks the sending DNS records to verify that the email came from an authorized source. If the sending IP address matches an entry in the record, SPF passes. If it does not, SPF fails.
What SPF records cannot do alone
SPF mechanisms are foundational, but they have limitations worth understanding:
- It validates the envelope sender, not the visible From address that recipients actually see
- It breaks during email forwarding, so forwarded emails often fail SPF even when the original sender is legitimate
- It cannot on its own prevent domain spoofing at the From header level, which is where most phishing attacks target recipients
This is why SPF works best as part of a broader authentication setup that also includes DKIM and DMARC. Configuring all three protocols together gives the strongest level of email protection.
What Is SPF Include?
If SPF records are the rulebook for who can send email from your domain, the SPF include mechanism is how you bring in the rules written by someone else. It allows a domain owner to delegate sending authority to another domain by referencing that domain’s SPF record within their own. Instead of manually listing every IP address used by a third-party email service, you include their domain, and the receiving server fetches and evaluates their SPF record as part of your own.
Why SPF include exists
Modern email sending is rarely done from a single server. For enterprise IT and security teams, SPF complexity usually grows as new SaaS tools, regional marketing platforms, CRMs, helpdesks, and transactional email services are added over time. Each new sender must be authorized correctly, monitored continuously, and kept within SPF’s 10-DNS-lookup limit to avoid authentication failures and deliverability issues.
The SPF include mechanism solves this by letting you reference the third-party service’s SPF record directly. When the receiving server evaluates your SPF record and encounters an include statement, it fetches and resolves that external domain’s SPF TXT record as part of the validation process. If the included domain’s SPF policy returns a pass for the sending IP address, the include mechanism matches and SPF evaluation can pass for that sender. If not, the receiving server continues evaluating the rest of your SPF record.
What SPF include looks like in practice
A basic SPF include statement looks like this:
| v=spf1 include:thirdpartydomain.com ~all |
In this example, the receiving server looks up the SPF record for thirdpartydomain.com and evaluates it alongside the rest of your record. If the sending IP is authorized within that record, the email passes SPF for your domain. The include mechanism is indispensable for domains that outsource email sending or rely on multiple vendors, since the alternative is manually enumerating every IP address used by every service, which is impractical and prone to error.
How Does the SPF Include Mechanism Work?
Understanding the SPF include mechanism at a technical level helps you avoid the configuration mistakes that cause SPF to silently fail. Here is what happens when a receiving server evaluates an SPF record that contains include statements.
The SPF validation process
- When an email arrives at a receiving mail server, the server extracts the domain from the MAIL FROM address and performs a DNS lookup to retrieve that domain’s SPF TXT record. It then reads the record from left to right, evaluating each mechanism until it finds a match or reaches the end. When it encounters an include statement:
- The receiving server performs an additional DNS lookup to fetch the SPF TXT record of the included domain.
- It evaluates the included domain’s SPF record against the sending IP address.
- If the included domain’s SPF policy returns a pass result for the sending IP, the include mechanism matches and SPF evaluation can pass for that sender.
- If no match is found, the server continues evaluating the remaining mechanisms in the original record.
How includes count toward the DNS lookup limit
Each include statement in an SPF record triggers at least one additional DNS query. This matters because SPF validation is restricted to a maximum of ten DNS lookups per check. Every include, along with mechanisms like mx and a, counts toward this limit. If the included domain’s SPF record itself contains further includes, those count too, creating a chain of lookups that can quickly add up.
Exceeding the ten-lookup limit causes SPF to return a PermError, which receiving servers treat as an SPF failure. This can result in email rejections or emails landing in spam folders, even when the sending source is entirely legitimate.
SPF Record Syntax: How to Write an SPF Include Correctly
Getting the syntax right is non-negotiable. A single error in your SPF record syntax can cause the entire record to fail, regardless of how well everything else is configured.
The basic structure of an SPF record
| v=spf1 [mechanisms] [qualifier:all] |
- v=spf1 declares the SPF version and must appear at the start of every SPF TXT record
- mechanisms define the authorized sending sources, which can include IP addresses, domains via include, mx records, and more
- all is the catch-all mechanism that determines what happens to emails that do not match any listed source
SPF qualifiers at a glance
| Qualifier | Meaning | Example |
|---|---|---|
| + (default) | Pass, sender is authorized | +all or include: |
| - | Fail, sender is not authorized; reject | -all |
| ~ | Softfail, flag but usually deliver | ~all |
| ? | Neutral, no policy stated | ?all |
How to write an SPF include statement correctly
The correct syntax for an include statement is include:domain.com. Note that there is no space between include and the colon. A space causes a syntax error. Here is a complete example of an SPF record with multiple includes:
| v=spf1 include:sendgrid.net include:mailchimp.com ip4:192.168.1.1 ~all |
- sendgrid.net and mailchimp.com are authorized as third-party senders via include
- 192.168.1.1 is an individually authorized IP address
- ~all is a softfail, meaning emails from unauthorized sources are flagged but not outright rejected
Checklist: how to safely add a new SPF include
- Identify the new sending service and confirm its vendor-provided include domain.
- Retrieve your current SPF TXT record using an SPF lookup tool.
- Count the total DNS lookups, including nested lookups within included records.
- Add the new include: mechanism to your single SPF TXT record.
- Validate syntax with an SPF record generator or lookup tool.
- Publish the updated record and test authentication results via email headers.
- Monitor DMARC reports to confirm the new sender passes SPF alignment.
SPF Include vs Redirect: What Is the Difference?
The include mechanism and the redirect modifier both reference another domain’s SPF record, but they behave very differently. Using one when you need the other is a common configuration mistake that can silently break authentication.
The include mechanism authorizes senders listed in another domain’s SPF record while still allowing your SPF record to contain additional mechanisms. The redirect modifier, by contrast, tells the receiving server to use another domain’s SPF record as the full policy for your domain, replacing everything else in your record.
| Mechanism / Modifier | What It Does | Best Used When | Example |
|---|---|---|---|
| include | Adds another domain’s authorized senders to your policy while preserving your own mechanisms | You want to authorize a third-party sender while keeping your own SPF policy active | include:sendgrid.net |
| redirect | Replaces your entire SPF policy with the referenced domain’s SPF record | You want another domain’s SPF record to act as the sole policy for your domain | redirect=example.com |
| ip4 / ip6 | Directly authorizes a specific IP address or range; no DNS lookup | A sender’s IP range is static and well-documented | ip4:203.0.113.0/24 |
| a | Authorizes the A-record IP(s) of the current domain; one DNS lookup | Your web server also sends email | a |
| mx | Authorizes the IP(s) of the domain’s MX records; one DNS lookup | Your inbound mail server also sends outbound email | mx |
Common Mistake
Using both include and redirect in the same record. The redirect modifier is ignored whenever an all mechanism appears in the record, so the two do not combine the way people expect. For most multi-sender setups, include is the correct choice and redirect is left out entirely.
Common syntax mistakes to avoid
- Publishing more than one SPF TXT record for the same domain, which causes a PermError because receiving servers cannot determine which policy to apply
- Adding a space after the colon in an include statement
- Using incorrect qualifiers or mechanisms that conflict with each other
- Forgetting to end the record with an all mechanism
An SPF record generator builds a correctly formatted record from scratch, or you can run your existing record through an SPF lookup tool to check for errors before they cause deliverability issues.
SPF Mechanisms Compared: include vs a, mx, ip4, ip6, and all
Before editing a DNS TXT record, it helps to understand which SPF mechanism to use and when. Each mechanism serves a different purpose and has a different impact on your DNS lookup count.
| Mechanism | What It Authorizes | DNS Lookup? | Best Use Case | Common Mistake |
|---|---|---|---|---|
| include | Senders authorized in another domain’s SPF record | Yes, at least 1 per include, plus nested lookups | Authorizing third-party senders such as ESPs and CRMs | Adding too many includes and exceeding the 10-lookup limit |
| a | IPs resolved from the domain’s A record | Yes, 1 lookup | When your web server sends email | Confusing with ip4; a requires a DNS lookup |
| mx | IPs of the domain’s MX records | Yes, 1 lookup per MX record | When your inbound server also sends outbound email | Underestimating how many MX lookups count |
| ip4 / ip6 | A specific IPv4 or IPv6 address or CIDR range | No | Senders with static, well-documented IP ranges | Using it when the provider changes IPs, causing stale records |
| all | Catch-all for any IP not matched earlier | No | Must appear at the end of every SPF record | Omitting it, or placing it before other mechanisms |
| redirect | Delegates the entire SPF policy to another domain | Yes, 1 lookup | Centralizing policy management to one authoritative domain | Using it with all in the same record, which causes redirect to be ignored |
SPF Multiple Include Rules and DNS Lookup Limits
Using multiple SPF includes is common and often necessary, but it introduces complexity that needs to be managed carefully. Here is what you need to know about handling an SPF record with multiple includes.
Why multiple includes are needed
Most organizations send email through more than one platform. A typical setup involves a primary mail server for internal and outbound email, a transactional email service for order confirmations and notifications, a marketing platform for newsletters and campaigns, and a CRM or helpdesk tool for customer communications. Each of these needs to be authorized in your SPF record, and the most practical way to do that is through include statements referencing each provider’s SPF record.
Why MSPs need to monitor SPF includes carefully
For MSPs and MSSPs, SPF include problems scale quickly across client environments. One client may add a new email marketing tool, another may change CRMs, and a third may unknowingly publish multiple SPF records. Without centralized visibility, these changes often become support tickets only after email delivery starts failing. A centralized SPF and DMARC management platform helps MSPs identify broken records, unused includes, lookup-limit risks, and authentication failures across all client domains from one dashboard, reducing reactive troubleshooting.
Why multiple SPF includes can exceed the 10-lookup limit
Each include statement triggers at least one DNS lookup, and some third-party SPF records themselves contain further includes, adding more lookups on top. By the time you have authorized four or five platforms, you may already be approaching or exceeding the ten-lookup limit. When the limit is exceeded, the receiving server returns a PermError and treats the email as an SPF authentication failure.
Example: how visible includes become more than 10 total lookups
| Mechanism in your record | Direct lookups | Typical nested lookups | Running total |
|---|---|---|---|
| include:_spf.google.com | 1 | 2 | 3 |
| include:sendgrid.net | 1 | 2 | 6 |
| include:salesforce.com | 1 | 1 | 8 |
| mx | 1 | 1 | 10 |
| include:mailchimp.com (added later) | 1 | 1 | 12, PermError triggered |
Three visible includes can easily become more than ten total lookups once nested includes within the referenced records are counted.
How Many SPF Includes Can One SPF Record Have?
There is no hard limit on the number of include statements you can write in an SPF record. However, all DNS-querying mechanisms combined, including include, a, mx, exists, and redirect, must not trigger more than 10 DNS lookups in total during evaluation. This limit includes nested lookups within included records.
In practice, most domains can safely use between three and five include statements before approaching the limit, depending on how many nested lookups each referenced record triggers. Adding a sixth or seventh include for a provider whose own SPF record contains multiple nested includes can push the total beyond 10 and cause a PermError, even though the visible record appears short. An SPF flattening tool counts total lookups and resolves include chains before you publish any record change.
How to stay within the DNS lookup limit
- Audit your current SPF record and count the total number of DNS lookups it triggers, including nested lookups within included records
- Remove any include statements for services you no longer use
- Where possible, replace include mechanisms with direct ip4 or ip6 entries for services whose IP ranges are static and well-documented
- Use SPF flattening to automatically resolve include chains and replace them with direct IP addresses, reducing the total lookup count
- Review your record whenever you add or remove a sending platform
One SPF record per domain, always
A critical rule that applies regardless of how many includes you are managing: never publish more than one SPF TXT record for the same domain or subdomain. Multiple SPF records cause an SPF PermError because receiving servers cannot determine which policy to apply, so everything must be consolidated into a single record. If you send from subdomains, each subdomain needs its own separate SPF TXT record.
SPF Include Examples for Common Email Sending Setups
The following examples illustrate correct SPF include syntax for typical multi-platform setups. Always verify the exact include domain in your provider’s documentation before publishing, and validate any new record with an SPF record lookup tool before publishing to DNS.
Single mail provider only
| v=spf1 include:_spf.google.com ~all |
Mail provider plus transactional email service
| v=spf1 include:_spf.google.com include:sendgrid.net ~all |
Mail provider, marketing platform, and CRM (watch the lookup count)
| v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ip4:203.0.113.10 ~all |
Invalid examples
Two records that will fail, with the reason:
| v=spf1 include: sendgrid.net ~all <- INCORRECT (space after colon) v=spf1 include:sendgrid.net <- INCORRECT (missing all mechanism) |
Common SPF Include Mistakes and How to Avoid Them
SPF includes are powerful but unforgiving. A single misconfiguration can cause authentication failures across your entire email stream, and the frustrating part is that many of these mistakes do not trigger an obvious error. Whether you are setting up SPF for the first time or auditing an existing record, these are the errors to watch for.
| Mistake | What Happens | How to Avoid It |
|---|---|---|
| Publishing multiple SPF TXT records for one domain | SPF fails immediately with a PermError, regardless of content | Consolidate everything into a single SPF TXT record per domain or subdomain |
| Exceeding the ten DNS lookup limit | Receiving servers return a PermError and treat the email as an SPF failure | Audit regularly, remove unused includes, and use SPF flattening where needed |
| Not updating SPF when adding new senders | Emails through the new platform fail SPF authentication | Update your SPF record every time you onboard a new email service provider |
| Ignoring subdomain requirements | Emails from subdomains fail SPF because the parent record does not cover them | Publish a separate SPF TXT record for each sending subdomain |
| Incorrect syntax such as spaces after the colon | The entire record becomes invalid and SPF fails for all senders | Validate your record with a lookup tool after every change |
| Including services you no longer use | Unnecessary lookups consume your DNS query budget | Regularly audit includes and remove platforms you no longer send through |
| Assuming SPF covers DMARC automatically | SPF may pass but DMARC still fails if the envelope domain does not align | Configure DKIM alignment as a fallback and review DMARC alignment settings |
| Using include when redirect was intended | Policy behaves differently than expected; your own mechanisms stay active | Understand the difference between include and redirect before editing |
| Adding duplicate include statements | Wastes DNS lookups and may push the record over the limit | Each include domain should appear only once in your record |
SPF Evaluation Results: Pass, Fail, Softfail, Neutral, TempError, and PermError
Understanding what each SPF result means helps you diagnose authentication failures quickly. The table below covers every outcome a receiving server can return after evaluating an SPF record.
| Result | Meaning | Common Cause | Recommended Action |
|---|---|---|---|
| Pass | Sending IP is authorized | IP matches an authorized mechanism in the record | No action needed; verify DMARC alignment |
| Fail | Sending IP is explicitly not authorized; email should be rejected | IP does not match and record ends with -all | Add the sender’s include or IP to the record |
| Softfail | Sending IP is probably not authorized; email may still be delivered | IP does not match and record ends with ~all | Review missing senders; consider moving to -all once confident |
| Neutral | No policy statement about the sending IP | Record ends with ?all or no all mechanism | Define a clear policy; add ~all or -all |
| None | No SPF record found for the domain | Missing SPF TXT record in DNS | Create and publish an SPF TXT record with a generator |
| TempError | Temporary error during evaluation; retry later | DNS timeout or transient DNS failure | Monitor for recurrence; check DNS provider reliability |
| PermError | Permanent error; SPF evaluation cannot complete | Syntax error, multiple SPF records, or more than 10 DNS lookups | Fix syntax, consolidate records, or reduce lookups with flattening |
SPF Include and DMARC Compliance
SPF includes do not operate in isolation. How you configure them has a direct impact on your DMARC compliance, and understanding the relationship between the two is essential for maintaining consistent deliverability.
For regulated industries such as finance, healthcare, education, retail, and the public sector, SPF include hygiene is not only a deliverability concern. It supports broader email authentication requirements tied to Google and Yahoo sender rules, Microsoft authentication expectations, PCI DSS, GDPR-aligned security controls, and internal risk management programs.
How SPF fits into DMARC
DMARC builds on top of SPF and DKIM to give domain owners control over how their email is handled when authentication fails. For an email to pass DMARC, at least one of the following must be true:
- SPF passes and the envelope domain aligns with the From domain
- DKIM passes and the DKIM signing domain aligns with the From domain
This means even a correctly configured SPF record with all the right includes is not enough on its own. SPF alignment must also pass, meaning the domain in the return path must match the From domain according to your DMARC alignment settings.
How SPF include affects alignment
When a third-party sender uses their own domain in the return path, their include may be present in your SPF record and SPF may technically pass for their domain, but it will not align with your From domain. DMARC still fails on the SPF check in this scenario. Configuring the third-party service to use a custom return path under your domain, or ensuring DKIM alignment is in place as a fallback, is essential.
Why SPF alone is not enough
SPF, DKIM, and DMARC are designed to work together as core email security controls. SPF validates the sending source but breaks during forwarding. DKIM signs the message itself and survives forwarding. DMARC ties both together and gives you visibility and control over what happens when either fails. Configuring all three is the only way to build a resilient email authentication setup.
Setting up DMARC alongside SPF
If you have your SPF includes correctly configured but have not yet deployed DMARC, setting up DMARC is the logical next step. Start with a policy of p=none to monitor your email streams without affecting deliverability, then move to quarantine, and reject as your confidence in your authentication setup grows.
Manage SPF Includes and DMARC Alignment With PowerDMARC
SPF include management becomes difficult when your organization uses multiple third-party senders across departments, domains, and regions. A single unused include, nested lookup chain, or misaligned return-path domain can create authentication failures that are hard to detect manually.
PowerDMARC gives IT teams, security leaders, and MSPs centralized visibility into SPF, DKIM, and DMARC results across all sending sources. With automated SPF management, DMARC reporting, SPF analytics, hosted authentication services, and expert support, teams can prevent SPF lookup-limit failures, identify unauthorized senders, and maintain compliance with less DNS overhead.
Organizations use PowerDMARC to consolidate SPF management, monitor authentication failures, and identify unauthorized sending sources before they affect deliverability.
Frequently Asked Questions
How many SPF includes can I have?
There is no fixed limit on include statements, but all DNS-querying mechanisms together must stay under 10 lookups, counting nested lookups inside referenced records. Most domains manage three to five includes safely before flattening is needed.
What is the difference between include and redirect?
include adds another domain’s senders while keeping your own mechanisms active. redirect replaces your entire policy with another domain’s record. redirect is ignored if an all mechanism is present, so the two do not mix.
Why does my SPF pass but DMARC still fail?
SPF can pass for a third-party sender’s own domain while failing to align with your From domain. DMARC needs alignment, so configure a custom return path under your domain or rely on DKIM alignment as a fallback.
What causes an SPF PermError?
Three common causes: exceeding the 10-lookup limit, publishing more than one SPF record for a domain, or a syntax error such as a space after include:. All three fail SPF for every sender until fixed.
Can I have one SPF record for multiple subdomains?
No. Each sending subdomain needs its own SPF TXT record. The parent domain’s record does not cover subdomains, so mail from an unconfigured subdomain fails SPF.
How do I reduce the number of SPF lookups?
Remove includes for unused services, replace static-IP senders with direct ip4 or ip6 entries, and use SPF flattening to resolve include chains into direct IPs. Audit whenever a sending platform is added or removed.
Does adding an include immediately affect email?
Only after DNS propagation, which can take up to 48 hours. Validate the record with a lookup tool before publishing, then confirm the new sender passes SPF alignment in your DMARC reports.
Domain & Email Security Expert at PowerDMARC
Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.
Latest posts by Yunes Tarada (see all)
- Happyfox DKIM, DMARC, and SPF Setup Guide - August 13, 2026
- Twikey SPF, DKIM, and DMARC Setup Guide - August 11, 2026
- What Is Whaling in Cyber Security? - August 7, 2026
