SPF, DKIM, DMARC and BIMI for Email Security

Phishing attacks have been increasing rapidly year on year, and surged as a result of COVID-19.  Research shows that 96% of phishing attacks are sent by email. A common technique used in these attacks is to impersonate well known or trusted brands to entice users to open links and attachments. One way to achieve this is to “spoof” the email address that is shown to users in their email client. Due to the way email protocols were designed in the 1970s, this can be as trivial as inserting a malicious value into the ‘from’ or ‘reply to’ fields, as email security was not a primary concern. This became problematic during the 1990s and 2000s as it was used to deliver spam and phishing emails.

Starting in 2014, additional email security protocols were added to combat phishing attacks. Provided these are correctly implemented, many spoofed emails should be sent to users’ spam boxes or rejected by mail servers. Unfortunately, many companies fail to implement these features in full. The consequences of this typically result in the following:

• Legitimate emails fail to reach their intended recipient as their mail server blocks the email as possible spam,
• Attackers can send spoofed emails impersonating the company staff.

The following sections will discuss the various security protocols that can be implemented to minimise the success of email spoofing and phishing attacks.

Sender Policy Framework

Sender Policy Framework (SPF) is a DNS TXT record that is added to a domain that tells email recipients which IP addresses or mail servers are authorised to send emails for the domain. Defined in RFC7208, it is designed to prevent mail spoofing as mail servers check that incoming mail really did come from an authorised host.

SPF records may be best understood from an example:

 

domain.com: the domain that this SPF record belongs to. An @ symbol is also commonly used as a representation of the current domain.

14400: Time to Live (TTL) is the time in seconds that must pass before a change to the records takes effect.

TXT indicates the type of record and how it is stored in the DNS (in text format).

v=spf1: specifies that the record in the DNS is an SPF record using version 1.

a: This indicates that the host is authorised to send emails of the domain, here the domain is specified at the start of the record.

include: This mechanism allows the specification of 3^rd party hosts, defined in another SPF record, to be included in the master SPF record. As a result, these hosts are also authorised to send emails from the domain.

ipv4: this serves the same purpose as the include statement but specifies IPV4 addresses and not hostnames.

-all: This mechanism is crucial to a successful SPF record. Using -all signals that only the hosts specified in the record can act as mail servers. If this is configured as +all it will allow any server to be authorised to send emails, thus making the SPF record completely ineffective. Another common setting ~all will allow servers to send but flag suspicious emails.

Domain Keys Identified Mail (DKIM)

Domain Keys Identified Mail (DKIM) is used to authenticate an email being sent. Once configured, senders attach a DKIM-signature to the emails they send. This is a digital signature that is normally not seen by the end user as the validation is completed by mail servers. This is one of the key advantages DKIM has over SPF, as DKIM supports mail forwarding. DKIM ensures that the email body and attachments have not been modified and that the message was sent and authorized by the owner of a domain.

How DKIM works

The sender signs the email using a private key. The protocol adds an encrypted cryptographic value to the header and hash of the message.

The receiving server of the message obtains the DKIM record from the sending domains DNS records. The receiving server then uses the public key contained in the DKIM record to verify the message’s signature, by encrypting the message with the sender’s public key and creating a hash. This hash is then compared with the decrypted sender’s hash. If the hashes match, it means that the message was sent by the address in the return path and has not been altered or modified in transit.

If this DKIM check fails, the message is suspicious and is treated using the receiving server’s process for dealing with these emails.

SPF VS DKIM

SPF records are designed to prevent spoofed emails being sent to recipients. However, it offers no guarantee that a message has not been tampered in transit. DKIM ensures that emails have not been altered in transit, but offers no protection over spoofing of the visible parts of a “from” field (including the email address, display name and domain). As a result, each measure used in isolation offers little protection against spoofing and tampering. Therefore, when used together, sending domains are successfully authenticated and there is verification that the contents of emails have not been modified.

Domain-based Message Authentication Reporting and Conformance (DMARC)

Domain-based Message Authentication Reporting and Conformance (DMARC) is yet another email protocol that involves domain records. DMARC can best be thought of as the rules that specify what should happen to emails that fail SPF or DKIM validation.

How DMARC works

DMARC operates by checking the domain in the “from” field and checks that this is “aligned” with other authenticated domain names specified in SPF and DKIM.

A DMARC txt record is added to the sending domain’s DNS records, using a subdomain label as demonstrated here:

 

v=DMARC1: the version of DMARC to be used.

p: the DMARC policy (see below).

sp:  the DMARC policy for subdomains.

pct: the percentage of bad emails to apply the policy (100 being all suspicious emails). If not specified, the default value is 100%.

rua: the URI to send aggregate reports to.

If a suspicious email is received, i.e. one that has failed SPF or DKIM validation, the recipient email server checks the DMARC policy of the sending domain to determine what to do with the email.

DMARC Policies

DMARC provides 3 options for handling emails that fail validation; quarantine, reject and none. Let’s explore each of these options in further detail:

Quarantine: informs receivers to treat messages that fail DMARC checks as suspicious. Mail receivers can choose to handle these differently, with some flagging messages and others delivering them to a spam folder. Essentially, this allows the receiving domain to choose what to do with the illegitimate email.

Reject: this informs receiving servers to reject messages that fail DMARC. This is the most secure setting, however it may have an impact on valid communications if SPF or DKIM is misconfigured.

None: this informs receiving servers not to act, but still enables a sending domain to receive reports of failed validation. This is often used during the initial implementation to verify that SPF and DKIM records are configured correctly, before a more restrictive setting is applied.

DMARC Aggregate Reports

DMARC sends reports (DMARC Aggregate Reports) to email addresses specified in the sending domain’s DMARC record. These reports are sent periodically and provide useful information on the percentages of emails that are passing and or failing SPF and DKIM checks. This information is most often used for monitoring suspicious activities (such as a sudden high volume of unsuccessful spoofed emails), and to gauge the impact of applying more restrictive DMARC policies.

Brand Identifiers for Message Identification (BIMI)

The Brand Identifiers for Message Identification (BIMI) specification is a relative newcomer, with the Internet Engineering Task Force (IETF) draft published in March 2021. This specification is an emerging security technology, that leverages SPF, DKIM and DMARC. If these three protocols successfully validate an email, then a logo is displayed in mail clients. This helps users to authenticate emails quickly and visually, whilst organisations appreciate the additional brand awareness associated with the prominent display of their brand logos in receiving users’ inboxes.

How does BIMI work?

BIMI requires that companies have a valid DMARC DNS record with a policy of either quarantine or reject. DMARC requires the domain to have either DKIM or SPF records. Both are recommended to provide the protections of each, as described in the sections above.

The logo provided for BIMI is required to be exactly square and in a SVG Tiny 1.2 P/S (Portable Secure) format. This file needs to be hosted publicly, and the URL provided in a DNS TXT record, such as the following:

 

When emails are sent using BIMI, the receiving mail server will complete the DMARC/DKIM authentication and SPF validation. If these tests are successful, the server will look up the BIMI record validation and display the associated logo within the mail client.

To prevent trademark infringement and malicious actors masquerading as a company that has yet to implement BIMI, some email providers require a Verified Mark Certificate (VMC). This digital certificate aims to provide assurance that the trademark and logo are owned by requesters seeking to implement BIMI. Whilst not currently required to implement BIMI, it is expected that more email providers will require VMCs in the future. If a VMC is required, these can be added to the BIMI DNS record using the authority (a= key) to specify the URI of the certificate .PEM file as shown below:

 

 Our thoughts on BIMI

A growing number of email services have adopted and support BIMI. Gmail began displaying verified trademarked logos on emails in July 2021 and Apple announced in June 2022 that IOS 16 and macOS Ventura would support BIMI. As BIMI is an emerging technology it will be interesting to see how well it its adopted and whether BIMI will help reduce spoofed emails.

We believe BIMI is a fantastic technology that could provide substantial benefits to reduce phishing attacks, however the current cost to obtain a VMC is at least $1,000 at the time of writing. Without a drastic reduction in this price, BIMI is unlikely to be adopted globally as small businesses simply cannot justify its implementation.

Recommendations for improving email security

It is important that all safeguards discussed above are implemented to improve security and prevent impersonation or phishing attacks.

Applying a correctly configured SPF record prevents sending unauthorised email from domains. Implementing DKIM will help prevent emails being modified after they are sent. There are several online validators to help ensure configurations of SPF and DKIM are valid.

Configure DMARC to take the correct actions when SPF or DKIM validation fails. If DMARC is being implemented for the first time, we recommend setting the policy to none and monitoring the results before choosing more restrictive actions.

Once SPF, DKIM and DMARC are configured, BIMI is a great addition that can help prevent more advanced phishing attacks and provide brand exposure as a bonus.

If you have any questions about these email security technologies or want to find out how we can help improve your organisation’s cyber security, you can contact our team here.