.svg)
Overview
Every cold email that lands in spam instead of the inbox starts with the same root cause: the receiving mail server did not trust the sender. Sender Policy Framework, or SPF, is the first layer of that trust. It is a DNS record that tells mailbox providers which servers are authorized to send email on behalf of your domain. Without it, anyone can spoof your sending domain, and inbox providers respond by treating all email from that domain as suspicious.
For GTM Engineers managing outbound infrastructure, SPF is not an IT checkbox. It is the foundation of your entire sending reputation. A misconfigured SPF record does not just reduce deliverability. It actively undermines every other investment you make in cold email tooling, personalization, and list quality. This guide covers how SPF actually works, how to configure it for multi-tool outbound stacks, and the common mistakes that silently destroy deliverability.
How SPF Actually Works
SPF operates at the DNS level. When you send an email, the receiving server performs a lookup on the envelope sender domain (the Return-Path header, not the visible From address). It queries the DNS for a TXT record that starts with v=spf1. That record contains a list of IP addresses, IP ranges, and third-party includes that are authorized to send on behalf of your domain.
If the sending server's IP matches one of the authorized sources, SPF passes. If it does not match, SPF fails. The receiving server then uses that result alongside DKIM and DMARC to decide whether the email reaches the inbox, lands in spam, or gets rejected outright.
The SPF Record Anatomy
An SPF record is a single TXT record on your domain's DNS. Here is a typical example for a GTM team running outbound through Google Workspace and a cold email platform:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all
Breaking this down:
v=spf1— Declares this is an SPF record. Every SPF record starts here.include:_spf.google.com— Authorizes Google Workspace to send on behalf of this domain.include:sendgrid.net— Authorizes SendGrid (used by many cold email platforms under the hood).include:servers.mcsv.net— Authorizes Mailchimp for marketing emails.~all— Soft fail for any server not listed. This tells receiving servers to accept but flag unauthorized senders rather than rejecting them outright.
The -all mechanism (hard fail) tells receiving servers to reject any email from unauthorized senders. The ~all mechanism (soft fail) tells them to accept but treat it suspiciously. Most teams start with ~all during initial setup to avoid accidentally blocking legitimate email, then move to -all once they have confirmed all sending sources are included. For cold outbound domains specifically, -all is the right long-term setting because you want maximum authentication enforcement.
Configuring SPF for Outbound Infrastructure
Setting up SPF for a single tool is straightforward. The complexity comes from the reality that most GTM teams send email through multiple services simultaneously: Google Workspace for direct replies, a cold email platform like Instantly or Smartlead for outbound sequences, a CRM like HubSpot or Salesforce for automated notifications, and possibly a marketing automation tool for nurture campaigns.
Step-by-Step SPF Configuration
include:_spf.google.com, Microsoft 365 uses include:spf.protection.outlook.com, HubSpot uses include:hubspot.com, and so on. Check each vendor's documentation for their current SPF include value.spf=pass.Dedicated Outbound Domains
If you follow the best practice of using dedicated sending domains for cold outbound (and you should), each domain needs its own SPF record. A domain like try-acme.com used exclusively for cold email might only need one include: the cold email platform. This keeps the record simple and avoids the DNS lookup limit problem that plagues primary domains with many sending sources.
| Domain Type | Typical Sending Sources | SPF Complexity |
|---|---|---|
| Primary domain (acme.com) | Google Workspace, CRM, marketing, transactional | High — often near the 10-lookup limit |
| Outbound domain (try-acme.com) | Cold email platform, Google Workspace for replies | Low — 2-3 includes |
| Marketing subdomain (mail.acme.com) | Marketing automation, ESP | Moderate — 2-4 includes |
The 10-Lookup Limit and How to Handle It
SPF has a hard limit of 10 DNS lookups per record evaluation. Each include, a, mx, and redirect mechanism counts as one lookup. The problem is that includes are recursive: when you include _spf.google.com, that record itself includes additional records, each consuming a lookup. Google Workspace alone uses 3-4 lookups. Add HubSpot, SendGrid, and Microsoft 365, and you have blown past the limit before you even add your cold email platform.
When an SPF evaluation exceeds 10 lookups, the result is a permanent error (permerror). Receiving servers treat this as an SPF failure. Your email still gets delivered in many cases, but without SPF passing, your DMARC alignment breaks, and inbox providers lose a critical trust signal.
Solutions for the Lookup Limit
- Flatten your SPF record — Replace include mechanisms with the actual IP addresses or IP ranges they resolve to. Tools like SPF Flattening services (AutoSPF, dmarcian) do this automatically and update the record when vendor IPs change. The trade-off is maintenance: if a vendor changes their IP ranges and your flattened record is not updated, their email will fail SPF.
- Use subdomains — Move different sending sources to different subdomains. Marketing email goes through
mail.acme.com, cold outbound throughoutreach.acme.com. Each subdomain gets its own SPF record with its own 10-lookup budget. - Remove unused includes — Audit your SPF record quarterly. Teams frequently leave old includes for tools they no longer use. That legacy Mailchimp include from 2023 is consuming a lookup you could use for your new cold email platform.
- Use IP4/IP6 mechanisms directly — If a sending service uses a small, stable set of IPs, add them directly instead of using an include.
ip4:192.168.1.0/24does not count against the lookup limit.
Run dig TXT yourdomain.com from the command line or use MXToolbox's SPF lookup to see your current record. Then use a tool like Kitterman's SPF validator to check the total lookup count. If you are at 8+ lookups on your primary domain, plan for subdomain segmentation before adding any new sending tools.
Common SPF Misconfigurations That Destroy Deliverability
SPF errors are silent killers. Your email still sends, your platform reports "delivered," but inbox placement slowly degrades because SPF is failing in the background. Here are the misconfigurations GTM Engineers encounter most often.
Multiple SPF Records
This is the most common and most damaging mistake. A domain can only have one SPF TXT record. If you have two, both are invalid, and SPF fails for every email sent from that domain. This typically happens when one team adds an SPF record for Google Workspace and another team adds a separate record for the marketing platform without checking what already exists. The fix is to merge all includes into a single record.
Missing Includes for Active Sending Services
Your outbound stack evolves over time. You add a new cold email platform, switch CRMs, or onboard a new marketing tool. If the SPF record is not updated to include the new service's sending servers, every email sent through that service fails SPF. This is particularly dangerous because the sending platform shows successful delivery while the email quietly lands in spam.
Exceeding the Lookup Limit Without Realizing It
As discussed above, exceeding 10 lookups causes a permanent error. The insidious part is that you might have been at 9 lookups for months without issues, and then a vendor updates their SPF record to add one more nested include, pushing you over the limit without you changing anything.
Using +all Instead of ~all or -all
A +all mechanism tells the world that literally any server can send email as your domain. This effectively disables SPF. It is rarely intentional but sometimes appears in records copied from outdated documentation or misconfigured by someone who did not understand the mechanism.
SPF on Subdomains Without MX Records
If you set up a subdomain for outbound sending (outreach.acme.com), it needs both an SPF record and an MX record. The SPF record authorizes sending, but without MX records, you cannot receive replies, bounces, or other feedback that mailbox providers use to verify your domain is legitimate. Always configure MX alongside SPF on any domain or subdomain used for email.
| Misconfiguration | Symptom | Fix |
|---|---|---|
| Multiple SPF records | All SPF checks fail, rapid deliverability decline | Merge into a single record |
| Missing include for a sending tool | That tool's emails land in spam despite clean lists | Add the vendor's include mechanism |
| Exceeding 10 lookups | SPF permerror, DMARC alignment breaks | Flatten record or split across subdomains |
| Using +all | SPF passes for everyone, including spoofers | Change to ~all or -all immediately |
| No MX on sending subdomain | Replies bounce, reputation signals lost | Add MX record pointing to your mail provider |
SPF Alignment with DKIM and DMARC
SPF alone does not protect your domain. It works as part of a three-layer authentication stack alongside DKIM and DMARC. Understanding how these layers interact is critical because a misconfiguration in one can undermine the others.
DMARC requires either SPF or DKIM to pass and align with the From domain. "Alignment" means the domain in the Return-Path (which SPF checks) matches the domain in the visible From header. When your cold email platform sends email using your domain in the From header but uses its own Return-Path domain for bounce handling, SPF might pass for the platform's domain but fail alignment with your From domain. In that scenario, you need DKIM to carry the authentication load.
This is why GTM Engineers cannot treat SPF, DKIM, and DMARC as independent configurations. They form a system. SPF handles server authorization, DKIM handles message integrity and domain signing, and DMARC ties them together with policy enforcement. Getting SPF right is necessary but not sufficient. You need all three configured correctly for each sending domain in your outbound infrastructure.
DMARC supports two alignment modes: strict and relaxed. Strict alignment requires an exact domain match between the Return-Path and From header. Relaxed alignment allows subdomains to match the organizational domain. For most outbound setups, relaxed alignment (aspf=r) is the right choice because cold email platforms often use subdomains for Return-Path handling. Configure this in your DMARC record.
Monitoring and Ongoing Maintenance
SPF is not a set-and-forget configuration. Your sending infrastructure evolves, vendors change their IP ranges, and new tools get added to the stack. GTM Engineers need a maintenance workflow that catches problems before they impact deliverability.
Regular Audits
Check your SPF records monthly. Verify that every active sending service is included and every deprecated service is removed. Use a validation tool to confirm the total lookup count stays under 10. For teams with structured maintenance workflows, add SPF audits to the monthly checklist alongside domain reputation checks in Google Postmaster Tools.
Monitoring SPF Results
DMARC aggregate reports include SPF pass/fail data for every email sent from your domain. If you have DMARC configured with reporting (and you should), these reports will show you when SPF is failing, which sending sources are causing failures, and how receiving servers are handling the failures. This is the most reliable way to detect SPF misconfigurations before they compound into reputation damage.
Vendor Changes
Email service providers occasionally update their SPF include records. If you are using flattened SPF records (with hardcoded IP addresses), these changes will break your configuration. Subscribe to status pages and changelogs from your sending vendors, and re-validate your SPF record whenever you receive an infrastructure update notification.
FAQ
Use MXToolbox's SPF lookup tool or run dig TXT yourdomain.com from the command line. Look for a single TXT record starting with v=spf1. Then send a test email to a Gmail account and inspect the email headers for spf=pass. If you see spf=softfail or spf=fail, your record is either missing an include for your sending service or has a structural error.
Yes. Each domain and subdomain has its own independent SPF record. A record on acme.com does not apply to outreach.acme.com. You need to create separate SPF records for each subdomain that sends email. This is actually an advantage because it lets you keep each record lean and well within the 10-lookup limit.
SPF alone does not prevent spoofing because it checks the Return-Path domain, not the visible From address that recipients see. A spoofer can set any From address while using their own Return-Path. This is why SPF must work alongside DKIM and DMARC. DMARC adds the alignment requirement that connects SPF and DKIM results back to the visible From domain, closing the spoofing gap.
Without an SPF record, receiving servers have no way to verify your sending servers are authorized. The result is not automatic spam placement, but it removes a trust signal that inbox providers use in their filtering decisions. Combined with the absence of DKIM and DMARC, missing SPF almost guarantees poor inbox placement for cold email. Every major inbox provider now considers authentication records as baseline expectations.
What Changes at Scale
Managing SPF for a single outbound domain with one sending platform is a 15-minute task. At scale, with 10 sending domains, 5 different tools in the stack, and domains being spun up and deprecated on a monthly cadence, SPF management becomes an operational burden that nobody owns. Records get stale, new tools get onboarded without DNS updates, and the first sign of a problem is a week of emails silently landing in spam.
What teams actually need is centralized visibility into authentication status across every domain in their outbound infrastructure, with automated alerts when configurations drift or break. SPF, DKIM, and DMARC checks should be part of a unified monitoring layer that tracks domain health alongside sending reputation, bounce rates, and engagement metrics.
Octave is an AI platform built to automate and optimize your outbound playbook, and that includes the infrastructure layer. Octave's Library centralizes your company context, products, and ICP definitions, while its Sequence Agent generates personalized email sequences that are automatically matched to the right playbook per lead. For teams running multi-domain outbound at volume, Octave ensures every send is backed by the right messaging strategy, so the authentication infrastructure you build actually supports outreach that converts.
Conclusion
SPF is the first line of defense for your outbound email infrastructure. It is a simple concept, a DNS record that authorizes your sending servers, but the implementation details matter enormously. A single misconfiguration can silently degrade deliverability across your entire outbound program, and the damage compounds because mailbox providers penalize domains with persistent authentication failures.
Get the fundamentals right: one SPF record per domain, every sending source included, total lookups under 10, and a hard fail policy once you are confident in your configuration. Then build the monitoring and maintenance workflows that catch problems before they become reputation crises. SPF is not glamorous, but for GTM Engineers building reliable outbound infrastructure, it is the foundation everything else depends on.