SPF glossary
What is the SPF include mechanism and how does it work?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
The include: mechanism delegates part of your SPF evaluation to another domain's record, include:_spf.google.com authorizes every server Google publishes, without you listing IPs yourself. It matches only when the included record returns pass. It's the standard way to authorize third-party senders like Google Workspace, Microsoft 365, or your ESP.
include: at a glance | |
|---|---|
| Tag | include (mechanism) |
| Valid values | include:<domain>: the domain whose SPF record gets evaluated |
| Default | None: if the included domain publishes no SPF record, the result is a permerror. |
| Where it goes | Between v=spf1 and the final all: typically one include per third-party email service. |
How include: works
include:_spf.google.com tells the receiver: fetch that domain's SPF record and evaluate the sending IP against it. If that evaluation returns pass, the include matches, and your record passes. Google, Microsoft, and every serious email provider publish an SPF record precisely so customers can include it. They maintain the IP ranges so you don't have to.
The name is misleading: include is a conditional match, not a textual include. If the included record returns fail, softfail, or neutral, your include simply doesn't match, evaluation moves on to your next term. An include of a record ending -all cannot fail your mail; that -all never becomes yours. But if the included domain publishes no SPF record at all, that's a permerror, and a single dead include breaks your whole record.
Each include costs one of the 10 DNS lookups allowed per evaluation, and nested includes count too. _spf.google.com itself contains three more includes, so “one include” quietly costs four lookups. Includes are the right tool for third parties; just budget for them.
Correct record vs common mistake
Correct
v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.10 -allThird parties authorized via include, your own fixed server via ip4, strict catch-all at the end.
Common mistake
v=spf1 include=_spf.google.com -allinclude takes a colon, not an equals sign. Written with =, it parses as an unknown modifier that receivers silently ignore. Google is quietly unauthorized and its mail starts failing.
Generate your SPF record
Build a correct SPF record for your domain. Add your senders, copy the TXT record. Free, no signup.
Who sends email for this domain?
Each service adds its documented include mechanism.
From your provider’s docs, e.g. spf.example-esp.com: commas or spaces between multiple. Some services (Klaviyo, HubSpot, Mailchimp Transactional) authenticate through their own CNAME records instead of a shared include, check their DNS settings page.
How should receivers treat everyone else?
Your SPF record
0/10 lookupsPublish as a TXT record at the domain root. One SPF record per domain: if one exists, merge into it instead of adding another.
yourdomain.com (or @)v=spf1 ~allClick the record to select all of it.
Record type: TXT · ip4/ip6 mechanisms don’t count against the 10-lookup limit.
After you publish
- Add the TXT record at your DNS host.
- Verify it with the free SPF checker.
- SPF alone doesn’t stop spoofing, pair it with DKIM and a DMARC policy. Generate one with the DMARC record generator.
Troubleshooting include:
| Issue | Likely cause | Fix |
|---|---|---|
| ESP mail passes SPF but fails DMARC | The ESP sends from its own bounce domain, so the SPF pass isn't aligned with yours | Turn on the ESP's custom return-path / bounce-domain option, then confirm alignment in the reports |
| Checker reports permerror after adding an include | The included domain publishes no SPF record, or the target name is misspelled | Verify the exact string from the provider's docs and confirm the target resolves to a v=spf1 record |
| 'Too many DNS lookups' after onboarding a new tool | Nested includes pushed the total over 10 | Count the full include tree, remove includes for tools you no longer use, and move fixed infrastructure to ip4/ip6 |
Why it matters for MSPs
Client records accumulate includes with every SaaS tool ever onboarded, and across 50–200 domains nobody prunes them. Each tenant's chain creeps toward the 10-lookup wall independently, and the failure mode is a silent permerror, the classic “SPF worked yesterday” ticket, times the whole fleet. Dead includes from cancelled tools are both wasted budget and a standing permerror risk.
Trusted by MSPs
“At implementation, 5 of 9 email authentication configuration checks showed issues. Today, all 9 are properly configured, reducing identified configuration issues from 5 to 0.”
DMARC software that does the work
Every include is a sender that has to actually pass and align, a pasted string proves nothing. Palisade identifies each source in a domain's DMARC reports and confirms it authenticates before tightening policy, across every client domain, without hand-auditing include chains tenant by tenant.
1 domain free up to 1,000 emails/month
Questions readers ask
Frequently asked questions
How many includes can I have in an SPF record?
As many as fit inside the 10-DNS-lookup limit, and nested includes count against it too. In practice that's a handful of providers; past that, records permerror.
What happens if an included domain's SPF check fails?
Nothing dramatic: the include just doesn't match, and evaluation continues with your next term. The included record's -all doesn't fail your mail. Only an included domain with no SPF record at all breaks yours (permerror).
Can includes be nested?
Yes: an included record can contain its own includes, and receivers follow the whole tree. Every level counts toward your 10-lookup budget, which is how a short-looking record ends up over the limit.
My ESP's include is in place. Why does DMARC still fail?
The ESP probably sends with its own bounce domain, so SPF passes for their domain, not yours, no alignment, no DMARC credit. Enable the ESP's custom return-path (bounce domain) feature so SPF aligns with your domain.