SPF Record Setup: Step-by-Step Guide

What Is an SPF Record?

SPF stands for Sender Policy Framework. It is a single DNS TXT record published at the apex of your domain that lists every mail server and IP range your team uses to send email. When a receiving mail server gets a message claiming to be from you@yourdomain.com, it resolves your SPF record and checks whether the sending IP is in the approved list. If it is, the message passes SPF; if it is not, SPF fails and the message is handled according to your DMARC policy.

A minimal SPF record looks like:

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

This example authorises Google Workspace to send on behalf of your domain and uses ~all (softfail) as the default. Every real production record is just a longer version of the same shape — multiple include: statements terminated by an all qualifier.

Need a refresher on how SPF fits alongside DKIM and DMARC? Read the SPF, DKIM, and DMARC Explained → guide for the full protocol stack.

Anatomy of an SPF Record

Every SPF record follows the same structure: the version literal v=spf1, followed by one or more space-separated mechanisms, terminated by a default all qualifier. Each mechanism is evaluated left-to-right; the first match wins.

include:domain

Pull in another organisation’s SPF record (their mail provider publishes it). Counts as one DNS lookup and follows nested includes recursively. This is how you authorise Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, and every other ESP without manually whitelisting IPs.

a

Authorise the IP behind your domain’s A record (or AAAA if written as aaaa). Useful when you run a small mail server on the same host as your website. Counts as one DNS lookup.

mx

Authorise the IPs behind all of your domain’s MX records. Mostly used in symmetric setups where the same servers send and receive. Counts as one DNS lookup.

ip4:192.0.2.0/24 / ip6:2001:db8::/32

Whitelist a specific IPv4 or IPv6 range directly. Does not perform a DNS lookup, so it does not count against the 10-lookup SPF limit. The cheapest mechanism once you know the IPs.

exists:domain

Authorise any IP if the listed domain resolves to any A record. Typically used by larger ESPs to express dynamic IP pools. Counts as one lookup.

redirect=domain

Forward SPF evaluation entirely to another domain’s record. Must be the only mechanism (or the last one) and counts as one lookup. Use when a third party completely manages your sending infrastructure.

all

The trailing default — what receivers should do for senders that did not match. The four qualifiers: +all (pass everything — never use), -all (hardfail, reject), ~all (softfail, suspicious), ?all (neutral).

Step 1: List Every Sending Source

Before you write the record, inventory every system that sends email using your domain. The most common omissions are what cause real senders to fail SPF once a strict (-all) policy is published. Make a list, then check it twice:

• Mailbox provider — Google Workspace (include:_spf.google.com), Microsoft 365 (include:spf.protection.outlook.com), or Fastmail.
• Marketing / ESP — Mailchimp, SendGrid, Postmark, Mailgun, Brevo, Klaviyo, HubSpot, or your own SMTP relay.
• Transactional — separate ESP for order confirmations, password resets, or receipts.
• CRM — Salesforce, HubSpot CRM, or any sales platform that sends on behalf of reps.
• In-house applications — your payroll system, monitoring alerts, CI/CD notifications, internal APIs.
• Helpdesk / ticketing — Zendesk, Intercom, Freshdesk, or any agent-reply mailer.

Each provider publishes an include: value in their SPF setup docs — copy those literally. Do not paraphrase or invent, and do not include subdomain providers you no longer use.

Step 2: Build the SPF Record

Combine the include values from step 1 into a single TXT record. Start with v=spf1, append every include: statement with a single space between each, and end with an all qualifier. Example:

v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com -all

This single record authorises Google Workspace, SendGrid, and Zendesk to send on behalf of your domain and tells receivers to reject any other sender outright.

Three rules to keep in mind:

• Only one SPF record should exist at the apex — multiple TXT records cause a PermError and SPF fails for every message.
• The record must stay under 10 DNS lookups during evaluation — the receivers cap it. Each include:, a, mx, exists: , and redirect= mechanism counts as one; nested includes count recursively.
• Choose ~all while you are still auditing senders; switch to -all once you have confirmed every legitimate source is in the record. Never ship +all or no qualifier at all.

Step 3: Publish the TXT Record

SPF records live in DNS as a TXT record — not as an SPF record type (the SPF RR type is deprecated) — at the apex of your domain. The host is literally @ (or blank) and the value is the v=spf1 string you built in step 2.

• Cloudflare → DNS → Records → Add → Type TXT, Name @, Content the v=spf1 string.
• Route 53 → Hosted zones → Create record → Simple routing → Record type TXT, Name the apex, Value the v=spf1 string.
• Google Cloud DNS → Record sets → Add record set → TXT, Name the apex (use @ for the root), TXT data the v=spf1 string.
• GoDaddy / Namecheap → DNS Management → Add → Type TXT, Host @, Value the v=spf1 string.

DNS changes typically propagate in 5–30 minutes, but allow up to 24 hours for full propagation across global resolvers. Subdomain mailers (a separate ESP sending from mail.yourdomain.com) need their own SPF record published at the subdomain, not the apex — see the SPF, DKIM, and DMARC Explained → guide for the full layout.

Want to inspect what your DNS publishes right now? Run a sanity check with dig TXT yourdomain.com +short or follow the manual DNS walkthrough in the SPF record check guide.

Step 4: Confirm the published DNS answer

After publishing, query the exact domain where you created the record and confirm the public answer contains the value you intended:

dig +short TXT yourdomain.com

Check that the DNS result has one SPF policy beginning with v=spf1. This confirms what DNS publishes; it does not by itself prove that every active sending service is authorized or that DMARC alignment passes. For a manual walkthrough of the DNS response and received-message headers, see How to Check Your Published SPF TXT Record.

When a test message reports an SPF problem

This page covers setup and publication. For troubleshooting duplicate policies, missing or incorrect mechanisms, nested includes, lookup-limit PermErrors, or DMARC alignment, use the dedicated SPF troubleshooting guide. It starts from the receiver's result and gives a separate next check for each symptom.

Keep the Setup Maintainable

• Keep an inventory of every service that sends using this domain, including transactional systems and internal applications.
• Use the current SPF instructions from each active provider. Do not guess an include hostname or copy a provider’s IP ranges without a reliable update owner.
• Publish one SPF policy at each domain used for sending. A separate subdomain only has its own scope when the sending platform uses that domain as its SPF identity.
• SPF is one part of email authentication. DMARC can pass through aligned SPF or aligned DKIM; read the SPF, DKIM, and DMARC guide for the relationship between the protocols.