Import, Modify, or Build Your SPF Record from Scratch

The details and explanation of how an SPF record works are detailed below the SPF Record builder.
SPF Record Builder
Here’s a tool to add your own TXT record to your domain or subdomain for the emails you’re sending from.
SPF Record Builder v2.0.0Last Update: May 11, 2026
Fill in the fields below to generate a validated SPF record for your domain — or import an existing record to start from.
It was quite a relief when we moved our company’s email to Google Workspace. Before Google, we had to submit requests for any changes, additions to lists, etc. Now we can handle it all through Google’s simple interface.
One setback we noticed when we started sending was that some emails from our system weren’t making it to the inbox… even our inbox. I 1d Google’s advice for Bulk Email Senders and got to work quickly. We have email coming from two applications we host, another application someone else hosts, and an ESP. Our problem was that we lacked an SPF record to inform ISPs that the emails sent out by Google were ours.
What is the Sender Policy Framework?
The Sender Policy Framework is an email authentication protocol used by ISPs to block phishing emails from reaching their users. It allows you to specify which mail servers are authorized to send email on behalf of your domain from which you’re sending emails. This allows any ISP to look up your record and validate that the email comes from an appropriate source.
Phishing is a type of online fraud in which criminals use social engineering techniques to trick people into disclosing sensitive information, such as passwords, credit card numbers, or other personal details. The attackers typically use email to lure individuals into providing personal information by disguising themselves as a legitimate business… like yours or mine.
SPF is a great idea – and I’m not sure why it’s not a mainstream method for bulk emailers and spam-blocking systems. You would think that every domain registrar would make it a point to build a wizard right into it so anyone can list the sources of email they send.
How Does An SPF Record Work?
An ISP checks an SPF record by performing a DNS query to retrieve the SPF record associated with the domain of the sender’s email address. The ISP then evaluates the SPF record, a list of authorized IP addresses or hostnames allowed to send an email on behalf of the domain, against the IP address of the server that sent the email. If the server’s IP address is not included in the SPF record, the ISP may flag the email as potentially fraudulent or reject the email entirely.
The process order is as follows:
- ISP performs a DNS query to retrieve the SPF record for the sender’s email domain.
- ISP evaluates the SPF record against the IP address of the email server. This can be denoted in CIDR format to include a range of IP addresses.
- ISP evaluates the IP address and ensures it’s not on a DNSBL server as a known spammer.
- ISP also evaluates DMARC and BIMI records.
- ISP then allows, rejects, or places the email in the junk folder, depending on its internal deliverability rules.
SPF Record Examples
The SPF record is a TXT record that you must add to the domain you’re sending emails with. SPF records cannot be over 255 characters in length and cannot include more than ten include statements.
- Start with
v=spf1tag and follow it with the IP addresses authorized to send your email. For example,v=spf1 ip4:1.2.3.4 ip4:2.3.4.5. - If you use a third party to send email on behalf of the domain in question, you must add include to your SPF record (e.g., include:domain.com) to designate that third party as a legitimate sender
- Once you have added all authorized IP addresses and include statements, end your record with an
~allor-alltag. An ~all tag indicates a soft SPF fail while an -all tag indicates a hard SPF fail. In the eyes of the major mailbox providers ~all and -all will both result in SPF failure.
Once you have your SPF record written, you’ll want to add the record to your domain registrar. Here are some examples:
v=spf1 a mx ip4:192.0.2.0/24 -all This SPF record states that any server with the domain’s A or MX records, or any IP address in the 192.0.2.0/24 range, is authorized to send an email on behalf of the domain. The -all at the end indicates that any other sources should fail the SPF check:
v=spf1 a mx include:_spf.google.com -all This SPF record states that any server with the domain’s A or MX records, or any server included in the SPF record for the domain “_spf.google.com”, is authorized to send an email on behalf of the domain. The -all at the end indicates that any other sources should fail the SPF check.
v=spf1 ip4:192.168.0.0/24 ip4:192.168.1.100 include:otherdomain.com -all This SPF record specifies that all email sent from this domain should come from IP addresses within the 192.168.0.0/24 network range, the single IP address 192.168.1.100, or any IP addresses authorized by the SPF record of the otherdomain.com domain. The -all at the end of the record specifies that all other IP addresses should be treated as failed SPF checks.
Best Practices in Implementing SPF
Implementing SPF correctly enhances email deliverability and protects your domain against email spoofing. A phased approach to implementing SPF can help ensure that legitimate email traffic is not inadvertently affected. Here’s a recommended strategy:
1. Inventory of Sending Sources
- Goal: Identify all the servers and services that send email on behalf of your domain, including your own mail servers, third-party email service providers, and any other systems that send email (e.g., CRM systems, marketing automation platforms).
- Action: Compile a comprehensive list of IP addresses and domains of these sending sources.
2. Create Your Initial SPF Record
- Goal: Draft an SPF record that includes all identified legitimate sending sources.
- Action: Use the SPF syntax to specify these sources. An example SPF record might look like this:
v=spf1 ip4:192.168.0.1 include:_spf.google.com ~all. This record allows emails from the IP address 192.168.0.1 and includes Google’s SPF record, with~allindicating a softfail for sources not explicitly listed.
3. Publish Your SPF Record in DNS
- Goal: Make your SPF policy known to receiving mail servers by adding it to your domain’s DNS records.
- Action: Publish the SPF record as a TXT record in your domain’s DNS. This enables recipient mail servers to retrieve and check your SPF record when they receive emails from your domain.
4. Monitor and Test
- Goal: Ensure your SPF record validates legitimate email sources without impacting email deliverability.
- Action: Use SPF validation tools to monitor email delivery reports from your service providers. Pay attention to any delivery issues that might indicate SPF checks are catching legitimate emails.
5. Refine Your SPF Record
- Goal: Adjust your SPF record to resolve any issues identified during monitoring and testing, and to reflect changes in your email sending practices.
- Action: Add or remove IP addresses or include statements as necessary. Be mindful of the SPF 10 lookup limit, which can cause validation issues if exceeded.
6. Regularly Review and Update
- Goal: Keep your SPF record accurate and up-to-date to adapt to changes in your email infrastructure and sending practices.
- Action: Periodically review your sending sources and update your SPF record accordingly. This includes adding new email service providers or removing ones you no longer use.
By following these steps, you can implement SPF to enhance your email security and deliverability while minimizing the risk of disrupting legitimate email communications.
Navigating SPF Limitations
While SPF is a powerful tool for authentication, it comes with strict technical constraints designed to prevent Denial-of-Service (DoS) attacks on DNS infrastructure. If you exceed these limits, your SPF record will break, causing legitimate emails to fail authentication and land straight in the spam folder.
The Two Hard Ceilings
- The 10 DNS Lookup Limit: To prevent excessive resource consumption, an SPF check is permitted a maximum of 10 recursive DNS lookups. Every time you use an
include,a,mx,ptr, orexistsmechanism, it counts toward this limit. Note thatip4andip6mechanisms do not count as lookups, as they provide the address directly. - The 255-Character Limit: A single TXT record string cannot exceed 255 characters. While you can technically chain multiple strings together in DNS, many older systems struggle to parse them, and a bloated record becomes difficult to manage.
As companies adopt more SaaS tools—using Zendesk for support, HubSpot for marketing, and Google Workspace for productivity—each service adds its own include statement. It’s surprisingly easy to hit 11 or 12 lookups, at which point the SPF record returns a PermError (Permanent Error).
The Solution: SPF Flattening
SPF Flattening is the process of taking a complex SPF record filled with include statements and flattening it into a list of plain IP addresses (ip4 or ip6).
How SPF Flattening Works
Instead of asking the receiving ISP to go find the IPs hidden inside include:_spf.google.com, a flattening tool performs those lookups in advance. It resolves all the nested hostnames into their respective IP ranges and replaces the include tags with the actual IPs.
Example:
- Before (3 lookups):
v=spf1 include:_spf.google.com include:sendgrid.net ~all - After (0 lookups):
v=spf1 ip4:209.85.128.0/17 ip4:167.89.0.0/17 ... ~all
Benefits of Flattening
- Stops PermErrors: By converting lookups into static IP lists, you stay well under the 10-lookup limit regardless of how many third-party services you use.
- Faster Validation: Mail servers don’t have to perform recursive DNS queries, which can slightly speed up the initial mail processing.
The Caveat: Dynamic Updates
The biggest risk of manual flattening is that third-party providers (like Google or Microsoft) occasionally update their IP ranges. If you hard-code their current IPs into your record and they change them, your emails will fail.
To solve this, most modern deliverability platforms offer Dynamic SPF Flattening. These services monitor your providers’ records and automatically update your flattened DNS record whenever a change is detected.







