SPF Record Builder: Create and Validate Sender Policy Framework DNS Records

Sender Policy Framework (SPF) is one of the three pillars of email authentication, alongside DKIM and DMARC. It works by publishing a DNS TXT record that lists every server authorized to send email for your domain. Receiving mail servers check that record on every incoming message, and when your SPF record is missing, malformed, or over the DNS lookup limit, legitimate mail can fail authentication while spoofed mail slips through.

The catch is that SPF syntax is deceptively strict. A single misplaced qualifier, an invalid CIDR range, or one include too many can silently break your email authentication setup. That is exactly why we built the SPF Record Builder — a free online SPF generator that lets you assemble a record mechanism by mechanism, validates every input, tracks the RFC 7208 ten-lookup limit in real time, and hands you the exact SPF TXT record string to paste into your DNS zone.

In this guide we will walk through what the tool does, how to use it step by step, and the underlying SPF concepts worth understanding — from mechanisms and qualifiers to the infamous lookup limit that trips up even experienced administrators.

Why Use the SPF Record Builder?

• No syntax memorization required. Add ip4, ip6, include, a, mx, exists, and ptr mechanisms through a guided interface instead of hand-typing an SPF TXT record from scratch.
• Built-in SPF validator. Every IPv4 and IPv6 CIDR range and every domain name is validated as you type, so malformed entries never make it into your published record.
• Live SPF lookup limit tracking. The builder counts DNS-lookup-consuming mechanisms against the RFC 7208 section 4.6.4 limit of 10 and warns you before you exceed it.
• Qualifier control per mechanism. Attach + (Pass), - (Fail), ~ (SoftFail), or ? (Neutral) to each entry, with sensible defaults that follow common mail server configuration guidance.
• Publish-ready output. The tool generates the exact TXT string starting with v=spf1, ready to copy to your clipboard or download as a .txt file for your DNS team.
• Free and instant. No account, no install — build, reorder, validate, and export a complete Sender Policy Framework record in under a minute.

Key Features

A few details are worth highlighting:

• The lookup counter follows RFC 7208 precisely: only include, a, mx, exists, ptr, and redirect consume DNS lookups, while ip4, ip6, and all are free. That means you can see your true budget, not a pessimistic guess.
• Reordering matters for readability and evaluation order, so mechanisms can be rearranged at any time before the final string is assembled.
• The generated output is a single line of text exactly as your DNS provider expects it — no quotes, no extra whitespace, no surprises.

How to Use the SPF Record Builder

1. Open the tool. Head to the SPF Record Builder page. You will see an empty mechanism list and the live DNS lookup counter.
2. Add your sending sources. Add one mechanism per authorized source: ip4 or ip6 for your own servers, include for third-party senders such as Google Workspace or Microsoft 365, and a or mx where a hostname covers your setup.
3. Set a qualifier for each mechanism. Choose + (Pass), - (Fail), ~ (SoftFail), or ? (Neutral). Most authorized senders should use the default Pass, while your closing all mechanism typically gets ~ or -.
4. Check the lookup counter. Watch the counter as you add entries. If it crosses the limit of 10, the builder warns you — remove or consolidate mechanisms until you are back under budget.
5. Generate, copy, and publish. Review the generated v=spf1 ... string, copy it to your clipboard or download it as a .txt file, then publish it as a TXT record for your domain in your DNS zone.

Understanding SPF Records

The anatomy of an SPF TXT record

Every SPF record is a single DNS TXT record that begins with the version tag v=spf1, followed by a space-separated list of mechanisms and qualifiers. A typical example looks like this:

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

Receiving servers evaluate the mechanisms from left to right. The first mechanism that matches the connecting sender determines the SPF result, and the all mechanism at the end catches everything that did not match earlier.

Mechanisms

• ip4 — authorizes an IPv4 address or CIDR range, e.g. ip4:192.0.2.0/24. Matches require no DNS lookups.
• ip6 — authorizes an IPv6 address or range, e.g. ip6:2001:db8::/32. Also lookup-free.
• include — delegates to another domain's SPF record, e.g. include:_spf.google.com. This is how third-party senders are authorized, and each include consumes at least one DNS lookup.
• a — authorizes the A/AAAA addresses of a hostname, e.g. a:mail.example.com. Consumes a lookup.
• mx — authorizes the domain's mail exchangers, e.g. mx:example.com. Consumes lookups for the MX query plus each returned host.
• exists — matches if the given domain resolves to any A record at all. Rarely used by hand, but it consumes a lookup.
• ptr — matches based on reverse DNS. It is expensive, unreliable, and discouraged by RFC 7208; the builder supports it for completeness, but you should almost never need it.

Qualifiers

Each mechanism can carry one of four qualifiers:

• + (Pass) — the sender is authorized. This is the default when no qualifier is written.
• - (Fail) — the sender is explicitly not authorized; receivers should reject the message.
• ~ (SoftFail) — the sender is probably not authorized; receivers should accept but flag the message.
• ? (Neutral) — no assertion is made either way.

The all mechanism

The all mechanism matches everything, so it belongs at the end of your record and defines your default policy. ~all (SoftFail) is a safe starting point while you audit your senders; -all (Fail) is the strict end state for full email spoofing prevention.

The ten-DNS-lookup limit

RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS lookups. The mechanisms that count toward the limit are include, a, mx, exists, ptr, and redirect — and includes count recursively, so a single include can hide several lookups of its own. If evaluation exceeds ten lookups, the result is a PermError: the receiving server treats your SPF record as invalid and effectively ignores it. All that carefully written authorization then provides zero protection, which is why the builder's live SPF lookup counter is arguably its most important feature.

One record per domain

A domain may publish exactly one SPF record. If two TXT records both start with v=spf1, validation fails with a PermError — the same outcome as exceeding the lookup limit. If you add a new email service, merge its mechanisms into your existing record rather than publishing a second one.

Practical Use Cases

Google Workspace or Microsoft 365 senders

If your mail flows through Google Workspace, your record needs include:_spf.google.com; Microsoft 365 uses include:spf.protection.outlook.com. A minimal Workspace-only domain would publish:

v=spf1 include:_spf.google.com -all

That single include costs several DNS lookups internally, so the builder's counter helps you see how much budget remains for other services.

Your own mail server with ip4 and ip6

Running your own mail server? Authorize its addresses directly:

v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 -all

Direct ip4 and ip6 mechanisms cost zero DNS lookups, making them the most budget-friendly way to cover infrastructure you control — a useful property when your mail server configuration also involves third-party includes.

Marketing platforms and SaaS includes

Every service that sends email on your behalf typically demands its own SPF include: include:servers.mcsv.net for Mailchimp, include:sendgrid.net for SendGrid, include:mail.zendesk.com for Zendesk, and so on. Stacking these is the fastest way to hit the lookup limit. Build the record in the tool, watch the counter, and if it crosses 10, consolidate senders or replace rarely used includes before publishing.

Tightening from ~all to -all

A sensible rollout starts with v=spf1 ... ~all, giving you weeks to monitor SPF failures in your mail logs and discover forgotten senders. Once you are confident every legitimate source is listed, switch the qualifier to -all. That is the moment SPF actively blocks forged mail instead of merely annotating it — a critical step before completing your DMARC setup.

Best Practices

• Keep the record lean. Every mechanism should represent a real, current sender. Remove services you no longer use.
• Prefer ip4/ip6 over includes when you can. Direct IP mechanisms cost no lookups and never break because a vendor changed their record.
• Avoid ptr. It is slow, consumes lookups, and RFC 7208 explicitly discourages it.
• Always end with all. A record without a closing ~all or -all leaves your default policy undefined and weakens enforcement.
• Validate before you publish. Use the builder's validation and lookup counter, then verify the live record with a DNS lookup after publishing.
• Treat SPF as one layer. SPF alone cannot handle forwarded mail; pair it with DKIM signatures and a DMARC policy for complete email authentication.

Start Building Your SPF Record Today

A correct SPF record takes minutes to build when you have the right tool — and hours to debug when you get it wrong. The SPF Record Builder removes the guesswork from Sender Policy Framework records: validated inputs, a live RFC 7208 lookup counter, and an exact, publish-ready TXT string you can copy or download in one click.

Whether you are authorizing your first Google Workspace include, migrating off a legacy mail server configuration, or tightening ~all into -all for real email spoofing prevention, build the record visually, watch your lookup budget, and publish with confidence.

Related Tools You Might Like

• DKIM Record Generator
• DMARC Record Builder
• DNS Lookup

Happy sending!