Definition
The SPF (Sender Policy Framework) include mechanism is a DNS record directive that authorises a third-party email sender to send emails on behalf of your domain by referencing their SPF record within your own. When an organisation uses an email service provider (ESP) such as Salesforce Marketing Cloud, Klaviyo, or Mailchimp, or a transactional email service such as SendGrid or Amazon SES, the SPF include mechanism tells receiving mail servers that the third-party's sending IP addresses are legitimate senders for your domain. The include mechanism is the most common method for managing multi-sender authentication, used by virtually every organisation that sends email through third-party platforms alongside or instead of their own mail servers.
The include mechanism operates by DNS lookup chaining: when a receiving mail server checks your SPF record and encounters an include statement for a third-party sender, it performs an additional DNS lookup against that third-party's SPF record to retrieve their authorised IP ranges. This nested lookup process is subject to the SPF specification's limit of ten DNS lookups for the overall SPF evaluation, including the initial lookup, all include directives, and any subsequent lookups within included records. Exceeding ten lookups causes the SPF evaluation to return a permanent error (PermError), which may cause receiving mail servers to treat the message as if it failed SPF authentication. Managing the lookup count across multiple third-party senders — typically an ESP, a CRM platform, a transactional email service, and possibly a marketing automation tool — requires careful optimisation to stay within the lookup limit while authorising all legitimate sending sources.
Best Practices
Create a consolidated SPF record that lists all authorised sending sources, combining include statements for third-party senders with any direct IP address ranges for self-hosted mail servers. Place include statements in a logical order with the most frequently used senders first, as some receiving mail servers may stop processing after a hard fail is encountered. Maintain the record as a single v=spf1 string, as multiple SPF records for the same domain cause authentication failures.
Monitor the total DNS lookup count of your SPF record after every change. Each include directive counts as one lookup, plus any lookups within the included SPF record itself. Direct IP range statements (ip4 and ip6) and the a, mx, exists, and ptr mechanisms also count toward the ten-lookup limit when they require DNS resolution. Use online SPF validation tools that report the actual lookup count when testing proposed record changes before deployment.
Apply the include mechanism when your third-party sender maintains their own SPF record that you trust and that is unlikely to change unpredictably. Use the redirect mechanism (redirect=) when you want to delegate all SPF authority for your domain to another domain's SPF record entirely. The key difference: include adds the included domain's authorised senders to your existing list of authorised senders, while redirect replaces your SPF policy entirely with another domain's policy. Include is almost always the correct choice when maintaining multiple sending sources on your domain.
Optimise SPF record lookup count by: minimising the number of include statements through consolidation where possible; using ip4 and ip6 mechanisms for small, static sender IP ranges instead of include directives; verifying that each third-party sender's SPF record cannot be restructured by the provider to reduce its internal lookups; and considering whether each included third-party specifically needs SPF authentication, as some senders may be adequately authenticated through DKIM alone.
Review SPF records quarterly and after any change to your sending infrastructure, including adding or changing ESPs, integrating new CRM or marketing automation platforms, or migrating transactional email services. Removing include statements for decommissioned sending platforms is as important as adding new ones, as outdated include statements consume lookup budget, broaden your authorised sender scope unnecessarily, and may include IP ranges controlled by parties no longer authorised to send on your behalf.
Related Glossary Terms
Bounce Classification
Bounce classification uses SMTP codes (550, 551, 552, 553, 554, 450, 451, 452) and enhanced status codes to categorise permanent and transient delivery failures.
DMARC Alignment
DMARC identifier alignment determines whether the domain in the From header matches the domains used in SPF and DKIM authentication. Strict or relaxed.
DMARC Policy Tags
DMARC DNS record tags including v, p, sp, rua, ruf, pct, adkim, aspf, fo, rf, and ri control authentication policy, reporting, and alignment enforcement.
Email Active Subscriber
An active email subscriber has opened or clicked an email within a defined recency period, typically 30-90 days by industry. Active subscriber rate of 40-60% is typical for healthy email lists.
Email Authentication Failure
Email authentication failures occur when SPF, DKIM, or DMARC checks fail, causing messages to be rejected, spammed, or quarantined by receiving mailbox providers.
Email Blacklist
An email blacklist (DNSBL) is a real-time database of IP addresses or domains known for sending spam or unwanted email.
Frequently Asked Questions
An SPF include directive in your domain's DNS record tells receiving mail servers: query this third-party domain's SPF record to find the IP addresses authorised to send email for that domain, and treat those addresses as also authorised for my domain. The include mechanism chains SPF lookups: your record includes a third-party, whose record may include others, and so on, up to the ten-lookup limit.
The syntax is: include:thirdpartydomain.com. For example, include:spf.sendgrid.net. Multiple include statements are added within a single SPF record: v=spf1 include:spf1.mysender.com include:spf.mysender.net ~all. The ~all or -all mechanism at the end defines the policy for senders not matching any include or IP range.
The SPF specification limits the total number of DNS lookups during SPF evaluation to ten. Each include statement counts as one lookup, plus any lookups within the included record. Direct IP ranges (ip4, ip6) don't count unless combined with a mechanism that requires DNS resolution. To manage the limit: consolidate include statements, use direct IP ranges for small sender groups, eliminate redundant lookups, and verify each third-party's SPF record is optimised.
Include adds a third-party's authorised IP ranges to the existing list of authorised senders for your domain, allowing you to maintain multiple sending sources. Redirect completely replaces your SPF policy with another domain's policy — all your existing ip4, ip6, and include statements are ignored when a redirect mechanism is present. Use include for maintaining multiple senders; use redirect only when you want to delegate full SPF authority to another domain.
List all include statements in a single SPF record. Monitor total DNS lookup count each time you add or remove a third-party sender. If approaching the ten-lookup limit, consider: replacing include statements for senders with small, static IP ranges using ip4 or ip6 mechanisms; negotiating with your ESP to reduce lookups in their shared SPF record; or relying on DKIM authentication alone for less critical senders to reduce SPF lookup burden.