SPF Record Checker: How to Test, Read, and Fix Your SPF Record
Email is still the number-one way attackers break into organisations — and the cheapest trick in the book is pretending to be you. The FBI's Internet Crime Complaint Center logged 193,407 phishing and spoofing complaints in 2024, more than any other crime type, and $2.77 billion lost to business email compromise (IC3 2024 Annual Report). The first line of defence against someone forging your domain is a correctly published SPF record — and the fastest way to know yours is healthy is to run it through an SPF record checker.
This guide explains what SPF is, how to read a record line by line, how to check it manually and with a free tool, and the exact errors a checker catches before they wreck your deliverability.
Quick check: FortifyNet's free 60-second scan validates your SPF, DKIM and DMARC together. Run a free scan and see your email-authentication score instantly.
What is an SPF record?
SPF (Sender Policy Framework) is an email-authentication standard, defined in RFC 7208, that lets a domain owner publish the list of mail servers allowed to send email on behalf of their domain. It lives in DNS as a single TXT record that begins with v=spf1. When a receiving server accepts a message, it looks up that record and checks whether the sending server's IP address is authorised.
A typical record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 ~all
One crucial nuance: SPF authenticates the envelope sender (the hidden MAIL FROM / Return-Path address), not the From: address your recipients actually see. That gap is exactly why SPF needs DMARC alongside it — more on that below.
Related guide: DNS Security Configuration: SPF, DMARC, DNSSEC & CAA Explained
Why you need an SPF record checker
Since February 2024, Google and Yahoo have required SPF for every sender, plus full SPF + DKIM + DMARC for anyone sending 5,000 or more messages a day to their users. Microsoft began enforcing the same rules in May 2025 (Red Sift). As of November 2025, Gmail rejects non-compliant bulk mail outright with 550 errors instead of deferring it. A single typo in your SPF record can now mean your invoices, password resets and newsletters bounce — not land in spam, but bounce.
A checker matters because SPF fails silently. Your mail keeps flowing until the day a receiver decides your record is broken — and then it doesn't. Running a checker turns those invisible problems into a clear pass or fail you can act on.
How to read your SPF record
An SPF record is a list of mechanisms (which senders are allowed) and qualifiers (what to do with everyone else).
Common mechanisms are ip4 / ip6 (a specific address or range), a (the domain's A record), mx (its mail servers), include (delegate to another domain's SPF, such as your email provider) and all (matches everything, always placed last).
The qualifier in front of all is the most important character in the entire record:
| Qualifier | Symbol | SPF result | What receivers typically do |
|---|---|---|---|
| Pass | + | Authorised | Deliver normally |
| Fail (hardfail) | -all | Not authorised | Reject the message |
| Softfail | ~all | Probably not authorised | Accept, but mark as suspicious |
| Neutral | ?all | No assertion | Deliver; no opinion |
Best practice in 2026 is to pair ~all (softfail) with a DMARC p=reject policy. M3AAWG and most deliverability teams now recommend this combination because DMARC becomes the real enforcement layer, while softfail avoids accidentally blocking a forgotten legitimate sender (Valimail). Never publish +all — it authorises the entire internet to send as you.
How to check your SPF record (step by step)
You can inspect any domain's SPF record yourself from a terminal:
- macOS / Linux:
dig TXT example.com +short - Windows:
nslookup -type=TXT example.com
Look for the line that starts with v=spf1. If you see two of them, that is already a problem (see below). Reading the raw record tells you what is published, but it will not count DNS lookups or flag policy mistakes — that is where a dedicated checker earns its keep.
To check SPF, DKIM and DMARC in a single pass, run FortifyNet's free scan: enter your domain and you will get each record parsed, the DNS-lookup count, and a prioritised list of fixes in about a minute.
The 10-DNS-lookup limit (the error most checkers catch)
This is the single most common SPF failure, and it stays invisible until it bites. RFC 7208 states that an SPF evaluation may trigger at most 10 DNS lookups. The include, a, mx, ptr and exists mechanisms and the redirect modifier each count; ip4, ip6 and all do not. Go over 10 and the receiver returns a PermError, which fails SPF for every message you send (DMARCLY).
There is a quieter second cap too: a maximum of 2 "void" lookups (mechanisms that resolve to nothing). A dead include pointing at a discontinued vendor can tip you over it.
It is easy to breach 10 lookups without realising. Each include: for a SaaS vendor (Google, Microsoft 365, a CRM, a help desk, a marketing platform) can itself contain nested includes, so three or four vendors is often enough. The fix is "SPF flattening": replace nested includes with the IP ranges they resolve to, or consolidate vendors.
Common SPF errors an SPF record checker flags
| What the checker finds | Result it triggers | How to fix it |
|---|---|---|
| More than 10 DNS lookups | PermError | Flatten or remove include: entries; consolidate senders |
| More than 2 void lookups | PermError | Delete includes, a or mx that resolve to nothing |
| Two or more SPF records | PermError | Merge everything into one v=spf1 TXT record |
| A string over 255 characters | Invalid / truncated record | Split into multiple quoted strings inside the same TXT record |
+all present | Passes every forgery | Replace with ~all or -all immediately |
No all mechanism | Ambiguous policy | End the record with ~all (or -all) |
The email-authentication gap, in one chart
Most domains still get this wrong. Of 73.3 million domains analysed in December 2025, 83.9% had no DMARC record at all and only 2.5% enforced p=reject — meaning the vast majority can be spoofed with little resistance (DMARC adoption research, 2025). SPF is the foundation that makes the rest possible.
Source: DMARC adoption research, December 2025 (73.3M-domain sample). SPF feeds the DMARC checks shown here.
SPF best-practice checklist
- Publish exactly one
v=spf1TXT record per sending domain. - Authorise every legitimate source: your mail host, marketing platform, CRM, ticketing system and any server that sends on your behalf.
- Keep total DNS lookups at or under 10; flatten when you add vendors.
- End with
~alland back it with DMARCp=reject(or use-allon parked, non-sending domains). - Add SPF for subdomains and parked domains too — attackers love unused ones. A domain that never sends mail should publish
v=spf1 -all. - Re-check after every change to your email vendors; SPF drifts as your stack changes.
SPF, DKIM and DMARC: the full picture
SPF on its own is necessary but not sufficient. Three records work together:
- SPF authorises sending servers (the envelope sender).
- DKIM cryptographically signs each message so it cannot be tampered with in transit.
- DMARC ties SPF and DKIM back to the visible
From:domain (alignment), tells receivers what to do when authentication fails, and emails you reports.
You need all three to satisfy Gmail, Yahoo and Microsoft — and to actually stop spoofing. Once your SPF passes, continue with our DNS security guide, and use the MXToolbox alternative for ongoing DNS and mail-record checks.
Frequently asked questions
How often should I check my SPF record? After every change to your email providers, and at least once a quarter. SPF silently drifts as you add and drop SaaS tools.
Can I have two SPF records? No. A domain must publish exactly one v=spf1 TXT record; two or more cause a PermError. Combine them into a single record.
Does SPF stop all spoofing? No. SPF only checks the envelope sender, so attackers can still forge the visible From: address. DMARC closes that gap by enforcing alignment — which is why you need both.
What is the difference between ~all and -all? ~all (softfail) tells receivers that unlisted senders are probably unauthorised but to accept and flag them; -all (hardfail) tells them to reject outright. Most senders use ~all plus DMARC enforcement.
Is a free SPF record checker accurate? Yes. A good checker performs the same DNS resolution and lookup counting that a receiving mail server does. FortifyNet's scan also validates DKIM and DMARC in the same pass.
Check your SPF record now
A broken SPF record is invisible until your email stops arriving — and with Gmail, Yahoo and Microsoft now rejecting unauthenticated mail outright, you cannot afford to guess. Run FortifyNet's free 60-second scan to validate your SPF, DKIM and DMARC, count your DNS lookups and get a clear, prioritised fix list. No signup required.
Originally published at fortifynet.com. Run a free 60-second security scan of your own site at fortifynet.com.