Email Marketing & AutomationMartech Zone Apps

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.

Optional — Enter a domain to look up its current SPF TXT record, or paste an SPF record directly to load its values into the builder.
Optional — Authorize the servers listed in your domain's MX records to send email. Most domains should answer Yes.
Optional — Authorize the IP address(es) in your domain's A record to send email. Use Yes if mail leaves from the same server as your website.
Optional — Authorize senders whose reverse DNS resolves to your domain. PTR is deprecated by RFC 7208 and should usually be left as No.
Optional — IPv4 or IPv6 addresses authorized to send email for your domain. CIDR ranges are supported. One entry per line.
Optional — Specific hostnames whose A records are authorized to send email for your domain. One entry per line.
Optional — SPF records of third-party senders (Google, SendGrid, Mailchimp, etc.) to authorize alongside your own. One domain per line.
Required — How receiving servers should treat mail from senders not listed above. Soft Fail (~all) is recommended while testing; Fail (-all) is strictest.
The complete SPF TXT record built from your selections. Copy this and publish it as a TXT record on your domain.

Copy

Was this helpful?

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:

  1. ISP performs a DNS query to retrieve the SPF record for the sender’s email domain.
  2. 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.
  3. ISP evaluates the IP address and ensures it’s not on a DNSBL server as a known spammer.
  4. ISP also evaluates DMARC and BIMI records.
  5. 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=spf1 tag 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 ~all or -all tag. 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 ~all indicating 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, or exists mechanism, it counts toward this limit. Note that ip4 and ip6 mechanisms 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.

Related Articles