How to protect yourself against email spoofing with SPF, DKIM or DMARC?

Despite all the tools in our possession, such as Slack, e-mail communication has been able to adapt to the major evolutions, and remains first in its category, whether for internal or external communications in companies.

E-mails are routed from one server to another using the SMTP protocol. This protocol was not originally designed to secure the exchange of e-mails between users. Spam therefore quickly appeared as soon as the use of e-mails started to be democratized.

Following this, in the early 2000s, the SPF system was announced and released 6 years later, closely followed by DKIM, which will complement it.

Later, DMARC will be added to solve the problems of the first two.

What is SPF?

The SPF (Sender Policy Framework) is a protocol created in 2006, which consists in the verification of the sender domain name of an e-mail.
This system makes it possible to define which servers are authorized to send an e-mail for a domain name.

Here is an example :

example.com. IN TXT ”v=spf1 ip4:201.57.100.224 -all”

This means that servers with IP address 201.57.100.224 are allowed to send emails as example.com.
The ”-all” means that all emails not coming from 201.57.100.224 are rejected.

What is DKIM ?

DKIM (Domain Keys Identified Mail) is a standard created in 2007 to complete the action of the SPF, allowing the authentication of the domain name sending an e-mail.
This standard also ensures the integrity of an e-mail, thanks to a signature affixed to it.

Consider this example :

1632477194.example._domainkey.example.com. IN TXT (
”v=DKIM1;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5klm13EvCRP”
”OJyH2076Hrdzzlh5opdsR86J46St50WyCcSPJGphl1SpRYCEqX1XmdLPdzOJCF6M”
”mOYwXbGUPuk0UpB0NdhkDGB6W81UX8hFWK4wZIpGBM8quv1X4JsrK0q+MiAqUsYo”
”X2Fk1K0BG9vmLv0jLwIDAQAB’)

In the example above, the public key is embedded in a DNS record.
When an email is sent, it will be signed with the private key.
When it is received, the mail server will query the DNS server which will return the public key.
If this public key corresponds to the signature of the e-mail, it will be considered as legitimate.

What are the limits of these policies?

SPF and DKIM can be bypassed in a fairly simple way.
When an email is sent, it contains two fields indicating the sender:

• MailFrom/ReturnPath: This field is the one that SPF and DKIM check, but it is not directly visible on the user’s mail client.
• From: This field is the one that will be visible by the user, but it is not checked by the SPF and/or DKIM.

A malicious person can therefore use the ReturnPath with a domain that he owns in order not to be blocked by the SPF or DKIM, and then put the victim’s domain in the From field (which is not analyzed) in order to impersonate him.

Here is an example of an e-mail header :

Return-Path: hello@hacker.org
Received-SPF: pass (domain of hacker.org designates 47.154.85.67 as permitted sender)
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Type: text/html; charset=utf-8
X-Mailer: Microsoft Outlook 16.0
Date: Fri, 24 Sep 2021 15:06:49 +0200
From: xxx@example.com
Reply-To: xxx@example.com
To: yyy@example.com
Subject: Very important message!
Message-Id: 42726176-6f2c-2074-7520-6d276173-2074-726f-7576-e9210a@example.com
Content-Length: 26024

In this example, we can see that hello@hacker.org pretends to be xxx@example.com in his email sent to yyy@example.com, his message will be validated at the SPF level as well as at the DKIM level since he has control over his domain ‘hacker.org’.

What is DMARC ?

DMARC was created precisely to correct the problem of impersonation bypassing SPF and DKIM.

DMARC (Domain-based Message Authentication Reporting and Conformance) is a standard, created in 2012, allowing for SPF and DKIM accuracy
It allows a more thorough analysis of emails that have passed SPF and DKIM by verifying that the identity of the visible sender (From Field) is indeed the same as the one transmitted to the server (MailFrom/ReturnPath Field).
The strength of DMARC is also to offer a visual on identity theft attempts, by providing a report, sent by e-mail to a domain administrator.

Exemple :

_dmarc.example.com IN TXT ”v=DMARC1; p=reject; rua=mailto:postmaster@example.com;”

In this example, the policy applied to illegitimate emails is rejected, which means that emails that do not meet the DMARC validity requirements will be deleted.
There are three applicable policies:

• none: Do nothing, let the e-mail pass anyway.
• quarantine : Notify the e-mail as SPAM.
• reject: Reject the e-mail.

The DMARC report is then sent to: postmaster@example.com.
There are two types of DMARC reports:

• rua: Allows you to generate reports in XML format, they contain the IP addresses being the origin of the emails, the results of SPF, DKIM and DMARC, as well as information about the actions taken by the recipient’s server.
• ruf: Allows you to generate reports of e-mails that have failed the DMARC check, these reports contain examples of e-mails sent (be careful with personal data).
  It is of course possible to request both types of reports by adding the rua and the ruf.

Once all these policies are properly implemented, spoofing becomes more complex.

They remain the strict minimum to be applied in order to limit the risks and even if they are not present from the beginning, it seems necessary to integrate them quickly.

Just because you don’t use a domain name for emailing doesn’t mean that a malicious person can’t impersonate you and send emails with your domain name.