SPF Record Generator

SPF Record Generator – Build Email Authentication DNS Records

SPF (Sender Policy Framework) is a DNS-based email authentication standard defined in RFC 7208 that lets domain owners publish a list of mail servers authorised to send email on their behalf. When a receiving mail server sees a message claiming to be from your domain, it looks up your SPF record to verify that the sending server is on the approved list. If it is not, the server can reject or flag the message as spam — protecting your domain against email spoofing and phishing attacks.

What an SPF Record Looks Like

An SPF record is a DNS TXT record published at your domain apex (e.g.,example.com). It always starts with v=spf1 followed by one or more mechanism tokens and ends with an all qualifier:

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

This example authorises Google Workspace and a specific IP address to send mail, and instructs receiving servers to softfail (flag as suspicious) any sender not matched by those mechanisms.

Core SPF Mechanisms

Choosing the Right Default Policy

The qualifier before all is the most important decision in your SPF record. It determines what receiving mail servers do with messages from senders not explicitly listed.

• -all (Fail) — Receiving servers should reject the message. Use this once you are confident your SPF record is complete and correctly covers all legitimate sending sources.
• ~all (Softfail) — Accepting servers should accept the message but mark it as suspicious. Softfail is the recommended starting point while testing because it never silently drops legitimate mail.
• ?all (Neutral) — No policy. The SPF check neither passes nor fails, which gives no benefit for security.
• +all (Pass all) — Allows any sender, which entirely defeats the purpose of SPF. Never use this.

The DNS Lookup Limit

RFC 7208 imposes a maximum of 10 DNS lookups during SPF evaluation. Each include, a, mx, ptr, andexists mechanism triggers at least one DNS lookup. If your SPF record causes more than 10 lookups, receiving servers return a permerror, which can cause legitimate emails to fail authentication and be rejected.

To stay within the limit, prefer ip4: and ip6: mechanisms where you control the sending IPs, and audit your include: chain to understand how many sub-lookups each third-party SPF record adds.

Using include: for Third-Party Services

Cloud email services publish their own SPF includes. You reference them with theinclude: mechanism. Common examples:

Publishing Your SPF Record

Once you have generated your SPF record, publish it as a TXT record at your domain apex (the bare domain, not a subdomain). The steps depend on your DNS provider, but in general:

1. Log in to your DNS provider's control panel.
2. Navigate to the DNS management page for your domain and look for existing TXT records.
3. Remove any existing record starting with v=spf1. A domain must have exactly one SPF record; having two causes a permanent error.
4. Add a new TXT record: Name = @ (or your domain), Value = the generated record string.
5. Test propagation with: dig TXT yourdomain.com or an online SPF checker.

SPF Alone Is Not Enough

SPF verifies the envelope sender (the Return-Path address used during the SMTP handshake), not the From: header visible to email recipients. For comprehensive email authentication, combine SPF with:

• DKIM — adds a cryptographic signature to outgoing messages that receivers can verify against a public key in your DNS.
• DMARC — aligns SPF and DKIM results, provides policy enforcement (none / quarantine / reject), and delivers aggregate reports about authentication failures.