The protocols that secure email
The email sending protocols SPF, DKIM and DMARC are used to increase the security and authenticity of emails sent over the internet. The use of these protocols allows recipients to have greater confidence in the authenticity of the emails and senders to protect their reputation and the image of their domain.
This article dives into how these protocols work to help recipients understand and verify the authenticity of emails they receive, prevent spam, and prevent important emails from being mistakenly blocked or marked as spam.
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.
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.
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.
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
| ag | Required? | Description and values |
| v | Required | DMARC version. Must be DMARC1. |
| p | Required | Instructs 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. |
| pct | Optional | Specifies 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. |
| rua | Optional | Email 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. |
| ruf | Not supported | Gmail doesn’t support the ruf tag, used to send failure reports. Failure reports are also called forensic reports. |
| sp | Optional | Sets 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. |
| adkim | Optional | Sets 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. |
| aspf | Optional | Sets 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.
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.
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, IETF, Wikipedia, Google Workspace Admin Help
Photo by: Stephen Phillips – Hostreviews.co.uk on Unsplash, Global Cyber Alliance
