The include mechanism in an SPF record lets you trust another domain’s published sending list as if it were your own. In practice, many organizations add an include statement for each third-party platform they use to send email (for example, marketing clouds, ticketing systems, or Google Workspace). This is why multiple includes frequently appear in a single spf record: each vendor publishes its own TXT record that expands to authorized IP ranges and further mechanisms.

• Example: v=spf1 include:_spf.google.com include:spf.messagelabs.com ~all

• Another common pattern: v=spf1 include:domain.com include:_spf.google.com -all

Under the sender policy framework, the receiving server performs an spf check against the domain in the MAIL FROM or HELO identity, processing your TXT record beginning at v=spf1 and ending with an all policy (~all, -all, or ?all). Because vendors like Google publish include targets (for example include:_spf.google.com) to let you consume their ever-changing IPs, multiple includes become a pragmatic way to stay current without hardcoding IP ranges in your spf string.

Yet, multiple includes can introduce risk. Each include mechanism can trigger DNS lookups, potentially cascading into nested includes that push you over the dns lookup limit. Managing this carefully is core to spf best practices and maintaining a valid spf record.

How the include mechanism evaluates during an SPF check

During an spf check, the include mechanism evaluates to “pass” if the target domain’s SPF authorizes the connecting IP. The include statement uses a domain specifier (for example include:domain.com) whose TXT record is fetched and parsed. If that child record returns no match, evaluation continues in your parent record. Because spf implementations resolve includes recursively, nested includes are normal—but they must be controlled to avoid exceeding the dns lookup limit and the spf check limit defined by the specification. Managing email authentication becomes tricky when your domain configuration contains spf multiple include entries that exceed DNS lookup limits.

The 10-DNS-lookup rule: how lookups are counted and where multiple includes go wrong

SPF has a strict dns lookup limit of 10 during evaluation. The specification (originally RFC 4408, later updated) defines which mechanisms and modifiers consume lookups: include, a, mx, ptr, exists, and redirect. Each of these can lead to more dns lookups through nested includes. By contrast, the ip4 mechanism and ip6 literals do not consume lookups.

Where multiple includes go wrong is when they stack—include:_spf.google.com might internally reference several other include targets, and if you also add includes for Messagelabs (include:spf.messagelabs.com), Eloqua (include:_netblocks.eloqua.com), Hotmail/Outlook, or a:domain.com and mx mechanism checks, the cumulative spf lookup count can exceed the max lookups and trigger an spf fail due to the dns query limit.

Counting lookups precisely

• Each include mechanism counts as one lookup; the TXT record it references may add more via nested includes.

• The a mechanism and mx mechanism (often written informally as mx:mechanism) each cause the receiver to resolve A/AAAA or MX records, which then may cause additional queries as MX hosts are resolved.

• The redirect modifier causes an immediate jump to another domain’s SPF (one lookup), replacing the current processing chain entirely.

• ip4 mechanism and ip6 literals cause no DNS queries.

This is why, before you add includes, you should inventory all domains, subdomains, and third-party platforms, and then merge includes or combine domains where possible to keep a single spf entry within the spf limit.

Edge cases: nested includes and MX expansion

Nested includes are the silent lookup multipliers. include:_spf.google.com can fan out to multiple domain includes; similarly, include:spf.messagelabs.com and include:_netblocks.eloqua.com often chain to additional records. MX evaluation also expands: the mx mechanism fetches MX, then resolves each target to A/AAAA—multiple dns lookups in one directive.

PTR and exists caveats

The ptr and exists mechanisms are costly: they can generate many dns lookups and are discouraged in modern spf rules. Using them alongside multiple includes risks crossing the limit and causing spf failures that hurt email deliverability.

Include vs redirect vs mechanisms (a, mx, ip4/ip6, exists, ptr): choosing the right building blocks

Choosing among include, redirect, and base mechanisms determines how concise—and compliant—your spf record will be.

• include mechanism: Use to trust another domain’s SPF, e.g., include:_spf.google.com or include:domain.com. Great for vendors and partners across spf multiple domains.

• redirect modifier: Use when one domain’s SPF should entirely defer to another (for example, sub.example.com redirects to example.com). This consolidates policy in a single spf entry rather than stacking multiple includes.

• Mechanisms: Prefer ip4 mechanism/ip6 for fixed networks; use a:domain.com or the mx mechanism only if those DNS records accurately reflect your sending hosts and you can tolerate the added dns lookups. Avoid ptr unless you fully understand the implications.

Your spf policy ends with the spf all mechanism: choose -all (hard fail) for strict spf compliance, ~all (soft fail) during migration, or ?all (neutral) for testing. Consider the operational consequence: an overly strict -all amid misconfigurations can cause unexpected spf fail, while a lingering ~all can mask spf failures and complicate spf validation.

When to prefer redirect modifier over multiple includes

If a subdomain should inherit the parent’s policy verbatim, use redirect instead of recreating the parent with multiple includes. This reduces spf entries to manage and helps merge spf records consistently. Example spf record format:

• Subdomain: v=spf1 redirect=example.com

• Parent: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all

This approach can merge includes into one policy and keep a single spf entry authoritative, improving spf alignment and simplifying spf parsing across your authorized domains.

Inventory and map all sending sources: domains, subdomains, and third-party vendors

Start with an inventory that captures:

• Primary domain and subdomains used in MAIL FROM/Return-Path (domain authentication scope)

• Platforms: Google (include:_spf.google.com), Messagelabs (include:spf.messagelabs.com), Eloqua (include:_netblocks.eloqua.com), IBM/ibm.com, Lenovo.com, Hotmail, and any others

• Internal services reachable via a:domain.com or mx:mechanism

• Static ranges to embed via the ip4 mechanism or ip6

Use nslookup and spf tools/spf validators (for example, kitterman.com’s spf record validator and other spf validation tools) to enumerate current spf DNS records and txt-record chains. Document trusted domains, authorized domains, and authorised senders separately; clarity here lets you combine domains and merge includes efficiently without crossing the dns lookup limit.

Documenting authorised senders and domain includes

Map each sender to the exact include statement you need (for example include:_spf.google.com). Note nested includes depth and the current spf lookup count; record whether each service requires ~all or fits safely under -all in your final policy. This diligence prevents spf failures during rollout and anchors your spf configuration in defensible spf best practices

Architecture patterns for multiple includes: consolidation, per-function includes, and subdomain delegation

Three durable patterns address the reality of multiple includes while respecting the dns lookup limit:

• Consolidation: Merge includes into a central, single spf entry where you can. If vendors allow, replace scattered include:domain.com entries by combining includes published by your parent domain and de-duplicating overlaps. This reduces nested includes and keeps within the max lookups.

• Per-function includes: Create internal domains that publish purpose-built TXT records (for example, include:mailops.example.com) which themselves aggregate vendor records such as include:_spf.google.com. Your primary spf string stays short; the per-function records absorb complexity while you monitor the spf check limit.

• Subdomain delegation: Delegate high-churn senders (bulk marketing, transactional services) to subdomains with their own spf record and a strict -all, while your apex uses redirect or minimal includes. This isolates risk and improves email deliverability.

Consolidation with a single spf entry

Aim to keep the apex policy as a single spf entry that ends with the right all qualifier. During transition, you might publish:

v=spf1 include:_spf.google.com include:spf.messagelabs.com ip4:203.0.113.0/24 ~all Then, after verification, tighten to -all. Throughout, control nested includes so the overall spf limit is respected and spf pass remains consistent across services.