This SPF record generator assembles a valid Sender Policy Framework record from the senders you select, then hands you a single line to publish in DNS. Knowing what that line contains makes it far easier to maintain - so here is what the generator is building and why each part matters.
The Anatomy of an SPF Record
Every SPF record is a single DNS TXT record made of three parts: a version tag, one or more mechanisms, and a closing qualifier. A complete record looks like this:
v=spf1 include:_spf.google.com ip4:203.0.113.10 -all
The v=spf1 tag identifies the entry as SPF and must come first - a record that starts with anything else is ignored. Each mechanism in the middle authorizes a group of senders, and the trailing -all tells receivers how to treat every sender that wasn't matched. The generator always emits these in the correct order, because a record without a leading v=spf1 or a closing all qualifier is treated as invalid.
The Mechanisms You Can Add
Each row you add to the generator becomes one of these mechanisms:
include:- authorizes another domain's senders (how you add Google Workspace, Microsoft 365, SendGrid, and most SaaS providers). Each include costs at least one DNS lookup, and often more, because it can pull in further includes.ip4:andip6:- authorize a specific IP address or CIDR range directly. These cost zero DNS lookups, which makes them the cheapest way to add a known mail server.aandmx- authorize the hosts in your domain's A or MX records. Each costs one lookup.all- the catch-all that must come last, paired with a qualifier that sets your policy.
Choosing Your Policy: -all, ~all, or ?all
The qualifier in front of all decides what receivers do with mail that isn't authorized by any other mechanism:
-all(hardfail) - reject unauthorized mail outright. This is the goal once every legitimate sender is in the record.~all(softfail) - accept but mark unauthorized mail as suspicious. Use this while you roll out SPF and confirm nothing legitimate is being missed.?all(neutral) - make no assertion at all. Offers no protection and is rarely the right choice.
A safe rollout is to generate with ~all, watch your reports for a week or two, then regenerate with -all once you're confident. Avoid +all entirely - it authorizes the entire internet to send as your domain.
Common Mistakes the Generator Prevents
- More than one SPF record. A domain may publish only one
v=spf1TXT record; a second one makes both invalid. Combine every sender into the single record the generator produces. - Exceeding the 10-lookup limit. Adding too many
include:mechanisms pushes you past the cap and triggers PermError. The live counter flags this before you publish. - Using
ptr. Theptrmechanism is deprecated and slow; the generator relies oninclude,ip4, andip6instead. - Missing the
allqualifier or splitting a string past the 255-character TXT limit - both quietly break the record.
Staying Under the 10 DNS Lookup Limit
The SPF specification caps DNS lookups at ten per evaluation (RFC 7208, section 4.6.4). Every include, a, mx, and exists mechanism counts, and nested includes count recursively - so a handful of SaaS providers can quietly blow past ten. When your generated record is over the limit (or close to it), AutoSPF flattens the includes into a compact record and re-scans every 15 minutes, keeping you under the cap without losing any authorized sender. See too many DNS lookups for the full explanation.
SPF, DKIM, and DMARC Work Together
A generated SPF record is one of three email authentication standards. SPF verifies the sending server, DKIM signs the message so receivers can prove it wasn't altered, and DMARC ties them together and tells receivers what to do on failure. Gmail, Yahoo, and Microsoft now require all three from bulk senders, so pair this generator with the free DMARC checker and DKIM lookup for full coverage.
Publish, Then Verify
Once you generate the record, publish it as a TXT record at your domain apex (host @), wait for DNS to propagate - usually 5 to 60 minutes - then confirm it with the free SPF checker to make sure it resolves and stays under ten lookups. Remember that subdomains don't inherit the parent's SPF record: any subdomain that sends mail needs its own record, which you can build the same way.