SPF — Sender Policy Framework

How SPF works in the SMTP transaction

SPF runs at SMTP envelope time, before any message data is exchanged. The receiving server, after the connecting client issues MAIL FROM:<sender@example.com>, performs a DNS TXT lookup against example.com to retrieve the SPF record. The record is a single string starting with v=spf1, followed by mechanisms that authorize specific IPs or delegate authorization to other domains, terminated by an all mechanism that defines the default action for unmatched IPs.

The receiving server reads the record left-to-right and stops at the first match. If the connecting IP is in _spf.google.com's allowed range, SPF returns pass. If it falls through to ~all, SPF returns softfail. The qualifier on all determines the default verdict for unmatched IPs:

The 10 DNS lookup limit — why it matters and how to count

RFC 7208 section 4.6.4 mandates that receiving servers MUST NOT perform more than 10 DNS lookups while evaluating an SPF record. Exceeding the limit produces a PermError (permanent error), which fails SPF authentication completely — not partially. Every email from your domain loses SPF authentication when this happens, regardless of which IP is sending. PermError also breaks DMARC pass-through if your DMARC policy depends on SPF rather than DKIM.

The limit exists for a real reason: SPF evaluation runs synchronously during SMTP, and unbounded recursive lookups would create a DNS amplification vector that malicious actors could weaponize against receiving infrastructure. The 10-lookup cap protects DNS resolvers from abuse — but it also creates the single most common SPF failure mode in production.

Mechanism cost — what counts and what doesn't

Not every SPF mechanism consumes a lookup. The cost varies by mechanism type:

ESP-by-ESP lookup cost map (the chart most guides skip)

The reason organizations hit the 10-lookup wall faster than expected is that ESP includes are rarely "1 lookup." Each major email provider's include: resolves to nested includes within their own infrastructure. Below is the actual cost of common ESP includes as of May 2026, verified by recursive DNS resolution against each provider's public SPF record. Treat these as moving targets — they change.

The void lookup limit (the one nobody mentions)

RFC 7208 imposes a separate limit that most practitioners miss: the void lookup limit. A void lookup is a DNS query that returns NXDOMAIN or an empty result set. The cap is 2 void lookups per evaluation. Exceeding it returns PermError even when your total lookup count remains under 10.

Common causes of void lookups:

• An include: pointing to a domain that no longer exists (vendor decommissioned, typo)
• An mx mechanism on a domain whose MX records were removed
• A ptr mechanism without a matching reverse DNS record
• An a mechanism on a domain with no A/AAAA record

Solving the lookup limit — flattening vs subdomains vs macros

Three structural fixes exist when you hit the lookup ceiling. The right choice depends on whether you need DMARC strict alignment, how often your ESP roster changes, and your tolerance for ongoing maintenance. The most common mistake is reaching for flattening when subdomains would solve the problem with less operational burden.

The subdomain pattern in practice

SPF and DMARC alignment — the part that bites

An email can pass SPF authentication and still fail DMARC. This is the most common cause of unexpected DMARC failures during enforcement rollout, and it's the consequence of how SPF authenticates the envelope (MAIL FROM) while DMARC checks the visible header (From:).

DMARC requires that the SPF-authenticated domain aligns with the From: header domain. The alignment mode is controlled by the aspf tag in your DMARC record:

Forwarding remains the persistent thorn in SPF alignment regardless of mode. When a recipient forwards an email through their server, the new outbound connection comes from the forwarder's IP — not from your authorized list. SPF fails. The fix isn't tightening SPF; the fix is ensuring DKIM is properly configured, since DKIM signatures survive forwarding (DKIM signs the message body, not the envelope). Most operators rely on DKIM for DMARC pass-through specifically because of this — and because DMARC passes if either SPF or DKIM aligns.

Common SPF failure modes in production

SPF in Cloud Server for Email's managed infrastructure

For clients on managed PowerMTA + MailWizz infrastructure, SPF setup is part of the day 1-3 onboarding sequence. The pattern we use across most accounts:

• Subdomain delegation by default. A new client typically gets a sending subdomain (e.g., m.clientdomain.com) delegated via NS records to our DNS, with SPF authorizing only the dedicated IPs allocated to that account. The apex domain SPF stays under the client's control and reflects only their corporate sending sources.
• Direct ip4: mechanisms over include:. Because the IPs are dedicated and stable, we publish them directly in ip4: form. Lookup cost: zero. No risk of nested includes silently breaking the lookup budget.
• ~all qualifier during the first 30 days, moving to -all only after DMARC aggregate reports confirm no legitimate sending sources are missing. Premature -all + p=reject is the most common cause of legitimate mail loss during enforcement rollout.
• Quarterly SPF audits on every domain in our managed portfolio, looking for stale includes, void lookup accumulation, lookup count drift, and TXT record fragmentation across multiple records.

Clients with multiple ESPs already in place before joining typically come with SPF records already at or over the 10-lookup limit. The first 14 days of onboarding usually include a flattening or subdomain restructure to bring the record into compliance. We provide the audit, document the recommended structure, and execute the DNS changes coordinated with the client's DNS administrator.

Auditing your current SPF — practical workflow

For programmatic auditing inside CI pipelines, the spfcheck CLI (Python) or checkspf (Go) both provide exit codes suitable for failing builds when a deployment would push a domain over the lookup limit.

Related concepts

• DMARC — the policy layer that uses SPF (and DKIM) authentication results plus alignment to decide what receivers should do with failing mail.
• DKIM — cryptographic signature on outbound mail that survives forwarding, complementing SPF's envelope-based authentication.
• Sender Reputation — SPF authentication is one input to overall sender reputation at major receivers, not the only one.
• MTA-STS — transport-layer security policy, separate from but often deployed alongside SPF/DKIM/DMARC.
• BIMI — brand logo display, requires DMARC enforcement (which requires functional SPF and DKIM). (Coming soon)

Frequently asked questions

What is the SPF 10 DNS lookup limit?

RFC 7208 mandates that receiving servers MUST NOT perform more than 10 DNS lookups while evaluating an SPF record. Mechanisms that count: include, a, mx, ptr, exists, and the redirect modifier. Mechanisms that don't count: ip4, ip6, all. Exceeding the limit returns PermError, which fails SPF authentication completely — not partially. There's a separate 'void lookup' limit of 2: lookups that return NXDOMAIN or empty results count against this even if you stay under the 10-lookup ceiling.

Does an include count as one lookup or many?

An include counts as 1 lookup at your level — but it inherits the lookup count of the included record. include:_spf.google.com is famously 4 lookups total because Google's record contains 3 additional nested includes (_netblocks, _netblocks2, _netblocks3). This is why it's easy to exceed 10 with only 3-4 ESPs: each provider's SPF is rarely just 1 lookup.

What's the difference between SPF flattening and SPF subdomains?

Flattening replaces include mechanisms with the resolved ip4/ip6 addresses, dropping lookup count to zero but creating a static record that breaks when vendors change IPs. Subdomains delegate each ESP to its own subdomain (m1.example.com for Mailgun, m2.example.com for SendGrid), so each subdomain has its own 10-lookup budget. Subdomains are the recommended structural fix for organizations with 5+ sending services because they don't require active maintenance. Flattening is the right choice when DMARC strict alignment is required — subdomains break aspf=s.

How does SPF interact with DMARC alignment?

SPF authenticates the SMTP MAIL FROM domain (also called Return-Path). DMARC then checks whether that authenticated domain aligns with the From: header domain visible to recipients. Relaxed alignment (default, aspf=r) considers them aligned if they share the same organizational domain — m.example.com aligns with example.com. Strict alignment (aspf=s) requires exact FQDN match. SPF can pass authentication but fail DMARC alignment, which is the most common cause of unexpected DMARC failures during enforcement rollout.

What does SPF PermError mean operationally?

PermError is a permanent SPF failure caused by a structural issue in your record: too many DNS lookups (>10), too many void lookups (>2), syntax errors, or invalid mechanism use. Critically, PermError fails SPF for ALL email from your domain, not just for the connection that triggered the count. It also fails any DMARC policy that depends on SPF authentication — so a single new ESP push can silently break authentication for your entire domain. Major receivers (Gmail, Microsoft, Yahoo) treat PermError as failure, not soft-fail.

Should SPF use ~all (softfail) or -all (hardfail)?

Use ~all (softfail) during initial rollout and any period where your sending source list might be incomplete. Use -all (hardfail) once you've confirmed via DMARC aggregate reports for at least 2 weeks that all legitimate sending sources are authorized. The practical difference: ~all tells receivers "this might not be us, mark suspicious"; -all tells receivers "this is definitely not us, reject". The real authority for handling SPF failures comes from your DMARC policy (p=quarantine or p=reject), so ~all + p=reject is more common than -all + p=none in mature deployments.

Are SPF macros worth using in production?

Rarely, despite being widely supported by MTAs. Macros let you build dynamic SPF records that vary by sender IP, local part, or HELO — useful for restricting third-party services to specific addresses (e.g., support@yourdomain.com can use Zendesk but the rest of your domain cannot). The trade-off is operational complexity: requires custom DNS infrastructure, isn't 100% supported by all receivers, and easy to misconfigure. For most organizations, subdomains solve the same scaling problem with less complexity. Consider macros only when you have specific per-address authorization requirements that subdomains can't address.

How do I check my current SPF lookup count?

Use any of these tools that recursively resolve includes and report the total: PowerDMARC SPF Checker, dmarcian SPF Surveyor, EasyDMARC SPF lookup, MxToolbox SPF tool, or Mailhardener SPF audit. From the command line: dig +short TXT example.com extracts your record, but counting nested includes manually is error-prone. The tool-based check should be done after every DNS change involving sending sources, not just when something breaks. Schedule a monthly audit even when you haven't made changes — ESPs occasionally add nested includes to their own records, silently consuming your budget.