An SPF record is a single DNS TXT record that lists which mail servers are allowed to send email for your domain. For a cold email sending domain, it is the first of the three authentication records a receiving server checks, and getting the syntax wrong is one of the quickest ways to break delivery before a campaign even starts.
This page covers the full SPF syntax: every mechanism and qualifier, copy-paste records for Google Workspace and Microsoft 365, the 10 DNS lookup limit, and the errors that show up most on cold email sending domains. It builds on our SPF, DKIM and DMARC overview, which covers the order to add all three records. This page goes deeper on SPF alone.
What is an SPF record for cold email?
An SPF record is a DNS TXT record, published at the domain apex, that tells receiving mail servers which servers are authorized to send email claiming to be from that domain. "SPF" stands for Sender Policy Framework.
A sending domain with no SPF record looks the same to Gmail or Outlook as a domain being spoofed by a spammer. Google's own SPF guidance describes the record as defining "the mail servers and domains that are allowed to send email on behalf of your domain." Without it, a receiving server has no list to check a message against.
Each domain can have exactly one SPF record. A cold email sending domain needs its own record, separate from your main business domain, since each sending domain usually routes through a different mailbox provider.
What is the SPF record format and syntax for cold email?
An SPF record is one line of plain text, published as a DNS TXT record, made up of a required version tag followed by one or more mechanisms and an optional final qualifier-and-all combination. A minimal record looks like this:
v=spf1 include:_spf.google.com ~all
The record always starts with v=spf1, which must be the first tag. Everything after it is a space-separated list of mechanisms, each one optionally preceded by a qualifier. Google's SPF documentation notes the record can be up to 255 characters, and the TXT record file itself should stay under 512 bytes.
Receiving servers read the mechanisms left to right and stop at the first match, so order inside the record matters less for cold email setups than simply listing every real sender once.
What mechanisms and qualifiers can a cold email SPF record use?
An SPF mechanism names a source that is allowed to send for the domain, and a qualifier tells the receiver what to do when a message matches that mechanism. Every SPF record for cold email is built from the same small set of each.
| Mechanism | What it authorizes | Example |
|---|---|---|
v | Required version tag, must come first | v=spf1 |
include | A third-party domain's own SPF record, nested inside yours | include:_spf.google.com |
ip4 | A specific IPv4 address or range | ip4:192.0.2.0/24 |
ip6 | A specific IPv6 address or range | ip6:2001:db8::/48 |
a | The domain's own A record | a:example.com |
mx | The domain's own MX record | mx:mail.example.com |
exists | Matches if a DNS lookup on the given name resolves | exists:example.com |
all | Matches everything; must be the last mechanism | ~all or -all |
| Qualifier | Result on a match | What the receiver does |
|---|---|---|
(none, defaults to +) | Pass | Message is authenticated |
- | Fail (hardfail) | Receiver may reject the message |
~ | Softfail | Receiver typically accepts but marks it suspicious |
? | Neutral | Neither passes nor fails |
Google's SPF documentation describes ~all as the safer default for most domains, since a misconfigured -all can push legitimate mail to spam while you are still confirming every real sender is listed. A cold email sending domain that is actively warming up benefits from the same caution: start with ~all, and only move to -all once every mailbox and tool sending on the domain's behalf is confirmed in the record.
What is a cold email SPF record example for Google Workspace?
The SPF record for a domain sending only through Google Workspace is one line that includes Google's own SPF record and ends in an all mechanism.
v=spf1 include:_spf.google.com ~all
Add it as a TXT record with the host set to @, meaning the domain itself. Google's own SPF record page documents include:_spf.google.com as the mechanism that authorizes Google Workspace's sending servers, and it recommends ~all to avoid rejecting legitimate mail while a domain is still being configured. Allow up to 48 hours for a new or changed SPF record to take effect everywhere.
What is a cold email SPF record example for Microsoft 365?
The SPF record for a domain sending only through Microsoft 365 includes Microsoft's own SPF record and, per Microsoft's own documentation, typically ends in a hardfail.
v=spf1 include:spf.protection.outlook.com -all
Microsoft's SPF setup guide gives this exact syntax and recommends -all for Microsoft 365 domains specifically because Microsoft also expects DKIM and DMARC to be configured alongside it, so a hard fail on SPF alone does not strand genuine mail. On a brand-new cold email sending domain still being warmed up, ~all is the more forgiving starting point; move to -all once DKIM and DMARC are both confirmed working, which our SPF, DKIM and DMARC guide covers in order.
How do you add a second sender to a cold email SPF record?
Add a second sender by adding another include:, ip4: or ip6: mechanism to your existing record, never by publishing a second SPF record. A domain sending through both Google Workspace and a separate cold email tool's own servers needs both sources in one line:
v=spf1 include:_spf.google.com include:servers.example-tool.com ~all
This matters most on a cold email sending domain, where it is common to add a verification service, a warm-up tool or a second mailbox provider after the domain is already live. Every addition goes into the same record. A second v=spf1 line anywhere in the domain's DNS breaks SPF entirely, covered below under common errors.
What is the 10 DNS lookup limit on a cold email SPF record?
The 10 DNS lookup limit is the maximum number of mechanisms that trigger a DNS query the record is allowed to use before a receiving server must reject it outright. RFC 7208, section 4.6.4, the standard that defines SPF, states that implementations "MUST limit the total number of those terms to 10 during SPF evaluation" and "MUST return permerror" if the limit is exceeded.
Not every mechanism counts against the limit. The terms that trigger a lookup, and therefore count, are:
| Counts toward the 10-lookup limit | Does not count |
|---|---|
include | ip4 |
a | ip6 |
mx | all |
exists | |
redirect modifier | |
ptr (RFC 7208 says not to publish this mechanism anyway) |
An include: nested inside another include: still counts, so a single third-party tool that itself includes two more domains can use up three lookups from one line in your record. A cold email sending domain that stacks Google Workspace, a verification service and two outreach tools can approach the limit faster than it looks from the record's length alone.
Stay under the limit by preferring ip4/ip6 over include where a sender publishes static IP ranges. Remove tools no longer sending from the domain, and recheck the record whenever a new sender is added.
What other SPF rules does a cold email sending domain need to know?
Beyond the lookup limit, two rules account for most SPF failures on cold email domains: one record per domain, and SPF's relationship to DMARC alignment.
- One SPF record per domain. RFC 7208 says two records starting with
v=spf1cause a PermError, failing SPF for every message. Add a new sender to the existing record instead. - SPF supports DMARC alignment, it does not replace it. DMARC passes a message when SPF or DKIM passes and the authenticated domain matches the "From" address. Our DMARC policy guide covers the alignment policy itself.
- Each sending domain is separate. A cold email sending domain, as our guide to sending domains covers, needs its own SPF record. Changing it never touches the main domain's.
Pipefire publishes SPF, DKIM and DMARC automatically on every sending domain it sets up, and each sending domain is kept separate from the customer's main domain, so the main domain's own SPF record is never touched. Our setup page covers what else gets configured before a sending domain goes live.
What are the most common SPF record errors in cold email?
Most SPF errors on a cold email domain come down to four causes, and all of them show up as a failed or PermError result when you check the record.
- Two SPF records. A new tool's setup instructions add a fresh TXT record instead of editing the existing one. Fix it by merging both into one record.
- Too many DNS lookups. Stacking
include:mechanisms past 10 triggers a PermError for every message. Fix it by removing unused senders or switching a static sender toip4/ip6. - A typo in the include domain.
include:_spf.goggle.cominstead of_spf.google.comauthorizes nothing. - No
allmechanism at the end. Without one, SPF defaults to a neutral result for every unlisted sender.
A free online DNS lookup tool will show exactly what a domain currently publishes, which is the fastest way to spot a second record or a typo. Check again whenever a sending domain's set of mailboxes or tools changes, since an outdated SPF record is one of the common reasons cold emails end up in spam.
SPF record cold email FAQ
What is an SPF record in cold email terms?
It is a DNS TXT record on your sending domain that lists the servers allowed to send cold email on its behalf. Receiving servers like Gmail and Outlook check it before deciding whether a message is likely genuine.
What is a cold email SPF record example for Google Workspace?
v=spf1 include:_spf.google.com ~all, published as a TXT record at the domain's apex. Google's own documentation covers the same syntax at knowledge.workspace.google.com.
What is a cold email SPF record example for Microsoft 365?
v=spf1 include:spf.protection.outlook.com -all, from Microsoft's own SPF setup guide. A cold email sending domain still warming up may prefer ~all until every sender is confirmed.
Can a cold email domain have more than one SPF record?
No. A domain with two records starting with v=spf1 fails SPF for every message, since RFC 7208 requires a PermError result in that case. Add a new sender to the one existing record instead.
How do I fix a cold email SPF record with too many DNS lookups?
Count every include, a, mx, exists and redirect in the record; RFC 7208 caps the total at 10. Remove senders no longer used, or replace an include: with a direct ip4/ip6 entry where the sender publishes static IP addresses.