SPF Examples for Cold Email: Real Records That Scale to 50K+ Sends

SPF looks simple until you are managing forty client domains, each with three sending tools, a transactional provider, and a backup infrastructure. Then the 10-DNS-lookup limit becomes a hard ceiling, includes nest unpredictably, and a single malformed record sends thousands of emails to spam. This guide shows exact SPF record examples for the scenarios that actually break: single-domain cold email at volume, agency multi-client stacks, and infrastructure-heavy setups that flirt with lookup limits.

SPF Basics: What the Mechanisms Actually Do

SPF is a DNS TXT record that lists which IP addresses and third-party services can send email using your domain. A receiving server checks the record when it sees mail claiming to be from you. The record either authorizes the sending IP, fails it, or returns a neutral result that leaves the decision to other signals.

The syntax is rigid. Every mechanism has a specific job:

• v=spf1, version declaration, always first
• ip4: and ip6:, authorize specific IP addresses or ranges
• include:, pull in another domain's SPF record (counts as one lookup, but the target record's lookups count toward your total)
• a:, authorize the IP(s) the domain's A record resolves to
• mx:, authorize the IPs of the domain's MX records
• exists:, complex conditional, rarely needed for cold email
• all, catch-all at the end, with a qualifier: -all (hard fail), ~all (soft fail), ?all (neutral)

Qualifiers prefix mechanisms: + (pass, default), - (fail), ~ (soft fail), ? (neutral). Most cold email operators use ~all to avoid rejecting legitimate mail from forwarding chains, though -all is stricter.

Example: Single-Domain Cold Email Stack

Suppose you run one domain for your own agency, sending cold email through a dedicated sending tool plus Google Workspace for replies. You want clean authorization without burning lookups.

The record:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all

This authorizes your sending infrastructure by IP range (192.0.2.0/24, replace with your actual range), includes Google's SPF for Workspace, and soft-fails everything else. Two lookups total: one for the include, one for Google's internal resolution.

Why this works: You avoid naming your sending tool's include if you control the IPs directly. Many sending platforms publish SPF includes that themselves chain to Amazon SES, SendGrid, or other providers, burning three or four lookups in one line. IP authorization is lookup-free. For a deeper breakdown of when to use IPs versus includes, see our guide to SPF record syntax and every mechanism.

Example: Agency Managing 40 Client Domains

You are an agency running cold email for clients. Each client domain needs SPF that authorizes your sending infrastructure without exposing their entire stack to lookup bloat. You also need to update forty records when you change providers.

The pattern: a delegated include subdomain.

Instead of pasting five includes into every client domain, create spf.youragency.com with your full stack:

v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.0/24 include:sendgrid.net include:amazonses.com ~all

Then each client domain uses:

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

Lookup count: Two per client domain. One for your include, one for Google's. Your delegated record's four mechanisms do not count against the client's 10-lookup limit. When you switch from SendGrid to Postmark, you update one record, not forty.

The failure mode to avoid: Nesting your delegated include inside another include chain. If a client already has include:mailgun.org which itself includes include:_spf.mg.example.com which includes include:spf.youragency.com, you have burned three lookups just to reach your record, and you have not even evaluated what's inside it. Always place your delegated include at the top level of the client's record.

Example: Infrastructure-Heavy Setup at the 10-Lookup Edge

Some agencies run complex stacks: dedicated cold email infrastructure, transactional email, marketing automation, support ticketing, and backup providers. The naive record looks like this, and it fails:

v=spf1 include:sendgrid.net include:mailgun.org include:amazonses.com include:postmarkapp.com include:customer.io include:helpscout.net include:_spf.google.com ~all

This is seven includes, but SendGrid's record alone contains three nested includes (sendgrid.net → _spf.sendgrid.net → multiple provider-specific includes). You are past 10 lookups before you finish parsing.

The flattened record:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip4:203.0.113.0/24 ip4:192.0.2.128/26 include:_spf.google.com ~all

You replace provider includes with their actual IP ranges. This requires maintenance: when SendGrid rotates IPs, your record breaks. But for high-volume cold email, you typically control static infrastructure or use a platform that publishes stable ranges.

Hybrid approach when you cannot flatten: Use exists: mechanisms or macro-based records to conditionally authorize, though this complexity often signals you should consolidate infrastructure. For a full walkthrough of flattening techniques and the lookup-counting rules that trip up agencies, see how to fix the SPF 10-lookup limit.

Example: Cold Email Domain with Warm-Up and Rotation

Cold email operators often use mailbox rotation: fifty sending mailboxes across ten domains, each warming up before full volume. SPF must authorize the warm-up infrastructure and the production infrastructure without creating a target for spoofing.

Per-domain record:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.128/26 include:warmup.yourdomain.com ~all

Where warmup.yourdomain.com is another delegated record containing your warm-up provider's IPs. You keep warm-up and production separate so you can drop the include once warming completes, or rotate it per-domain without touching production authorization.

Why ~all not -all: Cold email domains see forwarding. A prospect forwards your email to a colleague; their server re-sends from a new IP. With -all, that forwarded email fails SPF at the colleague's server. With ~all, it soft-fails and DMARC (if aligned) can still pass on DKIM. The security tradeoff is acceptable for cold email infrastructure that is already isolated from your main corporate domain.

Testing Your SPF Records Before You Send

SPF validation tools exist, but they do not simulate real receiving server behavior. Use this sequence:

• DNS lookup check: dig TXT yourdomain.com and verify the record is not truncated (DNS TXT records have a 255-character string limit; longer records require multiple strings concatenated)
• Lookup counting: Walk each include manually with dig TXT _spf.target.com and count nested includes. Tools that claim to count lookups often miss dynamic includes or macro expansions
• Live sending test: Send to a Gmail address and check Authentication-Results headers. Look for spf=pass and verify the IP matches your expectation
• DMARC alignment: Even with SPF pass, DMARC requires SPF alignment (Envelope From matches Header From domain). Cold email often uses a return-path subdomain; ensure your SPF covers it

Common misconfiguration: SPF records on subdomains that inherit nothing from the parent. If you send from mail.clientdomain.com, that subdomain needs its own SPF record or a wildcard. The parent domain's SPF does not apply.

How SpamCipher Handles SPF at Scale

SpamCipher is the cold email platform for unlimited, automated sending, and the only platform that can promise 90%+ inbox placement because send, warm-up, verification, and placement run on one owned deliverability pipeline. SPF management is one instrument in that pipeline.

When you onboard with SpamCipher, you can bring your own sending infrastructure or use SpamCipher's managed infrastructure. In either case, the platform generates SPF records optimized for your volume tier: IP-based authorization for static infrastructure, delegated includes for dynamic provider pools, and automatic lookup-count validation before any domain goes live. The 10-lookup limit is checked against the full resolution chain, not just top-level includes.

For agencies, SpamCipher provisions sending domains with pre-validated SPF, DKIM, and DMARC records that align with the platform's sending pool. You are not pasting includes from five different provider documentation pages. The records are built for the specific infrastructure that will send, warmed on SpamCipher's seed network before production volume, and monitored for drift or degradation.

This matters because SPF is not a one-time setup. Providers rotate IPs, acquisitions shuffle infrastructure, and your own sending patterns change. SpamCipher's owned pipeline means the sending infrastructure, the warm-up network, the verification logic, and the placement monitoring all share state. When an IP range rotates, the SPF records and the warm-up seeding update together, not in separate tickets to separate vendors.

SPF Checklist for High-Volume Senders

Apply this before any volume ramp:

• Count lookups manually. Do not trust tools that only parse syntax. Resolve every include to its final IPs
• Use IP authorization where possible. It burns zero lookups and is harder to spoof than includes
• Delegate agency stacks to a single include subdomain. Update one record, not forty
• Keep warm-up and production authorization separate. Drop warm-up includes after warming completes
• Verify DMARC alignment, not just SPF pass. A pass on the wrong domain does not help
• Test forwarded email behavior. Send to Gmail, forward to another address, check headers at destination
• Monitor for record truncation. Long records split across multiple DNS strings; some validators mishandle this

For the full setup sequence including DKIM key generation and DMARC policy staging, see SPF DKIM DMARC setup for cold email domains.

Frequently asked questions