What is an SPF Record for Email and How Does it Work?

If you ask anyone to tell you the most annoying aspect of email — the thing that causes the most frustration — spam is almost always going to be a top answer.

Perhaps the only thing worse than spam? Email spoofing — where bad actors send a message that pretends to be from an organization the subscriber knows and trusts. If the recipient can be fooled into believing the source, it’s only one more small step to convince them to hand over credit card numbers, share important login information, or download a virus.

While there’s legislation against things like spam, it can’t prevent bad behavior. Criminals are criminals because they don’t follow the law after all. That’s where email authentication protocols like SPF come into play.

SPF, or Sender Policy Framework, was one of the first attempts to help incoming mail servers correctly verify the source of a message — so real emails make it to the inbox and fakes are sent packing. When an incoming mail server receives a message, it checks the return path (which includes information like the domain name the email says it’s coming from) and then checks domain name system (DNS) records to see if they match.

This is an idea that dates back to 1997 but didn’t hit the big leagues until Microsoft began to support it in 2004.

Properly setting up SPF not only tells servers that they should let your email through the gates, but it also prevents your brand’s reputation from being associated with scams or spammy sending practices.

In short, if you care about protecting the brand you work with or maximizing email deliverability (and we know you do), SPF can help.

Without something like SPF, SMTP (Simple Mail Transfer Protocol) doesn’t have a way to authenticate senders. SPF lets incoming mail servers know that a message comes from a source authorized by the domain listed.

This makes spoofing much harder. If a bad actor sends an email purporting to be from PayPal, the subscriber’s incoming mail server can check if it originated from a server authorized by PayPal. If it did not, it won’t let the message through.

For legitimate email senders, implementing SPF provides a way to keep their reputation clean. And a clean reputation increases the chances that messages make it to the inbox. Plus, it demonstrates to internet service providers (ISPs) and incoming mail servers that you’re contributing to a positive email environment. It means you’re a good steward. As a result, you’ll not only prevent damage to your reputation, you’ll actually strengthen it.

The result? More emails will make it to their intended destination and more forged emails are caught before reaching the inbox. 

An SPF record is included in the DNS TXT record on a sender’s domain. So, if an organization uses subdomains to send emails, it will need to create an SPF record for each one. The record identifies all of the approved senders (represented by the IP address of their server) for the domain.

Actively-used domains likely send email from more than one server or sender. One sender might automatically distribute order information to customers (transactional emails) or respond to customer service inquiries. Another sender might be the ESP used for email marketing. Still, other servers might be for internal emails or direct communication between employees and customers.

What does the incoming mail server verify?

The incoming mail server checks the return path (“from” information) in the email header and verifies that the email originates from one of the servers authorized in the DNS TXT record of the domain.  

What happens next?

If the incoming mail server can verify the identity, it will send the email to the inbox. However, if the email fails identification or returns a neutral conclusion, the message may be sent to spam or quarantined in another location.

The incoming mail server might also report its findings and this could boost (or hurt) your reputation as a result.

The right sender policy framework does more than just verify that your email is from who it says it’s from. It means you’re actively committed to a good email ecosystem. It’s a trust signal. When you go through the effort to set up an SPF record, you increase the chances that your emails make it to the inboxes you’re targeting because you’re viewed in higher regard.

An SPF record contains three parts:

1. The version of SPF utilized

This should be “ v=spf1” (the first version) because all others have been discontinued.

2. A list of authorized senders

List authorized senders using mechanisms like IP addresses, hostnames, or arecords. You can choose to use all of the same type of mechanism or mix and match depending on your authorized senders.

There are a number of different mechanisms to choose from, but we’ll look at three options:

• The ip4 or ip6 mechanism lists the IP addresses authorized to send on your behalf.
• The “a” mechanism allows the incoming server to reference the arecords of a domain. So instead of listing a specific IP address that will return a pass/fail, as long as the IP where the email originates is found among the a records, the email will pass the test. 
• The “mx” mechanism works similarly to the a mechanism, but instead checks all of the a records and mx records for the domain. In other words, since mx records indicate the IP addresses that your domain uses to receive mail, if an email is sent from one of those IPs, the incoming mail server should accept it.

3. The “all” mechanism, qualified by one of four demarcations

The “all” mechanism works a little differently. It goes at the end of every SPF record to tell the incoming mail server what to do with the results and specifies that the IP addresses must exactly match what’s listed. Precede the “all” mechanism with one of the following:

• –all  — This means that if an exact match is not found, the email has failed and will not make it to the subscriber in any capacity.
• ~all — This is a soft fail and means that if an exact match is not found, the email has failed, but will still send. However, it’s likely to go to a spam folder.
• +all — This allows any server to send email from your domain. It’s a free pass to use your domain name and should rarely (never) be used.
• ?all — This is a neutral setting. The message has neither passed nor failed. It’s used when a domain owner doesn’t want to affirm or restrict any particular IP address.

A complete SPF code might look something like this:

                            

                                v=spf1
ip4:61.949.100.188 ip6:98.422.200.766 a:smtp.example.com -all 
                            
                        

1. Identify all senders for your domain

Remember, email might be sent from a variety of sources like internal email servers, ESPs for email marketing, or other sources for automated transactional emails.

2. Note all of the domains your organization owns

Each domain should have its own SPF record. An organization might utilize multiple domains or subdomains. You don’t want to miss any.

3. Create an SPF record for all domains, even those you don’t use

You should create an SPF for every domain and subdomain at your disposal. You can even create a blank SPF record (include parts 1 and 2 with the “-all” qualifier at the end) for any unused domains. This will prevent spoofing from domains you don’t use.

4. Publish the SPF record to the DNS record

Work with your domain’s administrator to properly add the SPF record. Many ESPs provide easy access to information to add their IP address to your SPF record. Or they may handle SPF implementation automatically, but this means you’re using a shared IP address and have less control over your sender reputation.

You can only have one SPF record per domain. If you list more than one, SPF will fail. This is a common mistake when administrators add new SPF records on top of existing ones.

The receiving server will actually return an error. Over time, this can hurt your overall deliverability.

You do need a separate SPF record for each subdomain. Unlike DMARC, if an incoming mail server doesn’t find an SPF record for an email coming from a certain subdomain, it won’t continue searching the primary domain. It will simply return a none result.

This doesn’t always mean that you should copy and paste the same SPF multiple times —  emails sent from a subdomain like sales.website.com might come from a different server than those sent from website.com.

Because an incoming mail server references the IP from the sending server with the SPF record, it will no longer pass SPF if an email is forwarded. The forwarder is sending from a new IP — one not approved in the SPF record from the domain.

SPF records are limited to ten mechanisms. This is fine if mail is sent from just a few IP addresses, but large organizations, or those with a matrix of email needs, will quickly surpass this limitation. You can either try to get around this using a complicated system of various subdomains, or you can allow more lenient rules, which make SPF less effective at preventing spoofing and spam.

Additionally, it can be hard to keep SPF records up to date. This is especially true if you’re listing specific IP addresses for third-party vendors like an ESP. If something changes on their end, you have to first be aware of it and then immediately update your SPF to prevent false fails in SPF authentication.

SPF isn’t a perfect solution. That’s why additional authentication protocols have been developed. DKIM or DomainKeys Identified Mail, for example, uses encrypted keys to verify the identity of an email’s sender.

DKIM has the benefit of surviving forwarding but has its own limitations. DMARC ties together DKIM and SPF so they’re stronger. And BIMI gives actual subscribers confidence in the identity of a sender with brand logos displayed in the inbox.

Email professionals succeed by protecting their brand’s reputation. This means preventing spammers and criminals from abusing domain names and demonstrating a commitment to email best practices. The result is greater subscriber trust, better deliverability, and superior results.

Email on Acid provides deliverability tools that protect sender and brand reputation, prevent mistakes, and ease send button anxiety. Email marketers can improve their deliverability and have confidence the content is perfect when it arrives — all with a more efficient workflow.

You can do even more to improve email deliverability when you add Pathwire’s suite of tools. That includes email validations and Inbox Placement, which helps marketers catch deliverability issues before hitting send.