SPF Email Authentication: Setup Guide for Cold Email

Why SPF Authentication Actually Matters

I've seen agencies spend weeks crafting the perfect cold email sequence - great subject lines, tight personalization, strong offers - and still get zero replies. Not because the copy was bad. Because their emails never reached the inbox in the first place.

SPF email authentication is one of the foundational reasons emails land in spam folders or get outright rejected. It's not glamorous infrastructure work, but it's the difference between your outbound machine running and it quietly hemorrhaging money every day.

The concept is straightforward: SPF (Sender Policy Framework) is a DNS TXT record that tells receiving mail servers which IP addresses and servers are authorized to send email on behalf of your domain. When someone on Gmail or Outlook receives an email from you, their server checks your domain's SPF record to verify your sending server is on the approved list. If it's not there, the email gets flagged, filtered, or rejected.

Think of it like a venue's approved vendor list. If your caterer isn't on the list, they don't get in - doesn't matter how good the food is.

And it's not just about deliverability. SPF-protected domains are far less attractive to fraudsters and therefore less likely to end up on blocklists. When spammers can't impersonate your domain, they don't drag your reputation into the mud with them. That matters for your sender score whether you're sending cold outreach or just routine business emails.

What Gmail and Outlook Now Require (Non-Negotiable)

This isn't optional anymore. Gmail requires all senders to have SPF and DKIM configured, along with valid MX records, valid reverse DNS (PTR records), and TLS-encrypted transmission. Bulk senders - defined as anyone sending 5,000 or more messages per day to Gmail addresses - must also have DMARC configured at a minimum of p=none, keep spam rates below 0.10%, and support one-click unsubscribe on marketing mail.

Outlook.com enforced similar requirements for high-volume senders in mid-2025, following Gmail's lead. These are no longer recommendations - they are hard prerequisites. Messages that fail these checks get routed to spam or rejected outright. If you're running cold outreach at any real volume, you're almost certainly in scope.

Even if you're sending below the 5,000-per-day threshold, the deliverability penalty for missing SPF is significant enough that treating it as required is the right call regardless. Google has also signaled that full DMARC alignment with both SPF and DKIM will likely become mandatory for all senders going forward - not just bulk senders. Set it up now and you're ahead of the curve.

The spam rate thresholds matter too: keep spam complaints below 0.10%, with 0.30% being the ceiling above which Gmail becomes ineligible for delivery mitigation - and recovery requires sustaining below 0.30% for seven consecutive days. That's a painful hole to dig out of.

How SPF Authentication Actually Works (Step by Step)

Here's the mechanics, stripped of jargon:

1. Your domain publishes an SPF record as a DNS TXT entry. This record lists all the mail servers and IP addresses authorized to send email for your domain.
2. You send an email. The email carries a Return-Path (also called the envelope sender) - this is the domain the receiving server checks, not the visible "From" address.
3. The receiving server queries your DNS to pull your SPF record and then compares your sending server's IP address against the list of authorized senders in that record.
4. SPF returns a result - Pass, Fail, SoftFail, Neutral, or an error state - and the receiving server uses that result, combined with DKIM and DMARC, to decide whether to deliver, quarantine, or reject the message.

One critical thing most people miss: SPF only checks the Return-Path domain, not the visible "From" address in the email header. That means SPF alone can't stop display-name spoofing. It's one piece of a larger authentication puzzle, not the whole picture.

There's also a subtlety around DMARC alignment that trips people up: even if SPF passes on its own, if the domain in the Return-Path doesn't match the visible From domain (or if DKIM doesn't pass alignment either), DMARC will still fail. That means you can have SPF technically working and still have DMARC failing - which affects your deliverability. Alignment matters as much as authentication.

How to Write Your SPF Record

An SPF record is a single line of text. Here's what a basic one looks like for Google Workspace:

v=spf1 include:_spf.google.com ~all

Breaking that down:

• v=spf1 - declares this is an SPF record (version 1)
• include:_spf.google.com - authorizes Google's mail servers to send on your behalf
• ~all - a SoftFail: any server not listed is suspicious but still delivered
• -all - a HardFail: any server not listed is rejected outright (stricter, recommended once you've confirmed all your senders are covered)
• +all - allows any server to send for your domain. Never use this. It defeats the entire purpose.
• ?all - Neutral: suggests no specific action on messages from unidentified sources. This is used for testing only. Don't use it in production.

If you're using multiple services - Google Workspace for your main email, a cold email tool like Smartlead or Instantly, plus maybe a CRM like Close - each of those services needs to be included in your SPF record.

Example with multiple senders:

v=spf1 include:_spf.google.com include:spf.smtp2go.com ip4:203.0.113.5 ~all

You can also specify individual IP addresses directly using ip4: for IPv4 or ip6: for IPv6, which is more reliable for vendors with stable, documented IP ranges since it eliminates an extra DNS lookup. Mechanisms like ip4, ip6, and all do NOT count toward the DNS lookup limit - only mechanisms that require a DNS resolution (like include, a, mx, exists, and redirect) count.

One more syntax note that causes real-world problems: an SPF record string must begin with v=spf1 and end with either -all or ~all. Tiny errors - an extra space, a misspelled mechanism like "incldue" instead of "include", or using "ipv4" instead of "ip4" - will break authentication silently. When in doubt, run your record through a validator before you deploy it.

The 10 DNS Lookup Limit - The SPF Mistake That Kills Deliverability Silently

This is the mistake I see most often, and it's painful because it breaks things quietly. SPF has a hard limit of 10 DNS lookups per evaluation. Every include:, a, mx, exists, and redirect mechanism counts toward that limit. Exceed it and SPF returns a PermError - which means authentication fails for every email you send, including the legitimate ones.

To illustrate how fast you can hit the limit: Google Workspace alone can consume 4 lookups through its nested includes. Add SendGrid (2 lookups), Mailchimp (1 lookup), another cold email tool (2 lookups), and an MX mechanism (1 lookup) - and you're already at 10 before you've added your CRM or any other sending tool. This is not a theoretical problem. Nearly 20% of SPF records exceed this limit, making them completely ineffective.

There's also a secondary limit most people don't know about: the void lookup limit. RFC 7208 limits void lookups (DNS queries that return a null or non-existent domain response) to 2 per SPF evaluation. Exceed 2 void lookups and you get a PermError even if you're under the 10-lookup ceiling. This usually happens when you have includes pointing to domains that no longer exist or have been misconfigured.

The fix isn't complicated but does require attention:

• Audit your includes. Every service you add to your SPF record costs at least one lookup, sometimes more if they use nested includes.
• Replace includes with IP addresses where a vendor has stable, documented IPs. This removes the lookup entirely.
• Move non-critical senders to subdomains. For example, put your marketing email on mail.yourdomain.com with its own SPF record. Each subdomain gets its own 10-lookup budget - but be aware that subdomain SPF records don't inherit from the root domain automatically. Each subdomain needs its own explicit configuration.
• Consolidate your sending tools. If you're running five different outreach platforms, you might want to rationalize down to fewer tools anyway - both for deliverability and sanity.
• Avoid the ptr mechanism entirely. It's unreliable, performance-heavy, and wastes lookup budget. Modern alternatives like ip4 do the job better.

Use a free SPF checker tool (MXToolbox is the go-to) to see your current lookup count and identify which includes are eating the most budget. Run it before you add any new tool to your stack, not after.

One SPF Record Per Domain - No Exceptions

This sounds obvious but I've seen it happen with agencies managing multiple client domains: you cannot have more than one SPF record for the same domain. The Internet Engineering Task Force (IETF) explicitly forbids multiple SPF records for a single domain. Multiple SPF TXT records on the same domain cause a PermError and break authentication entirely - both records are ignored, and every email from that domain fails SPF.

If you need to add a new sender, you edit the existing SPF record - you don't create a second one. Merge everything into a single, consolidated TXT record. This often happens when agencies switch email providers or add new tools without checking what's already in DNS. The fix is simple: use MXToolbox or Google Admin Toolbox to find all TXT records starting with v=spf1, delete all but one, and merge all authorized senders into that single record.

SPF Setup: Step by Step

1. Identify every service that sends email from your domain. This includes your email provider (Google Workspace, Microsoft 365), your cold email tool, your CRM, any invoicing or billing platforms, marketing automation tools, and your website's contact form. Get them all listed before you touch DNS.
2. Build your SPF record. Use an SPF generator if you're not comfortable writing the syntax manually. Dmarcian, MXToolbox, and EasyDMARC all have free generators. Check that the total lookup count stays under 10.
3. Log into your DNS registrar (Cloudflare, GoDaddy, Namecheap, wherever your domain's DNS lives) and add the SPF as a TXT record. Set the Name/Host field to @ to apply it to your root domain.
4. Wait for propagation. DNS changes can take up to 48 hours to fully propagate, though usually it's much faster - often within a few minutes on modern DNS providers.
5. Verify it's working. Send a test email to a Gmail account, open the original message headers, and look for spf=pass in the authentication results. If it says fail or softfail, go back and check your record.
6. Start with SoftFail (~all), then move to HardFail (-all). Begin with ~all while you confirm all your legitimate senders are covered. Once you consistently see spf=pass in tests, transition to -all for stricter enforcement. Microsoft also recommends -all specifically because DMARC treats both hard fail and soft fail as SPF failures - but using -all lets DMARC act on SPF failures even when DKIM signatures are absent.

Check out the Email Verification Guide for more on validating your setup end-to-end.

Understanding Every SPF Result Type

Most guides only cover Pass and Fail. Here's the full picture, because each result means something different and requires a different response:

• Pass: The sending IP is in the authorized list. Email is accepted. This is what you're aiming for.
• Fail (Hard Fail): The sending IP is explicitly not authorized. The receiving server typically rejects or filters the message. Used with -all.
• SoftFail: The IP isn't explicitly authorized but the domain isn't asserting a hard rejection. Used with ~all. Most providers still deliver these but flag them.
• Neutral: The domain makes no assertion about whether the IP is authorized. Used with ?all. Receiving servers treat this as neither pass nor fail. Only use this for testing.
• None: No SPF record exists on the domain at all, or the DNS can't be resolved. SPF None is treated as a failure in DMARC - if DKIM also fails, the overall authentication fails and the message gets quarantined or rejected depending on your DMARC policy.
• PermError (Permanent Error): The SPF record is structurally broken and can't be evaluated. Every email from the domain fails SPF until you fix the record. Causes include exceeding 10 DNS lookups, multiple SPF records, syntax errors, exceeding 2 void lookups, or invalid redirect mechanisms. PermError is treated as a DMARC failure. Fix it immediately.
• TempError (Temporary Error): A transient DNS issue prevented SPF evaluation - typically a DNS timeout. Unlike PermError, this usually resolves on its own. The receiving server returns a 4xx status code and may retry later. If you're seeing frequent TempErrors consistently, it may indicate instability with your DNS provider and is worth investigating.

The most damaging result is PermError because it's silent and persistent. Every message from the domain fails SPF until the record is fixed, with no retry - and your sending tool may not alert you to this because it still shows messages as "sent." Run MXToolbox on your sending domains regularly and before every major campaign launch.

SPF and Email Forwarding: Why It Breaks and What to Know

There's one scenario where SPF will fail even on a perfectly configured domain, and it's worth understanding: email forwarding.

When an email is forwarded, the forwarding server initiates a new SMTP transaction. The receiving server at the final destination checks the SPF record of the original domain against the IP of the forwarding server - which obviously isn't in the original sender's SPF record. So SPF fails. If the forwarding server also modifies the message (adding a footer, changing the subject, appending a disclaimer), DKIM can fail too. And if both SPF and DKIM fail, DMARC fails entirely.

This is why DMARC reports sometimes show SPF failures for legitimate emails. The fix isn't in your SPF record - it's in how the intermediary handles authentication.

The protocol designed to address this is ARC (Authenticated Received Chain). ARC allows intermediary servers to record and sign the original authentication results before forwarding the message, so the final receiving server can verify that the email originally passed SPF, DKIM, and DMARC - even if those checks now fail because of the forwarding path. Gmail and Microsoft both use ARC to make smarter delivery decisions on forwarded mail.

From a practical standpoint: if you see SPF failures in your DMARC reports for forwarded messages, but those emails are still being delivered, that's ARC doing its job. Don't panic about forwarding failures in DMARC reports if the email is actually landing in the inbox. Focus your attention on PermErrors and failures on direct sends.

SPF Alone Isn't Enough - It's Part of a Stack

SPF is table stakes, not a complete solution. You need all three protocols working together:

• SPF - authorizes which servers can send from your domain. Checks the Return-Path domain. Doesn't protect against display-name spoofing.
• DKIM - adds a cryptographic signature to each email, verifying it hasn't been tampered with in transit. Uses a 2048-bit key (stronger than the older 1024-bit standard). Each sending service should have its own DKIM record. The signature survives email forwarding as long as the message body isn't modified.
• DMARC - ties SPF and DKIM together with alignment requirements, tells receiving servers what to do when either check fails, and sends you aggregate reporting data so you can see who's sending on your behalf and whether authentication is passing correctly.

Gmail requires all senders to have SPF and DKIM configured, and bulk senders must have DMARC at a minimum of p=none. Google has stated that full DMARC alignment with both SPF and DKIM will likely become a sender requirement over time. Yahoo applies identical requirements on the same timeline.

For DMARC, start with p=none (monitoring mode) to collect data without risk, then move to p=quarantine and eventually p=reject as you confirm all legitimate senders are passing authentication. The DMARC reports you receive will show exactly what's hitting your domain and whether SPF and DKIM are passing correctly. If you're not reading DMARC reports, you're managing authentication completely blind.

Set up your DMARC record at _dmarc.yourdomain.com and include a reporting address (rua=) so you start receiving aggregate reports. Tools like Dmarcian, EasyDMARC, or Postmark's DMARC Digests can help you read and interpret those reports in a way that's actually actionable.

Cold Email Domains: Use Separate Sending Domains

One more thing that matters a lot for cold outbound specifically: don't send cold email from your primary business domain. If cold outreach tanks your sender reputation, it takes down your entire company's email deliverability with it - transactional emails, invoices, support replies, everything.

Register secondary domains (variations of your main domain like getacme.com or tryacme.com) and set up SPF, DKIM, and DMARC on each of those before sending a single cold email. Each domain needs its own records - there's no inheritance from your root domain. A subdomain like sales.yourdomain.com does not automatically pick up your root domain's SPF, DKIM, or DMARC. Each one needs its own explicit configuration.

Also important: cold outbound, transactional, and marketing email should not share one reputation pool. Keep them on separate domain families, not just subdomains. One reputation problem in your cold outreach stays contained and doesn't bleed into your transactional mail.

Each domain also needs to be properly warmed - don't skip that step. If you're running sequences at volume, a tool like Instantly or Smartlead can handle multi-inbox management across those secondary domains. The general guideline: plan for roughly one domain per two to three sending mailboxes, and cap cold sends at around 40-50 emails per mailbox per day.

For managing all of this - tools, domains, sequences - I put together a full breakdown at Cold Email Tech Stack that covers what actually belongs in your infrastructure.

Common SPF Errors and How to Fix Them

• PermError - Too Many DNS Lookups: You've exceeded the 10-lookup limit. Audit your includes using MXToolbox, replace some with direct IP addresses, or move senders to subdomains (each subdomain gets its own 10-lookup budget). Also check for void lookups - if more than 2 of your includes point to non-existent domains, you'll trigger PermError even if you're under the 10-lookup ceiling.
• Multiple SPF Records: Delete the extras and merge everything into one TXT record. Use MXToolbox or Google Admin Toolbox to find all records starting with v=spf1 and consolidate them. Simply copying and pasting two records together won't work - you need to properly merge the mechanisms.
• Missing Senders: You added a new tool (a new CRM, a new cold email platform) and forgot to update SPF. The fix is simple - add the new include to your existing record. But check your lookup count before you add it; if you're already at 8 or 9, adding another include will push you over the limit.
• Using +all: This tells the world that anyone can send email as you. Alarmingly, around 15% of SPF records use +all - it's functionally useless for authentication. Use ~all or -all.
• Not protecting non-sending domains: Domains you own that don't send email are easy spoofing targets. Add v=spf1 -all to those domains to explicitly block all sending.
• Syntax errors: Even tiny mistakes - an extra space, a misspelled mechanism, "ipv4" instead of "ip4" - cause PermError. Always validate your SPF record syntax before deploying changes to DNS.
• DNS changes breaking SPF silently: Any DNS change - domain transfer, hosting migration, nameserver update - can accidentally modify or delete your SPF record. After any DNS change, run a full authentication check before resuming campaign sends.
• Record not applied to the correct host: When adding your SPF TXT record, the Name/Host field should be @ (your root domain). Some people add it to a subdomain by mistake, which means the root domain has no SPF record at all.

SPF Maintenance: It's Not Set-and-Forget

Most people treat SPF like a one-time task. Set it up, forget it, move on. That's a mistake. SPF records drift over time - you add new tools, drop old ones, change email providers - and your record stops reflecting reality.

A syntactically valid SPF record can still be completely ineffective. The record exists, the DNS checker says it's fine, and deliverability still suffers because the wrong systems are authorized, the right ones are missing, or your lookup count crept over 10 because a third-party vendor updated their own SPF includes without telling you. That last one happens more than you'd think.

Build a simple maintenance routine:

• Run MXToolbox on all your sending domains once a month. It takes ten minutes for five domains. Set a calendar event.
• Before adding any new cold email platform, warmup tool, or email service, check how many DNS lookups your current record uses. If you're at 8 or 9, flatten the existing record first before adding the new service.
• After any DNS change (domain transfer, hosting migration, nameserver update), run a full authentication check immediately - don't wait until a campaign goes out.
• Read your DMARC aggregate reports monthly. They show exactly which authentication checks are passing and failing, at what volume, from which IPs. If you're not reading them, you're flying blind.

The practical version of this: treat your SPF record like your DNS firewall. You wouldn't set up a firewall and never review the rules again.

Verify Your Emails Are Hitting Inboxes

Once SPF, DKIM, and DMARC are configured, don't just assume everything is working. Verify it. Send test emails through Gmail and check the original headers for spf=pass, dkim=pass, and dmarc=pass. Set up Google Postmaster Tools for each sending domain - it gives you domain reputation, spam rate, and authentication pass rate data over time. Connect each sending domain independently and monitor them regularly, not just when something looks wrong.

And before you even send to real prospects, make sure your contact data is clean. Sending to bad addresses is a fast path to bounces, which tanks your sender reputation even if your authentication is perfect. A high bounce rate undermines everything you've done with SPF and DMARC. Tools like this email verification tool can clean your list before you pull the trigger on a campaign.

I also cover the full verification workflow in the Email Verification Guide.

For tracking how your sequences are actually performing once everything is set up correctly, the Cold Email Tracking Sheet gives you a simple way to measure what matters - open rates, reply rates, bounce rates, and step-by-step sequence performance.

SPF for Agencies Managing Multiple Client Domains

If you're an agency running outbound for multiple clients, you need a systematic approach. The mistakes I see most often in agency setups:

• Assuming SPF from the client's existing domain covers everything. It doesn't. Every sending domain - including secondary cold email domains - needs its own SPF, DKIM, and DMARC. And they don't inherit from each other.
• Adding your agency's tools to a client's root domain SPF without checking the lookup count. Many clients already have Google Workspace, Microsoft 365, a CRM, and some marketing tool in their SPF. Adding another include for your outreach tool can tip them over the 10-lookup limit instantly.
• Creating separate SPF records instead of editing the existing one. Always check DNS for an existing SPF record before creating a new one. If one exists, edit it. Never create a second one.
• Not maintaining records after offboarding tools. When a client stops using a cold email platform, remove it from the SPF record. Orphaned includes accumulate lookup cost for no reason and can eventually break authentication.

Build a DNS audit into your client onboarding checklist. Before you send a single email on a client's behalf, verify their SPF, DKIM, and DMARC are all correctly configured and passing. Then build the habit of checking quarterly.

If you want to sharpen your systems for running outbound at scale - for yourself or for clients - I cover this kind of operational depth inside Galadon Gold.

The Bottom Line

SPF email authentication is not optional anymore. It's baseline infrastructure. Without it, receiving servers have no reliable way to verify your emails are legitimate, and they'll treat you like a threat. Gmail and Outlook have made their requirements explicit, and enforcement is real.

Set it up once, verify it's working, keep the lookup count under 10, watch for void lookups, maintain it monthly, and then combine it with DKIM and DMARC for the full authentication stack. Fix any PermErrors immediately - every day you leave one in place, every email from that domain is failing authentication.

Do this before you write a single cold email. The best copy in the world does nothing if the email ends up in spam - and with SPF misconfigured, that's exactly where it's going.