PART 1 – SPF Record
Currently, the three protocols you need to put into place to secure and authorize your email are SPF, DMARC and DKIM. This first post will talk about the easiest to implement, Sender Policy Framework (SPF).
To quote Wikipedia:
(See Sender Policy Framework: https://en.wikipedia.org/wiki/Sender_Policy_Framework) “Sender Policy Framework (SPF) is an email authentication method designed to detect forging sender addresses during the delivery of the email. SPF alone, though, is limited to detecting a forged sender claim in the envelope of the email, which is used when the mail gets bounced. Only in combination with DMARC can it be used to detect the forging of the visible sender in emails (email spoofing), a technique often used in phishing and email spam.
SPF allows the receiving mail server to check during mail delivery that a mail claiming to come from a specific domain is submitted by an IP address authorized by that domain’s administrators. The list of authorized sending hosts and IP addresses for a domain is published in the DNS records for that domain.”
So why is this important to implement? When Simple Mail Transfer Protocol (SMTP – the internet standard communication protocol for electronic mail transmission) was designed, it did not have any built-in security features, encryption or authentication. What this means is that SMTP allows any computer or server to send email that claims to be from anyone you want it to be from – therefore someone can send an email to your customers claiming it came from your email address. This is one of the largest exploits used by spammers and phishing techniques to get people to open an email that they should not.
How to implement? It is as simple as adding a record in your DNS. I will not go into how to specifically add a DNS record as there are too numerous of ways to do so depending on the provider hosting your DNS, but in all cases, it is the same information. You will need to add a new TXT record listing the servers or computers that are authorized to send email for your domain. The computers can be defined by IP address or by FQDN. The SPF record itself needs to incorporate the following:
- Start with the SPF version. In almost all cases, that will be v=spf1
- Follow up with all the IP addresses or FQDN that are authorized to send email for your domain. For example: v=spf1 ip4:X.X.X.X ip6:X.X.X.X.X.X.X.X
- Next, include any third-party organization that is used to send email on your behalf. For instance, if your web site sends email out using a third-party system on your behalf. If you have ever wondered why email going out from your web site or your blog lands in your customers Junk folder, this would be one reason that happens. For example: v=spf1 ip4:X.X.X.X include:thirpartyservice.com
- When you have included all IP addresses and includes, you need to end the record with an ‘all’. The ‘all’ tag is an important part as it indicates what policy should be applied when the receiving end detects a server not listed in your SPF record. Here is the different ‘all’ tags:
-all: Fail – servers that are not listed in the SPF record are not authorized to send email so reject
~all: Softfail – if the email is received from a server that is not listed, the email will be marked as soft fail ending up in the receiving ends ‘Junk’ folder.
+all: SHOULD NOT BE IMPLEMENTED as this tag allows any server to send email from your domain.
Here is a real-world example. Anyone using Microsoft 365 would have this as a basic SPF record in their DNS:
v=spf1 spf.protection.outlook.com -all
If you are signed up for our email security system, you would see:
V=spf1 spf.protection.outlook.com include:scanscope.net -all
As you can see, if a domain publishes a SPF record, spammers and phishers are less likely to be able to forge emails pretending to come from you and are less likely to try. Worst case scenario, those emails should show up in the receivers Junk folder which should be a warning in of itself.