SPF Record: Strict Configuration (-all) for Email Anti-Spoofing
SPF is the foundation of email authentication. Learn how to configure a strict SPF (-all), manage the 10-lookup limit, and avoid errors that invalidate your policy.
In Short
SPF (Sender Policy Framework, RFC 7208) is a DNS TXT record that declares which IPs are authorized to send email for a domain. It is the foundation for DMARC—without correct SPF, DMARC cannot decide if an email is authentic. Lack of SPF means any attacker can send email with MAIL FROM: <anything>@company.com from any IP.
Configuration takes 2-4 hours (including inventory of sending sources) and is the first anti-spoofing measure we recommend to any organization that receives or sends email.
How SPF Works
When a recipient mail server receives an email with MAIL FROM: ceo@company.com:
- It looks up the TXT record for
company.comin DNS — findsv=spf1 ip4:91.234.56.78 include:_spf.google.com -all - It checks if the actual SMTP sender IP is in the declared list
- If yes → SPF Pass (likely legitimate)
- If no → SPF Fail. With
-all(hard fail), the receiver rejects or marks as spam
Important note: SPF verifies MAIL FROM (envelope sender), NOT the From: header displayed to the user. For From: header protection, you need additional DMARC.
Attacks Prevented by SPF
Mass Spam from Compromised IPs
Attackers controlling botnets (tens of thousands of infected residential IPs) send millions of spoofed emails. With strict SPF, every recipient verifies the IP → instant rejection.
Business Email Compromise (BEC)
An attacker rents a VPS for $5/month, configures Postfix, and sends emails as cfo@company.com to accounts@partner.com with a fake invoice. Without SPF (or with permissive ~all/?all), Gmail/Outlook deliver to the Inbox. With -all, it lands in Spam or is rejected completely.
Subdomain Spoofing
If SPF exists on company.com but is missing on mail.company.com or newsletter.company.com, the attacker uses the unprotected subdomain. Best practice: Explicit SPF on every subdomain that sends email.
Anatomy of a Correctly Configured SPF
company.com. IN TXT "v=spf1 ip4:91.234.56.78/32 ip4:91.234.56.79/32 include:_spf.google.com include:sendgrid.net include:mailgun.org -all"Decoded:
v=spf1— SPF versionip4:91.234.56.78/32— Fixed IP of your own MTA (self-hosted Postfix/Exim)include:_spf.google.com— Google Workspace (delegates their IP list)include:sendgrid.net— SendGrid for transactional emailsinclude:mailgun.org— Mailgun for notifications-all— hard fail for anything else (rejection at receiver)
SPF Fail Types
| Mechanism | Receiver Behavior |
|---|---|
-all (hard fail) | Reject or Spam — recommended for production |
~all (soft fail) | Marker only — used during initial deployment |
?all (neutral) | No effect — practically disabled SPF |
+all (pass all) | Dangerous — any IP passes SPF; never use |
The 10 DNS Lookup Limit (Major Practical Issue)
RFC 7208 limits SPF to 10 DNS lookups. Each include:, a:, mx:, exists:, redirect: consumes one lookup. In complex organizations (Google Workspace + SendGrid + Mailgun + Salesforce + HubSpot + 5 other SaaS), exceeding this limit is easy.
When SPF exceeds 10 lookups → receivers treat it as PermError = SPF failed = potential rejection.
How to Check
dig TXT company.comTool: https://www.kitterman.com/spf/validate.html — visualizer + lookup counter.
Solution: SPF Flattening
Dedicated tools (EasyDMARC, Cisco SPF flattening, dmarcian) take your list of include: records and resolve them into a list of static IPs — a single lookup. Recommended: weekly refresh because ESPs (Google, SendGrid) change their IPs periodically.
Step-by-Step Implementation
Step 1 — Inventory of Legitimate Sources
All systems sending email for your domain:
- Own MTA (Postfix, Exim) — fixed IP
- Email Service (Google Workspace, Microsoft 365)
- Marketing Tools (Mailchimp, SendGrid, Mailgun, Postmark)
- CRM/ERP (Salesforce, HubSpot, NetSuite)
- Monitoring (PagerDuty, Datadog) — if they send alerts from your domain
- Notification Scripts (cron jobs sending reports)
Step 2 — Build SPF TXT Record
Start with ~all (softfail) to monitor:
company.com. IN TXT "v=spf1 ip4:91.234.56.78 include:_spf.google.com include:sendgrid.net ~all"Allow 14-30 days to identify forgotten sources (appearing in DMARC reports as SPF fail).
Step 3 — Switch to -all (Hard Fail)
After DMARC reports confirm no more false-positive SPF fails:
company.com. IN TXT "v=spf1 ip4:91.234.56.78 include:_spf.google.com include:sendgrid.net -all"Step 4 — Subdomains
For each subdomain sending email separately:
mail.company.com. IN TXT "v=spf1 ip4:91.234.56.78 -all"
newsletter.company.com. IN TXT "v=spf1 include:sendgrid.net -all"For subdomains that do NOT send email (anti-abuse):
old.company.com. IN TXT "v=spf1 -all"Common Confusions
“SPF is enough — I don’t need DMARC.” — Incorrect. SPF does not protect the From: header displayed to the user. DMARC verifies alignment between From: and the domain authenticated by SPF/DKIM.
“I use ~all to be safe.” — Common confusion. ~all allows attackers to exploit ambiguity — many receivers deliver SPF softfail emails to the Inbox. -all is the standard in 2026.
“I have 11 lookups and it still works.” — Random chance. Some receivers tolerate 11-12, others fail strictly at 11. High deliverability risk.
Check Now
ARTEMIS automatically checks SPF in any Site audit (2 EUR) — plus DMARC, DKIM, MTA-STS, BIMI, DNSSEC, CAA, and 30+ technical checks.
🔗 Complementary CAI Technology Solutions
- ARTEMIS — Complete technical email auth audit (SPF + DKIM + DMARC + MTA-STS + BIMI) + 30+ infrastructure checks.
- Lexnomia — Auditor-grade NIS2 / GDPR assessment — email authentication is an explicit requirement under NIS2 Art.21.2.j.
- BeLegal — Free EU compliance check in 5 minutes.
- Auditope — Holistic web audit (SEO + AI search + GDPR + Performance).
- AriaUnited — EU PNRR funding consultancy for investments in secure email infrastructure (anti-spam gateway, internal DMARC reporting platform).
Questions? tehnic@caitech.ro