SPF Format: The Complete Syntax Guide for Cold Email

SPF records look simple until they break your delivery. A valid record starts with a specific version string, lists authorized sending sources through mechanisms like include and ip4, and ends with a qualifier that tells receivers how to treat unauthorized mail. Most failures happen not because you forgot to add a service, but because you violated the format rules: too many DNS lookups, multiple records on one subdomain, or a trailing dot in the wrong place. For agencies running dozens of client domains, one syntax error scales into hundreds of lost opportunities.

The Anatomy of a Valid SPF Record

An SPF record is a single DNS TXT resource record. The format is strict: it must begin with the version identifier v=spf1, followed by zero or more mechanisms and modifiers. A typical record for a cold email operation looks like this:

"v=spf1 include:_spf.google.com include:send.example.com ip4:192.0.2.1 -all"

The version string v=spf1 must appear first and exactly as written. Lowercase only, no spaces between v= and spf1. Following the version are the mechanisms, which define authorized senders. Common mechanisms include include (reference another domain's policy), ip4 and ip6 (specific IP addresses or ranges), a (the domain's A record), and mx (the domain's mail exchangers). Each mechanism may be prefixed with a qualifier: + for pass (default if omitted), - for fail, ~ for soft fail, or ? for neutral.

The record must contain the all mechanism, which matches any address and typically appears at the end. The qualifier attached to all determines the default policy for sources not matched by previous mechanisms. DNS TXT records have a 255-character limit per string, but many DNS managers automatically split longer records into multiple quoted strings that concatenate. If your record exceeds 450 characters total, you have an architectural problem, not just a formatting one.

Mechanisms and the Lookup Budget

Every SPF record operates under a hard limit of 10 DNS lookups, defined in RFC 7208 Section 4.6.4. This is not a suggestion; receivers that exceed this limit must return PermError, effectively treating your domain as having no SPF protection. The mechanisms that consume lookups are include, a, mx, ptr, and exists. The include mechanism is particularly costly because it counts as one lookup to fetch the referenced record, plus every lookup that nested record generates.

For example, include:_spf.google.com appears to be one lookup, but Google's SPF record contains four netblocks, each requiring a lookup. Your include of Google actually consumes five lookups from your budget. Add an include for your cold email platform, another for your CRM, and an MX check for your own infrastructure, and you are at eight or nine lookups before you blink.

This is where the SPF 10-lookup limit becomes a format constraint rather than a theoretical limit. When you hit it, you cannot simply add another service. You must restructure the record by flattening includes into explicit ip4 ranges or by removing redundant mechanisms. For agencies managing multiple sending domains, this arithmetic is not a one-time setup task; it is ongoing infrastructure maintenance every time you onboard a new tool or change sending providers.

Format Failures That Silence Mail

The most common format error is deploying multiple SPF records on a single domain. RFC 7208 Section 3.1 states that if multiple TXT records starting with v=spf1 exist, the receiver may select any one of them arbitrarily. This means your carefully crafted restrictive record might be ignored in favor of an older, permissive one you forgot to delete. Always maintain exactly one SPF record per subdomain.

Other format killers include trailing periods inside the record (DNS managers sometimes add them automatically, but inside the quoted SPF content they break parsing), uppercase version strings (V=spf1 is invalid), and missing spaces between mechanisms. Some DNS interfaces require you to wrap the record in quotes; others add them automatically. If you double-quote manually and the interface also quotes, you end up with escaped quotes inside the DNS response, which breaks SPF parsers.

Character encoding also matters. SPF records must be plain ASCII. Copying from a word processor or PDF can insert smart quotes or non-breaking spaces that look identical to the human eye but cause DNS lookups to return NXDOMAIN or malformed results. Always validate by querying the record directly: dig TXT example.com and inspect the raw output.

Qualifiers and Policy Semantics

The qualifier prefix determines how a receiver treats a match. The + qualifier (default) results in a Pass. The - qualifier results in a Fail, instructing the receiver to reject the message. The ~ qualifier results in SoftFail, typically meaning the message should be accepted but marked as suspicious. The ? qualifier returns Neutral, meaning the receiver should not take any action based on SPF.

For cold email operators, the choice between -all and ~all is strategic. -all provides the strongest signal to receivers that you control your infrastructure, but it risks losing legitimate mail if your SPF record is incomplete (for example, if a partner sends on your behalf and you forgot to include them). ~all is safer during migration periods or when using multiple forwarding services. The format requires the qualifier to immediately precede the mechanism with no space: -all is correct, - all is malformed.

SPF Format at Agency Scale

Suppose you run an agency managing cold email for twelve clients. Each client uses Google Workspace, a dedicated cold email sending subdomain, and a CRM integration. You might assume you can copy the same SPF record template to each domain, but the lookup arithmetic varies by client. Client A uses Google Workspace (five lookups for the netblocks), a cold email platform with two nested includes (three lookups total), and an MX check (one lookup). That is nine lookups, leaving room for one more service.

Client B uses Microsoft 365 instead of Google. Microsoft's SPF includes are flatter, consuming only two lookups, but they also use an a mechanism check. You are at three lookups before you add the cold email tool. Now you have room for expansion, but only if you remember that Client A is at capacity while Client B is not.

When you scale to forty domains, manual tracking becomes impossible. A centralized approach becomes necessary. Agencies need systems that validate SPF syntax and lookup counts across all client domains automatically, flagging records that approach the 10-lookup limit or contain malformed mechanisms before they impact delivery.

Validation and Continuous Monitoring

Validate your SPF format before it hits DNS. Use command-line tools to simulate the evaluation: dig TXT _spf.example.com to fetch included records and manually count the lookups. Online SPF validators can simulate the evaluation tree, but they often miss DNS-level issues like TTL mismatches or truncated UDP responses.

After deployment, monitor DMARC aggregate reports. A spike in SPF alignment failures often indicates a format problem, such as an include that suddenly started returning more lookups due to a vendor infrastructure change, or a subdomain inheriting an unexpected SPF record via CNAME flattening. Set calendar reminders to audit records quarterly, especially for domains using SaaS platforms that frequently change their IP ranges or SPF includes without notice.

SPF as One Component of Sender Identity

SPF format correctness is necessary but insufficient for cold email deliverability. SPF authenticates the envelope sender (the MAIL FROM address), but it does not cryptographically sign the message content. You also need DKIM to sign headers and body, and DMARC to align the two and set a policy for receivers when authentication fails. The full authentication stack must be implemented correctly for high-volume sending.

SpamCipher is the cold email platform for unlimited, automated sending, built on an owned deliverability pipeline it backs with its own 90%+ inbox placement claim. For agencies and growth teams, SPF format is just the entry ticket. The platform automates the warm-up, inbox rotation, and placement monitoring behind the records, so your correctly formatted SPF records actually translate into delivered mail rather than just DNS hygiene.

Frequently asked questions