SPF Record Generator

What is SPF?

SPF — short for Sender Policy Framework — is an email authentication standard that lets domain owners declare which mail servers are authorised to send email on their behalf. It is published as a DNS TXT record at the root of your domain and consulted by receiving mail servers every time a message arrives.

When a server receives an email claiming to come from you@example.com, it looks up the SPF record at example.com and checks whether the connecting IP is listed. If the IP is authorised, SPF passes. If not, SPF fails — and the receiver decides how to treat the message based on your SPF qualifier (~all, -all, or ?all).

SPF is one of the three core email authentication standards alongside DKIM and DMARC. Without SPF, anyone in the world can connect to a mail server and impersonate your domain. With SPF, only the IP addresses and services you explicitly authorise are trusted.

How SPF Works

SPF authentication happens during the SMTP envelope handshake, before the email body is even transferred. Here is the full lifecycle:

1. A sender connects to a receiving mail server and presents an envelope-from address (the MAIL FROM command).
2. The receiver extracts the domain from the envelope-from — typically the Return-Path domain.
3. A DNS lookup is performed on the TXT record at the root of that domain (e.g. example.com).
4. The SPF record is parsed — every include:, ip4:, ip6:, a, and mx mechanism is evaluated.
5. The connecting IP is compared to the list of authorised IPs produced by parsing the record.
6. A result is returned: pass, softfail, fail, neutral, none, temperror, or permerror.
7. The receiver decides what to do with the message based on that result and its own filtering policy.

Crucially, SPF authenticates the envelope-from domain — not the visible From: header users see. That is why SPF on its own does not stop display-name spoofing. DMARC closes that gap by tying SPF authentication results to the visible From: domain.

How to Use Our Free SPF Generator

Generating a valid SPF record takes under two minutes — no technical background needed.

1. Enter your domain — type your root domain (e.g. example.com) without any prefix like “www” or “mail”.
2. Select your ESPs — tick every service that sends email for this domain. Missing any will cause SPF failures and bounces.
3. Choose an enforcement mode — start with ~all (SoftFail) if this is your first SPF rollout, or use -all (HardFail) once you are confident.
4. Add custom includes (optional) — for any third-party sender not in the preset list (e.g. a CRM, a helpdesk tool, an automation platform).
5. Add IP addresses (optional) — for self-hosted SMTP servers, on-prem mail systems, or dedicated IPs.
6. Watch the live preview — your SPF record builds in real time as you fill in fields.
7. Check the DNS lookup counter — make sure you stay under 10 lookups (this is a hard SPF limit).
8. Click Generate — copy the record and paste it as a TXT record at the root of your domain.

SPF Syntax Explained

Every SPF record follows a simple grammar: a version tag, a list of mechanisms (in evaluation order), and a trailing all qualifier.

The SPF Include Mechanism Explained

The include: mechanism is the most common SPF directive — it lets you delegate authorisation to another domain’s SPF record. Instead of listing dozens of Google, Microsoft, or SendGrid IPs by hand (and updating them whenever they change), you simply include the provider’s own SPF record.

For example, include:_spf.google.com means: “whatever IPs Google currently lists as authorised for Google Workspace, treat those IPs as authorised for me too.”

This is powerful — but it has a cost. Every include: mechanism consumes one of your 10 allowed DNS lookups. Worse, the included record itself may contain further includes, each of which counts against your budget. A single innocent-looking include:_spf.google.com can trigger 3–4 additional lookups behind the scenes.

Best Practices for Include Mechanisms

• Always use the provider’s recommended include — not the bare domain. include:_spf.google.com, not include:google.com.
• Audit unused includes — remove any service no longer sending email for your domain.
• Prefer ip4: for fixed IPs — ip4: mechanisms consume zero DNS lookups.
• Watch nested includes — even a single include: can cascade into multiple internal lookups.

SPF SoftFail (~all) vs HardFail (-all)

The trailing qualifier — what appears at the very end of every SPF record — tells receivers exactly how strictly to treat mail from unauthorised IPs.

Recommendation: start with ~all for the first 2–4 weeks, monitor your DMARC reports for unauthorised senders, then tighten to -all once every legitimate source is in your SPF record.

SPF Record Examples

1. Minimal SPF — Google Workspace only

The simplest possible valid SPF record. Authorises Google Workspace to send mail from your domain and soft-fails everything else.

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

2. Multi-Provider SPF — Google + SendGrid + Mailgun

A typical SaaS setup: Google Workspace for human email, SendGrid for transactional, Mailgun for bulk.

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

3. Strict SPF with Self-Hosted IPs

HardFail policy with dedicated sending IPs added directly as ip4: mechanisms (zero DNS lookups).

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

4. Marketing-Heavy SPF

Combines Google for company email with HubSpot and Mailchimp for marketing — three includes total.

v=spf1 include:_spf.google.com include:_spf.hubspotemail.net include:servers.mcsv.net ~all

5. Enterprise SPF — Microsoft 365 + AWS SES + Custom Range

Corporate sending stack with on-prem IPs plus Microsoft 365 and Amazon SES.

v=spf1 ip4:198.51.100.0/24 include:spf.protection.outlook.com include:amazonses.com -all

SPF for Google Workspace

Google Workspace (formerly G Suite) is the most common business email provider. Its SPF setup is simple — but there are pitfalls worth knowing.

The Canonical Google SPF Include

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

• Do not use include:google.com — that is not a valid SPF include and will cause failures.
• The Google include itself triggers ~3 additional DNS lookups — they are nested. Plan your remaining lookup budget accordingly.
• Combine with DKIM — enable DKIM signing in Google Admin so DMARC has a second authentication anchor.
• Skip the mx mechanism — Google does not deliver outbound mail through the MX hosts, so mx only wastes a lookup.
• Move to -all only after DMARC monitoring — confirm via DMARC aggregate reports that all legitimate Google mail passes SPF before tightening.

SPF for Cold Email Outreach

If you run outbound campaigns, lead generation, or any cold email programme, your SPF setup directly determines whether your emails reach the inbox or the spam folder.

• Use dedicated sending domains — never cold email from your primary business domain. Use an alternative domain like outreach.yourcompany.com or a separate purchase.
• Keep SPF simple per sending domain — usually just one include (Google Workspace, Microsoft 365, or your sending tool) plus ~all.
• Use ~all not -all on cold sending domains — strict enforcement causes silent bounces if any IP is missed during ESP migrations.
• Pair SPF with DKIM on every inbox — sequencing tools rotate across many inboxes, and DMARC needs DKIM to align when SPF can’t.
• Warm up before launching — even perfect authentication can’t save a cold inbox without sender reputation. Use Warmbase to automate inbox warming before adding any inbox to a live campaign.
• Monitor your DNS lookup count — cold email tools sometimes require multiple includes, pushing you toward the 10-lookup limit fast.

The SPF 10 DNS Lookup Limit Explained

RFC 7208 strictly limits SPF evaluation to 10 DNS lookups per record. Exceed that number and receiving servers return permerror — which causes your SPF to fail entirely and (under DMARC enforcement) your mail to be rejected.

What Counts as a Lookup?

• 1 lookup: each include: mechanism
• 1 lookup: a mechanism
• 1 lookup: mx mechanism (plus one per returned MX host)
• 1 lookup: exists: mechanism
• 1 lookup: redirect= modifier
• 0 lookups: ip4:, ip6:, all — they are evaluated directly

Nested Lookups Stack

The trickiest part: lookups inside included records also count. include:_spf.google.com triggers 1 lookup at your level — but Google’s SPF record contains 3 more includes internally, each costing a lookup of its own. Just one Google include can therefore consume 4 of your 10 lookups.

How to Stay Under the Limit

• Remove unused includes — audit which services actually still send for your domain.
• Replace include: with ip4: where IPs are static — adds zero lookups.
• Use SPF flattening tools — services that resolve all nested includes into a flat list of IPs (with the trade-off that the flattened record must be re-flattened whenever an upstream provider changes IPs).
• Watch our live counter above — it warns you as soon as your record approaches 10 lookups.

Common SPF Mistakes to Avoid

• Having multiple SPF records — only ONE SPF TXT record is allowed per domain. Two records causes SPF to fail entirely. Always merge.
• Exceeding 10 DNS lookups — triggers permerror. Use ip4: for static IPs and flatten heavy includes.
• Forgetting a sender — every service that sends email from your domain MUST be in the SPF record. Missing one causes silent SPF failures.
• Using -all too early — strict enforcement before verifying every sender causes legitimate mail to bounce.
• Using +all — this authorises every IP on the internet to send mail from your domain. It is effectively the same as having no SPF at all and is a major security risk.
• Wrong include for the provider — for example using include:google.com instead of include:_spf.google.com.
• Adding mx when you don’t need it — costs a lookup and adds nothing if your MX hosts are not also outbound senders.
• SPF without DKIM — SPF alone breaks when emails are forwarded. DKIM survives forwarding; DMARC needs at least one to pass.
• Storing SPF as the wrong DNS record type — modern SPF must be a TXT record. The old SPF record type is deprecated and ignored.

SPF vs DKIM vs DMARC — What’s the Difference?

In short: SPF authorises servers, DKIM authorises content, and DMARC ties them to the visible sender identity. All three are needed for full email authentication.

Troubleshooting SPF Issues