Loading...
WebShield Audit
High severity
Missing SPF Record
SPF (Sender Policy Framework) lists the IP addresses and hostnames authorized to send mail for your domain, and defines what receivers should do with mail from any other source.
Business risk
Without SPF, anyone can spoof mail from your domain and receivers have no mechanism to verify it. Gmail and Yahoo both require SPF for bulk senders since February 2024. For smaller domains, missing SPF still causes legitimate mail to land in spam (because DMARC has nothing to align against) and leaves you invisible to phishing campaigns impersonating your brand.
Technical details
RFC 7208 caps SPF evaluation at 10 DNS lookups per message. Every `include:` counts. `include:_spf.google.com` alone already chains 3 lookups. Nested SaaS providers blow the budget fast and then your SPF silently fails with a `permerror`. If you are close to the limit, flatten IPs or split senders onto subdomains (`mail.yourdomain.com`, `marketing.yourdomain.com`) with their own SPF records. Start with `~all` (softfail) while you audit senders, then move to `-all` (hardfail) once reports are clean.
How to detect it
SPF is a TXT record at the apex of your domain, starting with `v=spf1`. Only one SPF record is allowed per domain - if dig returns multiple, that is itself a finding (MX-validators treat duplicates as permerror). `checkdmarc` counts the DNS-lookup chain each `include:` triggers.
Read the SPF record
dig +short TXT yourdomain.com | grep spf1Audit the lookup count (must be <=10)
pip install checkdmarc && checkdmarc yourdomain.comOnline validator
https://mxtoolbox.com/spf.aspxCommon pitfalls
- Publishing two SPF records. SPF permits only one `v=spf1` TXT per domain. Two records cause `permerror` and DMARC alignment fails silently. Merge them.
- Exceeding the 10 DNS-lookup cap. `include:_spf.google.com` chains 3 lookups. Add a few SaaS providers and you hit the limit fast. Check with `checkdmarc` and consolidate or delegate senders to subdomains.
- Using `~all` (softfail) as the permanent stance. Softfail lets spoofed mail through to the inbox in some configurations. Move to `-all` (hardfail) once DMARC reports show no legitimate senders being failed.
- Listing individual IPs when the provider offers an `include:`. Providers rotate IPs - hard-coded lists go stale silently. Use the provider's `include:` mechanism instead.
- Forgetting subdomains that send mail. Apex SPF does not cover `mail.yourdomain.com` sending - each sending subdomain needs its own record, or a wildcard SPF delegation.
Remediation guide
External references
Frequently asked questions
Can I have multiple SPF records?
No. RFC 7208 explicitly says one. Multiple records cause a permanent error; receivers reject the message with "too many SPF records". Merge all senders into a single record.
~all or -all?
`-all` is the stronger stance (hardfail - mail is rejected). `~all` is softfail (mail is accepted but marked). Use `~all` during the audit phase while you identify every legitimate sender, then switch to `-all` once DMARC reports are clean.
I keep hitting the 10-lookup limit. What do I do?
Three options: (1) flatten by resolving `include:` chains to IPs (fragile - requires a tool to refresh daily), (2) delegate bulk senders to subdomains like `marketing.yourdomain.com` with their own SPF, (3) drop providers you do not actively use. Option 2 is usually the right answer.
Keep going
Related guide
Missing DMARC Policy
High severity · Email
Related guide
Missing DKIM Signature
High severity · Email
Related guide
Missing DNSSEC
Medium severity · DNS
Deep guide
DMARC: From p=none to p=reject, Safely
The alignment work between p=none and p=reject is the real DMARC project.
Free tool
MTA-STS Checker
Check your SMTP TLS policy the way receiving MTAs do.
Verify your fix
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.