When we talk about security of anything first thing which comes into our minds is to validate the authenticity of the of the object to ensure it is safe before allowing it to our premises. For example, to allow you to any computer or application it wants you to authenticate yourself by providing the credentials. If credentials are not matched the access is denied. Similarly, when we talk about email security, we will have to ensure that the email is authenticated before delivery.
Do not forget to follow our Newsletter for more such articles, latest Job openings and many more Lead with Tech Newsletter
Email Security Protocols -An Introduction
The recipient domain’s email gateway authenticates the emails to ensure if the email was originated from a legitimate source and has not been altered in transit. This method of cross checking is called reverse look up. As emails travel over the internet and they get originated from a specific server or IP, So, we need a system to translate the server names to IP addresses and vice versa. In other words, we take help of DNS records for email authentication. It’s the responsibility of the sender domain to legitimize the emails originating from it. That is, sender domain will have to create some DNS records to ensure the email is marked as safe in the process of authentication by the recipient domain and gets delivered successfully. We generally use TXT and CNAME records for this purpose and protocols we use are called SPF, DKIM and DMARC.
SPF (Sender Policy Framework)
This is a DNS TXT record. A TXT record has the ability to connect the text with a zone. DNS TXT records are used for ownership validation. When we add email resources of the domain with TXT record, we call it SPF TXT record or only SPF record. In other words, the record contains the list of resources used to validate the ownership of the emails sent from the domain. If the email is successfully validated against the resources mentioned in SPF TXT record, SPF passes else it gets failed.
Now the question is how does a SPF record look like and how to write the record. Let’s understand this with examples. The example of an SPF record to allow a domain is as follows,
Example1 – v=spf1 include:xyz.com -all
The example of an SPF record to allow an IP and domain is as follows,
Example2 – v=spf1 include:xyz.com ip4:192.168.1.1 -all
According to above examples, we will have to take care of three points while writing any SPF record
Record type
The first is “v=spf1”. This defines that it’s a DNS TXT record is of SPF type and using SPF version 1.
Authorized Mail Source
In Example1 we have “include:spf.xyz.com” after the space. This means that the domain xyz.com is allowed the send emails on behalf of the domain where this record is published. We can have multiple separations between v=spf1 and -all. All intermediate separations define the details of the resources which are allowed to send emails of the behalf of the domain for which we are publishing the record e.g. in Example 2 we have a domain and an IP. We use “include:” for domains, “ip4:” for IPv4 and “ip6:” for IPv6 addresses. We follow the same format for subnets (also called CIDR – Classless inter domain routing). In case if we want to allow a subnet 192.168.1.1/32 along with domain xyz.com the record will look like as follows
v=spf1 include:xyz.com ip4:192.168.1.1/32 -all
If we add a domain in SPF record then SPF look up will happen for that domain also. Maximum of 10 such look ups are allowed.
Enforcement Rule
Now, lets look at enforcement rules that defines the action part of the record. This means what action to be taken on the email if it is found not to be originated from the resources mentioned in the Mail Source separation. The enforcement rule is of following types;
+all – This means the record publisher domain trusts the mailing resources mentioned in the SPF record and trusts all other resources also. This is not recommended because it has high risks involved.
?all – This means no action is needed if the email is not sent from the resources found in the SPF record. This is also not recommended.
~all – This means we will mark the email if it is found not be sent from the resources found in the SPF record but will not fail SPF, we will let the recipient domain’s internal policies make decision about the mail delivery.
-all – This means SPF should fail if the email is found not be originated from one of the resources mentioned in the record. This is the safest rule to write the record is highly recommended.
Both ~all & -all are recommended. Organizations choose any of two depending on their requirements.
Let’s under this with Example 1 (v=spf1 include:xyz.com -all). The last separation is “-all”. We call it minus all. This means that the record publisher domain has only authorized the emails originated from xyz.com. For Example 2 (v=spf1 include:spf.xyz.com ip4:192.168.1.1 -all) it has only authorized the emails originated from xyz.com and IP 192.168.1.1.
All SPF records have the above separations. Mail source section may have multiple separations. The number of separations is equals to number of sources which are authorized to send emails on behalf of sending domain. All sources are separated by a space. No punctuation is required.
In case if we want to send email from our web server the we will have to add the A record in SPF and SPF will look as follows,
v=spf1 a include:xyz.com -all
In case if we want to send email from our web server as well as from our MX endpoint server then the SPF will look as follows,
v=spf1 a mx include:xyz.com -all
Validate the SPF record
There are several tools in the market to check if the SPF record is correct or not. I generally use Kitterman. The link for Kitterman is as follows,
Kitterman Site to validate SPF
Some other tools are as follows,
MXToolBox
MxToolbox tool can help you generate a SPF Record or modify your current SPF Record as well as to check the modified record has the correct syntax
If you want to modify an existing SPF Record from a domain, please look for the domain in question
Or create one from scratch
Dmarcly
Dmarcly provides a SPF Record Generator to create an SPF record.
How to SPF TXT record in DNS
After validation is done, we will have to publish the record to internet so that it can be used for the emails travelling through internet. We use the following format for publishing it,
The above screenshot is taken from Go Daddy. The look may vary if the name server belongs to a different DNS provider.
Type = TXT means the DNS record is of TXT type.
Host = @ – It means that the record is for the same domain i.e. if the record is being published for the domain xyz.com it will only work if the sender’s domain suffix has @xyz.com, in other no prefix or suffix is allowed with the domain name. In essence, the record is not for subdomains.
TXT Value – This field has the actual SPF record which has passed the validation check.
TTL = 1 Hour – It means maximum time taken to publish any changes in the record is one hour.
Let say we have published this record in the DNS for a domain called abc.com. Now according to first example domain xyz.com has permissions to send email on behalf of the domain abc.com. According to second example the domain xyz.com and IP 192.168.1.1 has permission to send emails on behalf of the domain abc.com
Limitations of SPF
- Auto Forwarding – If auto forwarding is enabled on the recipient’s mailbox to an external email address, then SPF may fail.
- Complex Routing Scenarios – When we have more than one email filtering services in picture then also SPF may fail.
SPF validation – Background Process
When a sender sends an email, the email carries the domain name of the sender with a message header called return-path. The recipient domain uses the domain suffix from return path and does a reverse look up to validate the email. In this process it calls the DNS of sender domain and checks the mail sources defined in SPF. If the originating IP of the email matches with sources found in SPF record, then SPF validation is successful else it gets failed.
Return path is email address where bounce back is sent in case of delivery failure.
If SPF validation is successful then email gets delivered to Inbox. If validation fails, then the action is taken according to the policies of recipient domain’s email gateway.
Conclusion
In essence SPF record authenticates originating IP of an email with domain name of the sender. If the authentication is successful, the SPF passes else it fails. All the above details of this article is to explain different dimensions of it.
What next
To overcome the limitations, we have some other email security protocols like DKIM & DMARC. We also have some features like Enhanced Filtering in case if SPF fails in a complex routing scenario. We will discuss them in detail in the next article.