Last updated: July 2026

In short: The include mechanism in an SPF record imports the authorization policy of another domain. It is designed for allowing third-party services to send email on your behalf, but every check consumes DNS lookups.

When your emails originate not only from your primary mail server or hosting provider, but also from newsletter tools, CRM platforms, or cloud billing systems, you must authorize those sending paths in your SPF (Sender Policy Framework) record. The include mechanism is built exactly for this purpose.

How the include mechanism works

Under RFC 7208, an include triggers a recursive evaluation: the receiving mail server pauses evaluation of your domain’s record and performs a full check_host() evaluation on the target domain’s SPF record.

A typical SPF record with an include looks like this:

v=spf1 include:_spf.example.com ~all

Or, when authorizing multiple external sending services:

v=spf1 include:_spf.example.com include:spf.example.net ~all

If the evaluation of the included domain returns a pass (because the connecting server’s IP address matches the target’s policy), that pass result applies immediately to your record as well. If the included record does not return pass, the receiving server simply continues checking the remaining mechanisms in your record until it hits your ~all or -all qualifier.

When to use include (and when not to)

According to the standard, the include mechanism is intended for crossing administrative boundaries. When an external service provider (such as an email marketing service or cloud suite like Microsoft 365) operates servers across frequently changing IP addresses, that provider maintains its own centralized SPF record. Using include points directly to their dynamic policy without requiring manual updates to your zone every time their infrastructure shifts.

When remaining within one administrative authority (such as structuring your own internal servers), include is usually not the best choice. For authorizing IP addresses under your direct administrative control, direct mechanisms like ip4 or ip6 are more efficient and dependable.

The 10-lookup limit and permerror

A critical constraint when using include is the DNS lookup limit. RFC 7208 specifies that certain mechanisms and modifiers (collectively called “terms”) cause DNS queries during evaluation: specifically include, a, mx, ptr, and exists, along with the redirect modifier.

SPF implementations must limit the total number of those terms to 10 lookups during evaluation to prevent excessive load on the Domain Name System. If this limit is exceeded, the receiving server immediately stops evaluation and returns permerror (permanent error). Consequently, your email is often treated as unauthenticated and rejected or routed to spam.

Because every include costs at least one DNS query—and the included domain itself might contain further nested include mechanisms—the 10-lookup budget is consumed rapidly. By contrast, terms like ip4, ip6, and all do not cause DNS queries during evaluation and are exempt from this limit.

Verifying your configuration

Because a domain must not publish multiple separate SPF records (which would also cause an immediate permerror), you must combine every required include into a single unified TXT record.

Check your configuration with the free MXAudit scanner. It verifies your SPF syntax, validates all imported targets, and counts the exact number of DNS lookups consumed by your nested include statements.

For complete guidance on building your record or integrating specific providers, visit the SPF hub and follow practical walkthroughs like IONOS SPF setup.

Further reading