Desktop image with email

What are the SPF, DKIM and DMARC protocols

What are the SPF, DKIM and DMARC protocols 700 460 Nicola Lapenta

The protocols that secure email

This article explores the information needed to understand if a mail account is secure and protected by the latest DMARC (Domain-based Message Authentication, Reporting & Conformance) protocol.

Table of contents:

Introduction

The SMTP (Simple Mail Transfer Protocol) email protocol was created in the 80’s with the assumption that all users of the service were reliable, therefore no configuration was implemented to validate the identity of users.

Afterwards, the international organization IETF (Internet Engineering Task Force) in order to avoid computer attacks in which the IP address of the sender is falsified (spoofing) implemented some protocols that work with minimal impact together with SMTP that has now spread as a worldwide standard.

SPF Protocol

The SPF (Sender Policy Framework) security protocol defines which mail servers are allowed to send email for a given domain. Typically these are a company’s own mail servers, but they can also include third-party email services.

It effectively certifies that the sending IP is actually authorized to send the email. It is a protocol used to prevent fraudulent use of a domain name and prevent third parties from pretending to be a legitimate email address; it is particularly effective against phishing attacks.

Image scheme functioning spf
Figure 1 SPF protocol functioning scheme

In Figure 1, the operation scheme is shown. If the receiving e-mail service is not able to confirm the IP address as valid, it will mark the e-mail as spam.

DKIM protocol

The DKIM (Domain Keys Identified Mail) cryptographic security protocol is designed to add a digital signature (not visible to the sender and recipient) to every message sent from a mail server. The purpose of this signature is to allow recipient systems to confirm that the message came from an authenticated domain.

Scheme functioning dkim images
Figure 2 DKIM Protocol Operation Diagram

In this way, the recipient of the email is assured that it was indeed the sender who wrote the email and that it was not altered during transmission. This protocol is particularly effective against “man in the middle” attacks. Figure 2 shows the functioning scheme.

DMARC protocol

DMARC protocol (Domain-based Message Authentication, Reporting & Conformance) is a complex system of validation of e-mail messages developed mainly to counteract email spoofing, an attack technique widely used in spam and phishing.

Based on the previously described SPF and DKIM protocols, it confirms the identity of the sender and ensures that the email comes from a valid source for that domain. It also tells the recipient’s email server what to do with emails that have failed the check. Figure 3 shows the complete working diagram.

Scheme functioning dmarc images
Figure 3 DMARC protocol working scheme

The DMARC protocol makes the email server domain much more secure by combining the SPF and DKIM protocols that individually contain various weaknesses. In fact, its implementation helps to reduce risks for companies by blocking malicious emails before they reach users and discarding and reporting those fraudulent or fake messages that misuse other people’s domains.

Record format

The DMARC record is in the form of a line of plain text. The text is a list of DMARC tags and values, separated by semicolons. Some tags are required and some are optional.

A DMARC policy tells receiving servers what action to take on unauthenticated messages they get from your domain. The action to take is specified with the policy (p) tag when you define your DMARC record. This is an example of a DMARC policy record. The v and p tags must be listed first, other tags can be in any order:

v=DMARC1; p=reject; rua=mailto:postmaster@solarmora.com,
mailto:dmarc@solarmora.com; pct=100; adkim=s; aspf=s

Table 1 lists the tags in the DMARC record with a description of the possible values.

Table 1 Tags in the DMARC record

agRequired?Description and values
vRequiredDMARC version. Must be DMARC1.
pRequiredInstructs the receiving mail server what to do with messages that don’t pass authentication.
none – Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the record.
quarantine –Mark the messages as spam and send it to the recipient’s spam folder. Recipients can review spam messages to identify legitimate messages.
reject –Reject the message. With this option, the receiving server usually sends a bounce message  to the sending server.BIMI note: If your domain uses BIMI, the DMARC p option must be set to quarantine or reject. BIMI doesn’t support DMARC policies with the p option set to none.
pctOptionalSpecifies the percent of unauthenticated messages are subject to the DMARC policy. When you gradually deploy DMARC, you might start with a small percentage of your messages. As more messages from your domain pass authentication with receiving servers, update your record with a higher percentage, until you reach 100 percent.Must be a whole number from 1 to 100. If you don’t use this option in the record, your DMARC policy applies to 100% of messages sent from your domain.BIMI note: If your domain uses BIMI, your DMARC policy must have a pct value of 100. BIMI doesn’t support  DMARC policies with the pct value set to less than 100.
ruaOptionalEmail address to receive reports about DMARC activity for your domain.The email address must include mailto:. For example: mailto:dmarc-reports@solarmora.comTo send the report to more than one email address, separate emails with a comma.This option can potentially result in a high volume of report emails. We don’t recommend using your own email address. Instead, consider using a dedicated mailbox, a group, or a third-party service that specializes in DMARC reports.
rufNot supportedGmail doesn’t support the ruf tag, used to send failure reports. Failure reports are also called forensic reports.
spOptionalSets the policy for messages from subdomains of your primary domain. Use this option if you want to use a different DMARC policy for your subdomains.none – Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the policy .quarantine – Mark the messages as spam and send it to the recipient’s spam folder. Recipients can review spam messages to identify legitimate messages.reject – Reject the message. With this option, the receiving server should send a bounce message  to the sending serverIf you don’t use this option in the record, subdomains inherit the DMARC policy set for the parent domain.
adkimOptionalSets the alignment policy for DKIM, which defines how strictly message information must match DKIM signatures. Learn how alignment works.s – Strict alignment. The sender domain name must exactly match the corresponding d=domainname in the DKIM mail headers.r – Relaxed alignment (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted.
aspfOptionalSets the alignment policy for SPF, which specifies how strictly message information must match SPF signatures. Learn how alignment works.s – Strict alignment. The message From header must exactly match the domain name in the SMTP MAIL FROM commandr – Relaxed alignment (default). Allows partial matches. Any valid subdomain of domain name is accepted.

Real Gmail example

In order to verify whether an email provider correctly handles the described security protocols, two real-world examples from a Gmail email account are used below.

Email verification

In order to verify if the security protocols configurations of a Gmail account have been correctly implemented, it’s enough to visualize the main parameters of the email header. To do this, just click on the 3 dots at the top right of any email and the results of the checks of the three protocols described as shown in Figure 4 will be displayed.

Example gmail verify email image
Figure 4 Example of Gmail header verification

Report verification

The DMARC protocol can require the recipients mail server to provide reports on the origin of the email. If the used email provider allows the configurations, it is possible to receive an email of the complete report in xml format that visualizes all the results of the controls executed.

An example of this report for a Gmail address is shown in figure 5 where the sequence of the checks carried out is displayed. The results of the checks are highlighted in green.

Example of gmail report email image
Figure 5 Example of Gmail report

Conclusions

The configuration of the DMARC protocol helps to protect your business and reputation from fraudulent attacks, and the reporting activity also allows you to monitor the legitimate use of your domain.

Given the criticality of the reliability of email communications, it is of fundamental importance to ensure that it is configured correctly to allow reliable and timely verification of the identity of the sender.

To obtain this result, it is necessary to ask your email provider to activate the necessary protocols and verify the correct configuration. If you want to know more about this topic, book a phone appointment in the contacts section, I will help you to secure all email communications of your business.

Autor: Nicola Lapenta

Credits: Global Cyber Alliance, IETFWikipedia, Google Workspace Admin Help

Photo by: Stephen Phillips – Hostreviews.co.uk on Unsplash, Global Cyber Alliance