/ developer & network toolbox
← all tools

$ spf+

runs locally

SPF Generator

Build an SPF record from provider presets (Google, Microsoft 365, Mailgun, SendGrid…), your own IPs and includes, with a live DNS-lookup count.

spfgen — invoker.tools
typeTXT
host@ (the domain itself)
lookups1 / 10 at the top level
v=spf1 mx ~all

About the SPF Generator

This SPF generator builds a Sender Policy Framework record from what you actually use. Tick the domain's own mail servers (mx and a), pick your mailbox provider and sending services from a list of presets, add any extra IP addresses or ranges and custom include domains, and choose how receivers should treat everyone else. The v=spf1 record appears instantly, ready to publish as a TXT record on the domain itself.

Every preset uses the include domain the provider documents, such as _spf.google.com for Google Workspace, spf.protection.outlook.com for Microsoft 365 and mailgun.org for Mailgun, so you do not have to look them up one by one. While you build, the tool counts the mechanisms that cost a DNS lookup and warns before you pass the limit of 10 that RFC 7208 sets. Going over that limit is one of the most common SPF faults: the record becomes a PermError and SPF fails for every message, including legitimate ones.

An SPF record tells receiving mail servers which hosts may send mail using your domain in the envelope sender. On its own it does not stop spoofing of the visible From address; that is DMARC's job, which uses SPF (and DKIM) as its input. So a correct SPF record is the first step, followed by DKIM for each service and a DMARC policy.

The generator runs entirely in your browser. After publishing, use the SPF checker to see the live record and its lookup count.

How to use it

  1. Keep mx ticked if the servers that receive your mail also send it; tick a if the web server's address sends mail too.
  2. Select your mailbox provider, for example Google Workspace or Microsoft 365.
  3. Select every sending service that sends mail as your domain: newsletter tool, CRM, helpdesk, transactional mail API.
  4. Add fixed IP addresses or CIDR ranges of your own servers, and any include domain that is not in the presets.
  5. Choose ~all (softfail) or -all (fail) for all other senders.
  6. Watch the lookup counter and warnings, then copy the record.
  7. Publish it as a single TXT record on the root of the domain (host @) and replace any existing v=spf1 record rather than adding a second one.

Examples

  • Google Workspace only: v=spf1 include:_spf.google.com ~all
  • Microsoft 365 plus Mailchimp: v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all
  • Own server plus Mailgun: v=spf1 mx include:mailgun.org ~all
  • A fixed IP range and Amazon SES: v=spf1 ip4:203.0.113.0/24 include:amazonses.com -all
  • A domain that never sends mail: v=spf1 -all

The 10-lookup limit, explained

Receivers stop evaluating an SPF record after 10 DNS lookups. The mechanisms include, a, mx, ptr and exists, and the redirect modifier, each cost a lookup, and so do the mechanisms inside every included record. ip4, ip6 and all cost nothing. A provider include can easily use three or four lookups by itself, so a record with six includes may already be over the limit even though it looks short. This generator counts the top level; the SPF checker resolves the whole tree after you publish.

  • Replace a and mx with ip4/ip6 ranges when the addresses are stable.
  • Remove includes for services you no longer use.
  • Let services with a custom return-path or bounce domain be authorised on that subdomain instead of the root.
  • Avoid ptr entirely; it is slow and discouraged by the RFC.

~all or -all?

-all asks receivers to reject mail from unlisted hosts, ~all asks them to accept it but mark it as suspicious. Once a DMARC policy is in place, DMARC makes the final decision, and many deliverability practitioners prefer ~all: some receivers reject on -all before DMARC is evaluated, which can bounce forwarded mail that DKIM would have saved. For a domain that never sends mail, v=spf1 -all is the right record. Never use +all, which authorises the entire internet.

One domain, one SPF record

A domain may publish only one TXT record that starts with v=spf1. Two separate SPF records produce a PermError. When you add a service, edit the existing record and add its include. A record longer than 255 characters is still one record, split into several quoted strings inside the same TXT entry; most DNS panels handle that for you.

Frequently asked questions

How do I create an SPF record?

List every service that sends mail as your domain, add the include each one documents, finish with ~all or -all, and publish the result as one TXT record on the domain. This generator does the assembling and checks the lookup count.

What SPF record do I need for Google Workspace?

v=spf1 include:_spf.google.com ~all, plus includes for any other services that send as your domain.

What SPF record do I need for Microsoft 365?

v=spf1 include:spf.protection.outlook.com ~all (or -all), plus includes for other sending services.

Can I have two SPF records?

No. Multiple v=spf1 records cause a PermError, so SPF fails for all mail. Merge them into a single record.

Why does the generator say lookups are at the top level only?

Each include points to another record that may contain more lookups. The generator cannot know those without querying DNS, so check the published record with the SPF checker for the full count.

Is SPF enough to stop spoofing?

No. SPF checks the envelope sender, not the From address people see. Combine it with DKIM signing and a DMARC policy to actually block spoofed mail.

More email / dns tools