In this tutorial, you'll learn what is SPF, configuring SPF properly, the importance of SPF in protecting your email from getting spoofed and how SPF can overall help in improving your email delivery to ensure high inbox rates.
The Sender Policy Framework (SPF) is a set of technical guidelines used to prevent spammers from sending messages on behalf of your domain. You can enable SPF based authentication by adding a specific TXT DNS entry in the domain. In this SPF record, individuals and organizations can authorize a list of mail servers which can send emails using their domain identify.
The definition of SPF says you can use this email-authentication technique to authorize a list of mail servers which can send emails using your domain name. But why you should allow others to send emails on your behalf? Bit confusing. Isn't it?
In the real world, while the organizations own their respective domain names, but not everyone invests in setting up their in-house mail servers to send emails. Instead, organizations rely on third-party email service providers like Pepipost, Sendgrid for sending their transactional and marketing emails, and other corporate emails, they use mailbox providers like Gmail, ZohoMail. In either of the cases, they need to use SPF record to authorize these external mail servers to relay their emails to the internet. Not publishing an SPF record technically means, you are allowing everyone to use your domain to send emails. In such a scenario, email spoofing is possible using your domain name just because of the nature of the SMTP protocol used for sending and receiving emails. SMTP doesn't verify the sender of the email. As long as it's syntactically correct, there is no further validation. A spammer can impersonate your bank, your employer or anyone at all.
You might have seen phishing emails with sender domain as PayPal, Apple or even Microsoft asking you to update your user preference, password or some settings. All these are examples of email spoofing where the actual sender is a spammer and not the organization mentioned as the sender. This problem led to the evolution of SPF as an email-authentication concept.
The receiving mail servers like Gmail, Yahoo or AOL can easily categories these emails as spam because most of these organizations are using SPF record and have published the list of mail servers which are allowed to relay their emails to the internet. In this scenario, the spammer's mail server IP address is not going to be there as a part of the SPF list. Therefore such spoofed emails are bound to fail if the organizations have published the SPF records.
Now that you have the broader idea behind SPF let's understand the working in more technical details. There are multiple variations of SPF proposed by experts in the early 2000s, but the final acceptable policy framework is available on RFC 4408.
The simple workflow of how SPF checking works at the recipient mail server's end:
Implementing SPF on your sender domain is quite easy. Most of the email service provider get this done, either by asking you to add a TXT or CNAME entry into your domain's DNS.
Implementing SPF using a TXT record is the most common way among all email service providers. If you're using multiple vendors or email service providers for sending emails then to enable SPF, you should not be adding multiple TXT record lines for each of these vendors. Instead, one TXT record should be there is your DNS which consolidates multiple SPF entries from different service providers.
e.g. v=spf1 include:pepipost.net include:spf.mandrillapp.com include:_spf.elasticemail.com ~all. This one TXT record enables SPF for three email service providers.
If an email service provider needs you to add them to your SPF entry, then they'll provide you with the full text that needs to copy into your SPF entry. However, as you're using multiple providers in the background, so you should not delete the existing records or add a new record. Instead, you should consolidate each of the current records into one by using the "include:" tag.
Having multiple TXT records representing SPF is an invalid practice to have. This will lead to a situation where even you have added SPF records, but on the actual email delivery, the SPF validation will fail at the ISP's end. You should be cautious while setting up the SPF because, in such a case of SPF failure, the chances of your emails landing in spam also increases. If you're not very sure about your SPF record settings, then connect with your service provider or any good email deliverability consultant to fix the issues at the right time.
If you're using Pepipost you can connect with the 24x7 live chat support to fix any of your SPF or email delivery related queries or read the comprehensive guide on how to get rid of your emails landing in spam.
Steps to add SPF record
While implementing SPF is a good start to ensuring safe delivery of your emails with higher inbox placement rate. Having said that, this is not sufficient. Emails can still be spoofed and flagged suspicious. To overcome that, you should implement SPF with an additional layer of email authentication using DKIM and DMARC.
How to implement SPF using a CNAME record in DNS
If you're adding a CNAME record of Pepipost, you do not need to do anything extra to pass SPF on your emails. Neither you have to do separate settings to enable custom link tracking URLs in your emails.
e.g. in Pepipost, you need to add only one record to enable all types of email authentication and custom links on your emails.:
delivery.yourdomain.com CNAME lnk.pepipost.net
Adding this one record reduces the chances of any misconfiguration and DNS management at your end, which can impact your email delivery. Instead of using the primary domain e.g. yourdomain.com, you should always use a dedicated subdomain of the primary domain for sending marketing emails. Using subdomain has been considered as one of the best email practice to avoid hampering the reputation of your primary sending domain. Choosing the right sending domain and implementing the best email practices is very important to maintain your domain reputation.
If you're running your own mail delivery services like Postfix, then implementing SPF and DKIM on a Postfix server will require more advance level learning of SPF.
Identifying the spoofed emails was the primary objective with which SPF came into existence. However, SPF failed to protect emails from getting spoofed. Years ago when SPF came into existence as an email authentication standard, the email ISPs like Gmail, Yahoo, AOL and email service providers like Pepipost, started validating the SPF record of the Sender domain which is visible to the end recipient.
This move made a compulsion to all the users of Pepipost and other ESPs to start adding a custom SPF record in their domain's DNS to grant ESPs IP to sender emails on their behalf.
But, with the rise in email spam and spoofing issues, the industry started realizing the need for a more secure way of doing email authentication. Over the years, the email ISPs stopped checking the SPF on From field domain. Instead, they started using SPF validation for Return-Path domain. Because of this shift, now your emails sent via email service providers like Pepipost will automatically pass the SPF validation checks as the Return-Path domain is by default owned by the email service provider who is going to maintain the SPF.
If you are sending emails using Pepipost's Return-Path domain, then the recipient of your email will see a string in the header saying this email is "sent via Pepipost". To get rid of that you need to use your own custom Return-Path domain, and this is when you need to add SPF on this Return-Path domain instead of the visible From header domain. People generally add their own custom Return-Path domain to get rid of via string in Gmail or any such ISPs.
As SPF is now limited to Return-Path domain, so it's easy for someone to forge the visible from domain to anything else. So, alone SPF is no longer a fail-proof email-authentication mechanism to fight against email spoofing. But, SPF along with DKIM and DMARC is a fail-proof mechanism which is now becoming the next standard for email-authentication.
SPF is now just one of the many factors that email ISPs like Gmail use to determine whether there are some chances of spoofing or whether they should deliver the email or not.
To stop sender domain forging and to verify the From address, DMARC is the new standard of domain authentication.
As per Microsoft's email delivery guidelines, any emails sent to Outlook.com users should comply with Sender ID authentication using SPF and DKIM guidelines.
SenderID was a version of SPF created by Microsoft and referred to be as "SPF v2". If you see "spf2.0" in a TXT record, then that is a record indicating to SPF v2 specs.
But, somewhere last year in 2019, Microsoft made a couple of changes in the way how they are going to handle email authentication. While they have not announced everything official but research shows that along with SPF and DKIM, they have also started taking DMARC seriously.
Unlike some of the other ISPs who checks SPF record on the Return-Path domain, Microsoft is considering the visible FROM address to validate the SPF record.
As per the research, it shows that Microsoft is enforcing email senders to use a custom envelope or Return-Path domain which is same or a sub-domain of the visible FROM domain. And, along with DMARC, the sender should also do SPF and DKIM on the FROM and the Return-Path domain.
As per RFC 5322, FROM domain is the email address of the actual author of the email which is visible to the end recipient. In the absence of a Reply-To email address, Sender ID is the email address on which your reply will go by default. In any mail client, the most obvious use of the Sender ID is to filter emails by the author.
Hope, this tutorial shared a useful piece of information around SPF, how it works, what are the limitations and how to make your emails more secure. In case if you have some different observations or have any queries, please feel free to share below in comments or write to dx(at)pepipost(dot)com.