The battle against spam and email scams is never-ending. As a result, several standards have evolved to help stem the tide.
SPF,
or “Sender Policy Framework” is one of those standards. It enables a
domain to publicly state which servers may send emails on its behalf.
You don't have to understand every detail of SPF in order to use it, but
a deeper knowledge can help you see the bigger picture. Let's see how
you can protect your domain’s reputation and improve your email
deliverability.
SPF is an open
standard so that the owner of a domain can provide a public list of
approved senders. For instance, if you use an application like Gigabit
to send your transnational email and then use Campaign Monitor to send
your marketing emails, you’d want to include both of those services as
approved senders. This way, receiving mail servers can cross-check that
the email originated from a server that has permission to send on your
behalf. If the message originates from a server that’s not on your list,
then the receiving server can consider it a fake and treat it
accordingly.
An important aspect to understand about SPF is that it does not validate against the
From domain. Instead, SPF looks at the
Return-Path value to validate the originating server. What’s a
Return-Path?
Good question. It’s the email address that receiving servers use to
notify the sending mail server of delivery problems, like bounces. So an
email can pass SPF regardless of whether the from address is fake. The
problem with this limitation is that the
From address is
what recipients see in their email clients. Furthermore, even if a
message fails SPF, there's no guarantee it won't be delivered. That
final decision about delivery is up to the receiving ISP.
SPF is just one of many factors that ISPs use to determine whether an email should be delivered. When it comes to verifying the
From address, DMARC is a relatively new standard designed to address this shortcoming in SPF.
Why use SPF for your domain?
SPF
may not be perfect, but you’re still much better off using it than not
using it. Emails can still be delivered without setting up SPF, but
doing so improves your chances. Having an SPF policy provides an
additional trust signal to ISPs so you can increase the likelihood that
your emails arrive in the inbox. The SPF policy can also help mitigate
the backscatter of bounce and error notifications when spammers try to
abuse your domain. Ultimately, SPF won't solve all of your delivery
problems, but it’s an additional layer that, combined with
DKIM and
DMARC, can improve your delivery rates and prevent abuse.
How does SPF work?
Now
that you have the big picture behind SPF, let’s dive in and understand
the more technical details. Most email services provide simple SPF
configuration instructions and then handle the hard part for you. So
thankfully, you don't have to understand the inner-workings of SPF to
benefit from it. But knowing a little more about it can come in handy.
Let’s take a look at an SPF policy in action and see how the process unfolds:
The key technical detail with SPF is that it works by looking at the domain of the
Return-Path
value included in the email’s headers. The receiving server extracts
the domain’s SPF record, and then checks if the source email server IP
is approved to send emails for that domain.
Receiving servers
verify SPF by checking a specific TXT DNS entry in your domain, which
includes a list of approved IP addresses. This is one of the key aspects
of SPF. By using DNS, it’s able to build on something that every
website or application already has. That DNS entry includes several
parts which each provide different information to the server.
How do I implement SPF on my domain?
You
do not need to do anything to pass SPF on emails sent through Gigabit
but for most services, implementing SPF only requires a TXT entry in
DNS. That entry consolidates multiple values in a short line of text. If
a provider needs you to add them to your SPF entry, they’ll provide the
full text that you need to copy into your SPF entry. However, as you
accumulate providers and need to add more, it’s important to know that
you only need to take the “include:" portion from their instructions and
insert that into your existing SPF entry.
The most common mistake
when setting up SPF is having multiple SPF TXT entries in your DNS. If
you do, the receiving server won't know which SPF TXT entry is the
definitive entry. This can result in valid servers failing SPF. So
whenever you need to add SPF information for a new service, always make
sure that you don’t have an existing SPF TXT entry first. If you already
have an entry, you’ll only need to add the service to that entry.
You can find a
detailed explanation of SPF record syntax on the OpenSPF site, but we’ll do a quick breakdown of the key elements in an example SPF record entry of
v=spf1 a mx include:spf.mtasv.net include:_spf.createsend.com ~all:
v=spf1 This states which version of SPF is being used.a
This states that if the domain includes an address record (A or AAAA)
for the sender’s address, it will match. So, if the IP address of your A
record is used to send email, it will pass.mx The
short version is that as long as the email originates from an IP
address of the domain’s incoming mail servers, then it’s a match. The
recipient server will check the MX record with the highest priority
first.include: The include statements essentially say to include the values for the SPF records at the specified domain.~all
This specifies that everything else should be a “Soft” fail. That means
that the message should be accepted but tagged as a soft fail, and the
receiving ISP can use that as an additional factor in scoring the
message’s likeliness of being spam. You could replace the ~ with a -
and that would indicate that the message should be rejected. However,
this is more aggressive and is known to create more issues than it
solves (we don’t recommend it).
Each one of these values
give recipient servers important information they can use to make sure a
message is sent from one of your trusted sources. As one of the
earliest attempts to secure email, SPF created a path for future email
security protocols like DKIM and DMARC.
The very best approach to
securing your domain's email is to layer SPF with DKIM and DMARC. Don't
miss our other guides on these protocols to learn more about how they
work together to protect your domain.
Resources
Dive deeper into SPFFAQ
Why doesn’t SPF focus on the From address? It seems like that’s what spammers would want to impersonate.SPF
was designed to protect the envelope sender and it stops spammers from
abusing mail systems with backscatter and other irrelevant traffic. DKIM
protects the
From address by cryptographically signing messages to verify the author.
If I add an SPF record to our DNS, will I be able to see which emails have been blocked?Not always. If you'd like a report on how email from your domain performs against SPF checks, you can setup
DMARC with our free tool to get weekly reports.
Will the sender of the email get a bounce message or does the email just disappear if it fails SPF?It's
really up to the recipient server to decide how they handle messages
that don't align with SPF. Sometimes postmasters choose to bou
