How to set up an SPF record

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. Without SPF, anyone can send email that appears to come from your domain — and most spam filters will penalise or reject your legitimate mail as a result.

This guide walks you through setting up SPF from scratch. If you want a broader comparison of SPF alongside DKIM and DMARC, read SPF vs DKIM vs DMARC first.

What is an SPF record

An SPF record is a DNS TXT record published at your domain root (e.g. example.com). It lists every mail server and sending service that is allowed to send email from your domain. When a receiving mail server accepts a message claiming to be from you@example.com, it looks up your SPF record and checks whether the sending IP is authorised. If it is not, the message fails SPF.

SPF alone does not prevent spoofing of the From: header the recipient sees — that requires DMARC. But SPF is a required building block: you need it before DMARC can do anything useful.

Step-by-step setup

1. Inventory every source that sends email from your domain

   Before you write a single character of the record, list every service that sends email on behalf of your domain:

   • Your primary mail server (Google Workspace, Microsoft 365, Zoho, self-hosted)
   • Transactional email providers (SendGrid, Postmark, Amazon SES, Mailgun)
   • Marketing platforms (Mailchimp, HubSpot, ActiveCampaign)
   • CRMs and billing systems that send receipts or notifications
   • Any custom applications that send password resets or alerts

   If you miss a sender here, its messages will fail SPF. Check with your team — forgotten senders are the most common cause of SPF failures after a policy change.

2. Draft the SPF record syntax

   An SPF record always starts with v=spf1 and ends with an all mechanism. Everything in between authorises specific senders.

   A typical record for a company using Google Workspace and SendGrid:

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

   The key mechanisms:

   Mechanism	What it does
   v=spf1	Required version tag — must come first
   include:domain	Authorise all IPs listed in another domain's SPF record
   a	Authorise the IP addresses in your domain's A/AAAA record
   mx	Authorise the IP addresses of your domain's MX mail exchangers
   ip4:1.2.3.4	Authorise a specific IPv4 address or CIDR range
   ip6:2001:db8::/32	Authorise a specific IPv6 address or CIDR range
   -all	Hard fail — reject any sender not listed above
   ~all	Soft fail — mark unlisted senders as suspicious but do not reject
   ?all	Neutral — no recommendation (rarely useful)
   +all	Authorise everyone — never use this

   For most setups, include: is the right choice. Mail providers publish their own SPF records and keep them up to date; referencing them with include: means you pick up IP changes automatically.

   If your mail server has a fixed IP address that does not appear in any include: record, add it explicitly:

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

3. Add the TXT record at your domain root

   Log in to your DNS provider (Cloudflare, Route 53, Namecheap, your registrar's DNS panel, etc.) and create a new TXT record:

   • Host / Name: @ or leave blank (means the root domain)
   • Type: TXT
   • Value: your SPF record string, e.g. v=spf1 include:_spf.google.com ~all
   • TTL: 3600 (1 hour) is fine; lower values speed up propagation during testing

   Your domain must have exactly one SPF record. If a record starting with v=spf1 already exists, edit it — do not create a second one. Two SPF records cause a permerror and SPF fails for all mail.

4. Wait for DNS propagation

   After saving, DNS changes take time to reach resolvers around the world. TTL determines how long resolvers cache the old value. With a 1-hour TTL, expect propagation within 1–2 hours for most resolvers, though some may take longer.

   You can track propagation in real time using DomainCare's DNS propagation tool, which queries 20 global resolvers simultaneously and shows which ones have picked up the change.

5. Verify with dig or nslookup

   Once propagated, confirm the record is live:

   dig TXT example.com +short

   Or on Windows:

   nslookup -type=TXT example.com

   You should see your SPF record in the output. Example:

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

   If you see no TXT record starting with v=spf1, the record has not propagated yet or was entered incorrectly.

   You can also paste your record into an online SPF validator (many are free) to check the syntax and count DNS lookups before committing.

6. Monitor with DomainCare

   Publishing the record is not the end — it can change. A misconfigured deployment, a DNS provider API key leak, or a team member editing the wrong record can silently break SPF.

   DomainCare's email deliverability check reads your SPF record every 6 hours and fires an alert the moment it goes missing (spf_record_missing), becomes structurally invalid (spf_record_invalid), or changes unexpectedly (spf_record_changed). You find out before recipients start seeing bounce messages or spam folder deliveries.

Common mistakes

Publishing two SPF records. A domain can only have one v=spf1 TXT record. If you have two, receiving servers return a permerror and SPF fails for all mail, even legitimate mail. Merge them into one record.

Using a hostname in ip4: instead of an IP address. The ip4: mechanism takes an IP address or CIDR range, not a hostname. ip4:mail.example.com is invalid. Use a:mail.example.com to authorise the IPs behind a hostname, or resolve the hostname yourself and use its IP.

Forgetting the all mechanism. An SPF record without all at the end is technically valid but leaves receiving servers without guidance on what to do with unlisted senders. Always end with -all or ~all.

Using +all or no qualifier on all. +all (or bare all with an implicit +) tells every server in the world that it is authorised to send your mail. It makes SPF completely pointless. Always use ~all or -all.

Missing a sending service. A CRM that sends invoices, a billing platform that sends payment confirmations, a monitoring tool that sends alerts — any service omitted from the SPF record will fail. Keep your sender inventory up to date.

The 10-DNS-lookup limit

SPF limits the number of DNS lookups triggered during evaluation to 10. Each include:, a, and mx mechanism counts as a lookup. The domains those include records point to may themselves contain further lookups — those count too.

If your total exceeds 10, receivers get a permerror and treat SPF as failed, even for fully legitimate mail.

To check your count:

dig TXT _spf.google.com +short

Repeat for each include: in the chain to count nested lookups.

The fix: SPF flattening. Flattening resolves all include: references and replaces them with the resulting IP addresses directly in your record. This turns multiple DNS lookups into a single record read. The trade-off is that you must re-flatten whenever a provider changes its IP ranges. Several commercial tools automate this — search for "SPF flattening service".

Example before flattening (may trigger 8+ lookups):

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:mail.zendesk.com ~all

Example after flattening (one record, no further lookups):

v=spf1 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:185.220.10.0/23 ip4:198.2.128.0/18 ~all

Recommended starting policy

Start with ~all (soft fail), not -all (hard fail).

Soft fail marks failing messages as suspicious but still delivers them. This gives you a window — typically 2–4 weeks — to:

1. Review which senders are failing and why.
2. Add any missing sources to your record.
3. Confirm that all legitimate mail is passing.

Once DMARC aggregate reports (if you have DMARC set up) show a consistently low failure rate from legitimate sources, switch ~all to -all. Hard fail tells receiving servers to reject unlisted senders outright. That is the end state you want, but do not rush to it before you are confident your record is complete.