For many organisations there is a genuine concern that a malicious threat actor will send emails to others, making it seem that the organisation has sent them. This form of attack - known as ‘spoofing’ - is a concern because individuals and organisations the company does business with, will think the emails are genuine.
This makes it easier for criminals to commit fraud by compromising the confidentiality and integrity of the communications. Dealing with the aftermath and reputational harm is both expensive and time consuming.
AN ILLUSTRATIVE EXAMPLE
For example, imagine receiving an email from email@example.com when the actual contact is firstname.lastname@example.org. Spot the difference? Don't worry if took you a while - this is exactly the type of problem that organisations run into all the time.
However, to develop this scenario one step further, imagine now that a malicious actor has pillaged every publicly available information source on the organisation, its staff, operations, supply chain and customer base. All of a sudden, the spoofed email looks and feels even more convincing to the unsuspecting recipient.
WHAT TECHNICAL CONTROLS ARE AVAILABLE TO MITIGATE THIS PROBLEM?
There are a couple of parts to the solution. Let's break them down:
SENDER POLICY FRAMEWORK (SPF)
It is possible for an organisation to draw up a list of mail servers that it uses. These servers are responsible for firing off emails to anyone company employees wish to communicate with. The organisation will publish the address of these mail servers so others can see them. This is known as the ‘SPF’ record. If I receive an email purporting to be from your company, I can use the SPF record to check that the email did actually originate from one of your authorised systems.
DOMAIN KEYS IDENTIFIED MAIL (DKIM)
Without getting embroiled into a discussion of how 'hashing' works or what public cryptography is, DKIM lets you ‘sign’ an email, even ones that you forward. This ‘digital signature’, can prove that the email address was not ‘faked’ or ‘altered’ - the message really did come from this point of origin.
If we can somehow merge SPF and DKIM - these two technologies can prove where emails originate and that the point of origin is one of our legitimate business partners. This is where DMARC steps in. It pulls everything together.
DOMAIN-BASED MESSAGING AUTHENTICATION REPORTING & CONFORMANCE (DMARC)
DMARC will look at the ‘from' bit to see if the address shown by the SPF and the address shown in the DKIM signature match. The diagram illustrates how these addresses are checked.
A recipient’s email system can choose to dump, flag or accept an email that fails this authentication process.
Copies of messages which fail authentication, will be sent to the purported sender organisation. This will help the organisation fix authentication issues and identify malicious threat actors and web sites.
ENCRYPTING THE ENTIRE MESSAGE.
Cryptography can be used to scramble a message so that any unauthorised party between point A and B, is unable to read an intercepted message. Today, this means enforcing TLS 1.2 or TLS 1.3 which are the gold standard of encrypted communication. Other protocols exist, but consult NCSC Guidance for more information on how to configure these settings.
There are a number of open source and commercial tools available which will help an organisation to check the configuration of DMARC, SPF, DKIM and TLS. If errors are detected, they often give advice on how to correct the configurations. NCSC recommend the following tools to assess your email security and anti-spoofing measures.
Finally, if you are a public sector body, or an operator of Critical National Infrastructure (CNI) you may be able to sign up for the NCSC's Mail Check service here. Mail Check helps you to setup and maintain good DMARC, SPF, DKIM and email cryptographic configurations.