Skip to main content

Understanding SPF

SPF increases domain reputation and email deliverability.

SPF fights domain impersonation and email spoofing to protect your brand reputation.

SPF is one of the foundational methods of email authentication for DMARC.

SPF explained

What is SPF?

Sender Policy Framework (SPF) is used to authenticate the sender of an email. With an SPF record in place, Internet Service Providers can verify that a mail server is authorized to send email for a specific domain. An SPF record is a DNS TXT record containing a list of the IP addresses that are allowed to send email on behalf of your domain.

SPF has become exceedingly vital to help verify which sending infrastructure can relay email on behalf of your domain. Implementing SPF for email provides major benefits.

How does SPF work?

To take advantage of SPF, you publish an SPF record in the DNS. The record is a list of all the IP addresses that are allowed to send email on behalf of the domain.

The SPF mechanism uses the domain in the return-path address to identify the SPF record. When a sender tries to hand-off an email to an email “receiving” server for delivery, the server checks to see if the sender is on the domain’s list of allowed senders. If so, then a link has been established between the piece of email and the email domain. If not, then the server continues processing the email as usual without this link, as any number of things could be going on.

The email might be real, but the list of senders might not be accurate. Real email might have been forwarded which means the email could have come from anywhere and the list of allowed senders doesn’t help too much. Or, the email is fake and unwanted. Too many possible outcomes makes it difficult to attach meaning to the absence of the link that SPF can provide. DKIM fills the gap in the DMARC technical framework as an additional way to try and link a piece of email back to a domain.

How SPF Works

What is SPF Format?

More information about how an SPF record is formatted, and how you can create one for your email domain, can be found here: How to Create and Add an SPF Record

Already have an SPF record? We have also developed a comprehensive guide to SPF record formatting to increase your understanding and help troubleshoot any SPF issues that our free SPF Surveyor may bring to your attention: SPF Record Syntax.

 

SPF and DMARC for Email

By itself, SPF can associate a piece of email with a domain. With the DNS records in place, DMARC ties the results of SPF to the content of email, specifically to the domain found in the return path or From: header of an email. For SPF to work correctly in the context of DMARC, the return-path address has to be relevant to the domain of the From: header, which is the item that ties together DMARC alignment.

How do I check my SPF Record?

Check your domain’s SPF settings – dmarcian’s SPF Surveyor is an SPF diagnostic tool that presents a graphical view of SPF records. It allows you to quickly identify which servers are authorized to send on behalf of a domain.

Why SPF-Only Isn’t Safe Enough

Though SPF is a layer of proven email authentication that has been around since the late 1990s, it does have its challenges. Simply put, forwarding of email happens on the Internet and the SPF mechanism doesn’t survive the forwarding process. Forwarding typically happens when you send email to someone@EXAMPLE.ORG and that person has set their email to be forwarded to another address, like someone@SAMPLE.NET. In this example, your email appears to be coming out of infrastructure that appears to have nothing to do with you.

DKIM signing can survive forwarding. If your domain is covered with DKIM, dmarcian’s ability to detect forwarding increases. SPF does not work in the context of forwarding, as SPF is simply a list of servers that are authorized to send on behalf of your domain, and it isn’t possible for a domain owner to maintain a list of forwarders.

SPF Misconceptions

Companies often misunderstand how SPF works and instruct their customers to include the company’s own SPF record. However, this ends up doing nothing if the company uses its own domain in the bounce address. When an email receiver processes a piece of email, it will look at the company’s SPF record—not the SPF record of the customer.

Two unwanted things happen because of this misconception:

  • Unnecessary “includes” are added into their SPF records. This causes SPF records to bloat and introduces management challenges.
  • Confusion is introduced as people just want to get SPF into place to complete their DMARC deployment. The result is that SPF passes, but DMARC fails.

For SPF to work correctly in the context of DMARC, the bounce address has to be relevant to the domain of the From: header. Unfortunately, many companies that send email on behalf of others do not currently allow their customers to change the bounce address to the customer’s domain. This is slowly changing, but companies first have to understand the basics of how SPF works. We have resources available to help companies send DMARC compliant email on behalf of others.

Note: There is obsolete technology called SenderID that tried to perform SPF-like checks, except it used the From: header domain (among others) as the item to check. SenderID also attempted to reuse existing SPF records, causing even more confusion.

Learn More about SPF

We’re very pleased to feature a series of short, technical videos that walk through various aspects of DMARC.  These videos draw upon the best of our training courses, are freely available and can be viewed at your leisure.

Get your domains into compliance.
Try out dmarcian for free!