How to Set Up SPF for Cold Email

What SPF Does

SPF (Sender Policy Framework, defined in RFC 7208) is a DNS TXT record that lists the mail servers authorized to send email on behalf of your domain. When a receiving server gets an incoming message, it checks this record against the IP of the server that delivered it. If the IP is listed, SPF passes. If it is not, the server applies your policy — either soft fail or hard fail.

One detail that matters for cold email senders: SPF checks the MAIL FROM domain (also called the envelope sender or Return-Path address), not the From header your recipient sees. These can be different. When they differ, SPF can pass while DMARC alignment still fails, which has consequences for enforcement. This is particularly relevant for SES users, covered in its own section below.

SPF by itself does not guarantee inbox placement. What it does is establish that your sending source is authorized. Without it, receiving servers have no DNS-based evidence your mail is legitimate, which consistently lowers placement even when list quality and content are clean.

For cold email specifically, SPF matters because most cold outreach uses a dedicated sending domain that has no existing reputation. A new domain with no SPF record looks identical to a domain set up for spam. Getting SPF, DKIM, and DMARC all publishing correctly before the first send is the minimum baseline. Warmup builds reputation on top of that baseline; you cannot build reputation without the authentication layer underneath.

Step-by-Step SPF Setup

Step 1: List every service that sends from your domain

Before writing the record, account for every service that sends on your behalf: your mailbox provider (Gmail, Outlook, Zoho), your cold email platform, any transactional email service, and anything else — helpdesk software, marketing automation, CRMs that send notifications. Missing even one means mail from that service will fail SPF checks.

Step 2: Build the record

An SPF record is a single TXT record at the apex of your sending domain. Common include values by provider:

Google Workspace: v=spf1 include:_spf.google.com ~all
Microsoft 365: v=spf1 include:spf.protection.outlook.com ~all
Zoho: v=spf1 include:zoho.com ~all
Google + SES: v=spf1 include:_spf.google.com include:amazonses.com ~all

All includes go in one record. Two separate TXT records starting with v=spf1 on the same domain cause a PermerError and both fail. The ~all softfail at the end is right for cold email — it accepts mail from unlisted IPs but flags it rather than rejecting outright. +all authorizes every server on the internet to send as your domain and should never be used.

Step 3: Publish the record in DNS

Create a TXT record at the apex (@) of your domain. Set TTL to 3600 seconds. Save it and wait for propagation — typically 15 minutes to a few hours, though some registrars can take up to 48 hours. Before creating the record, check whether an existing SPF record is already published. If one exists, update it rather than creating a new one alongside it.

SES-Specific SPF Setup

Amazon SES has a SPF nuance that catches many senders off guard. By default, SES sets the MAIL FROM address to a domain under amazonses.com — something like 0100018abc@us-east-1.amazonses.com. Adding include:amazonses.com to your SPF record makes SPF pass for that address. But the MAIL FROM domain (amazonses.com) does not match your From header domain (yourdomain.com), so SPF alignment for DMARC fails. SPF passes; DMARC cannot use it for enforcement.

The fix is configuring a custom MAIL FROM subdomain in SES. This makes SES use bounce.yourdomain.com (or any subdomain you choose) as the envelope sender address instead of the default. Two DNS records are required on that subdomain:

MX record: bounce.yourdomain.com → 10 feedback-smtp.us-east-1.amazonses.com
SPF record: bounce.yourdomain.com → v=spf1 include:amazonses.com ~all

Note that the SPF record here goes on bounce.yourdomain.com, not the apex. Your apex SPF record (yourdomain.com) covers services that send using your root domain as the MAIL FROM. The subdomain SPF record covers SES bounce routing specifically.

In the SES console, go to Verified Identities, select your domain, and find Custom MAIL FROM domain settings. Enter bounce.yourdomain.com and save. Once the subdomain verifies, SES will use it as the MAIL FROM on all outbound mail, and SPF will align with your From header domain for DMARC. Adjust the MX record region (us-east-1, eu-west-1, etc.) to match whichever SES region you send from.

Common SPF Mistakes

Multiple SPF records. Your domain should have exactly one TXT record starting with v=spf1. Adding a second one instead of updating the first causes PermerError and both records fail. This happens often when teams use different DNS tools or providers and do not check for an existing record before adding a new one.

Exceeding 10 DNS lookups. RFC 7208 limits SPF to 10 DNS lookups. Each include: counts as one lookup, and the included records may contain further includes that count as additional lookups. Exceeding the limit returns PermerError. Use an SPF checker to count lookups. If you are over the limit, replace include: statements for services with stable IPs with direct ip4: records.

Skipping the custom MAIL FROM for SES. Without it, SPF passes but does not align with your From domain, so DMARC must rely entirely on DKIM for enforcement. Both passing is significantly better. Setting up the custom MAIL FROM is a 10-minute task that pays off for every campaign you send.

SPF on the wrong domain. If you send cold email from go.yourdomain.com but publish SPF only at the apex, SPF checks for the subdomain will find no record and fail. Publish SPF at whichever domain appears in the MAIL FROM address, which may be a dedicated sending subdomain.

Not updating after adding a new service. Any service that sends on your behalf and is not in your SPF record will produce softfail results. Teams that add a new CRM or helpdesk tool without updating SPF often discover the problem weeks later through unexplained placement drops.

How to Verify SPF Is Working

Gmail's Show Original. Send a test email from your sending domain to a Gmail account. Open the message, click the three-dot menu, select "Show original." The authentication results near the top should include spf=pass. If you see spf=softfail or spf=neutral, the sending server's IP is not in your SPF record. If you see spf=permerror, you have multiple SPF records or exceeded the lookup limit.

dig command. From a terminal, run dig TXT yourdomain.com. The output should show exactly one TXT record starting with v=spf1. If you see two, delete the duplicate. If you see none, the record was not published or has not propagated yet.

EmailQo's free SPF checker. The tool at /spf-checker validates record syntax, counts DNS lookups, and flags common misconfigurations without requiring a test send. Useful for checking subdomains and newly added records before campaigns launch.

Pre-send checks. EmailQo validates SPF on the actual sending domain before every campaign. If the record is absent, misconfigured, or over the lookup limit, the check flags it before any email goes out. This is the most practical verification because it checks whichever domain is in use for that specific campaign, which may differ from the apex domain.