App: How To Build Your SPF Record

The details and explanation of how an SPF record works are detailed below the SPF Record builder.

SPF Record Builder

Here’s a form that you can use to build your own TXT record to add to your domain or subdomain that you’re sending emails from.

It was quite a relief when we moved our company's email to Google from the managed IT service we used. Before being on Google, we used to have to put requests in for any changes, list additions, 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 did some reading up on Google's advice for Bulk Email Senders and quickly got to work. We have email coming out of 2 applications that we host, another application that someone else hosts in addition to an Email Service Provider. Our problem was that we lacked an SPF record to inform ISPs that the emails sent out of Google were ours.

What is the Sender Policy Framework?

Sender Policy Framework is an email authentication protocol and part of email cybersecurity used by ISPs to block phishing emails from being delivered to their users. An SPF record is a domain record listing all your domains, IP addresses, etc. that you're sending emails from. 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 where criminals use social engineering techniques to trick people into giving away sensitive information, such as passwords, credit card numbers, or other personal information. 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 for anyone to list out the sources of email they'd be sending.

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 does a DNS query to retrieve the SPF record associated with the sender's email address 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 email delivery, rejects it, or places it 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.