Create SPF Record: What to Publish for Your Domain

To create an SPF record for your domain, publish a single DNS TXT record at the domain root that starts with v=spf1, lists every service allowed to send your mail, and ends with -all or ~all. A domain must have only one SPF record, and it must stay within 10 DNS lookups.

The rest of this guide explains what goes into that record, how to assemble it from your own list of senders, and how to publish and check it. If you would rather skip the manual work, the SPF generator builds the string for you.

What does an SPF record look like?

An SPF record is a DNS TXT record that begins with v=spf1, followed by mechanisms that name the servers allowed to send for your domain, and ends with an all mechanism that says what to do with everything else. Receivers evaluate the mechanisms from left to right.

A simple example for a domain that sends through Google Workspace and one fixed server:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.25 -all"

The parts are:

• v=spf1 identifies the record as SPF version 1.
• include: authorises another domain's SPF policy, which is how most email providers are added.
• ip4: and ip6: authorise specific addresses or ranges.
• a and mx authorise the addresses in your domain's A or MX records. Each one costs a DNS lookup.
• -all tells receivers that any other sender should fail.

The full specification is in RFC 7208.

How do I create an SPF record from scratch?

List every system that sends email as your domain, find the SPF include or IP range each one publishes, combine them into one v=spf1 string ending in an all mechanism, and publish it as a single TXT record at the domain root. Then verify it.

Work through it in this order:

1. Inventory your senders. Include your mailbox provider, marketing platform, CRM, helpdesk, billing system, and any servers or applications that send mail directly. Check with each team, because forgotten senders are the usual cause of failures.
2. Collect each sender's SPF value. Providers document an include: domain or IP ranges in their setup guides. Use exactly what they give you.
3. Choose the right mechanisms. Prefer include: for third-party services and ip4:/ip6: for infrastructure you control.
4. Finish with an all mechanism. More on this below.
5. Publish and test. Add the TXT record, wait for DNS to propagate, and check the result.

A completed record for a domain with three senders could look like this:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:mail.example-esp.net ip4:203.0.113.0/24 ~all"

The include:mail.example-esp.net value is a placeholder. Always copy the real value from your provider's documentation.

Should I end with -all or ~all?

Use -all (fail) when you are confident your record lists every legitimate sender, and ~all (softfail) while you are still discovering senders or have just started. Both tell receivers the sender is not authorised, but -all is the stricter instruction.

A common approach is to publish ~all first, review your mail sources, then tighten to -all once nothing legitimate is failing. Avoid +all, which authorises the entire internet and defeats the purpose of SPF. ?all (neutral) states no opinion and offers little protection.

Keep in mind that receivers can treat SPF results differently, and DMARC is what ties SPF to your visible From domain and tells receivers what policy to apply.

What mistakes break an SPF record?

Most broken SPF records come from a short list of avoidable errors. Each of these can cause an SPF permerror, unintended failures, or a record that receivers do not treat as SPF at all, so check for them before and after publishing.

• Publishing more than one SPF record. Two TXT records starting with v=spf1 on the same name cause a permanent error. Merge them into one.
• Exceeding 10 DNS lookups. The mechanisms include, a, mx, ptr, exists and the redirect modifier each count toward the limit of 10, including lookups triggered by nested includes. ip4, ip6 and all do not count. Going over the limit produces a permanent error. To get back under it, remove includes for retired services, and replace an a or mx mechanism with ip4: or ip6: ranges where the addresses rarely change.
• Too many void lookups. RFC 7208 recommends a limit of two lookups that return no data, and a receiver that enforces it returns a permerror. Remove includes for services you no longer use.
• Syntax slips. A missing colon or a space inside a term, such as include: example.com, breaks the syntax and returns a permerror. Extra spaces between terms are legal. A record that starts v=spf instead of v=spf1 is not selected as SPF at all, so the result is none rather than an error.
• Overly long strings. A single DNS TXT string is limited to 255 characters. Longer records must be split into multiple quoted strings within the same record, so check how your DNS provider handles this.
• Forgetting subdomains. SPF is checked against the domain in the envelope sender, so each sending subdomain needs its own record if it sends mail.
• Using ptr. RFC 7208 discourages it, so use ip4, ip6 or include instead.
• Leaving non-sending domains unprotected. A domain that never sends mail should publish v=spf1 -all, which says no server is authorised.

How do I publish and check my SPF record?

Add a TXT record in your DNS provider's control panel with the host set to @ (the domain root) and the value set to your complete SPF string. Then query the domain to confirm that exactly one SPF record is returned and that it parses correctly.

Steps in most DNS panels:

1. Open DNS management for your domain.
2. Edit your existing SPF TXT record if there is one, rather than adding a second.
3. Paste the full v=spf1 ... all value.
4. Save, and allow time for the change to propagate.

You can confirm it from a terminal:

dig +short TXT example.com

Or use the domain scanner to check SPF alongside DMARC, DKIM and related records in one pass.

Send a test message to a mailbox you control and inspect the headers. The Authentication-Results header should show spf=pass for your sending domain.

Is SPF enough on its own?

No. SPF only validates the envelope sender (the Return-Path domain) and the server's IP address, not the From address people see. It also breaks when mail is forwarded. Pair it with DKIM and a DMARC policy so receivers know how to treat mail that fails.

DMARC passes when SPF or DKIM passes and the passing domain aligns with the From domain. That alignment requirement is why a valid SPF record alone may not protect your visible From address. Once SPF is in place, publish a DMARC record, check it with the DMARC lookup tool, and use DMARC monitoring to see which sources pass and fail from the aggregate reports. Large senders should also review the email sender compliance requirements, since mailbox providers expect authenticated mail.

If you manage many domains or want help moving to an enforcement policy, the managed service covers the rollout to p=reject, and pricing lists the available plans. MSPs and resellers can look at the partner programme.

Key takeaways

• To create an SPF record, publish one TXT record at the domain root beginning with v=spf1.
• List every legitimate sender using include:, ip4: and ip6: mechanisms.
• End with ~all while discovering senders, then move to -all when the list is complete.
• Never publish more than one SPF record per domain.
• Stay within the 10 DNS lookup limit and the recommended limit of two void lookups.
• Verify the record with a DNS query or the domain scanner, and test with a real message.
• Add DKIM and DMARC, because SPF alone does not protect the visible From address.
• Use the SPF generator if you want the record built for you.