An SPF record is a public list of servers allowed to send email for your domain. What it does, how it is checked, and why cold email needs it.
An SPF record is a single line of text published in your domain's DNS that lists which mail servers are allowed to send email using your domain name. When a receiving server gets a message claiming to be from you, it checks that record: if the sending server is on the list, SPF passes; if not, SPF fails. It exists to stop anyone from forging your domain as the sender. For cold email, a missing or broken SPF record is one of the fastest routes to the spam folder. This is the definition; for the setup walkthrough, see our SPF DKIM DMARC setup guide.
An SPF (Sender Policy Framework) record is a DNS TXT record on a domain that specifies which IP addresses and mail services are authorized to send email on that domain's behalf. Receiving mail servers check the SPF record against the connecting server's address to decide whether the message's claimed sender domain is legitimate, which helps block sender spoofing.
It answers one question for the receiving server: "Is the machine trying to send this email actually allowed to send email for the domain in the From address?" Your domain publishes the answer as a public list. When mail arrives, the recipient's server compares the connecting server's IP address to that list. A match is an SPF pass. No match is an SPF fail or softfail.
The point is anti-spoofing. Without SPF, anyone can send email with "from: you@yourcompany.com" in the envelope, and receiving servers have no way to tell it apart from your real mail. SPF gives them a way. It does not encrypt anything or check the message contents; it only validates the sending server. That is why SPF is one of three records, alongside DKIM and DMARC, that together authenticate email.
For cold outreach specifically, receiving servers weight authentication heavily. A domain with no SPF record looks unauthenticated, and unauthenticated bulk-style mail is treated as suspicious by default. See cold email deliverability guide and how to improve email deliverability.
It is a DNS TXT record on the root of your domain. A simple one looks like this: v=spf1 include:_spf.google.com ~all. Reading it left to right: v=spf1 declares it is an SPF record; include:_spf.google.com says "Google's mail servers are authorized to send for this domain"; ~all is the policy for everything not listed, in this case softfail.
Real records often have several include: entries, one per sending service: your mailbox provider, your marketing platform, your cold email tool, your CRM's transactional mail. Every service that sends mail as your domain needs to be represented, or its mail will fail SPF.
The record must be a single TXT record. If a domain has two separate v=spf1 records, SPF breaks entirely, and neither one is honored. When you add a new sending tool, you merge its include: into the existing record rather than creating a second one. See the common errors section of our setup guide.
They are the catch-all policy at the end of the record, and they tell receiving servers what to do with mail from a server that is not on the list.
Most senders start with ~all and only move to -all once every sending source is confirmed in the record. In practice, with a strong DMARC policy in place, the difference between ~all and -all matters less than it once did, because DMARC's failure policy does the heavy lifting. ~all remains the pragmatic default for outbound sales infrastructure because it avoids the forwarding-related false rejections that -all can cause.
SPF has a technical constraint worth knowing: a receiving server will only perform up to 10 DNS lookups while evaluating your record. Each include:, a, mx, and redirect mechanism counts, and some include: entries chain into more lookups internally. Exceed 10 and the whole record returns a permerror, which most servers treat as a fail.
This is why teams with many sending tools sometimes hit SPF problems that look random. The fix is to consolidate: remove services you no longer use, use flattening tools that resolve includes into IP ranges, or route mail through fewer providers. A caution on flattening: it hard-codes your provider's current IP ranges into your record, so if the provider changes those ranges, your SPF silently breaks until you update it. Prefer removing unused includes over flattening where you can. See how to set up cold email infrastructure.
One quirk worth knowing: SPF breaks on forwarding. When a message is forwarded, the forwarding server sends it on from its own IP address, which is not on the original domain's SPF list. So a legitimate email that gets auto-forwarded, say a prospect forwards your note to a colleague, or a shared mailbox relays it, can SPF-fail at the second hop even though it passed at the first.
This is a big reason ~all (softfail) is preferred over -all (hardfail) for most senders, and a big reason DMARC alignment leans on DKIM: a DKIM signature survives forwarding because it travels with the message, while SPF does not. The practical takeaway for cold email: do not rely on SPF alone. A domain with SPF only, no DKIM, will see intermittent authentication failures on forwarded mail that a full three-record setup avoids.
There is a partial fix on the infrastructure side called SRS (Sender Rewriting Scheme), which some forwarding services use to rewrite the envelope sender so SPF passes at each hop. You do not configure SRS on your sending domain; it is something the forwarding server does. Knowing it exists explains why forwarded mail sometimes passes SPF and sometimes does not. See how to improve email deliverability.
The Sender Allowlist: an SPF record is a public allowlist of the servers permitted to send email as your domain. If a server is not on the list, its mail claiming to be from you is treated as suspect.
The allowlist framing captures what SPF is and is not. It is a list you publish, publicly, of who is allowed to act as you for the purpose of sending mail. It is not a lock on the message and not a guarantee of trustworthiness. A spammer can publish a valid SPF record for their own throwaway domain and pass SPF; the check only proves the sender is who the record says, not that they are good.
For your own domain, the allowlist has to be complete and current. Every tool that sends as you, transactional, marketing, sales, support, belongs on it. A tool that falls off the list, or was never added, has its mail softfail or hardfail, which pushes it toward spam. Auditing the list whenever you add or remove a sending tool is the maintenance job.
The quotable version: "SPF does not vouch for your email. It vouches for the server that sent it, and only if you put that server on the list."
SPF is one lock of three. On its own it does not stop a message from being altered in transit or tell receivers what to do on failure; that is DKIM and DMARC. And none of the three help if you send to dead addresses and rack up bounces. See how to reduce email bounce rate for cold outreach.
A correct SPF record makes your domain eligible for the inbox. It does nothing about whether the addresses you send to are real. Bounces from a stale list damage the sender reputation your SPF record is meant to support.
InboundLabs is a sales intelligence platform built on a database of 280M verified B2B contacts with 98% email deliverability on verified contacts. It lets you filter by industry, headcount, region, and title, so your authenticated domain sends to verified inboxes and its reputation builds instead of eroding. Monthly plans, no annual lock-in. Free to start, no credit card required.
See how InboundLabs finds verified contacts instantly → inboundlabs.app
An SPF record is a public allowlist in your DNS naming the servers allowed to send email as your domain. Receiving servers check it to spot spoofing. Keep it to one TXT record, list every sending tool as an include:, end it with ~all for cold email, and stay under the 10-lookup limit. SPF is necessary but partial: pair it with DKIM and DMARC, and send to verified addresses, or the authentication does not help.
What is an SPF record in simple terms?
It is a line of text in your domain's DNS that lists which mail servers are allowed to send email using your domain name. When someone receives an email claiming to be from you, their server checks that list. If the sending server is on it, the check passes. If not, the email is treated as suspicious.
Do I need an SPF record for cold email?
Yes. Receiving servers weight authentication heavily, and a domain with no SPF record looks unauthenticated. Unauthenticated bulk-style mail is filtered aggressively. SPF is one of three records, with DKIM and DMARC, that you need before sending cold email from a domain.
Can I have more than one SPF record?
No. A domain must have exactly one v=spf1 TXT record. If it has two, SPF fails completely and neither is honored. When you add a new sending service, merge its authorization into the existing record as another include: rather than creating a second record.
What is the difference between ~all and -all in an SPF record?
-all is hardfail: reject any server not on the list. ~all is softfail: treat unlisted senders as suspicious but do not outright reject. For cold email infrastructure, ~all is the common choice because it tolerates forwarding and edge cases. Move to -all only once every sending source is listed.
Why is my SPF record failing even though it looks correct?
Common causes: two SPF records on the domain, exceeding the 10 DNS lookup limit, a sending tool that was never added, or a DNS change that has not propagated yet. Check with a validator like mxtoolbox.com, which will flag lookup-count and multiple-record errors.
Does SPF stop spam?
Not by itself. SPF only verifies that the sending server is authorized for the claimed domain. A spammer with their own domain can publish a valid SPF record and pass. SPF reduces spoofing of your domain, and combined with DKIM and DMARC it strengthens overall authentication, but it is not a spam filter.
LSI keywords: SPF record, Sender Policy Framework, DNS TXT record, email authentication, sender spoofing, include mechanism, ~all softfail, -all hardfail, 10 DNS lookup limit, mail server allowlist, DKIM, DMARC
Yahoo sender requirements mirror Gmail's, with one sharper edge: Yahoo rejects non-compliant bulk mail outright instead of foldering it.
Google bulk sender requirements apply at 5,000 emails a day, but the thresholds that filter you apply to everyone. The full 2026 checklist.
How to get off an email blacklist: fix the root cause first, then request delisting. Skip the fix and you get relisted, often faster.
No commitment. No credit card. Just 50 free verified contact lookups.