---
title: "SPF Record Check: Read Yours, Count the Lookups"
description: "Run an SPF record check in your browser: paste your record, count the DNS lookups against the limit of ten, and fix what makes receivers ignore it."
canonical: "https://derrick-app.com/cold-email/spf-record-check"
category: "B2B Marketing"
updated: "2026-09-05"
---
# SPF record check: how to read yours, and the ceiling that breaks it
> An SPF record check reads the TXT record on your domain and lists the servers allowed to send email as you. It answers a permission question, not a deliverability one. The failure it most often misses is the ten DNS lookup ceiling: past ten, receivers return permerror and treat your SPF as absent, with no bounce and no warning. Outreach setups reach that ceiling faster than corporate ones because each sending tool adds its own include, so the structural fix is a separate sending domain with one record per subdomain.
*Canonical: https://derrick-app.com/cold-email/spf-record-check* ยท *B2B Marketing*
---
## SPF record check: what the result actually tells you
An **SPF record check** reads the TXT record published on your domain and tells you which servers you have authorised to send email as you. It answers one question, narrowly: is this sender on the list. It does not tell you whether your email reaches an inbox, and the gap between those two things is where most outreach setups quietly fail.
Most checkers hand you a green tick and stop. The three things that actually break a sending domain are further down: the ten DNS lookup ceiling, a policy that authorises everyone, and a record that was correct until you added a third sending tool. This page covers the check, then those three, from the position of someone running cold outreach rather than administering a corporate mail server. It sits in our wider [cold email cluster](https://derrick-app.com/cold-email).
## How to read an SPF record, mechanism by mechanism
A record is one line of text. Every element is a mechanism, and the ones that force the receiving server to make another DNS query are the ones that carry a cost.
| Mechanism | What it does | Costs a DNS lookup |
| --- | --- | --- |
| `v=spf1` | Version tag. Without it the whole record is ignored | No |
| `include:` | Delegates to another domain's record, typically a sending tool | Yes, and so does everything inside it |
| `a` / `mx` | Authorises the domain's own A or MX hosts | Yes, one each |
| `ip4:` / `ip6:` | Authorises an address or range directly | No, which is why flattening works |
| `ptr` | Reverse lookup. Deprecated, some receivers discard the record | Yes, and slowly |
| `~all` / `-all` | What to do with everyone else: softfail or hardfail | No |
If you are setting this up from scratch rather than repairing it, the [once per domain controls](https://derrick-app.com/cold-email/deliverability-checklist) cover the order to do it in. Read left to right, the record is a list of who may send, ending with a verdict on everyone not named. The verdict matters less than people think and the lookups matter far more.
## SPF record check: paste your record and count the lookups
The tools that do this are called an SPF checker, an SPF lookup or an SPF record checker, and they all read the same TXT record. Most query DNS for you from a domain name; the one below takes the record itself, so it also works on a draft you have not published yet. Paste the record you publish today. The analyser runs in your browser, counts the mechanisms that cost a lookup, and flags the structural faults that make receivers ignore the record.
Free checker
### SPF checker and record analyser
Paste the record published on your domain. Nothing leaves your browser.
Your SPF record
Paste a record and press Analyse.
This counts the lookup-causing mechanisms written IN your record. Each include: can itself contain more, which is exactly how a record that looks short goes over the limit. Treat the count as a floor, never as a ceiling.
If it flagged a problem, the two sections that follow explain what breaks and how to repair it, in the order that costs least. One honest limit first, and it is the important one: this counts the mechanisms written in your record. An `include:` resolves to another record that carries its own, so eight written mechanisms can be fifteen in practice. Treat the number as a floor.
## Writing an SPF record from scratch
A first record is three parts on one line: the version tag, one mechanism per sender you use, and a policy for everyone else. For a domain sending through a single provider that is `v=spf1 include:the-provider ~all`, and nothing more is needed on day one.
Two constraints govern what comes after. The record must fit in one DNS TXT string of 255 characters, and a longer one has to be split into several quoted strings that resolvers rejoin, which is a common source of records that break silently. And every sender you add later spends part of your lookup budget, so add them one at a time and re-check in between. Generators exist for this, but a record short enough to be correct is also short enough to write by hand.
## The ten DNS lookup limit, the failure nobody sees coming
The standard that defines SPF, RFC 7208, caps a receiving server at ten DNS lookups per evaluation. Go past it and the server returns **permerror**, which means it stops evaluating and treats your SPF as if it did not exist. Nothing bounces. Nothing warns you. Your authentication simply stops counting, and if you publish DMARC on top, the alignment it depends on quietly disappears.
This is a counting problem, not a syntax problem, which is why a record can pass a basic validator and still be dead. It is also cumulative and invisible: the tools you delegate to change their own records without telling you, so a record that counted nine last quarter can count eleven today without anyone touching it.
## Why an outreach setup breaks SPF faster than a corporate one
A company mail server usually resolves to one or two includes and stays there for years. An outreach setup accumulates. The sequencing tool, then a second one for a different segment, then the CRM that sends notifications, then a calendar tool, then a form handler. Each arrives with an `include:` and a reassuring setup guide, and none of them mentions the other four.
Three consequences worth planning for.
- **The ceiling arrives without an event.** No tool tells you that adding it took you from nine to eleven. The first symptom is a slow decline in placement, which reads exactly like a copy problem.
- **A separate sending domain is the structural answer.** Running outreach on its own domain keeps the primary record small, and gives each domain a lookup budget of its own. It also isolates reputation, which is the reason most teams do it anyway.
- **Subdomains do not inherit.** A record on the root does not cover `mail.example.com`. Each sending subdomain publishes its own, and forgetting this is the most common reason a new outreach domain fails authentication from day one.
**Related guide**
[Email deliverability checklist: 15 controls, sorted by cadence](https://derrick-app.com/cold-email/deliverability-checklist)
## What an SPF record check does not tell you
A passing SPF check proves one thing only: this server was on the list. It predicts nothing about the inbox, says nothing about the addresses you send to, and covers only the envelope sender. This is the part the tools leave out, and it decides whether the exercise was worth anything.
**It does not predict the inbox.** SPF is a permission list, not a reputation score. A perfectly authenticated message from a cold domain to an unengaged list still lands in spam. Authentication buys you the right to be judged on your merits, and nothing more.
**It says nothing about the addresses you send to.** Bounces are decided by list quality, not by your DNS. A record can be flawless while a tenth of your list is undeliverable, and that bounce rate damages the sender reputation your record was protecting.
**It only covers the envelope sender.** SPF validates the return-path domain, which your sending tool often controls. That is why SPF alone is not enough, and why DKIM and DMARC exist.
Put plainly, authentication is a gate you pass once. What you send to it afterwards is what decides the outcome, and that is the part covered in our guides on [subject line formats](https://derrick-app.com/cold-email/cold-email-subject-lines) and [send timing](https://derrick-app.com/cold-email/best-time-to-send-cold-emails).
## Fixing a record that exceeds the limit
Getting back under ten is almost always possible without flattening anything. Four moves, cheapest first: do them in order and stop as soon as you are under the ceiling.
1. **Remove what no longer sends.** Most over-limit records carry an include for a tool the team stopped using two years ago. This is free and it is usually enough.
2. **Replace an include with its IP ranges.** If a provider publishes a stable range, `ip4:` entries cost zero lookups. The tradeoff is real: when the provider changes its ranges, your record is wrong and nothing tells you.
3. **Split by subdomain.** Marketing on one subdomain, outreach on another, transactional on a third. Each gets its own record and its own ten. This is the option that keeps working as you add tools.
4. **Flatten, knowingly.** Automated flattening resolves everything to IPs and keeps it updated. It solves the count and creates a dependency, so treat it as a last resort rather than a default.
Re-run the check after each move rather than at the end, so you know which one bought you the headroom. And if you have just moved outreach onto its own domain, the copy side starts again from scratch too: our [six template formats](https://derrick-app.com/cold-email/cold-email-template) assume a domain that already authenticates.
**Related guide**
[Best time to send cold emails: what the data says](https://derrick-app.com/cold-email/best-time-to-send-cold-emails)
## SPF, DKIM and DMARC: which one your check should cover
SPF alone is the most common half-finished setup in outreach. The three records do different jobs and only work as a set.
| Record | What it proves | What breaks without it |
| --- | --- | --- |
| SPF | This server was allowed to send for this domain | Forwarding and unknown senders are indistinguishable |
| DKIM | The message was not altered and comes from the domain | SPF alone breaks on forwarded mail |
| DMARC | What receivers should do when the other two fail, plus reporting | You never find out that anything failed |
Start DMARC on the monitoring policy so the reports arrive before you enforce anything. The reports are also where a permerror surfaces on its own, without anyone thinking to go and look for it.
## The SPF record check mistakes specific to outreach setups
- **Publishing two SPF records.** Two TXT records starting with `v=spf1` invalidate each other. Merge them into one, always.
- **Leaving `+all` after a debugging session.** It authorises the entire internet to send as you, which is worse than publishing nothing.
- **Jumping straight to `-all`.** Hardfail before your sender list is complete blocks your own legitimate mail. Sit on `~all` until the reports are clean.
- **Checking the root and assuming the subdomain.** They are separate records. Check the exact domain in your return-path.
- **Treating a green tick as a deliverability verdict.** It is a permission check. The list you send to decides the rest.
## Key takeaways
- An SPF record check tells you who may send as you, not whether you reach the inbox.
- The ten DNS lookup ceiling is the failure that arrives silently, and includes nest, so count conservatively.
- Outreach setups hit that ceiling faster because tools accumulate one include at a time.
- A separate sending domain, with its own record per subdomain, is the fix that keeps working.
- `~all` while you are still adding senders, `-all` once the list is stable, never `+all`.
- SPF, DKIM and DMARC are one set. DMARC on monitoring is how a permerror becomes visible.
Once authentication is in order, the variable that still decides your bounce rate is the list itself, and that one is not a DNS problem. Derrick finds and verifies addresses from the Google Sheet, the AI assistant or the API where your list already lives, with [Email Verification](https://derrick-app.com/features/email-verification) at 1 credit per email, billed only when a result comes back. Verification sits on the paid plans; the free plan and its 100 credits per month are there to try the finding and enrichment side on a real batch first. [Start with the free plan](https://derrick-app.com/?utm_source=seo&utm_medium=cocon&utm_campaign=ce-spf-record-check&utm_content=cta-primary), or read the rest of the [cold email cluster](https://derrick-app.com/cold-email).
We also publish one email every 2 weeks with what we are measuring on cold outreach and data quality. [Subscribe from the homepage](https://derrick-app.com/?utm_source=seo&utm_medium=cocon&utm_campaign=ce-spf-record-check&utm_content=newsletter).
## Use Derrick in Claude (MCP) or via API
Derrick isn't only a Google Sheets add-on. The same B2B data enrichment runs as an MCP server (use it directly inside Claude and other AI agents) and as a REST API:
- **Claude / AI agents (MCP)**: connect the Derrick MCP server, then enrich from chat. Setup: /mcp
- **REST API**: call the same enrichment endpoints from your own stack (PLUS plan and up). Docs: https://app1.derrick-app.com/api/v1/docs/
## FAQ
### How do I check my SPF record?
Read the TXT record published on the exact domain in your return-path, then check three things in order. First, that it starts with v=spf1 and that only one such record exists, because two invalidate each other. Second, the number of mechanisms that force a DNS lookup: include, a, mx, ptr, exists and redirect, against a ceiling of ten. Third, the final all mechanism. An SPF checker does all three for you, either by querying DNS from a domain name or by reading a record you paste.
### What is the SPF 10 DNS lookup limit?
The specification caps a receiving server at ten DNS lookups when evaluating your record. Past that it returns permerror, stops evaluating, and treats your SPF as if it were not published. Nothing bounces and nothing warns you, which is what makes it dangerous. It is also cumulative in a way you do not control: the providers you delegate to through include can change their own records, so a record that counted nine last quarter can count eleven today without anyone touching yours.
### Why does my SPF record pass a validator but still fail?
Because most validators check syntax and stop. A record can be perfectly formed and still exceed the ten lookup ceiling once nested includes are resolved, which produces permerror at evaluation time rather than a syntax error. The other common case is checking the wrong domain: SPF is evaluated on the return-path domain, which your sending tool often sets to a subdomain, and a record on the root does not cover a subdomain.
### Should I use ~all or -all?
Use ~all, softfail, while you are still adding senders, and move to -all, hardfail, once your sender list is stable and your DMARC reports come back clean. Going to -all too early blocks your own legitimate mail, typically from a tool nobody remembered to add. Never publish +all: it authorises the entire internet to send as your domain, which is worse than publishing no record at all, and it usually survives a debugging session by accident.
### Does a valid SPF record mean my emails reach the inbox?
No. SPF is a permission list, not a reputation score. A perfectly authenticated message sent from a cold domain to an unengaged or unverified list still lands in spam. Authentication buys you the right to be judged on the message itself, and after that the variables are the domain's reputation and the quality of the list. A flawless record does nothing about a bounce rate driven by undeliverable addresses.
### What is the difference between an SPF checker, an SPF lookup and an SPF record generator?
A checker and a lookup are the same thing under two names: both read the SPF record published on a domain and report what it contains, usually with a verdict on syntax and on the ten lookup ceiling. A generator does the opposite job, assembling a record from the list of providers you declare. In practice you use a generator once, when you set the domain up, and a checker every time you add a sender or a campaign underperforms. Whichever you use, a domain must end up with exactly one SPF record: two TXT records starting with v=spf1 invalidate each other and leave the domain with no valid policy.
### How do I fix an SPF record that exceeds the lookup limit?
Four moves, cheapest first. Remove the includes for tools you no longer use, which is free and usually enough. Replace an include with the provider's published ip4 ranges, which cost no lookups but go stale silently when the provider changes them. Split your sending across subdomains so each gets its own budget of ten. Flatten as a last resort, since automated flattening solves the count but creates a dependency. Re-check after each move so you know which one bought the headroom.
### Do I need DKIM and DMARC as well as SPF?
Yes, they do different jobs and only work as a set. SPF proves a server was allowed to send for the domain, but it breaks on forwarded mail. DKIM signs the message so the receiver can confirm it was not altered and comes from the domain, which survives forwarding. DMARC tells receivers what to do when the other two fail and, more usefully, sends you reports. Start DMARC on the monitoring policy: those reports are where a permerror surfaces on its own, without anyone thinking to go and look for it.
## Related
- [Cold Email Templates That Work in 2026, and the Data Behind Them](https://derrick-app.com/cold-email/cold-email-template)
- [Cold Email Subject Lines That Earn the Open, and the Data Behind Them](https://derrick-app.com/cold-email/cold-email-subject-lines)
- [The email deliverability checklist, sorted by when each control actually happens](https://derrick-app.com/cold-email/deliverability-checklist)
- [Best time to send cold emails, and the data problem underneath it](https://derrick-app.com/cold-email/best-time-to-send-cold-emails)
- [Cold email software: the seat price hides where campaigns actually fail](https://derrick-app.com/cold-email/cold-email-software)
- [Email deliverability tools: which one answers which symptom](https://derrick-app.com/cold-email/deliverability-tools)