Tutorials

How SPF Records Work: The Easy Half of Email Authentication

Published 2026-06-02

SPF in plain language: what the record does, how the syntax decomposes, and why it alone is not enough to stop email spoofing.

The Core Idea

SPF (Sender Policy Framework) is a domain owner's public statement saying: 'these specific IP addresses and hostnames are allowed to send email claiming to be from my domain. Anything else, treat with suspicion.' It's published as a DNS TXT record at the apex of the domain (e.g. example.com) and is checked by receiving mail servers during the SMTP conversation, before the message body is even transmitted.

A Real-World Example

If you query dig +short TXT google.com today, you'll see something like:

v=spf1 include:_spf.google.com ~all

Decoded:

v=spf1 — SPF version 1. The only version in production use.
include:_spf.google.com — defer the IP list to another SPF record at _spf.google.com. This is how big senders manage massive IP ranges.
~all — soft fail. Any IP not listed should be marked as suspicious but not rejected outright.

The Qualifier Symbols

Every mechanism in an SPF record can be prefixed with a qualifier:

+ (pass) — default if no prefix. The IP is authorised.
? (neutral) — no policy. Treat as if no SPF record exists.
~ (soft fail) — suspected unauthorised. Usually means accept but mark.
- (hard fail) — unauthorised. Reject the message.

~all at the end of an SPF record means 'any IP I haven't explicitly listed: soft fail.' -all means 'reject anything not listed.' Strict senders use -all; cautious senders use ~all.

The Common Mechanisms

ip4:192.0.2.0/24 — a specific IPv4 range
ip6:2001:db8::/32 — a specific IPv6 range
a — the A record for the SPF domain itself
mx — the MX servers for the domain
include:other-domain.com — defer to that domain's SPF record
exists:check.example.com — rare; passes if the DNS lookup succeeds

The 10-Lookup Limit

SPF specs limit the total DNS lookups during evaluation to 10. include, a, mx, and exists all count toward this limit, and nested includes count their inner lookups too. Exceeding 10 results in a permerror that some receivers treat as a hard fail.

This is the most common SPF mistake: an organisation adds a marketing platform with include:, then a CRM, then another tool, until the count exceeds 10 and the whole record breaks silently. Audit periodically with tools like dmarcian.com/spf-survey.

Why SPF Alone Isn't Enough

SPF checks the envelope sender (the SMTP MAIL FROM) — not the visible From: address in the email headers. A spammer can pass SPF for their own domain while putting your bank's name in the visible From: field. That's why DMARC was invented: it adds an alignment check requiring the SPF-validated domain to match the visible From: domain.

Common Failures

Forgot to add a new email-sending service to the SPF record. The service's mail starts going to spam.
SPF chained too deeply, blew through the 10-lookup limit. Random mail starts failing.
Multiple TXT records starting with v=spf1 at the same domain. Spec says only one is allowed; some receivers fail evaluation entirely.
Used ~all when -all was expected. Strict receivers might still accept spoofed mail.

Practical Takeaway

SPF is the easy half of email authentication: it's just a single TXT record. DKIM signing requires cryptographic key management. DMARC requires understanding the alignment rules. If you run a domain, publishing SPF is the cheapest deliverability + anti-spoofing improvement you can make.