What is SPF (Sender Policy Framework)?

SPF — Sender Policy Framework — is defined in RFC 7208 and is the first line of defence against email spoofing. It works by publishing a DNS TXT record at your domain root that lists every IP address and hostname authorised to send mail from your domain. When a receiving server accepts a message, it looks up your SPF record, checks the connecting IP, and either passes, softfails, hardfails, or errors. Without SPF, any server on the internet can forge your domain in the envelope sender and many receivers will accept it.

How SPF works step by step

1. Your domain publishes example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"
2. A sender connects to Gmail's MX and delivers a message with MAIL FROM: [email protected]
3. Gmail resolves example.com TXT records and finds the SPF record
4. Gmail checks whether the connecting IP is covered by ip4:203.0.113.10 or Google's own SPF ranges
5. If yes: SPF pass. If no: SPF fail (or softfail with ~all)
6. The result is passed to DMARC evaluation alongside the DKIM result

Note that SPF validates the envelope sender (the MAIL FROM / Return-Path address), not the visible From: header. This distinction is critical — a phisher can pass SPF using their own domain in the envelope while showing your brand in the visible From. This is exactly why DMARC alignment is required.

SPF record syntax

v=spf1 [mechanisms] [modifiers] all

Common mechanisms:

| Mechanism | What it authorises | |-----------|-------------------| | ip4:x.x.x.x | A single IPv4 address | | ip4:x.x.x.x/24 | A CIDR range | | ip6:2001:db8::/32 | An IPv6 range | | include:_spf.google.com | All IPs from another domain's SPF | | a | The domain's own A records | | mx | The domain's MX records |

The all qualifier at the end:

| Qualifier | Result | Meaning | |-----------|--------|---------| | -all | Fail | Reject anything not listed | | ~all | Softfail | Accept but mark anything not listed | | ?all | Neutral | No policy | | +all | Pass | Allow everything (dangerous, never use) |

For production domains, use -all (hardfail) once you are confident all legitimate senders are listed.

The 10 DNS lookup limit

RFC 7208 caps SPF at 10 DNS lookups during evaluation. Every include:, a, mx, ptr, and exists mechanism counts toward this limit. Exceeding it causes permerror, which most receivers treat the same as a hard fail.

A typical enterprise domain hits this limit fast:

• Google Workspace: ~3 lookups
• Microsoft 365: ~4 lookups
• Mailchimp: 2 lookups
• HubSpot: 2 lookups

Total: already 11 — SPF permerror for every message.

How to fix it: Flatten your SPF by replacing include: mechanisms with the actual IP ranges they resolve to. Tools like IntoDNS.ai's SPF checker show your current lookup count and flag permerror before it reaches production.

SPF and DMARC alignment

SPF alone does not protect against the most common phishing vector: a forged From: header. For SPF to count toward DMARC, the envelope sender domain must align with the visible From: domain:

• Relaxed alignment (default): bounces.example.com aligns with example.com
• Strict alignment (aspf=s): domains must match exactly

If you use an ESP that sends with MAIL FROM: [email protected] but From: [email protected], SPF alignment fails for DMARC purposes even if SPF itself passes on the ESP's domain. In this case DKIM alignment must pass instead.

Common SPF mistakes

1. Missing senders. Every service that sends on your behalf needs to be in the record: transactional email (SendGrid, Mailgun), marketing (Mailchimp, HubSpot), CRM (Salesforce), helpdesk (Zendesk), e-commerce platforms, and your own mail servers. Check your DMARC aggregate reports to find senders that are failing.

2. Publishing multiple SPF records. RFC 7208 forbids more than one TXT record starting with v=spf1 at the same name. If you have two, receivers return permerror immediately. Merge them into a single record.

3. Using ~all permanently. Softfail (~all) is intended as a testing mode. In practice, many receivers accept softfail messages without marking them, defeating the purpose. Upgrade to -all once your senders are fully enumerated.

4. Subdomain blindspot. SPF at example.com does not cover mail.example.com or newsletters.example.com — each subdomain needs its own record, or receives no SPF protection.

5. Forgetting IPv6. If your mail servers have IPv6 addresses, add ip6: mechanisms. An SPF pass on IPv4 does not help when the server connects over IPv6.

Checking your SPF record

dig +short TXT example.com | grep spf
# or
nslookup -type=TXT example.com

IntoDNS.ai's free SPF check resolves all nested include: chains, counts your DNS lookups, validates syntax, and shows exactly which IPs are authorised — including the ones you may have forgotten.

SPF in 2026: still necessary but not sufficient

Gmail and Yahoo's 2024 bulk sender requirements made SPF (or DKIM) mandatory, and DMARC mandatory at p=none minimum. In practice, without both SPF and DKIM passing and DMARC at p=reject, your domain remains vulnerable to spoofing and your deliverability suffers. SPF is the starting point, not the finish line.