SPF glossary
What does v=spf1 mean at the start of an SPF record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
v=spf1 is the version identifier that marks a TXT record as an SPF record. It must be the exact first term — receivers ignore any TXT record that doesn't start with it. A domain must have at most one: two or more records starting v=spf1 is a permerror, and SPF breaks entirely.
v=spf1 at a glance | |
|---|---|
| Tag | v (version) |
| Valid values | spf1 — the only version there is; there is no v=spf2 |
| Default | Required — a TXT record that doesn't begin with v=spf1 simply isn't an SPF record. |
| Where it goes | The exact first term of the record, e.g. v=spf1 include:_spf.google.com -all |
How v=spf1 works
SPF lives in an ordinary TXT record published on the domain name itself — at the apex for yourdomain.com, with no special prefix like DMARC's _dmarc. Receivers fetch the domain's TXT records and treat the one starting v=spf1 as its SPF policy. That's why the version tag must be the exact first characters: it's the marker that says “this TXT record is my SPF record.”
One domain, one SPF record. If a receiver finds two or more TXT records starting v=spf1, RFC 7208 says the result is a permerror — SPF fails to evaluate at all. This is one of the most common real-world SPF breakages: someone adds a second record for a new email tool instead of merging the new mechanism into the existing record.
And no, there is no v=spf2. The spf2.0/pra strings in old documentation belong to Sender ID, an abandoned Microsoft experiment. Publish v=spf1 and nothing else.
Correct record vs common mistake
Correct
v=spf1 include:_spf.google.com ip4:192.0.2.10 -allOne record: version tag first, your senders in the middle, a catch-all at the end.
Common mistake
v=spf1 include:_spf.google.com -all
v=spf1 include:sendgrid.net -allTwo SPF records on one domain is a permerror — receivers can't pick one, so SPF breaks entirely. Merge the includes into a single record.
Generate your SPF record
Build a correct SPF record for your domain — add your senders, copy the TXT record. Free, no signup.
Who sends email for this domain?
Each service adds its documented include mechanism.
From your provider's docs, e.g. spf.example-esp.com — commas or spaces between multiple. Some services (Klaviyo, HubSpot, Mailchimp Transactional) authenticate through their own CNAME records instead of a shared include — check their DNS settings page.
How should receivers treat everyone else?
Your SPF record
0/10 DNS lookupsPublish as a TXT record at the domain root. One SPF record per domain — if one exists, merge into it instead of adding another.
yourdomain.com (or @)
v=spf1 ~all
Record type: TXT · ip4/ip6 mechanisms don't count against the 10-lookup limit.
After you publish
- Add the TXT record at your DNS host.
- Verify it with the free SPF checker.
- SPF alone doesn't stop spoofing — pair it with DKIM and a DMARC policy. Generate one with the DMARC record generator.
Troubleshooting v=spf1
| Issue | Likely cause | Fix |
|---|---|---|
| Checker says 'no SPF record found' but a TXT record exists | The record doesn't begin with the exact string v=spf1 — leading whitespace, a typo, or text pasted before it | Make v=spf1 the very first characters of the TXT value, then re-check |
| Mail broke right after adding a new email tool | The tool's setup guide had you create a second v=spf1 record next to the existing one | Delete one record and merge: a single v=spf1 line containing both includes, ending in -all |
| Record edits don't seem to take effect | DNS TTL — receivers are still serving the cached old record | Wait out the TTL and re-test; lower the TTL ahead of planned SPF changes |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
Across 50–200 client domains, duplicate v=spf1 records are one of the most common inherited messes: a previous provider's record sits next to yours, and the domain permerrors while looking “configured” in DNS. Every tool onboarding is another chance for a client to paste a second record instead of merging — and the breakage is silent until mail starts failing.
Trusted by MSPs
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
Enforce it — don't just monitor it
A broken version line doesn't announce itself — it shows up as SPF quietly contributing nothing. Palisade reads every client domain's DMARC reports, so a record that stopped evaluating surfaces as evidence, and each domain still advances safely toward `p=reject` on data, not guesswork.
Free 15-day trial · No credit card · Your own domain free forever (NFR)