SPF Record Generator: Step-by-Step Setup Guide

An SPF record generator builds the one TXT record that tells receiving mail servers which services are allowed to send email for your domain. You list the platforms that send on your behalf — your mailbox provider, marketing tool, help desk — and the generator returns valid SPF (Sender Policy Framework) syntax you paste into DNS. It removes the two things people get wrong by hand: the exact mechanism order and staying under SPF's ten-lookup limit.
Build yours now: use the free interactive SPF record generator — select the services that send for you and copy the finished record.
An SPF record is one TXT record at your domain's root, starting with v=spf1.
What an SPF record actually is
SPF is an email authentication standard that lets a domain owner publish, in DNS, the list of mail servers authorized to send for that domain. Receiving servers read the record and check whether the connecting server's IP is on your approved list. If it is, SPF passes; if it isn't, the result depends on how your record ends.
The record itself is a single TXT record at your domain's root (the apex, e.g. yourdomain.com), and it always begins with v=spf1. The older dedicated SPF record type (DNS type 99) was retired in RFC 7208 — publish SPF as a TXT record only, and publish exactly one SPF record per domain. Two v=spf1 records on the same domain is the single most common fatal mistake: receivers treat it as a permerror and SPF fails outright.
Anatomy of the record a generator builds
Every SPF record is a version tag, one or more mechanisms, and an "everything else" rule at the end:
v=spf1— the version, always first.include:— authorizes another domain's SPF record. This is how you add senders likeinclude:_spf.google.com(Google Workspace) orinclude:sendgrid.net— you delegate to their published record instead of listing IPs.aandmx— authorize the IPs in your domain's A record or the servers in your MX records. Useful if your own server sends mail.ip4:/ip6:— authorize specific addresses or ranges directly.all— the catch-all at the end, prefixed by a qualifier that sets the verdict for every server not matched above.
v=spf1 include:_spf.google.com include:sendgrid.net ~all
A good generator assembles this for you, deduplicates overlapping includes, and warns you before you cross the lookup limit.
Why the ten-lookup limit matters
SPF caps the number of DNS lookups a record may trigger during evaluation at ten. Each include, a, mx, ptr, and exists mechanism counts, and some include: values expand into several more lookups behind the scenes. Go over ten and receivers return a permerror — which, under a strict DMARC policy, means legitimate mail can be rejected.
This is exactly where hand-editing breaks down: you add one more marketing platform, quietly cross the limit, and mail starts failing weeks later with no obvious cause. A generator counts lookups as you build and flags the overflow, so you can flatten or consolidate includes before you publish. If you routinely bump against ten, the SPF checker shows your current lookup count against the ceiling.
The -all vs ~all choice
The qualifier on all decides what happens to mail from servers you didn't authorize:
~all(softfail) — unlisted senders are marked suspicious but usually still delivered, often to spam. This is the safe setting while you're confirming you've captured every sending service.-all(hardfail) — unlisted senders are rejected. This is the stronger policy and the one to move to once you're confident your record is complete.
~all first, watch your DMARC reports for a week or two to confirm no legitimate source is failing, then tighten to -all. Note that SPF alone never stops an attacker from spoofing your visible From: address — it only checks the hidden envelope sender. Closing the display-name gap requires DMARC alignment, which is why SPF, DKIM, and DMARC are deployed together.
Publishing and verifying the record
- Generate the record with the SPF generator and copy it exactly.
- In your DNS provider, add a TXT record. Set the host/name to
@(or your root domain) and paste the record as the value. - Save, and allow time for propagation — usually minutes, up to 48 hours depending on your record's TTL.
- Confirm it resolves and passes with the SPF checker, or check SPF, DKIM, and DMARC together with the Email Security Score.
Frequently asked questions
Can I have more than one SPF record?
No. A domain must publish exactly one v=spf1 TXT record. If you send through several providers, merge their include: mechanisms into that single record rather than adding a second one — multiple SPF records cause a permerror and break authentication for every message.
Does an SPF record on my root domain cover my subdomains?
Not automatically. SPF is evaluated per the exact domain in the envelope sender, so a subdomain like mail.yourdomain.com needs its own record. Subdomains that never send mail should publish v=spf1 -all to stop attackers from using them.
Why does my SPF pass but DMARC still fail?
Because DMARC also requires alignment — the domain SPF authenticated must match the domain in the visible From: address. Mail relayed through a provider that uses its own envelope domain can pass SPF while failing DMARC alignment. In those cases DKIM, which survives forwarding, is the more reliable path to a DMARC pass.
Do I need to update SPF when I add a new sending tool?
Yes. Any new service that sends mail as your domain — a new CRM, invoicing tool, or newsletter platform — must be added to the record, or its messages will fail SPF. Regenerate the record whenever your sending stack changes, and re-check the lookup count each time.
What TTL should I set on the record?
A few hours (for example 3600 seconds) is a sensible default. A shorter TTL lets changes propagate faster while you're still adjusting the record; you can raise it once the record is stable.
Related reading
Keep going with AI
Ask AI how this applies to you
Take this guide to your assistant — each question opens pre-filled, with a link back to this page so it can read the details.

Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, the DMARC automation platform for MSPs. He writes Palisade's guides on DMARC, SPF, DKIM and email deliverability.
More from Samuel →


