Email Deliverability
Authentication
Email Deliverability
Authentication
When you're sending out emails from a domain (@yourcompany.com), an SPF record is a crucial part of making sure no one outside your organization can send emails on your behalf. But setting up a valid SPF record can be harder than it looks. We've listed the most common mistakes when working with the Sender Policy Framework.
Published in:
May 2022
A lot of questions we get about the Sender Policy Framework involve the setup of the record itself. Existing SPF records return a fail, cannot be read by SPF record checks, or people don't see their changes after they saved them.
The SPF RFC is very clear about this: the receiving mail server should only look at one SPF record - and thus disregard a potential second one. Every change or addition that you want to make should happen inside of this one record.
The receiving mail server will recognize the SPF record by the opening tag 'v=spf1' and it will stop analyzing the SPF record after the all-mechanism. The record checker will read the SPF record from left-to-right, but mechanisms inbetween the v=spf1 and all can be in random order. Read more about mechanisms here.
The moment you have made changes to your DNS, it depends on your provider how fast your record is actually active. Usually, this happens within a few minutes. In addition, you have to deal with TTL (Time to Live) in your DNS, defining the amount of seconds it takes for your new record to become active. Usually this is set to 300 - 5 minutes - but sometimes is set to 86400 - 1 day.
Though -all is officially the strictest SPF policy, we will always recommend to qualify your SPF record with ~all:
Let's take a deeper dive into how that works.
Forwarding and replying to messages is often done without rewriting the Return-Path. This causes the receiving server to perform an SPF check on the wrong (intermediate) host. Obviously, this leads to unexpected 'rejected' messages. Although this is just a configuration error, there are much riskier situations where -all can lead to problems.
SPF itself only checks the Return-Path (MAIL FROM), not the header From (the one that is visible to your recipient). This makes SPF non-effective without a proper DMARC policy. Spammers can easily use an SPF validated Return-Path and still use a spoofed header From. This is why SPF needs a DMARC policy. However, DMARC treats -all and ~all equally, according to its RFC. So if you take into account the problems that arise with an -all qualifier, using ~all is the better option.
Although -all should be better, the result is this policy is extra bounces. For these bounces, we (as a sender) are held accountable. So, how tempting the -all policy may be, there are close to zero scenarios where this provides extra security.
An SPF record may contain a maximum of 10 lookups, otherwise the check fails. This maximum number also counts so-called nested lookups - includes within a record that you included. The mechanisms that count towards this number are: a, include, and mx.
You can prevent your SPF record from exceeding the maximum number of lookups by taking a few things into consideration:
Sometimes, you'll find oddities in your SPF record. Not all of them are harmful to your SPF validity, though. We've listed a few things that might look odd, but don't have an impact on how receiving mail servers view your SPF record.
An SPF record usually consists of a single string of mechanisms: v=spf1 mx a:outgoing.yourcompany.com include:emailserviceprovider.com include:_spf.esp.com -all
However, you are allowed to use multiple strings in one record. The RFC clarifies that v=spf1 .... first" "second string..." is equivalent to: v=spf1 .... firstsecond string.... Though it's not the most logical practice, it shouldn't affect the SPF record check.
Feel like this article misses some information about the Sender Policy Framework or does it not answer your specific question? Read our explanation of SPF, our dissection of the SPF record, or reach out to us to discuss your situation.