The Art of Email Spoofing Protection

The art of email spoofing protections.

Email is a vital backbone of all businesses in todays fast moving connected world, defined as a protocol it is called ‘Simple Mail Transfer Protocol’ and it’s quite correct in saying that the protocol is quite simple. Email was never designed with security in mind, it was created when networks were small enough that everyone knew each other, and that alone was considered good enough reason to implicitly trust emails from each other, there were no identification checks in place.

However, as time went on networks got larger and larger with the internet becoming a massive global spanning network, and no longer could everyone implicitly trust each other. It was realised that it was possible to in effect ‘lie’ about who sent the email, giving rise to a form of attack known as email spoofing, where an attacker will forge the email headers to say the email is from a person it is not from. This can lead to various scenarios, most commonly where an attacker will forge the identity of someone to use their authorization in order to gain something, for example impersonate a CEO to order someone to wire money to a bank account.

In response to this three protocols have been introduced over time to attempt to mitigate the issue of email spoofing by providing mechanisms to verify that incoming mail is from the domain it claims to be sent from. These three protocols are known as the Sender Framework Policy (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication Reporting & Conformance (DMARC). These protocols will be explained in detail in how they operate, what they mitigate, and how to use them to help protect your own domain from being spoofed.

It’s important to note that there is no complete solution to prevent email spoofing. These protocols rely on the mail provider of the victim adhering to the usage of these protocols which cannot be guaranteed. However, the majority of mailbox providers will support these protocols and consequently deploying all three protocols will help to mitigate a vast majority of email spoofing attacks.

Sender Framework Policy (SPF)

The Sender Framework Policy works by providing a list of IP addresses that are authorized to send email on behalf of the domain. This IP list is stored in the DNS records of the domain as a TXT record. Email providers that have SPF implemented will lookup the DNS records of the domain from where the email is claiming to be from and if it finds an SPF record in the DNS it will then compare the SPF record’s authorized IP addresses to that of the originating IP address of the email. If these IP’s match then the email will pass the test, otherwise it will fail the test. What then happens to the email will depend on the fail states of the SPF implantation by the email provider, it may be marked as spam, or even rejected from the inbox. The following figure demonstrates SPF in action:

Image Source: https://itzap.com.au/prodimages/sender-policy-framework-explained.jpg

How to setup SPF

To setup SPF a TXT record is added to the DNS records of the domain sending the emails. The TXT record to be added is known as an SPF record and will define the parameters of SPF such as what IP addresses are valid senders for the domain. This SPF record can be created from scratch or by using online tools, below examples of the two are linked:

SPF from scratch: https://www.openspf.org/SPF_Record_Syntax

SPF from online tool: https://www.spfwizard.net/

Once the SPF record is created place this in the DNS records as a TXT record. To verify that it has correctly been added to the DNS records we can use a tool called DIG against the domain. DIG will lookup the DNS records of the specified domain, this is shown in the following picture where we can see that the SPF record exists in the domain:

Failures of SPF

While SPF does aid in the mitigation of email spoofing, it also has multiple downfalls. Firstly, SPF will only check the ‘envelope from’ of the email for the domain name and its related SPF DNS Record. This is separate to the ‘header from’ field which is the from email address that is visible to the end user in many email clients. This difference allows an attacker to create a spoofed email without failing SPF. Additionally, SPF has multiple fail states, including still permitting SPF failed emails to continue into the inbox of the victim. The settings for these fail states are often controlled directly by the Email Provider, which can cause difficulty in having these settings adjusted and tailored to what the company requires. Overall this makes SPF unreliable to solely use for preventing mail spoofing.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) is a mail protocol that enables the signing of emails in such a way that it is possible to verify who sent the mail through cryptographic signature. Elements of the email will be selected to be converted into a unique signature to the email through the method of hashing. These elements must remain unchanged throughout sending the email otherwise DKIM will fail its check on the receiving end.

Once this DKIM hash is created it is then encrypted with a private key held by the original sender. This encrypted DKIM signature is then sent along with the original email to the receiver. On receiving the email the mailbox provider will lookup the from domain for the public key which will be used to decrypt the DKIM signature into its original hash. The mailbox provider will now hash the selected elements themselves and compare it to the sent DKIM signature hash, if the two matches then it will pass DKIM authentication, proving who claims to have sent the email did send it. Otherwise if the hashes don’t match then the email fails DKIM authentication.

How to setup

To setup DKIM a TXT record is added to the DNS records of the domain sending the emails. This TXT record is known as a DKIM record and defines the parameters required by DKIM to be operational. One of the primary parameter of this record will be the public key of the private/public key required in order to encrypt and decrypt DKIM signatures. As shown in the following figure:

The process of setting up DKIM can be difficult to set up correctly the first time, it requires generating a public and private key pair and correctly placing the public key in your DNS records, and the private key within the email exchange server.

For the exact details on how to setup the record the following guide can be used: https://support.dnsimple.com/articles/dkim-record/

Failures of DKIM

However, DKIM has the same flaws as SPF, in that an attacker can forge the ‘header from’ address of the email which is the from email address that is visible to the end user in many email clients. DKIM will only authenticate the ‘envelope from’ address of the email which is generally hidden from the user. This, just like with SPF, can make DKIM unreliable for solely preventing mail spoofing.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

Domain-based Message Authentication, Reporting & Conformance (DMARC) is the latest mail protocol that combines and improves the SPF and DKIM protocols, while also adding its own checks to resolve known issues with SPF and DKIM.

DMARC verifies that the email is being tested against DKIM and SPF correctly, and that the email is passing these protocol’s respective checks, DMARC also provides a way for organizations to specify what should happen if an email does fail the DKIM, or SPF checks, should the email be marked as spam, rejected, accepted, etc. DMARC also then adds another layer of check in the form of alignment checks which verifies the ‘header from’ domain in SPF matches the ‘envelope from’ domain name used, and that the ‘header from’ domain also matches the DKIM signature ‘d= domain’ header, thus preventing the use of ‘header from’ for email spoofing as has been an issue for SPF and DKIM. This process of alignment is shown in the following figure:

Source: https://www.dmarcanalyzer.com

Lastly the Aggregate reporting, and Forensic reporting features of DMARC provide valuable information and insight to its operations. The aggregate reporting side aids in helping to identify potential issues regarding the protocol, and identifying potential malicious activity, giving a general overlook of the operation of DMARC. The forensic reporting feature builds on this by providing detailed reports regarding specific of DMARC authentication failure. This can alert the company to attempts to spoof the company email address, as well as details about the email trying to spoof the domain, including IP information, time logs, authentication logs, From domain information, subject line, and any URLs included in the email.

How to setup

To setup DMARC there are three requirements that must be completed before enabling DMARC. Firstly, both SPF and DKIM must be enabled and correctly functioning beforehand. Secondly the Envelope FROM, Header FROM, and d=domain fields must all align and have the same domain and/or subdomain in order to pass DMARC’s alignment checks. Lastly two email accounts should be created to receive aggregate and forensic DMARC reports.

Once the aforementioned requirements are completed, setting up DMARC is a relatively simple process. The following link can be used in order to generate DMARC records simply:

DMARC Record Generator: https://mxtoolbox.com/DMARCRecordGenerator.aspx

A great feature of DMARC is that you can set the record up to have a policy of ‘none’ so that forensic and aggregate reports get sent on a DMARC failure, but the emails do not get rejected straight away. This is useful for troubleshooting the setup stages of DMARC, without causing any impact on emails being sent and received. Once the record is correctly setup and only failing the intended emails, then the policy can be upgraded to enact on emails failing DMARC.

Once the DMARC record is created place this in the DNS records as a TXT record. This can be verified in the same way that the SPF records were verified by using DIG against the domain to lookup the DNS records of the specified domain, this is shown in the following picture where we can see that the DMARC record exists in the domain:

Related Posts

Share this post

Subscribe Our Newsletter