The aim of this post is not to make the umpteenth comparison of email providers.
That’s always subjective, depending on our needs.
The aim here is to study compliance with sending standards from a technical point of view.
Personally, I couldn’t find any comparisons, so to choose my future provider, I went on a provider tour.
And I was quite surprised…
A few notions
While chatting, I realize that many people don’t know that anyone can send an e-mail from any address, to anyone.
Fortunately, standards have appeared to try and limit this Far West: SPF, DKIM…
I won’t go into the details, but a minimum is necessary to understand the rest.
SPF
SPF is a protocol for determining which servers are authorized to send e-mail for your domain.
You publish an SPF record in your domain’s DNS, and this record lists the IP addresses authorized to send e-mail on your behalf.
This is not intended to certify that the e-mail is coming from you, but just to reduce the attack surface.
An e-mail sent from a non-listed IP will not respect this protocol and may be blocked (see DMARC).
Nevertheless, an attacker using the same provider will be able to send an e-mail without any problem.
Many providers include a verification step to avoid exploiting this, but by no means all. For example, Gandi doesn’t consider this to be a gaping security hole (I reported this problem 10 years ago), especially as they don’t also check DKIM…
DKIM
DKIM adds a digital signature to your emails to guarantee origin and non-modification during transit.
As with SPF, this is done via DNS.
The aim is not to prevent sending, but rather to authenticate the sender.
It doesn’t replace SPF, but it does complement it.
This method is not infallible. It’s in the e-mail that we specify the identifier of the key used, which may be another key that you generally use, for example from another domain name, or a sub-domain that you don’t control via a CNAME.
DMARC
The purpose of DMARC is to define e-mail management policy according to the results of SPF and DKIM.
For a change, this is also done via DNS (we’ll see how important this is later).
By default, the servers do nothing in the event of SPF or DKIM rejection. We can then indicate whether we want to quarantine or reject them.
Note that this is only an indication, as the server may well overload these rules and be more restrictive, for example.
The problem here is that if one of the two works, then the DMARC policy is ok. Which is perhaps problematic.
However, if you monitor this (and I advise you to do so), you’ll see that DKIM can fail, for example, due to DNS unavailability (of the sender or receiver). What’s more, some old (but not marginal) servers reroute e-mails by adding data, causing the signature to be invalidated.
Nevertheless, it’s still highly advisable to have a strict rejection policy.
And I insist on the monitoring aspect. All too often, I come across people who use service providers who don’t respect anything and don’t realize the rejection rate of their mail.
If you think you have zero rejection, you’re not monitoring 😞.
BIMI
A little often forgotten, but also important.
It is, however, more expensive to set up.
The aim is to allow a logo to be displayed next to the e-mail recipient. To allow for this, it’s a bit like DKIM, but with identity verification by an authority.
So it’s harder to fake.
Alignment
At first, the servers didn’t check the correspondence between the sender’s domain name and the domain used for the DKIM parameters.
So I could send a domain-a.com mail (which I don’t control) with a domain-b.com key (which I do control).
As a result, DKIM was well respected…
So the notion of alignment appeared with two modes:
- Strict: it must match exactly
- Lax: tolerance with sub-domains
With DKIM, I think it’s pretty clear how alignment is applied.
With SPF, it’s more complicated. The used address to control is the address used by the mail envelope.
By example:
Received-SPF: pass
(sender.fr: Sender is authorized to use 'bounce+aaaaaa@sender.fr' in 'mfrom' identity (mechanism 'include:superprovider.com' matched))
receiver=destinatiare.com;
identity=mailfrom;
envelope-from="bounce+aaaaaa@sender.fr";
helo=m32-11.superprovider.com;
client-ip=1.1.1.1
Received: from m32-11.superprovider.com (m32-11.superprovider.com [1.1.1.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by destinatiare.com (Postfix) with ESMTPS id AAAAAAAAAA
for <user@destinataire.fr>; Fri, 3 May 2024 08:56:32 -0400 (EDT)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=sender.fr; q=dns/txt; s=mailo; t=1714740990; x=1714748190;
h=Content-Type: MIME-Version: To: To: Reply-To: From: From: Subject: Subject: Date: Message-ID: Sender: Sender;
bh=AAAAAAA=;
b=AAAAAAAA==
Received: from server (1.1.1.1) by
aaaaaa with SMTP id aaaaaaa (version=TLS1.2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 03 May 2024 12:56:30 GMT
Sender: noreply@sender.fr
Message-ID: <aaaaaaaaa@server>
Date: Fri, 03 May 2024 12:56:30 +0000
Subject: BLAblaBLA
From: noreply@sender.fr
To: user@destinataire.fr
MIME-Version: 1.0
We can see that the envelope was sent with the address bounce+aaaaaa@sender.fr, and the SPF and DKIM follow the domain sender.fr.
So all’s well.
Note that the envelope doesn’t use the Sender or From address. Providers use a special address to handle bounces, i.e. when mail is rejected.
And here we come to the heart of the problem.
Many providers simply use an address with their domain name and thus break the alignment.
Tests
List of providers I’ve tested:
- mailerlite
- getresponse
- mailjet
- mailgun
- brevo
- mailchimp
- fastmail
- scaleway
- sarbacane
I know there are plenty of other providers, but my time is limited. Nevertheless, you can notify me if your beloved provider isn’t present, but I make no promises. I should also point out that I limit myself to European providers, with a few exceptions for legacy reasons in the use of my company.
As this article is already too long, I’ll stop here and divide it into several parts. I’ll then draw up a summary table.