SPF

SPF is the oldest of the three modern email authentication primitives. RFC 7208. A TXT record at the root of your domain declares which IPs are allowed to send on its behalf. The receiver looks up the record, compares the connecting IP, and decides what to do.

No cryptography. No keys. Just a list. That simplicity is also the problem. SPF was designed in 2006, when "send a list of IPs" felt sufficient. Today most production senders touch a dozen third-party services that send on their behalf, each requiring an include: directive, and the lookup limit catches almost everyone eventually.

You still need SPF. But pretending it does what DKIM and DMARC do is the most common mistake we see in audits.

What a typical record looks like:

v=spf1 ip4:185.10.20.0/24 include:_spf.google.com include:spf.mailgun.org -all

Decoded:

• v=spf1. Version. Always 1.
• ip4:185.10.20.0/24. Authorise this IPv4 range. Use ip4: for individual addresses or CIDR blocks; ip6: for IPv6.
• include:_spf.google.com. Delegate to another SPF record. Anything authorised by _spf.google.com is authorised here too. Each include: counts toward the 10-lookup ceiling.
• -all. The terminator. -all means hard fail (recommended for production). ~all means soft fail. ?all is neutral. +all authorises anyone, which is the same as having no SPF at all and worse, because it tells receivers you don't care.

Other mechanisms exist (a:, mx:, exists:, redirect=) but the four above cover most production records.

SPF caps DNS lookups at 10 per evaluation. include:, a:, mx:, exists:, and redirect= all count. Go past 10 and you get permerror, which receivers treat as policy failure.

The lookups are recursive. Your record includes _spf.google.com: that's one lookup. _spf.google.com includes _netblocks.google.com: two lookups. That includes another two zones: four lookups. So just by adding Google, you've used four of your ten. Add Mailgun, SendGrid, Mailchimp, your CRM, and you're past the ceiling without realising it.

Ways to stay under:

• Audit the include chain. Our SPF validator counts lookups for you.
• Replace include: with explicit ip4: ranges where the third party publishes them. Sendgrid, Mailgun, AWS SES all publish IP lists. Copy those directly and skip a lookup.
• Remove abandoned senders. SaaS platforms you stopped using two years ago are still in your include chain, eating lookup budget for nothing.
• SPF flattening as a last resort. Tools that compress your include chain into a single ip4 list. They work, but you have to update them when third-party IPs change, which they do without warning.

What you put at the end of your record (-all or ~all) tells receivers how seriously to take SPF failures.

Hard fail (-all) is the strong posture. Receivers MAY reject outright. In practice most receivers do not reject on SPF alone; they downgrade trust and let DMARC policy decide. But -all is what you want declared once you've enumerated your real senders honestly.

Soft fail (~all) is the cautious posture. Treat as suspicious but still deliver. Use this during migration when you're not 100% sure you've listed every legitimate sender. Move to -all once you're confident.

Don't use ?all or +all. ?all says "no opinion," which is operationally useless. +all says "anyone can send for me," which defeats the entire point.

SPF on its own only validates the connecting IP. Under DMARC, SPF also has to align with the From: header domain. That's a different check.

SPF alignment compares the domain in the SMTP envelope's MAIL FROM (also called Return-Path or bounce address) against the From: header. Forwarders break this constantly. They typically rewrite MAIL FROM but keep the original From:, so SPF passes the IP check while failing DMARC alignment.

This is why DKIM matters more than SPF for DMARC alignment in practice. DKIM survives forwarding cleanly. SPF often doesn't.

Modern receivers treat SPF as table stakes, not a competitive edge. Having valid SPF doesn't earn you anything. Lacking it gets you penalised. Asymmetric, and not in your favour.

Specifically:

• Gmail: missing or failing SPF reduces sender score in Postmaster Tools. Repeat failures push messages toward spam.
• Microsoft (Outlook, Hotmail): SPF failure feeds the SCL score directly.
• Yahoo / AOL: contributes to bulk-mail bucket assignment.
• Corporate filters (Proofpoint, Mimecast, Barracuda): SPF failure is often a hard reject at the SMTP layer, not a downgrade.

What you need in 2026: present, valid, aligned, under 10 lookups, hard fail terminator. That's the floor. Anything missing and you're losing inbox placement to senders who got the basics right.

SPF flattening replaces include: mechanisms with the IP ranges they resolve to, eliminating DNS lookups. The technique solves the 10-lookup limit but introduces maintenance burden because the resolved IPs change over time as ESPs adjust their infrastructure.

Three flattening approaches with different trade-offs. Manual flattening: resolve includes once, paste IP ranges into your record, never update. Acceptable only for stable ESPs that genuinely don't change IPs (rare in 2024+); breaks silently when ESPs migrate. Most operators who use this approach experience eventual broken SPF without realizing it. Automated flattening services (services like dmarcian, Valimail, EasyDMARC): re-resolve includes daily and update DNS via API. Subscription cost (typically $50-300/month depending on volume); maintenance handled. Self-hosted flattening: cron job re-resolves includes nightly and updates DNS via your DNS provider's API. Free in software but requires engineering capacity and reliability discipline. Acceptable for operations with capacity to maintain it.

Failure modes specific to flattening. ESP migration adds new IPs not in your flattened record; their mail starts failing SPF until next refresh. ESP retires old IPs; SPF still authorizes them long after retirement, creating spoofing surface. DNS update API failures (provider-side issues) cause flattened record to stale; mail starts failing across all included senders. Mitigations: monitor SPF compliance via DMARC reports specifically for flattening targets; alert when SPF pass rate drops; manual sanity checks at quarterly intervals.

Operations should generally prefer reducing include count over flattening. Flattening is a workaround for accumulated complexity; the cleaner solution is to remove ESPs you no longer use, consolidate to fewer senders, and keep SPF naturally under 10 lookups. Flattening becomes appropriate when you have legitimate need for 8+ ESPs and reducing further is infeasible.

SPF authorizes the connecting IP that delivers mail to the recipient's server. When mail is forwarded (mailing list, individual auto-forward, alias delivery), the connecting IP changes from the original sender's IP to the forwarding host's IP. SPF checks against forwarding hosts always fail unless the forwarding host happens to be authorized in your SPF record (which usually it isn't, because forwarding hosts are unrelated infrastructure).

This is structural, not a bug. SPF was designed before mail forwarding patterns became common; it doesn't handle the forwarding case gracefully. Three downstream effects matter. Mail forwarded to corporate Outlook tenants from Gmail forwarding rules sometimes fails SPF at the corporate gateway and gets rejected before DMARC alignment is checked. Mail forwarded through mailing lists rewrites the envelope sender (Sender Rewriting Scheme, SRS) to make SPF pass; this works but breaks DMARC alignment, requiring DKIM to carry alignment.

The practical implication: SPF alone is insufficient for senders whose recipients commonly use forwarding. DKIM provides forwarding-resilient authentication because it signs the message itself rather than the connection. DMARC alignment can be achieved through DKIM even when SPF fails after forwarding. Modern deliverability requires DKIM as primary authentication; SPF as supplementary check. Senders that rely on SPF alone discover deliverability gaps with forwarded recipients that DKIM-signed mail doesn't exhibit.

SPF remains operationally required despite being the older and less reliable of the two authentication mechanisms. Receivers continue checking SPF and apply the result to their classification decisions, and DMARC alignment can be satisfied through SPF when DKIM alignment is unavailable. The continued importance of SPF in 2026 reflects the structural role it plays in the broader authentication picture rather than any specific receiver requirement for SPF independently.

The 2026 receiver-side weighting on SPF has shifted somewhat from earlier periods. SPF passing is treated as baseline expectation rather than positive signal; SPF failing is treated as moderate negative signal that combines with other factors. The most important operational implication is that SPF must be configured correctly across all the senders sending infrastructure; gaps where some sending sources have SPF authorization and others do not produce inconsistent authentication that DMARC then surfaces as alignment failures.