Protect your emails thanks to the DNS (SPF, DKIM, DMARC)

In an article published in February 2021, the European Organization for Nuclear Research (CERN) alerted its employees to an email threatening to disclose very private pictures of its recipients. The would-be blackmailer was demanding a sum of money from his potential victims in exchange for deleting the pictures. The email in question seemed to have been sent to contacts from their own CERN email address.

Figure 1: ransomware email apparently sent from a “trusted” email address

In using an email address ending in “cern.ch” the hacker was trying to give the impression that the mailbox and the computer had been well and truly infected. To do so, he used a characteristic allowed by messaging servers; the fact that the sender field can be personalised by anyone at all. By way of example; here’s how it is possible to send an email from an Exchange messaging client that will look as though it has come from a reliable addressee.

Figure 2: possibility of establishing an email value in the “From” field unrelated to the messaging server

For a large-scale scam, this manipulation will be done at the level of the server, which will allow emails to be sent to a large number of addressees.

This possibility offered by messaging servers can cause great difficulties to companies, institutions and other actors anxious to limit the usurpation of their domain names. It is in fact fairly easy to create an email that seems to come from a valid sender when a phishing expedition is really involved. In this case, the victim often instinctively blames the company for not giving sufficient protection. It is, after all, understandable that, in their eyes, the company has allowed the improper use of its domain name; the technical explanation given will not repair the damage caused in terms of brand image.

There is a way to protect against this kind of abuse by preventing the delivery of malicious messages using your domains. The DNS is the way to do this.

Emails and DNS resolution

Figure 3: SPF, DKIM and DMARC verifications when routing an email

To reach its recipient, a messaging server interrogates a DNS server in the form of a DNS request. The response to this request will allow it to know “where” its recipient is and to recover, among other things, its IP address. This is what is referred to as resolution.

The receiving messaging server also makes DNS requests each time it receives an email. It is during this step that the server can filter attempts at usurpation by requiring additional information, which will enable it, for example, to make sure that the IP of the sender’s messaging server is indeed authorised to send emails using your domain information.

This verification relies on three protocols:

• SPF: Sender Policy Framework
• DKIM: DomainKeys Identified Mail
• DMARC: Domain-based Message Authentication, Reporting, and Conformance

SPF protocol - Sender Policy Framework

SPF authentication works by specifying the IP domain addresses authorised to send emails. When configuring the SPF record on your domain name server, you can specify a domain or a list. It is this information that the receiving messaging servers will consult to make sure that the sender’s IP is really authorised to send emails using that domain.

Figure 4: IP and rules associated with the SPF record culture.gouv.fr 

While messages coming from unauthorised IP addresses can be rejected, they can also be marked as suspect or even accepted, depending on the strategy defined on the receiving server.

DKIM protocol - DomainKeys Identified Mail

DKIM provides a mechanism for authenticating email messages with the aid of a cryptographic key. A DKIM signature has to be added to all outgoing emails.

The messaging server receiving the email is responsible for recovering the public key published on the DNS server in order to verify the validity of the signatures.

This DKIM verification confirms that the sender is authorised and that the message has not been altered in transit. If the signature is not valid, or if the domain does not have DKIM record, the transmission of the message will be ‘DKIM failed’ and the message may be rejected depending on the policy defined by the server.

DMARC protocol: Domain-based Message Authentication, Reporting, and Conformance

The SPF protocol provides assurance that the IP address of the sender of the email is indeed authorised by the domain. As well as confirming the sender’s domain, DKIM also provides assurance that the message has not been altered in transit. The third protocol, DMARC, is the one that allows you to reject emails from senders usurping your domain based on the “From” field as per the example given at the beginning of this article.

Figure 5: Functioning of the DMARC protocol

In order for an email to pass the DMARC validation, it must meet both the following conditions:

• It must have passed an SPF or DKIM validation
• The domain used at every step of the verification must match that in the “From” field of the email

If the email fails the DMARC validation, the receiving messaging system applies one of the three options defined in the policy specified in the DMARC record of the sender’s domain:

• “Rejected”: the email is rejected
• “Quarantine”: the email is delivered to its addressee but marked as suspect
• “None”: the email is delivered to its addressee without any special process

The DMARC record may also define a percentage of messages failing validation that will nonetheless be delivered to the addressee but put in quarantine. This liberal approach allowing some or all of the emails failing the DMARC validation to be delivered may be useful if the administrator wishes to collect information on abuse/usurpations and thus improve the policy for combating them.