# SPF Record Generator: Step-by-Step Setup Guide > Generate a correct SPF record for your domain: syntax, include mechanisms, and the -all vs ~all choice — plus a free SPF generator tool. 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)](/learning/what-is-spf) 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](/tools/spf-generator) — select the services that send for you and copy the finished record. ![Example SPF record published as a single TXT record.](/images/figures/spf-record-card.webp) *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](/learning/what-is-a-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](https://datatracker.ietf.org/doc/html/rfc7208) — 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 like `include:_spf.google.com` (Google Workspace) or `include:sendgrid.net` — you delegate to their published record instead of listing IPs. - **`a` and `mx`** — authorize the IPs in your domain's A record or the servers in your [MX records](/learning/what-is-an-mx-record). 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. A finished record for a domain sending through Google Workspace and SendGrid looks like: `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](/learning/what-is-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](/tools/spf) 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. Publish `~all` first, watch your [DMARC reports](/resources-post/how-to-understand-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](/learning/what-is-dkim), and DMARC are deployed [together](/resources-post/what-are-dmarc-dkim-and-spf). ## Publishing and verifying the record 1. Generate the record with the [SPF generator](/tools/spf-generator) and copy it exactly. 2. In your DNS provider, add a **TXT** record. Set the host/name to `@` (or your root domain) and paste the record as the value. 3. Save, and allow time for propagation — usually minutes, up to 48 hours depending on your record's TTL. 4. Confirm it resolves and passes with the [SPF checker](/tools/spf), or check SPF, DKIM, and DMARC together with the [Email Security Score](/tools/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 - [How to Create an SPF Record (Step-by-Step + Examples)](/resources-post/how-to-create-an-spf-record-a-step-by-step-guide-for-better-email-authentication) - [What are DMARC, DKIM, and SPF?](/resources-post/what-are-dmarc-dkim-and-spf) - [What is a TXT record?](/learning/what-is-a-txt-record)