What is an SPF record and how do I check mine?
SPF is fifteen minutes of work that decides whether your invoices reach anyone. It also fails silently, in a way nothing in your mail client will ever tell you about.
An SPF (Sender Policy Framework) record is a single DNS TXT record on your domain that lists which mail servers are allowed to send email using your domain in the envelope sender. It starts with v=spf1 and ends with an all mechanism that says what to do with everyone else. You may publish exactly one per domain, and evaluating it must not require more than ten DNS lookups — exceed either limit and SPF returns a permanent error, which most receivers treat as no SPF at all.
Reading the syntax
A typical record: v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all. Each term after the version is a mechanism, evaluated left to right, and the first one that matches decides the result.
| Mechanism | Means | DNS lookups it costs |
|---|---|---|
| v=spf1 | Version marker — must be first | 0 |
| ip4: / ip6: | This literal address or CIDR range may send | 0 |
| include: | Also apply the SPF record at this domain | 1, plus whatever that record costs |
| a | The domain's own A record may send | 1 |
| mx | The domain's mail servers may send | 1, plus one per MX host |
| ptr | Reverse-DNS match — deprecated, do not use | 1 and slow |
| exists: | Pass if this name resolves at all | 1 |
| redirect= | Use this other domain's record instead | 1 |
| ~all | Soft fail everyone else | 0 |
| -all | Hard fail everyone else | 0 |
| ?all | Neutral — equivalent to publishing nothing | 0 |
| +all | Anyone may send as you. Never publish this. | 0 |
The results a receiver can get
| Result | When | Typical receiver behaviour |
|---|---|---|
| pass | Sending IP matches a mechanism | Delivered; contributes to DMARC alignment |
| fail | No match and the record ends in -all | Rejected or junked |
| softfail | No match and the record ends in ~all | Accepted, marked suspicious |
| neutral | Record ends in ?all | Treated as no policy |
| none | No SPF record exists | Treated as no policy — and increasingly penalised |
| permerror | Syntax error, two records, or over 10 lookups | Treated as no policy. This is the silent failure. |
| temperror | DNS timeout during evaluation | Usually retried |
Why this became mandatory in 2024
SPF was optional for twenty years. It stopped being optional on 1 February 2024, when Google began requiring SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day to Gmail addresses, along with one-click unsubscribe and a spam-complaint rate below 0.3%. Microsoft applied equivalent requirements to Outlook.com from 5 May 2025. Between them those two decisions cover most consumer inboxes, so the practical position now is that a bulk sender without all three records does not reach people.
| Record | Proves | Lives at |
|---|---|---|
| SPF | This server was permitted to send for this domain | example.com (TXT) |
| DKIM | This message was signed by the domain and not altered in transit | selector._domainkey.example.com (TXT) |
| DMARC | What to do when SPF and DKIM disagree with the visible From address | _dmarc.example.com (TXT) |
Sources: IETF RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), Google Workspace Email sender guidelines (effective 1 February 2024) and Microsoft’s Outlook.com sender requirements (effective 5 May 2025).
Check your own numbers
Read the live TXT records for any domain, including its SPF record.
Frequently asked
What is the difference between ~all and -all?
~all is a soft fail: mail from an unlisted server should be accepted but marked suspicious. -all is a hard fail: it should be rejected. Start with ~all while you find out which systems send on your behalf, because the list is always longer than you think - invoicing, CRM, helpdesk, the website contact form. Move to -all once a few weeks of DMARC reports show nothing legitimate is failing.
What is the 10-lookup limit and how do I know if I have hit it?
Every include, a, mx, ptr and redirect in your record costs a DNS lookup, and so does every one of those inside the records they point at. RFC 7208 caps the total at ten; past that, receivers return permerror and your SPF is effectively absent. Three or four SaaS senders will do it. The fixes are flattening - replacing includes with the IP ranges they resolve to, at the cost of having to maintain them - or removing senders you no longer use.
Does SPF stop people spoofing my domain?
Partly, and less than its name suggests. SPF authenticates the envelope sender, which recipients never see, not the From: header they actually read. A spoofer can pass SPF on their own domain while displaying yours in the From line. Closing that gap is exactly what DMARC does, by requiring the authenticated domain to align with the visible one.
Do I need SPF if I do not send email from my domain?
Yes, and it is more important than for a domain that does. A domain with no SPF record is the easiest thing in the world to forge. For a domain that sends nothing, publish v=spf1 -all and a DMARC record with p=reject - together they tell every receiver that no mail claiming to be from this domain is ever legitimate.
Related answers
Need email authentication checks inside your own product?
We build SPF, DKIM, DMARC and MX validators as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.
Request received
Thanks — we will reply within one business day. Meanwhile, all 164 tools are free to use, no signup.