How to Create an SPF Record (Step-by-Step + Examples)

Steps to create an SPF record

Step 1: Identify every sending source

List every system that sends email using your domain. The mailbox provider is only one source. Teams often overlook:

• The mailbox platform itself (Google Workspace, Microsoft 365)
• Marketing and newsletter platforms
• Transactional mail from your application
• Helpdesk, CRM, invoicing, and applicant-tracking systems
• Scanners, copiers, and monitoring systems that email alerts

Step 2: Choose your mechanisms

An SPF record is a TXT record that begins with the SPF version tag, v=spf1, and ends with an all mechanism. In between, you authorise sources with:

• include:: authorise another domain's SPF record (how nearly every provider is added)
• ip4: / ip6:: authorise a literal IP address or CIDR range
• a: authorise the domain's own A/AAAA records
• mx: authorise the hosts in the domain's MX records

Step 3: Choose how strictly to fail

The final all mechanism sets the SPF result for servers not on your list:

• -all returns fail, an explicit statement that the sender is not authorized.
• ~all returns softfail, a weaker statement that the sender is probably not authorized.
• ?all returns neutral, which makes no authorization assertion.

There is no universal qualifier for every deployment. Google's Workspace SPF setup publishes an example ending in ~all, while Microsoft's commercial-cloud SPF guidance uses -all in its straightforward Microsoft 365 example. Choose the final result only after you have identified every legitimate sender for the SPF identity.

Step 4: Write and publish the record

Publish it as a TXT record at the exact envelope-sender or HELO domain that needs the policy. A root-domain example belongs at the root only when that is the SPF identity your mail uses.

Google Workspace only:

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

v=spf1 declares SPF version 1. include:_spf.google.com asks SPF to evaluate Google's published policy for the connecting IP. ~all returns softfail for a sender that reaches the final term without matching.

Microsoft 365 only:

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

The Microsoft include authorizes sending infrastructure covered by Microsoft's published policy. The final -all returns fail for a sender that reaches it without matching. This example is for the commercial cloud. Follow Microsoft's environment-specific guidance for another cloud or a more complex mail flow.

Google Workspace plus Mailgun using the same SPF identity:

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

This combined record keeps one version token, adds the Mailgun mechanism documented for a root-domain merge, and keeps one final qualifier. Use it only when both services send with the exact domain whose TXT record you are editing. If Mailgun uses a dedicated return-path subdomain, that subdomain has its own SPF policy instead.

Domain that sends no mail:

v=spf1 -all

This record has no authorizing mechanism. Because all always matches and the - qualifier returns fail, every SMTP client is unauthorized for that SPF identity. Protecting the visible From domain also requires a reviewed DMARC policy; SPF does not authenticate that visible address by itself.

Then confirm it resolves and parses with the SPF checker, or check every authentication record at once with the Email Security Score tool.

The limits that break SPF records

These processing limits come from RFC 7208. Exceeding a mandatory limit makes SPF return permerror; the receiver decides how to handle that result.

Ten DNS lookups. SPF evaluation must not perform more than 10 DNS-querying terms. The terms that count are include, a, mx, ptr, exists, and the redirect modifier. The terms that do not count are all, ip4, ip6, and exp. The count is recursive: an include: whose own record contains three include: statements spends four of the ten.

Two void lookups. A void lookup is a DNS query that returns either no records or NXDOMAIN. RFC 7208 recommends limiting these to two and returning permerror when the limit is exceeded. A retired or misspelled include target can contribute to this condition.

One SPF record per domain. Publishing two v=spf1 TXT records on the same name produces permerror. The receiver does not choose or merge them. When you add a vendor, merge its documented mechanism into the existing record instead of publishing a second policy.

255 octets per string. A single DNS TXT character-string cannot exceed 255 octets. One TXT record can contain multiple quoted strings, which SPF joins without inserting spaces.

Common issues with SPF records

Why does my SPF record return "permerror" or "too many DNS lookups"?

You have exceeded ten DNS-querying terms. Count recursively, each include: costs one lookup plus whatever its own record spends. Fix it by dropping vendors you no longer use, replacing an include: with the specific ip4: ranges the vendor publishes (those cost zero lookups), or moving a vendor onto a subdomain that sends with its own envelope domain.

Why does my mail fail SPF even though the sender is in the record?

First confirm which domain SPF checked. SPF validates the envelope sender, not the visible From:. A bulk platform or ticketing system can use its own bounce domain in MAIL FROM, so an SPF pass for that domain does not establish alignment with yours. A DMARC report can show the authenticated domains observed for a source.

Why did mail break after I added a second SPF record?

Two v=spf1 records on one name is a permerror, and a permerror counts as an authentication failure. This usually happens when a vendor's setup wizard publishes its own record instead of editing yours. Delete one and merge the include: into the survivor.

Why does forwarded mail fail SPF?

Forwarding changes the SMTP client seen by the final receiver while the envelope identity can remain the same. If the forwarder's IP is not authorized for that identity, SPF can fail. DMARC can still pass through an aligned DKIM signature when the forwarding path leaves the signed content intact.

Best practices

• Keep the record current. Remove vendors as you stop using them. Stale include: statements burn lookups and cause void-lookup errors.
• Never publish more than one SPF record. Merge, don't append.
• Pair SPF with DKIM and DMARC. SPF does not authenticate the visible From address by itself. SPF, DKIM, and DMARC connect sender authentication to the domain a recipient sees.
• Review report evidence. DMARC aggregate reports can show observed sources and their authentication results.

Related reading

• What are DMARC, DKIM, and SPF?
• How to understand DMARC reports
• Email deliverability is not set and forget