What Is SPF Include And How Do You Use It In Your SPF Record?

Your SPF record tells the world which servers are allowed to send email on behalf of your domain. But as soon as you start using third-party platforms to send email, things get complicated fast. At this point, a SPF include mechanism can help.

This guide breaks down what SPF include is, how it works, and how to handle multiple includes without breaking your record. Additionally, we cover how to keep everything aligned with DMARC, so your emails consistently reach the inbox.

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 doesn’t, SPF fails.

What SPF records can’t 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, meaning forwarded emails will 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 is strongly recommended for the best 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.

The SPF Include mechanism 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 simply 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.

Most organizations use a combination of their own mail server alongside third-party platforms for transactional emails, marketing campaigns, helpdesk tools, and CRMs. Each of these services sends email on your behalf from their own infrastructure, using IP addresses that are not yours to list directly.

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 sending IP address matches an entry in the included record, SPF passes.

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 will look up the SPF record for thirdpartydomain.com and evaluate 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 for different emailing needs. Without it, you would need to manually enumerate 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 of the record.

When it encounters an include statement, the following happens:

1. The receiving server performs an additional DNS lookup to fetch the SPF TXT record of the included domain
2. It evaluates the included domain’s SPF record against the sending IP address
3. If the IP matches an authorized entry in the included record, the include mechanism returns a pass result
4. 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 is important 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 is treated as an SPF failure by receiving servers. 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

All SPF records follow the same foundational structure:

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 don’t match any of the listed sources

Writing an SPF include statement

The correct syntax for an include statement is:

include:domain.com

Note that there is no space between include and the colon. A space will cause 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

In this record:

• 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 will be flagged but not outright rejected

Common syntax mistakes to avoid

• Publishing more than one SPF TXT record for the same domain. Multiple SPF records cause a DNS lookup loop that makes SPF fail entirely. You must consolidate everything into a single record per domain or subdomain
• 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

You can use PowerDMARC’s SPF record generator to build a correctly formatted record from scratch. Alternatively, run your existing record through an SPF record lookup tool to check for errors before they cause deliverability issues.

SPF Record With Multiple Includes: What You Need to Know

Using multiple SPF includes is common and often necessary, but it introduces complexity that needs to be managed carefully. Here is everything 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 might involve:

• 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
• A CRM or helpdesk tool for customer communications

Each of these services 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.

The DNS lookup limit problem

This is where multiple includes create risk.

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.

Here is a simplified example of how lookups add up:

• include:sendgrid.net = 1 lookup, plus any lookups within SendGrid’s own record
• include:mailchimp.com = 1 lookup, plus any within Mailchimp’s record
• include:salesforce.com = 1 lookup, plus any within Salesforce’s record
• mx = 1 lookup
• Total can easily reach or exceed 10

When the limit is exceeded, the receiving server returns a PermError and treats the email as an SPF authentication failure.

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 PowerDMARC’s SPF flattening tool that automatically resolve include chains and replace them with direct IP addresses, reducing the total lookup count
• Regularly 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 immediate failure and cannot be resolved by any receiving server. Everything must be consolidated into a single record.

If you send from subdomains, each subdomain needs its own separate SPF TXT record.

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 don’t 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 and exactly how to avoid them.

SPF Include and DMARC Compliance

SPF Include don’t 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 email deliverability.

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 that 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 won’t align with your From domain.

DMARC will still fail 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. 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 robust, 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.

Get Your SPF Include Right With PowerDMARC

Managing SPF Include is straightforward when you are working with one or two sending platforms. But as your email infrastructure grows, so does the complexity.

More platforms mean more includes, more DNS lookups, and more opportunities for something to break quietly in the background without you noticing until deliverability starts to drop.

PowerDMARC gives you the tools and visibility to stay ahead of that. It helps generate and validate your SPF record, and monitor alignment and authentication results across every sending source.

Hear it from a customer:

“PowerDMARC helped us consolidate 15 different email services into a single, optimized SPF record. Our email deliverability improved by 23% within the first month.” – IT Director, Fortune 500 SaaS Company

If you are ready to take control of your email authentication and make sure your SPF includes are doing exactly what they should, start your free trial.

FAQs

1. What happens if I exceed 10 DNS lookups in my SPF record?

If your SPF record exceeds 10 DNS lookups, it will result in a PermError, causing SPF authentication to fail completely. This can lead to legitimate emails being rejected or marked as spam. Use SPF flattening or macros to stay within the limit.

2. Can I include the same domain multiple times in my SPF record?

While technically possible, including the same domain multiple times is redundant and wastes DNS lookups. Each include statement should be unique and serve a specific purpose in your email authentication strategy.

3. How often should I review my SPF includes?

Review your SPF record quarterly or whenever you add/remove email services. Set up automated monitoring to detect unauthorized changes or service provider updates that might affect your authentication.

4. What’s the difference between ~all and -all in SPF records?

~all (softfail) suggests that emails from unauthorized sources should be marked as suspicious but still delivered. -all (hardfail) instructs receiving servers to reject emails from unauthorized sources completely. Most organizations start with ~all and move to -all after testing.

5. Can SPF includes affect email deliverability?

Yes, improperly configured SPF includes can significantly impact deliverability. Missing includes for legitimate services can cause emails to fail authentication, while too many includes can exceed DNS lookup limits and cause PermErrors.

• About
• Latest Posts

Yunes Tarada

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)

• Verified Mark Certificate vs Common Mark Certificate: Choosing the Right One - March 10, 2026
• Spam Confidence Level (SCL) -1 Bypass: What It Means and How to Handle It - March 4, 2026
• “Does Not Pass DMARC Verification and Has a DMARC Policy of Reject”: What It Means and How to Fix It - February 26, 2026