SPF Record Examples: Real Syntax for Every Sending Scenario

An SPF record tells receiving mail servers which IP addresses are allowed to send email for your domain. Get the syntax wrong, exceed the lookup limit, or forget an include, and your cold email lands in spam no matter how good the copy. Below are real SPF examples for the most common sending scenarios, with the exact syntax and the failure modes each one introduces.

Basic SPF Syntax: The Minimal Record

The simplest valid SPF record authorizes no senders and fails everything else:

v=spf1 -all

This says: version SPF1, no mechanisms before the all, so reject everything. You use this when the domain sends no mail, or as a starting point before adding mechanisms.

A slightly more useful example authorizes the domain's own A record (the IP of the domain itself) and the MX servers (wherever inbound mail is handled):

v=spf1 a mx -all

The a mechanism checks if the sending IP matches the A record for the domain. The mx mechanism checks if the sending IP matches any of the domain's MX records. The -all at the end is a hard fail for everything else.

This works if you send from the same server that receives mail, but breaks the moment you add Google Workspace, an ESP, or a dedicated sending IP. Most production SPF records need at least one include: directive.

Google Workspace SPF Example

If you send email through Google Workspace (Gmail for business), you include Google's SPF record:

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

The include:_spf.google.com tells the receiving server to check Google's SPF record for authorized IPs. Google publishes a list of their sending IPs at that subdomain, and the include counts as one DNS lookup against your 10-lookup limit.

The ~all at the end is a soft fail. It means "if the IP doesn't match anything, mark it as suspicious but don't reject it outright." Many senders use ~all during testing and switch to -all (hard fail) once they confirm all legitimate sending sources are covered.

If you also send from your own server or a transactional ESP, you add those before the all:

v=spf1 include:_spf.google.com ip4:203.0.113.50 ~all

The ip4: mechanism authorizes a specific IPv4 address. You can also use ip6: for IPv6, or ip4: with CIDR notation for a range (e.g. ip4:203.0.113.0/24).

Microsoft 365 (Office 365) SPF Example

Microsoft 365 requires a similar include:

v=spf1 include:spf.protection.outlook.com ~all

This authorizes all Microsoft 365 sending IPs. If you use Exchange Online Protection or send through Outlook, this is the include you need.

Microsoft's SPF record itself contains multiple nested includes, so this single directive can consume several of your 10 DNS lookups. If you add other ESPs or sending services, you hit the lookup limit faster than with Google.

A common mistake is including both Google and Microsoft when only one is actually sending:

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

This works, but costs two lookups. If you migrated from Google to Microsoft and forgot to remove the old include, you are burning a lookup slot for no reason. Audit your SPF record every time you change email providers.

ESP SPF Examples: SendGrid, Mailgun, Postmark

Most transactional and cold email ESPs require an include directive. Here are the exact records for the most common platforms:

SendGrid:

v=spf1 include:sendgrid.net ~all

Mailgun:

v=spf1 include:mailgun.org ~all

Postmark:

v=spf1 include:spf.mtasv.net ~all

Amazon SES: SES does not publish a single include. You must add the specific IP addresses or CIDR ranges SES assigns to your account, or use a custom MAIL FROM domain with its own SPF record. Example:

v=spf1 ip4:203.0.113.0/24 ~all

When you send through multiple ESPs (common for agencies running cold email alongside transactional mail), you chain the includes:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

Each include costs one DNS lookup. Three includes plus any nested lookups inside those records can push you close to the 10-lookup limit. If you add a fourth ESP, you risk exceeding the limit and breaking SPF validation entirely. We cover how to fix that in our guide to the 10-lookup limit.

Multi-Sender SPF: Combining Office, ESP, and Dedicated IPs

A realistic SPF record for an agency sending cold email at scale might look like this:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ip4:198.51.100.10 ip4:198.51.100.11 ~all

This authorizes Microsoft 365 for internal email, SendGrid for transactional sends, and two dedicated IPs for cold email sending. The two ip4: directives do not count as DNS lookups (they are evaluated directly), but the two includes do.

If SendGrid's SPF record contains nested includes, this setup could easily consume 4 or 5 lookups. Add one more ESP and you are at the edge of the limit.

The failure mode here is silent. If you exceed 10 lookups, receiving servers stop processing the SPF record and treat it as a PermError. Your email does not bounce; it just lands in spam or gets rejected without a clear error message.

For agencies managing dozens of sending domains, the better approach is to flatten the SPF record (replace includes with the actual IP ranges) or use subdomains with separate SPF records for each sending channel. SpamCipher handles this automatically when you bring your own sending infrastructure or let us build it for you. The platform rotates sending mailboxes across multiple domains, each with its own optimized SPF record, so you never hit the lookup limit and inbox placement stays above 90%.

SPF Qualifiers: Pass, Fail, SoftFail, Neutral

Every mechanism in an SPF record can have a qualifier that tells the receiving server what to do if the mechanism matches:

• + (pass): The IP is authorized. This is the default if you omit the qualifier.
• - (fail): The IP is not authorized. Reject the email.
• ~ (softfail): The IP is not authorized, but don't reject outright. Mark it as suspicious.
• ? (neutral): No policy. Treat the result as if no SPF record exists.

Most SPF records end with -all or ~all. The difference matters:

v=spf1 include:_spf.google.com -all

This hard-fails any IP not covered by Google's include. If you send from an IP you forgot to authorize, the email is rejected.

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

This soft-fails unknown IPs. The receiving server might still accept the email but flag it as suspicious. Use ~all during testing, then switch to -all once you have confirmed all legitimate senders are covered.

You can also apply qualifiers to individual mechanisms:

v=spf1 +ip4:203.0.113.50 -ip4:203.0.113.51 ~all

This explicitly authorizes .50, explicitly rejects .51, and soft-fails everything else. In practice, you rarely need per-mechanism qualifiers; the final all handles the default case.

For a deeper breakdown of every mechanism and modifier, see our full SPF syntax guide.

SPF for Subdomains: Separate Records for Sending Channels

SPF records do not inherit. If you set an SPF record on example.com, it does not apply to mail.example.com or cold.example.com. Each subdomain needs its own TXT record.

This is useful for isolating cold email sending from your primary domain. You can set up:

example.com:         v=spf1 include:_spf.google.com -all
mail.example.com:    v=spf1 ip4:198.51.100.10 -all
cold.example.com:    v=spf1 ip4:198.51.100.11 -all

Now your internal email uses Google Workspace, your transactional email sends from a dedicated IP on mail.example.com, and your cold email sends from a different IP on cold.example.com. Each subdomain has a simple SPF record with no lookup limit risk.

This also protects your primary domain reputation. If cold email sending triggers a spam complaint or blacklist, only the subdomain is affected. Your main domain continues to deliver internal and transactional mail without interference.

For high-volume cold email, SpamCipher rotates sending across multiple subdomains and mailboxes automatically, each with its own SPF record and warm-up history. This keeps any single sending identity below the volume threshold that triggers spam filters, and spreads deliverability risk across the infrastructure.

How SpamCipher Handles SPF at Scale

When you send cold email at high volume, SPF becomes an infrastructure problem, not a one-time DNS setup. You need multiple sending domains, each with its own SPF record, rotated automatically to avoid volume-based filtering. You need those domains warmed up before you send, and you need inbox placement monitoring to catch SPF failures before they tank your campaign.

SpamCipher runs all of this on one owned deliverability pipeline. You bring your own sending infrastructure (domains, mailboxes, IPs), or let us build and manage it for you. The platform handles SPF setup, warm-up on a real seed network, automatic mailbox rotation, and inbox placement monitoring in the same product. You get 90%+ inbox placement because sending, authentication, and deliverability are managed together, not bolted on after the fact.

For agencies managing cold email for multiple clients, this means you do not manually configure SPF records for every new domain, do not chase down lookup-limit errors, and do not guess whether a sending IP is warmed up. The platform handles it, and you scale volume without scaling deliverability overhead.

SpamCipher starts free and scales to unlimited sending. No per-email cost, no lookup-limit surprises, no separate tools for verification, warm-up, and placement. It is cold email sending built for agencies that operate at scale.

Frequently asked questions