SPF Record Setup: Step-by-Step Guide

What is SPF?

Imagine you send a cold email campaign from your domain, but Gmail thinks it might be spam because anyone could claim to send from your domain. How does Gmail know it’s really you? That’s where SPF comes in.

SPF (Sender Policy Framework) is an email authentication method that creates a whitelist of servers authorized to send email on behalf of your domain. Think of it as a guest list at an exclusive event—if your name isn’t on the list, you’re not getting in.

Here’s how the process works in practice. You publish a list of authorized email servers in your domain’s DNS records. When you send an email, the receiving server (like Gmail or Outlook) checks your SPF record to see if the sending server is on your approved list. If the server matches one of your authorized sources, the email passes SPF authentication. If the server isn’t listed, the email fails SPF and likely gets flagged as spam.

Without SPF, there’s nothing stopping bad actors from sending emails that appear to come from your domain. Email providers know this, which is why they treat emails from domains without SPF records with extreme skepticism. With SPF properly configured, you’re proving that emails from your domain come from legitimate, authorized sources. Email providers reward this with better inbox placement.

Why SPF Matters for Cold Email

Let’s be blunt: if you’re running cold email campaigns without SPF, you’re essentially burning money. Your carefully crafted outreach emails aren’t reaching prospects—they’re going straight to spam folders where nobody will ever see them.

Here’s why SPF is non-negotiable for cold email. First, about 90% of your B2B prospects use Gmail for business email, and Gmail checks SPF on every incoming message. Microsoft Outlook and Office 365 users make up most of the remaining prospects, and they verify SPF just as rigorously. Between these two providers, you’re looking at nearly all your target audience.

SPF serves as a baseline requirement for email authentication. Even if you have DKIM and DMARC configured (which you should), failing SPF undermines your entire authentication setup. Modern spam filters weigh SPF heavily in their algorithms. A failed SPF check is one of the strongest spam signals an email can have.

The reality is harsh but simple. Running cold email without SPF means your emails don’t get delivered. Your open rates plummet. Your reply rates tank. And you’re wasting resources on campaigns that never had a chance to succeed.

Understanding SPF Record Syntax

SPF records follow a specific format that might look cryptic at first, but becomes straightforward once you understand the components. Let’s break down a typical SPF record: v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.168.1.1 -all

The record always starts with v=spf1, which identifies the SPF version. This is required and never changes. The include statements pull in SPF records from other domains. When you use include:_spf.google.com, you’re telling email providers to also check Google’s list of authorized servers. Each email service provider you use will have their own include statement.

You can also authorize specific IP addresses directly. The ip4: mechanism authorizes a specific IPv4 address, while ip6: does the same for IPv6 addresses. Some organizations use the a mechanism to authorize their A record IP, or mx to authorize their mail server IPs, though these are less common in modern configurations.

The ending is crucial. The -all at the end means hard fail—any server not listed should be rejected outright. The alternative ~all means soft fail, which marks unauthorized emails as suspicious but doesn’t reject them entirely. For cold email, you want to use -all to demonstrate strong security practices.

Let’s look at some real-world examples. If you only use Google Workspace, your SPF record is simple: v=spf1 include:_spf.google.com -all. For Microsoft 365 users, it’s: v=spf1 include:spf.protection.outlook.com -all.

Most cold email setups are more complex. If you use Google Workspace for regular email and Instantly for cold outreach, your record becomes: v=spf1 include:_spf.google.com include:sendgrid.net -all. Instantly uses SendGrid’s infrastructure, so you include SendGrid’s SPF record.

Many companies have multiple sending sources. A record like v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com -all might represent a company using Google Workspace, a cold email tool, and Amazon SES for transactional emails.

Step-by-Step SPF Setup

Setting up SPF correctly requires methodical attention to detail. Here’s exactly how to do it.

Step 1: Identify All Sending Sources

Start by making a comprehensive list of every service that sends email for your domain. This is critical because missing even one source will cause those emails to fail SPF.

Your list should include your primary email provider like Google Workspace or Microsoft 365. Add your cold email tool—whether that’s Instantly, Lemlist, Apollo, or another platform. Don’t forget marketing automation platforms like HubSpot or Mailchimp if you use them. Include transactional email services like SendGrid or Postmark if you send automated emails from your application. Check if your CRM sends emails on your behalf—Salesforce and HubSpot often do. Finally, support desk software like Zendesk or Intercom might send from your domain too.

Every single one of these services needs to be represented in your SPF record. Missing one means those emails will fail authentication.

Step 2: Find Include Statements

Each provider has their own SPF include statement. Here are the most common ones you’ll need:

Always verify the current SPF include in your provider’s documentation, as these occasionally change.

Step 3: Build Your SPF Record

Now combine everything into a single record. The format is straightforward: v=spf1 followed by all your include statements, ending with -all.

For example, if you use Google Workspace for email, Instantly for cold outreach, and HubSpot for marketing, your record would be: v=spf1 include:_spf.google.com include:sendgrid.net include:spf.hubspot.com -all

Remember, you can only have one SPF record per domain. Everything must be combined into this single record.

Step 4: Add to DNS

Log into your DNS provider. This might be GoDaddy, Cloudflare, Namecheap, or wherever you registered your domain. Navigate to the DNS settings section—different providers label this differently, but look for DNS Management, DNS Records, or Advanced DNS.

Add a new TXT record with these settings. For the name or host field, enter @ or leave it blank (this represents your root domain). Select TXT as the record type. In the value field, paste your complete SPF record. Set TTL to 3600 or use the default setting.

Save the record and you’re done with the DNS portion.

This is crucial: you can only have ONE SPF record per domain. If you already have an SPF record, you need to edit it to include your new providers. Don’t create a second SPF record—multiple records will cause both to fail.

Step 5: Verify the Record

DNS changes take time to propagate across the internet. Wait 5 to 15 minutes, then verify your record is working correctly.

Head to MXToolbox’s SPF checker at mxtoolbox.com/spf.aspx and enter your domain. You should see “SPF Record Found” with green checkmarks confirming the record is valid. The tool will also show how many DNS lookups your record requires—make sure this is under 10.

Check that your record ends with either -all or ~all. Verify that all your expected include statements appear in the results. If something looks wrong, double-check your DNS settings and wait a bit longer for propagation.

The 10 DNS Lookup Limit

SPF has a technical limitation that trips up many people: your SPF record cannot exceed 10 DNS lookups. This seems arbitrary, but it’s a hard limit built into the SPF specification to prevent infinite loops and denial of service attacks.

Each include statement in your SPF record counts as at least one DNS lookup. Some include statements reference other SPF records that contain their own includes, creating nested lookups. For example, include:_spf.google.com actually requires 2 DNS lookups because Google’s SPF record itself includes other domains.

Direct IP addresses don’t count toward the limit. Using ip4: or ip6: requires zero lookups because the IP is already specified. The a mechanism counts as 1 lookup, and mx counts as 1 or more depending on how many mail servers you have.

Here’s what happens when you exceed 10 lookups: SPF evaluation simply stops. Your emails fail SPF authentication. Your deliverability crashes. All because you went over a technical limit.

Let’s say you have Google Workspace (2 lookups), Instantly via SendGrid (1 lookup), HubSpot (1 lookup), Mailchimp (1 lookup), and a few other services. You could easily hit 8 or 9 lookups, dangerously close to the limit. Add one more service and you’re over.

You have several options to reduce lookups. First, remove any include statements for services you no longer use. We’ve seen SPF records with includes for email providers the company switched away from years ago.

Second, consider replacing include statements with direct IP addresses when possible. If a provider uses static IPs, you can use ip4:123.45.67.89 instead of an include statement. This only works for providers with IPs that don’t change, which is rare for larger services.

Third, use SPF flattening services that automatically convert includes to IP addresses and manage updates for you. These services monitor your providers’ SPF records and update your flattened record when IPs change.

Finally, consolidate your sending infrastructure. If you’re using three different email marketing tools, consider whether you really need all three. Fewer services mean fewer includes and more headroom under the lookup limit.

Hard Fail vs Soft Fail

The ending of your SPF record determines what happens when someone tries to send email from an unauthorized server. This choice has real implications for your deliverability.

Hard fail, written as -all, tells receiving servers to reject any email not from authorized sources. Period. No exceptions. This is the strictest setting and sends the strongest signal to email providers that you take security seriously.

The advantages are clear. Hard fail provides the strongest protection against domain spoofing. Email providers view it as a positive deliverability signal because it shows you’re serious about email authentication. Most email security experts recommend using hard fail.

The downside is that misconfigurations get punished severely. If you forget to add your new cold email tool to your SPF record, those emails get rejected entirely. There’s no room for error. You need to be diligent about keeping your SPF record updated.

Soft fail, written as ~all, marks unauthorized emails as suspicious but doesn’t reject them outright. It’s more forgiving but sends a weaker signal to email providers. Spammers can still somewhat spoof your domain, though their emails will be flagged as questionable.

For cold email, we recommend using -all (hard fail). The stronger authentication signal outweighs the risk of misconfiguration, especially if you’re careful about maintaining your SPF record. The only exception is during initial setup—you might use ~all while testing to avoid completely breaking email if something’s wrong, then switch to -all once verified.

There’s also neutral (?all) which essentially says “I have no opinion about unauthorized senders.” Never use this. It completely defeats the purpose of having an SPF record.

Common SPF Mistakes

The most frequent mistake is creating multiple SPF records. People think they need separate records for each service, so they add multiple TXT records that all start with v=spf1. This breaks SPF entirely—if multiple records exist, email providers ignore all of them.

The correct approach is combining everything into one record. Instead of having v=spf1 include:_spf.google.com -all as one record and v=spf1 include:sendgrid.net -all as another, you need: v=spf1 include:_spf.google.com include:sendgrid.net -all

Another common error is forgetting to start the record with v=spf1. Without this version identifier, email providers don’t recognize the record as an SPF record at all. Always begin with v=spf1, no exceptions.

Exceeding the 10 DNS lookup limit is increasingly common as companies use more email services. Someone might have a record like: v=spf1 include:a.com include:b.com include:c.com include:d.com include:e.com include:f.com include:g.com include:h.com -all. Even if each include only requires one lookup, this could easily exceed 10 with nested lookups. Use MXToolbox to check your actual lookup count.

Many companies set up SPF for their primary email but forget to add their cold email tools. Your SPF includes Google Workspace, but you send cold emails through Instantly. Result: all your cold emails fail SPF and land in spam. Always add every service that sends from your domain.

Finally, people make changes to their SPF record and assume everything works without testing. Always verify with MXToolbox after any SPF modification. DNS mistakes happen, typos happen, and you won’t know until you test.

SPF for Multiple Domains

If you’re doing cold email properly, you’re using secondary domains to protect your primary domain’s reputation. Each domain needs its own SPF record configured for its specific sending sources.

Your primary domain (let’s say yourcompany.com) might use Google Workspace and HubSpot: v=spf1 include:_spf.google.com include:spf.hubspot.com -all

Your cold email domain (getyourcompany.com) might use Google Workspace and Instantly: v=spf1 include:_spf.google.com include:sendgrid.net -all

Each domain’s SPF record should match only the services that actually send from that domain. Don’t include HubSpot in your cold email domain’s SPF if you don’t send marketing emails from it. Keep records as minimal as possible while including everything necessary.

Verifying SPF Is Working

After setup, you need to confirm everything works correctly. There are three reliable methods.

MXToolbox is the most comprehensive. Visit mxtoolbox.com/spf.aspx, enter your domain, and review the results. You should see “SPF Record Found” in green, confirmation that syntax is valid, a lookup count under 10, and your record ending with -all or ~all.

Google Admin Toolbox provides another verification method at toolbox.googleapps.com/apps/checkmx/. Enter your domain and review the SPF status. This tool is particularly useful if most of your prospects use Gmail.

For the most practical test, send an email to your personal Gmail account. Open the email, click the three dots menu, select “Show original,” and look for the SPF result. You want to see “SPF: PASS with IP” followed by the sending server’s IP address. This confirms that real-world email delivery is working correctly.

Troubleshooting SPF Issues

When you see “SPF Record Not Found,” the record either doesn’t exist, DNS propagation is still pending, or you’re checking the wrong domain. Verify the record exists in your DNS settings. Wait up to 24 hours for full DNS propagation. Double-check you’re testing the correct domain spelling.

“SPF PermError” indicates a permanent error with your record. Common causes include exceeding 10 DNS lookups, syntax errors in the record, or multiple SPF records existing. Use MXToolbox to check your lookup count, review your record’s syntax character by character, and ensure only one SPF record exists for your domain.

“SPF Fail” means you’re sending from an unauthorized server. This happens when you send through a service not included in your SPF record, you’ve added a new email service but haven’t updated SPF, or there’s a misconfiguration in how your email is being sent. Identify which server is sending your emails and add the appropriate include statement to your SPF record.

Key Takeaways

SPF forms the foundation of email authentication for cold email campaigns. Without it, you’re fighting an uphill battle for inbox placement that you’ll inevitably lose.

Make sure every service that sends email for your domain is included in your SPF record. Missing even one will cause authentication failures for those emails. Use -all (hard fail) rather than ~all to send the strongest possible signal to email providers that you take security seriously.

Watch your DNS lookup count carefully. Stay under the 10 lookup limit to avoid SPF failures that will tank your deliverability. After any SPF changes, always test your record with MXToolbox or Google Admin Toolbox to confirm everything works correctly.

Get SPF right, and you’ve completed the first critical step of email authentication. Combined with DKIM and DMARC, you’ll have the technical foundation for successful cold email campaigns.

Need Help With Email Authentication?

We set up SPF, DKIM, and DMARC for cold email teams every week. If you want it done right the first time, book a call with our team.