SPF Record Builder

The SPF Record Builder generates syntactically correct Sender Policy Framework (SPF) DNS TXT records that authorize specific mail servers to send email on behalf of your domain. Enter your mail server IPs, third-party service includes, and policy preferences to produce a ready-to-publish record like v=spf1 ip4:203.0.113.5 include:_spf.google.com -all.

Understanding SPF Records

If you run a domain that sends email, SPF is one of the first things you need to configure correctly. Without an SPF record, any server on the internet can send messages that appear to come from your domain, and receiving mail servers have no way to distinguish your legitimate mail from spoofed phishing messages. SPF gives you a way to declare which IP addresses and services are authorized to send on your behalf, and it gives receivers a way to check that declaration before accepting a message.

An SPF record is a DNS TXT record published at the root of your domain. When a receiving mail server gets a message claiming to be from your domain, it looks up your SPF record and checks whether the sending server's IP address matches any of the authorized mechanisms you listed. If it matches, the message passes SPF. If it does not match, the receiving server applies whatever policy you specified in the all mechanism at the end of the record -- typically soft-failing or hard-failing the message.

The tricky part is getting the record right. SPF has a specific syntax, strict limits on DNS lookups, and rules about how mechanisms are evaluated. A missing include means a legitimate service gets blocked. A typo in an IP range means your own mail server fails authentication. This builder walks you through each mechanism interactively, validates your entries, and produces a record you can copy directly into your DNS configuration.

How to Build an SPF Record

1. Start with the required version tag v=spf1
2. Add ip4 or ip6 mechanisms for your mail server IP addresses
3. Add include mechanisms for third-party email services (Google Workspace, Microsoft 365, Mailchimp, etc.)
4. Add a or mx mechanisms if your domain's A or MX records point to sending servers
5. Set the all mechanism at the end to define the default policy for unauthorized senders
6. Review the generated record for length and lookup limits
7. Copy the record and publish it as a DNS TXT record on your domain

SPF Record Examples

SPF Mechanism Qualifiers

Each mechanism can be prefixed with a qualifier that tells receiving servers how to interpret a match:

The -all qualifier provides the strictest protection, instructing receivers to reject messages from unlisted servers. Use ~all during initial deployment to monitor without blocking legitimate mail.

When to Use the SPF Record Builder

• Setting up email authentication for a new domain for the first time
• Adding a third-party email service like SendGrid, Amazon SES, or Postmark that sends on your behalf
• Consolidating multiple SPF mechanisms from different teams or departments into a single valid record
• Troubleshooting email deliverability when messages land in spam due to SPF failures
• Migrating email infrastructure and updating authorized sender lists
• Strengthening your DMARC policy by ensuring SPF is correctly configured before moving to p=reject

How SPF Records Work

SPF records are published as DNS TXT records on your domain's root. When a receiving mail server gets an email claiming to be from your domain, it queries DNS for your SPF record and checks whether the sending server's IP address matches any authorized mechanism.

SPF Evaluation Order

The receiving server evaluates mechanisms left to right. The first mechanism that matches the sending IP determines the result. If no mechanism matches, the all qualifier at the end provides the default action.

DNS Lookup Limits

SPF evaluation is limited to 10 DNS lookups per RFC 7208. These mechanisms each consume one lookup: include, a, mx, ptr, exists, and redirect. Literal IP mechanisms (ip4, ip6) do not count. Nested includes also count against this limit -- if an included domain's SPF has 3 more includes, those add 4 total lookups.

Common Third-Party Include Values

Record Length Constraints

A single DNS TXT string cannot exceed 255 characters. Longer records must be split into multiple quoted strings within a single TXT record. The builder tracks character count and warns when approaching this limit.

SPF Configuration in Practice

The single most important decision in your SPF record is the all mechanism at the end. Many administrators leave it at ~all (softfail) indefinitely because they are worried about blocking legitimate email. While ~all is appropriate during the initial deployment period, you should plan to move to -all (hard fail) once you have confirmed all your authorized senders are listed. A softfail tells receivers the message is suspicious but does not instruct them to reject it, which gives spoofers a window to abuse your domain. A hard fail gives receivers a clear signal to reject unauthorized messages, which is the whole point of deploying SPF.

The second thing to watch is lookup count. Every time you add a new SaaS tool that sends email -- a marketing platform, a helpdesk, a CRM, a transactional email service -- you add at least one include mechanism, and each include consumes one or more DNS lookups. It is surprisingly easy to hit the 10-lookup limit, especially when each service's SPF record itself contains nested includes. Google Workspace alone consumes 4 lookups (1 direct plus 3 nested). Add Microsoft 365, SendGrid, and Mailchimp, and you may already be at 10. When you exceed the limit, SPF returns a permanent error and your legitimate email starts failing authentication.

To stay under the limit, consider flattening includes into ip4 and ip6 mechanisms where possible. Flattening replaces a dynamic include with the static IP addresses it currently resolves to, which eliminates the DNS lookup. The tradeoff is maintenance: if the provider changes their IP ranges, your flattened record becomes stale. SPF flattening services automate this process by periodically re-resolving the includes and updating your record. Use the SPF Record Length Checker to audit your current lookup count before making changes.

Frequently Asked Questions

Can I have multiple SPF records on one domain?

No. A domain must have exactly one SPF TXT record. Multiple SPF records cause a permerror during evaluation, which typically means SPF fails entirely. If you need to authorize many services, combine all mechanisms into a single record. If you are running out of space or lookups, use flattening or the redirect mechanism to point to a dedicated SPF policy domain.

What is the difference between -all and ~all?

The -all (hard fail) instructs receivers to reject emails from unauthorized servers. The ~all (soft fail) tells receivers the message is suspicious but should still be accepted, typically marked for further scrutiny. Start with ~all while testing, then switch to -all once you have confirmed all legitimate senders are included.

How do I add Google Workspace to my existing SPF record?

Add include:_spf.google.com before the all mechanism in your existing record. For example, if your current record is v=spf1 ip4:203.0.113.5 -all, change it to v=spf1 ip4:203.0.113.5 include:_spf.google.com -all.

What happens if I exceed the 10 DNS lookup limit?

The SPF evaluation returns a permanent error (permerror). Most receiving servers treat this as an SPF failure, which means your emails may be marked as spam or rejected outright -- especially if you also have a strict DMARC policy. Use the SPF Record Length Checker to audit your lookup count.

Should I use the a or mx mechanism?

The a mechanism authorizes the IP address that your domain's A record points to. The mx mechanism authorizes the IP addresses of your MX records. Both consume one DNS lookup each. If the same IPs are already covered by ip4 mechanisms, skip a and mx to save lookups. They are most useful when your sending server IP changes frequently and is always reflected in your A or MX records.

How does SPF relate to DKIM and DMARC?

SPF, DKIM, and DMARC work together as a layered email authentication system. SPF checks whether the sending server is authorized. DKIM verifies that the message content has not been tampered with using a cryptographic signature. DMARC ties them together by defining a policy for messages that fail both checks and by requiring domain alignment. You need all three for robust email authentication.

Related Tools

• SPF Record Length Checker - Check SPF record length and lookup limits
• DKIM TXT Record Formatter - Format DKIM records with proper quoting
• DMARC Record Builder - Build DMARC records with all policy tags
• DNS Record Set Deduper - Find and remove duplicate DNS records
• Zone File Linter - Check zone files for syntax errors and duplicates