How to Create an SPF Record

An SPF record tells receiving mail servers which systems are allowed to send email using your domain. You publish it as one TXT record that starts with v=spf1, lists your senders, and ends with a policy for everything else. The SPF record generator builds the line for you, but it helps to understand each part before you publish.

What goes in the record

An SPF record is a list of mechanisms, read left to right. Each one either authorizes a source or sets the final policy.

• ip4 / ip6 authorize a specific address or range, for a server whose IP will not change.
• include pulls in another domain’s SPF record, which is how you authorize a hosted service such as include:_spf.google.com for Google Workspace. The provider keeps their list current, so you do not have to.
• a and mx authorize the hosts named in your domain’s A or MX records, useful when your web or mail server also sends.
• all is the catch-all at the end, with a qualifier that decides what happens to everything you did not list.

A real record might read:

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

That allows Google’s servers and one fixed IP, and soft-fails the rest.

Choosing the all policy

The qualifier in front of all is the most consequential choice. It applies to any source that none of your mechanisms matched.

• -all is a hard fail: ask receivers to reject unlisted mail.
• ~all is a soft fail: accept but mark it, the common starting point.
• ?all is neutral: no opinion, useful only while testing.
• +all passes everything, which defeats the point and should never be used.

Begin with ~all so a missed sender does not bounce. Once your reports confirm every legitimate source is covered, tighten to -all.

The two limits that break records

SPF has two rules that quietly cause most failures.

First, one record per domain. If you add a second v=spf1 TXT record, perhaps when onboarding a new mail service, SPF returns a permanent error and stops working. Always merge new mechanisms into the existing line.

Second, the ten-lookup limit. Evaluating the record may trigger at most ten DNS lookups. Every include, a, mx and redirect counts, and includes can nest, so a few providers can blow past ten without you noticing. When that happens receivers return permerror. If you are near the limit, drop services you no longer use, or replace an include with the provider’s published ip4 ranges.

Publishing it

Add the generated value as a TXT record on the root of your domain, not a subdomain, with the host left as the apex (often shown as @). DNS changes can take up to a day to propagate. After it goes live, send yourself a test message and check the headers for an spf=pass result.

SPF is one of three

SPF on its own proves a server is allowed to send, but it does not survive forwarding and says nothing about the visible From address. That is why it works best alongside the other two email-authentication records. DKIM adds a cryptographic signature that proves the message was not altered, covered in how to set up DKIM. DMARC ties SPF and DKIM to the From domain and tells receivers what to do on failure, explained in how to set up DMARC. Publish all three for mail that lands reliably and resists spoofing.

When you are ready, open the SPF record generator, add your senders, pick a policy, and copy the record to publish.