SPF Record Setup Guide: How to Configure SPF for Email (2026)

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorized to send email from your domain. When a receiving server gets an email from your domain, it looks up the record and checks whether the connecting server's IP is on the list.

If the sending server is not listed, the email fails SPF. On its own an SPF failure is a soft signal, but combined with a DMARC policy it decides whether the message is delivered, quarantined to spam, or rejected. SPF is one of the three authentication records every sending domain needs; SPF, DKIM and DMARC explained covers how the three work together.

A complete SPF record for a domain that sends only through Google Workspace looks like this:

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

That one line says: version 1, trust whatever Google publishes as its sending servers, and treat everything else as a soft fail.

Every SPF record is a single TXT record made of mechanisms evaluated left to right. The first mechanism that matches the sending IP decides the result.

Ready-to-use SPF records:

Critical rule: only one SPF record per domain. If two TXT records start with v=spf1, receivers return a permanent error and every message fails. Combine all senders into a single record.

Step 1: List every service that sends as your domain. Your mailbox provider (Google Workspace or Microsoft 365), any transactional ESP (SendGrid, Amazon SES, Postmark), any marketing platform (Mailchimp, HubSpot, Brevo), your helpdesk (Zendesk), your CRM, and any billing or ERP system that emails invoices. Most SPF failures come from a sender nobody remembered.

Step 2: Collect each service's include value. The table in the next section covers the common ones. Sequencers that send through your own Google or Microsoft mailbox do not need an include of their own; see the note under that table.

Step 3: Build the record. Start with v=spf1, add one include: per service (or ip4: for servers you control), and end with ~all. Count the lookups: the total must stay under 10.

Step 4: Add the TXT record at your DNS host. Host or name is @ (the bare domain), type is TXT, value is the full record. The next section shows where the fields are at Cloudflare, GoDaddy and Namecheap. If an SPF record already exists, edit it; do not add a second one.

Step 5: Wait for the TTL to expire. Most hosts default to 1 hour or less. Cloudflare changes are usually visible within minutes.

Step 6: Verify. Run the domain through the SPF checker to confirm the record parses, the lookup count is under 10, and there is only one record. Then send a test to a Gmail address, open it, choose "Show original", and confirm SPF: PASS.

Step 7: Add DKIM and DMARC. SPF alone does not stop spoofing, because it checks the envelope sender, not the From address a recipient sees. Follow the DKIM setup guide and the DMARC setup guide to finish authentication.

The record is identical everywhere; only the form differs.

Two details that catch people: paste the record without surrounding quotes unless the host's form shows quotes for existing TXT records, and if you send from a subdomain (for example mail.example.com), that subdomain needs its own SPF record with its own name in the Host field.

InboxKit publishes SPF, DKIM, DMARC and MX through Cloudflare automatically for every domain it manages, so on an InboxKit domain there is nothing to type. The DNS checker shows every record it created.

Include values below are the ones each provider documents at the time of writing. Providers occasionally change them, so confirm against the provider's own setup page before you publish, and re-check the lookup count afterwards.

Sequencers do not need an include. Instantly, Smartlead, lemlist, SendKit and similar tools send through your own Google Workspace or Microsoft 365 mailbox over API or SMTP. The message leaves Google's or Microsoft's servers, which your record already covers. Adding an extra include for the sequencer wastes a lookup and, if the value is wrong, breaks the record. Only add an include for a service that sends from its own infrastructure.

Example combined records:

• Google Workspace + Amazon SES: v=spf1 include:_spf.google.com include:amazonses.com ~all (about 5 lookups)
• Google Workspace + Microsoft 365 + Zendesk: v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com ~all (about 7 lookups)

InboxKit configures the correct SPF record automatically for Google Workspace ($2.50/mo) and Microsoft 365 ($2.50/mo) mailboxes.

RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include:, a, mx, redirect= and exists: mechanism counts, and so does every nested include inside those. ip4: and ip6: cost nothing. Go over 10 and receivers return PERMERROR, which most gateways treat as a failure for every message, including the ones from senders that were correctly listed.

Google alone uses about 4 lookups. Add Microsoft 365 and two SaaS tools and you are at 9 or 10 before anyone notices.

How to get back under the limit:

1. 1Remove senders you no longer use. Old ESPs and abandoned tools are the usual culprits. Check DMARC aggregate reports to see which sources actually send.
2. 2Replace includes with ip4: where the IPs are fixed. Your own mail server or a dedicated-IP ESP can be listed by address at zero lookup cost.
3. 3Move marketing and transactional mail to a subdomain. Send newsletters from news.example.com with its own SPF record. Each subdomain gets its own 10-lookup budget, and a reputation hit on marketing mail stays off your primary domain.
4. 4Flatten as a last resort. Flattening replaces includes with the IPs they resolve to. It works, but providers change IPs without notice, so flattened records need re-checking on a schedule. Use it only with a service that re-flattens automatically.

The SPF checker counts lookups for you and shows which include is responsible for each one.

These are the 6 SPF errors that cause the most deliverability damage in email setups:

Quick diagnostic: send a test email to Gmail, open it, click the three dots, choose "Show original". If SPF shows FAIL or SOFTFAIL, the sending server is missing from the record. If it shows PERMERROR, you have exceeded the 10-lookup limit or published two records. If it shows NONE, the record is not published on the domain the receiver checked, which usually means a subdomain mismatch.

The last mechanism tells receivers what to do with a server you did not list.

• ~all (soft fail) marks unlisted senders as suspicious without demanding rejection. It is the right choice while you are still discovering senders, and it is what Google and Microsoft recommend as a starting point. With DMARC in place, a soft fail still counts as an SPF failure for policy purposes, so you lose nothing in protection.
• -all (hard fail) tells receivers to reject unlisted senders outright. Move to it once DMARC aggregate reports have run for a few weeks and show every legitimate source passing. Switch too early and a forgotten billing system starts bouncing invoices.

For cold email domains that send only through Google Workspace or Microsoft 365, ~all is the safe default and there is little to gain from -all. DMARC alignment, not the SPF qualifier, is what stops spoofing.

InboxKit configures SPF records automatically when you create a mailbox. Here is what happens behind the scenes:

This removes the most common source of deliverability problems: DNS that was right on day one and wrong by month three. For teams managing 50+ domains, InboxKit saves roughly 8 to 10 hours of manual SPF work per batch and prevents the copy-paste errors that break authentication.

Check the record itself:

1. 1Run the domain through the SPF checker. It confirms the record parses, counts the DNS lookups, flags duplicate records and lists every authorized source.
2. 2Run the DNS checker to see SPF alongside DKIM, DMARC and MX, so a missing companion record is caught at the same time.

Check a real message:

1. 3Send a test email to a Gmail address, open it, click the three dots and choose "Show original". The summary box shows SPF: PASS with the IP that passed.
2. 4For any other provider, paste the raw headers into the email header analyzer and read the Authentication-Results line.

Keep checking:

1. 5Re-verify after every DNS change, every new sending tool, and every domain transfer. Registrar migrations silently drop TXT records more often than you would expect.

InboxKit users: InfraGuard runs steps 1 and 2 on every managed domain every six hours and alerts you when anything changes.