SPF Record Generator

Build a valid SPF (Sender Policy Framework) TXT record for your domain. Check the senders you authorize — your own MX servers, A record, specific IP ranges, and third-party mail providers via include: — choose your failure policy, and get a ready-to-publish DNS value. The tool counts DNS-lookup mechanisms and warns you if you exceed the 10-lookup limit that causes SPF permerror.

How to use the SPF Record Generator

Fill in the mechanisms that describe who is allowed to send email as your domain:

1. MX — your own mail servers (the hosts in your domain's MX records). Check this if your domain sends outbound mail from the same hosts that receive it.
2. A — your domain's A/AAAA record IP. Useful if your web server also sends transactional email.
3. include: — third-party sending services such as Google Workspace (_spf.google.com), Microsoft 365 (spf.protection.outlook.com), SendGrid (sendgrid.net), Mailchimp (servers.mcsv.net), etc. Each include: counts as one DNS lookup.
4. ip4:/ip6: — explicit IP addresses or CIDR ranges. These do not consume DNS lookups, so prefer them when you control the IPs.
5. Fail policy — -all (hard fail) tells receivers to reject mail from unlisted senders; ~all (soft fail) accepts but marks it. Use -all in production once you have confirmed all legitimate senders are listed.

Click Generate SPF. If the record exceeds the 10-lookup limit (MX + A + one per include: domain), a red warning appears — you must restructure by replacing some include: mechanisms with explicit ip4: ranges or using sub-includes to flatten the chain.

About SPF Records

SPF (Sender Policy Framework, RFC 7208) is a DNS-based mechanism that lists the IP addresses and servers authorized to send email on behalf of a domain. When a receiving mail server accepts a connection, it checks the envelope sender's domain for a TXT record starting with v=spf1 and evaluates the connecting IP against it. If the IP is not listed and the record ends with -all, the receiver may reject the message outright — stopping spoofed email that uses your domain in the From or Return-Path header.

SPF is one of three email authentication standards. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message body and headers. DMARC ties SPF and DKIM together and tells receivers what to do when both fail (quarantine or reject). All three work together: SPF alone can be bypassed by spoofing the visible From header while passing only the envelope sender check, which DMARC's alignment requirement closes. If you're setting up SPF, also see the SPF Record Parser to verify existing records.

The 10-lookup limit is the most common source of SPF breakage in production. Each mx, a, include:, exists, and redirect= mechanism triggers one DNS lookup at evaluation time. Because included records may themselves contain further include: mechanisms, the total can silently exceed 10 as your sending providers update their SPF chains. Exceeding 10 lookups causes a permerror, which receiving servers typically treat as a hard fail. To stay under the limit, replace include: mechanisms with ip4: ranges where possible, or consolidate providers.

Common use cases

• Initial domain setup — build the first SPF record for a new domain before any mail is sent, so spammers cannot spoof it immediately.
• Adding a new email provider — when onboarding Mailchimp, HubSpot, or any new SaaS that sends on your behalf, extend the SPF record without breaking existing senders.
• Enforcing -all after testing — start with ~all (soft fail) to monitor without blocking, then switch to -all once you are confident all senders are listed.
• Transactional email migration — moving from one SMTP relay to another; update ip4: ranges and includes atomically to avoid a gap in authorization.
• Lookup-limit remediation — replace include: chains that push you over 10 lookups with flattened ip4: ranges.