Although it is increasingly encrypted during its transport and sometimes itself, email is not designed to be very secure. Spam, phishing and spoofing are thus still its daily life, our daily life. Fortunately, there are solutions... that you should be able to use.
Did you know that anyone can send an email from any address they want? It is very easy to send an email with [email protected] as the sender from any computer connected to the Internet. All you need is access to an in-house SMTP server, or one that doesn't look too carefully. The origin of many problems.
Secure emailing has been a problem for years
SMTP is one of those old protocols from the early days of the Internet. It hasn't evolved much since then, except to specify its implementation of TLS encryption... in 2018. For him, the sender's address (from) is just a text field among others, not requiring any specific authentication or verification.
And even so: an SMTP server (or Mail Transfer Agent, MTA) can use any sender address. Setting up such a security only allows a service to protect itself against malicious actions of its users. Thus, when you connect with your Google account to the Gmail SMTP, it is to protect itself that the company decides that "[email protected]" will necessarily be used as a sender address.
But since anyone can send emails from their own MTA, how can they be sure that they have the right to send an email for such and such a domain, that this information is reliable, that the message or its headers have not been modified during transport? This, without having to replace a software brick such as SMTP, created nearly 40 years ago, at the basis of many tools and services, used on a daily basis and with multiple implementations.
It is not the cryptographic signature of emails that can help here. Because, even if it were massively used (which is not the case), it would only allow to certify that a message has not been modified and has been sent by a user holding a private key. No assurance that he is the owner of a domain or an email address.
Fortunately, solutions have been found in the form of acronyms, partly based on good old DNS: SPF, DKIM, (DM)ARC and BIMI. Never heard of them? You are not the only one...
SPF: who can do what?
SPF was defined about fifteen years ago to provide a first solution to the fight against identity theft (spoofing). It is therefore most often implemented by hosting and service providers. Nevertheless, it is necessary to check that this is the case and that the stated rule corresponds to what you want.
The Sender Policy Framework (SPF) allows you to declare which servers can send emails for each of your domains and what to do in case of an error. Thus, when a user receives an email from one of your domains in the sender's address, his MTA will be able to easily verify that it comes from an authorized server and will have an indication of what to do if it does not. However, the MTA is still in control of the decision (more on this later).
SPF takes the form of a DNS record of type TXT, readable with a simple dig or nslookup command. For example, for Stéphane Bortzmeyer's domain, who analyzed the RFC 7208 detailing the procedure :
nslookup -type=txt bortzmeyer.fr
We obtain the following result:
text = "v=spf1 mx -all"
It means that all the servers indicated in the DNS records of type MX of the domain (those used for receiving emails) can send emails. All others must be rejected, a choice symbolized by the "-". It is done among four possibilities, called qualifiers. They are presented as follows by Google:
Validated (nothing or +): If the e-mail comes from a server that corresponds to a mechanism with the "+" qualifier (or without qualifier), it is validated. The recipient must accept the email.
Fail (-): If the email comes from a server that matches a mechanism with the "-" qualifier, it is failed. The recipient must reject the e-mail.
Partial failure (~): If the email comes from a server that matches a mechanism with the "~" qualifier, it is validated, but considered suspicious.
Neutral (?): Mechanisms with the "?" qualifier have no impact on the validation of the email.
Some domains return a response with a different version indicator, like here :
v=spf2.0/pra
It corresponds to the Sender ID standard, once defended by Microsoft, but since fallen into disuse.
DKIM: cryptography to the rescue
SPF is a DNS record indicating a list of servers considered compliant. But how do you ensure that the message is also compliant? This is the role of DomainKeys Identified Mail (DKIM).
As its name suggests, it is a domain authentication mechanism that uses asymmetric encryption. It is not a replacement for SPF, but rather a complement, accompanying every outgoing message with a digital signature (in its header), generated from a pair of public/private keys linked to the domain.
This not only verifies that the message has been sent from the advertised sender's domain, but also that it has not been altered in transit. A welcome double assurance. In addition to SPF, DKIM should enable MTAs to determine whether a message should be considered spam or not.
But it is almost never exposed to the user, as few email clients display the SPF or DKIM status of a received message. Google has been doing this in Gmail for a few years. There is also a Thunderbird extension that is not well known for this. Third party services also exist like Mail Tester or MX Toolbox. You can finally look at the headers of emails if your client allows it.
(DM)ARC: what to do with e-mails received but misidentified?
(DM)ARC: what to do with e-mails received but misidentified?
You now know how to indicate that a server is authorized to send emails from your domain, how to add a digital signature in the header of your messages to verify their recipient and ensure that they have not been modified. But when you receive emails, how do you take these signals into account?
That's the role of the Domain-based Message Authentication, Reporting and Conformance (DMARC) protocol, which tells you what to do when an email fails the SPF and DKIM tests. Or when the domains of the two tests are not "aligned" (identical or subdomains of each other). You then have three options:
- Reject
- Do nothing (none)
- Consider as suspect (quarantine)
Note: in the case of the none policy, it will be specified that the email did not pass the test, but no action is requested. Suspicion also does not lead to any systematic action, everything will depend on the MTA of the recipient and its spam filter. The only case where the sentence is direct, almost irrevocable: rejection.
The distribution of this policy again takes the form of a DNS record of type TXT. This time, it corresponds to the sub-domain _dmarc. of the domain concerned. For example, in the case of Microsoft's email service :
nslookup -type=txt _dmarc.outlook.com
We obtain the following result:
"v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"
As for SPF, we have first a version indicator (DMARC1), then another mandatory parameter (p). The others are optional, detailed in point 6.3 of RFC 7489. For those present above :
- p: policy to follow for the main domain
- sp : policy to follow for the sub-domains
- pct : percentage of emails concerned by DMARC analysis (100 by default)
- rua : address to send DMARC aggregated reports to
- ruf : address to send individual error reports to
- fo : DMARC report configuration
Note the possibility to receive reports, which can be interesting to know who is exploiting your domain in an unwanted way. Even if you have an open policy (none), this is an interesting feature to act in case of abuse.
However, unlike SPF, the precision of a policy via DMARC is still too rare. It can be a problem. The case of AOL/Yahoo is one of the best known: in 2014, the company decided overnight to indicate that all emails deemed non-compliant should be rejected. A choice that has not changed since:
"v=DMARC1; p=reject; pct=100; rua=mailto:[email protected];"
This can disturb many services that received emails from AOL/Yahoo users, SPF and DKIM being imperfect solutions. Especially in case of redirection or transmission via a mailing list, which can return a negative result for SPF (modified sender) or DKIM (modified message). These are legitimate cases.
The Authenticated Received Chain (ARC) was designed to address these problems. When a message passes through different servers and intermediaries, it preserves the result of the original DKIM and SPF tests, while building up a chain of trust across the servers. The recipient's MTA will receive all the information, and can choose whether or not to consider the intermediate server(s) as a trusted third party.
To do so, it will have to rely on three header elements added to each "hop" and numbered (variable "i"):
- ARC-Authentication-Results: the ARC/DMARC, DKIM and SPF status upon receipt of the message
- ARC-Message-Signature: a signature of the message when it is sent
- ARC-Seal : a signature of ARC headers along the chain
Regarding its support, we find ourselves in the same situation as DKIM: it will depend mainly on the configuration of the mail server and therefore on your configuration or your provider. We can only hope that the majority of users will adopt it quickly (more than for DKIM...).
