What is an SPF lookup and why does it matter for email delivery?

An SPF lookup is the DNS-based check mail servers perform to verify that the sending IP is authorized by a domain’s SPF record, and it matters for email delivery because it directly influences whether messages pass authentication, avoid spoofing, and land in the inbox rather than being rejected or spam-foldered.

Per RFC 7208, SPF evaluation is capped at 10 DNS mechanism lookups and 2 void lookups per check - exceeding either limit produces a PermError that fails authentication for every message from the domain.

Sender Policy Framework (SPF) tells receiving servers which IP addresses are allowed to send on behalf of your domain name, and an SPF lookup is the real-time DNS evaluation that enforces that rule during SMTP. When the recipient’s server receives a message claiming to be from your domain, it queries DNS for your SPF policy, evaluates it against the sender’s IP address, and returns a pass/fail outcome that downstream systems use for filtering and DMARC alignment. If your SPF record is missing, misconfigured, or exceeds DNS limits, your legitimate mail can fail email authentication.

That outcome is why an SPF lookup sits at the center of both email authentication and email deliverability. Nearly every major mailbox provider now treats SPF (with DKIM and DMARC) as a signal for acceptance, reputation, and routing. In AutoSPF’s analysis of 2.1 billion messages across mid-market senders, domains with a valid, lookup-budget-conscious SPF had 24-38% fewer spam-folder placements and 2-4x fewer spoofing attempts that bypassed basic filters. Domains with duplicate SPF records or over-limit policies triggered PermErrors on up to 8.7% of messages - a measurable hit to deliverability. Running your domain through an SPF record checker before and after any DNS change is the quickest way to catch those failures early.

How an SPF Lookup Works at the DNS Level

This section explains the DNS mechanics of an SPF lookup: how a record is read, how mechanisms are processed, and what each outcome means - so you can engineer a reliable policy for your domain name.

Record types read

• SPF is published in a DNS TXT record. Example: v=spf1 include:_spf.google.com -all

• The historical SPF RR type (type 99) is deprecated; receivers primarily check TXT (RFC 7208). Publishing only TXT avoids ambiguity.

• You must publish exactly one SPF policy per hostname. Multiple TXT records that begin with v=spf1 lead to a PermError, so duplicates must be merged into a single validated record.

Mechanism evaluation and order

• SPF mechanisms are evaluated left-to-right; the first match decides the result.

• Common mechanisms: a, mx, ip4, ip6, include, exists, ptr (discouraged), all; modifiers: redirect, exp.

• Qualifiers set the disposition: (implicit +) pass,, fail, ~ softfail, ? neutral.

• Evaluation flow (simplified):

  1. Expand macros (if present) and fetch DNS data.
  2. Evaluate each mechanism in order.
  3. On first match, return that mechanism’s qualified result.
  4. If no match and a redirect= is present, evaluate the target’s SPF.
  5. If no match and no redirect, result is neutral (unless an explicit all is present).

What counts as a lookup and outcomes

• Lookups that count toward the 10-lookup limit: a, mx, include, exists, ptr, redirect, exp. Not counted: ip4, ip6, all.

• Outcomes: pass, fail (-all), softfail (~all), neutral (?all), none (no SPF record), temperror (transient DNS), permerror (syntax or limit violation).

• Void lookups (NXDOMAIN/NOERROR-NODATA) have a separate limit: if you hit too many void results (commonly 2), receivers may return permerror. Pruning unused includes and validating vendor targets keeps voids under control.

SPF Record Syntax and Mechanisms (with correct usage)

SPF records start with v=spf1 followed by mechanisms/modifiers in order of specificity. Use precise, scoped entries - specific IP addresses and vendor includes - and avoid deprecated features.

Core syntax

• Start: v=spf1

• Mechanisms: a, mx, ip4:CIDR, ip6:CIDR, include:domain, exists:domain, ptr, all

• Modifiers: redirect=domain, exp=domain

• Qualifiers: -, ~, ?, + (implicit)

• Example baseline: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net -all

Mechanisms explained with examples

• a (match the A/AAAA of a host)

• v=spf1 a -all (authorize the domain’s A/AAAA)

• v=spf1 a:mail.example.com/28 -all (authorize a subset of a host’s range)

• mx (authorize the IPs of MX hosts)

• v=spf1 mx -all (allow mail from hosts that receive your mail)

• Caution: MX changes can add unexpected IP addresses, so mx can quietly widen your sending surface.

• ip4/ip6 (literal ranges)

• v=spf1 ip4:198.51.100.12 ip6:2001:db8::/32 -all

• Prefer literal ranges for in-house infrastructure, and normalize duplicate or overlapping CIDRs.

• include (import another domain’s SPF)

• v=spf1 include:_spf.google.com -all

• include matches only on pass; fail/neutral/softfail fall through. Each include resolves to its own chain of lookups, which counts against your budget.

• exists (domain existence test; often used with macros)

• v=spf1 exists:%{i}._spf.example.com -all

• Powerful but can explode your lookup count; avoid unless you genuinely need it.

• ptr (reverse lookup; discouraged)

• v=spf1 ptr -all

• Deprecated for reliability/performance; many receivers ignore it. Replace it with explicit ip4/ip6 entries.

• all (default catch-all)

• v=spf1 include:vendors -all (final decision)

• Place last; earlier all renders later mechanisms unreachable.

Modifiers

• redirect=domain

• v=spf1 redirect=_spf.parent.example

• If no mechanism matches, evaluate the target domain’s SPF. Useful for standardizing a multi-domain estate under one managed policy.

• exp=domain

• Adds an explanatory string on fail; rarely used in modern filtering.

Concrete examples

• Typical Microsoft 365 primary with SendGrid marketing:

• v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

• Hybrid on-prem plus cloud:

• v=spf1 ip4:203.0.113.10/31 mx include:_spf.google.com ~all (start with softfail; later move to -all). Order mechanisms from most specific to broad so the common senders match first and you spend the fewest lookups.

Limits, Constraints, and the Reality of Large Deployments

SPF is constrained by DNS realities, and violating those limits causes authentication failures even when every IP address on the record is correct.

DNS lookup and size limits

• 10-lookup rule: Total DNS-querying mechanisms (include/a/mx/exists/ptr/redirect/exp) across the entire evaluation path must not exceed 10.

• Void lookups: Excessive NXDOMAIN/empty responses can trigger permerror (commonly after 2); pruning dead includes matters.

• TXT record sizing:

• Each TXT string is limited to 255 chars; multiple strings are concatenated.

• Keep SPF payloads practically under ~450-1,000 bytes to avoid fragmentation issues with legacy resolvers. EDNS0 helps, but not universally.

• TTL and drift: Vendors change IPs, so static “flattened” IP addresses go stale. If you flatten, refresh on a schedule aligned to each vendor’s TTL.

How limits bite in practice

• Case: A retailer used 11 third-party senders (marketing, CRM, support, ERP, HR, ticketing). Their vendor includes chained to 17 total lookups → permerror at peak hours; 6-12% of messages failed SPF.

• AutoSPF fix: Aggregated includes to a single managed include, auto-flattened two high-churn vendors, removed unused entries, cut to 8 lookups. Result: SPF pass rate +13.5%, spam-folder rate -29% within a week.

Strategies that work

• Aggregate includes: Create _spf.example.com with all vendor entries so you manage one record centrally instead of many.

• Targeted flattening: Replace volatile includes with managed IP address lists refreshed on schedule.

• Subdomain delegation: Offload high-churn sender classes to subdomains (e.g., bounce.marketing.example) with their own SPF.

• Avoid risky mechanisms: No ptr; cautious mx; prefer ip4/ip6 for owned systems.

Authorizing Third-Party Senders Without Breaking Limits or Security

Third parties are the top cause of SPF sprawl. Use vendor-documented includes and align MAIL FROM domains to your DMARC policy so every outside sender contributes to email authentication instead of undermining it.

Securely authorizing vendors

• Always use vendor-published include domains (e.g., include:mailgun.org, include:_spf.salesforce.com).

• Align the envelope sender (MAIL FROM/Return-Path) to your domain or a delegated subdomain so DMARC can pass via SPF.

• Prefer vendor-specific bounce subdomains (e.g., bounce.marketing.example) and point CNAME/records per vendor instructions; keep SPF separate for that subdomain.

• Audit vendor TTLs and IP-address drift frequency so flattened segments don’t go stale.

How Do You Prevent include chain explosions?

• Some vendors include other vendors (A → B → C), burning your lookup budget unexpectedly.

• Map the entire include chain and its resolved lookup count for the worst-case path, then flatten or aggregate to stay ≤10. An SPF record checker that expands nested includes shows you that number directly.

Data point

• Across 1,000+ AutoSPF-managed domains, 34% of vendor includes added more than one downstream lookup; targeted flattening reduced average lookups by 41% without loss of coverage.

Diagnosing and Fixing Common SPF Misconfigurations

Misconfigurations are frequent - and fixable with disciplined checks. A regular SPF record check catches most of them before they reach the inbox.

Frequent issues

• Duplicate SPF records: Two TXT records with v=spf1 → permerror. Fix by merging into one policy.

• Early all: Placing -all before other mechanisms makes them unreachable.

• Missing vendors: Forgetting to add a new marketing tool causes intermittent fails from unknown IP addresses. DMARC aggregate reports reveal those sources so you can add the right include.

• Wrong IP ranges: Using ip4 without CIDR when the provider uses a block → surprise fails. Match the vendor’s documented range exactly.

• Syntax errors: Misplaced qualifiers, stray quotes, unescaped semicolons. You can catch these early with an SPF syntax validator that checks RFC 7208 compliance.

• Using ptr or broad mx leading to unintended authorization - prefer explicit, scoped entries instead.

Tools and commands to validate

• Check the SPF record:

• dig +short TXT example.com

• nslookup -type=txt example.com

• host -t txt example.com

• Trace lookups:

• dig +trace TXT example.com (see authoritative answers)

• Use SPF validators or pyspf/spfquery locally to emulate evaluation, or check your SPF record with AutoSPF’s free SPF checker to expand includes and count lookups instantly.

• Count lookups:

• Paste any domain into an SPF lookup tool to expand every include and count the DNS lookups - including void lookups and redirect paths - in seconds, rather than tracing the chain by hand.

Monitoring with DMARC

• Publish DMARC with aggregate reports (rua) to see who sends on your behalf:

• _dmarc.example.com TXT “v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1”

• The reports highlight unauthorized sources so you can decide what to add to SPF or DKIM. Check your DMARC record first to confirm the policy is published correctly.

Case study: CRM rollout

• A B2B SaaS added a CRM that relayed through regional IPs. Their SPF exceeded 10 lookups intermittently as the CRM toggled include targets by region.

• AutoSPF spotted the spike during preflight, flattened the CRM include into five IP ranges with a 1-hour refresh, and kept total lookups at 9. Result: Zero SPF permerrors during launch.

Forwarding, Mailing Lists, and SRS: Why SPF Fails in Transit

SPF authenticates the connecting IP against the MAIL FROM domain. Forwarding changes the connecting IP without changing MAIL FROM, so SPF often fails.

Forwarding and SRS

• Classic forwarding: Recipient’s ISP forwards to another mailbox; the new server connects using the forwarder’s IP but the MAIL FROM remains the original sender → SPF fails.

• SRS (Sender Rewriting Scheme) rewrites MAIL FROM to the forwarder’s domain so SPF can pass against the forwarder’s SPF. Not all forwarders implement SRS.

• Practical guidance: Expect SPF failures on non-SRS forwarders and rely on aligned DKIM to carry the DMARC pass. DMARC analytics show which paths fail and whether SRS is present.

Mailing lists and ARC

• Lists often modify content/headers, breaking DKIM and failing SPF (because list servers send from their own IPs).

• ARC (Authenticated Received Chain) helps downstream receivers trust prior authentication.

• Recommendation: Ensure DKIM is strong and aligned, accept that SPF may fail in list scenarios, and use DMARC relaxed alignment plus ARC where supported.

What Are Best Practices for Creating, Testing, and Deploying SPF?

Follow a repeatable playbook to reduce risk whenever you touch the record.

Build and stage carefully

• Start with ~all (softfail) during discovery; monitor DMARC to ensure coverage; move to -all when confident.

• Order mechanisms from most specific to broad; put all last.

• Keep total lookups ≤8 to leave headroom; avoid ptr; be cautious with mx.

• Use a dedicated _spf.example.com include that aggregates your policy for clarity.

Change management

• Version your SPF policy and set reasonable TTLs (e.g., 1 hour during rollout, 24 hours after stabilization).

• Test specific source IP addresses against the new record before publishing, so you know exactly what will pass or fail after the change.

• Monitor after changes and watch for permerror/temperror spikes and vendor drift.

Using SPF with DKIM and DMARC to Maximize Deliverability

SPF alone doesn’t authenticate the header From domain used by recipients. DMARC requires SPF or DKIM to pass and align with the header From domain.

Alignment rules and policy

• SPF alignment: The domain in MAIL FROM (or HELO) must match (relaxed: organizational match) the header From domain.

• DKIM alignment: The d= domain in the DKIM signature must match the header From domain under DMARC. Alongside SPF, check your DKIM record to ensure that d= domain aligns.

• DMARC policy progression:

• Start: v=DMARC1; p=none; rua=…

• Then: p=quarantine; pct=50 (gradual)

• Finally: p=reject; aspf=s; adkim=s for strict alignment (optional)

• Practical tip: For third-party senders, configure a Return-Path subdomain aligned to your From domain (or delegate a subdomain) so DMARC can pass via SPF if DKIM is unreliable.

Data point

• AutoSPF customers who moved from ~all to -all with DKIM on all major streams and a DMARC p=reject policy saw a 31% reduction in spoof attempts and a 19% improvement in inbox placement for marketing campaigns over 60 days.

Flattening, Include Aggregation, and Delegation: When and How

These techniques help you stay under limits but carry trade-offs worth understanding before you reach for them.

Flattening

• What it is: Replace include mechanisms with their resolved IP address ranges.

• Pros: Fewer lookups; deterministic evaluation.

• Cons: Stale quickly; manual updates create drift; can grow record size.

• Doing it safely: automate the refresh on a TTL-aware schedule with diff-based publishing and a rollback path - AutoSPF is built to handle exactly this. Example output:

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

• Where Google remains include (stable) and volatile vendors are flattened.

Include aggregation

• Group many vendor includes under one maintained include domain (e.g., include:_spf.example.com).

• Pros: Central control; easier auditing; one place to validate and count lookups.

Subdomain delegation

• Delegate sender classes (marketing, support) to subdomains with their own SPF/DMARC, decreasing blast radius and simplifying alignment.

• Trade-off: More DNS records to maintain, and you must coordinate the From and Return-Path domains so alignment still holds.

FAQ

Can I publish more than one SPF record for my domain?

No. You must publish exactly one TXT record that starts with v=spf1 for each hostname. If you need to combine entries, merge them into a single policy to avoid a permerror.

Does SPF check the visible From header?

No. SPF checks the MAIL FROM (envelope) or HELO domain, not the visible From header. DMARC is what ties SPF/DKIM to the visible From domain through alignment, which is why SPF alone is not full email authentication.

Is the ptr mechanism safe to use?

Not recommended. It’s slow, unreliable, and often ignored. Replace ptr with explicit ip4/ip6 ranges or vendor includes.

What’s the difference between -all and ~all?

• -all is a hardfail: unauthorized mail is expected to be rejected.

• ~all is a softfail: unauthorized mail is accepted but marked. Use ~all during discovery, then move to -all once your sender list is complete.

What happens if I exceed the 10-lookup limit?

Receivers should return permerror, which many treat as an outright failure - hurting email deliverability for every message. Stay under budget with flattening or include aggregation, and confirm the count with an SPF record checker after each change.

Conclusion: Make SPF Reliable and Impactful with AutoSPF

An SPF lookup is the receiver’s DNS check to confirm your sending IP is authorized, and it matters because it directly drives authentication, DMARC alignment, and deliverability outcomes. To get it right, you must model mechanism order, respect DNS lookup and size limits, authorize third parties without exploding your budget, account for forwarding realities, and deploy changes safely alongside DKIM and DMARC.

AutoSPF was built to operationalize all of this: a guided policy builder with a vendor catalog; preflight simulations that count lookups and trace decisions; guardrails that block duplicates, ptr, and syntax errors; automated, TTL-aware flattening; aggregate includes you can publish once and forget; DMARC ingestion to discover unknown senders; and change management with alerts and rollbacks. Whether you’re consolidating a simple stack or wrangling dozens of third-party platforms, AutoSPF turns SPF from a brittle TXT string into a resilient, monitored control plane - so your mail authenticates, your brand is protected, and your messages actually reach the inbox.