Introduction

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.

FAQs

• What is SPF?
• Why do I need to allow other mail servers to send emails using my domain name?
• Limitations with SPF
• How does SPF work?
• How to implement SPF on your sender domain?
• How important is SPF to deliver emails to Hotmail, Outlook or any of the Microsoft domains?
• What is this SenderID?
• What is FROM Domain?

What is SPF?

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.

Why do I need to allow other mail servers to send emails using my domain name?

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.

How does SPF work?

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:

• You compose a personal email or even a bulk marketing email with FROM address as [email protected]. Here remember you're the owner of yourcompany.com domain.
• The email is processed by your email service provider, e.g. Pepipost.  
• The Pepipost server with IP address 1.2.3.4 sends an email FROM yourcompany.com TO one of the recipients in your list say jenny(at)gmail.com. 
• The gmail.com mail server fetches the TXT DNS records for the FROM domain, i.e. yourcompany.com.
• The gmail.com server looks for the SPF record and tries to find the sender IP address 1.2.3.4 in the SPF record of yourcompany.com.
• The email is accepted or rejected based on the result of the SPF match query.

How to implement SPF on your sender domain?

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.

How to implement SPF using TXT record in 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

1. If you're adding an SPF record for a new email service provider, then first check whether you already have an existing SPF TXT entry in your domain's DNS. If you already have an SPF entry, you'll only need to append the new service provider's SPF record to that entry instead of creating a new one. 
2. Use tools like MXToolbox to check the existing SPF record on your domain:
3. You can refer OpenSPF site for a detailed SPF record syntax. Here's a quick breakdown of the syntax and key parameters for an example SPF record entry of v=spf1 a mx include:pepipost.net include:spf.mandrillapp.com include:_spf.elasticemail.com ~all:

• v=spf1: This specifies the version of SPF used.
• a: This means that if the domain includes A or AAAA record, and if the IP address linked to the A record is used to send emails, it will pass the SPF.
• mx: This means that if the domain has an MX record, then the email sent from an IP address resolving the MX record, i.e. the domain's incoming mail server will be considered as a match and SPF will pass in such a case. If mx is mentioned in SPF record, then this also means that the recipient mail server will check the MX record first with a P0 priority.
• include: The include parameter is used to specify the set of IP addresses or domain which are allowed to send emails. SPF will not pass if emails are sent from any other server which is not associated with the IP addresses or domain mentioned in the include statement. In the above example; include:pepipost.net represents the sending IP address of Pepipost, include:spf.mandrillapp.com represents the sending IP address of Mandrill and include:_spf.elasticemail.com represents the sending IP address of Elasticemail mail servers.
• ~all: This means that all emails sent from servers excluding the ones mentioned in the include a and mx statements, should be accepted by the recipient server but need to be treated as a "Soft" fail. In case of a soft fail, the recipient server might apply additional email scoring factor to understand the intent of content and to tag them as spam or ham. You can also replace the ~ with - and that would give instructions to recipient's mail server to reject any email coming from servers which are not included in this 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.

Limitations with 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.

How important is SPF to deliver emails to Hotmail, Outlook or any of the Microsoft domains?

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.

What is this SenderID?

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.

What is FROM 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.

Conclusion

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.

Other Related Tutorials.

Email spam

Domain reputation

barracuda blacklist

spamhaus blacklist

cbl blacklist