# Meilleures pratiques M3AAWG pour l'authentification des emails (2020)

> La liste de contrôle du secteur pour déployer SPF, DKIM, DMARC et ARC : exigences concrètes sur les enregistrements pour les expéditeurs, et ce que l'on attend des intermédiaires et des serveurs de réception.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-l-authentification-des-emails

Que vous envoyiez, transfériez ou receviez des emails, le secteur attend de vous un ensemble précis de mesures d'authentification. Le Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) les expose dans ses *Email Authentication Recommended Best Practices*, une **liste de contrôle d'exigences techniques binaires** (« elles sont mises en œuvre ou elles ne le sont pas ») pour authentifier les emails avec SPF, DKIM, DMARC et ARC.

La liste de contrôle couvre trois catégories d'acteurs : les expéditeurs (émetteurs), les intermédiaires (services de transfert, listes de diffusion) et les serveurs de réception (fournisseurs de messagerie). [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc) explique les notions de base.

SMTP AUTH (les identifiants présentés lors de la soumission d'un message, du MUA ou du MSA vers le MTA) est explicitement hors du périmètre, car il sert un autre objectif.

**Pourquoi c'est important :** les fournisseurs de messagerie évoquent régulièrement un avenir possible du type « **No auth, no entry** » (pas d'authentification, pas d'entrée), dans lequel un message devrait réussir une ou plusieurs vérifications d'authentification pour être seulement envisagé pour la livraison. Ces recommandations visent à établir la confiance dès aujourd'hui, et à satisfaire toute future obligation de ce type. L'objectif est partout de protéger le **domaine organisationnel** de l'en-tête RFC5322.From (le domaine que voit le destinataire). Cela implique de s'appuyer sur **DMARC**, qui protège ce domaine d'une façon que SPF et DKIM seuls ne permettent pas.

## Protocoles couverts

| Protocole | RFC | Rôle en une ligne |
|---|---|---|
| SPF | RFC 7208 | Les propriétaires de domaines publient, dans un enregistrement DNS TXT, les systèmes autorisés à envoyer des emails en leur nom. |
| DKIM | RFC 6376 | Une organisation revendique la responsabilité de la transmission d'un message, d'une façon que le destinataire peut valider. |
| DMARC | RFC 7489 | Une organisation qui émet des messages exprime, au niveau du domaine, ses politiques et ses préférences de validation, de traitement et de rapport. |
| ARC | RFC 8617 | Une chaîne de responsabilité authentifiée qui enregistre chaque intermédiaire et son évaluation d'authentification à chaque saut. Ce n'est pas encore une norme Internet, mais son adoption progresse. |

## Liste de contrôle pour les décideurs

| Acteur | Pratiques recommandées |
|---|---|
| **Expéditeur** | SPF : publier des enregistrements pour les domaines MAIL FROM **et** EHLO, terminer les enregistrements par `~all`, n'autoriser que les adresses IP strictement nécessaires, aligner MAIL FROM avec RFC5322.From lorsque c'est possible, et publier `v=spf1 -all` sur les domaines qui n'envoient pas d'emails. DKIM : signer tous les messages sortants avec un domaine aligné avec RFC5322.From, et suivre les meilleures pratiques de gestion des clés. DMARC : utiliser `p=reject` lorsque c'est possible, et `p=quarantine` sinon. `p=none`, `sp=none` et `pct<100` sont des états transitoires à quitter le plus vite possible. Toujours inclure une balise `rua`. |
| **Intermédiaire** | Mettre en œuvre ARC. Générer des rapports DMARC. |
| **Serveur de réception** | Effectuer les vérifications SPF, DKIM et DMARC. Respecter les politiques DMARC. Un pass DMARC l'emporte sur un verdict SPF fail, sauf lorsque l'enregistrement SPF est `v=spf1 -all`. Envoyer des rapports DMARC. Exploiter les en-têtes ARC des messages reçus. |

## Recommandations pour les expéditeurs

Un expéditeur est le point d'émission des messages : les propriétaires de marques, les fournisseurs de messagerie et les ESP, mais pas les utilisateurs finaux qui s'écrivent de personne à personne.

### SPF

Publiez des enregistrements SPF pour **tout domaine utilisé dans la commande RFC5321.MailFrom (MAIL FROM)** et pour **tout domaine utilisé comme identité SMTP HELO ou EHLO** de n'importe quel serveur d'envoi.

- Assurez-vous que l'enregistrement est valide et respecte les **limites de requêtes DNS de la RFC 7208** (la limite de 10 requêtes DNS).
- Les enregistrements **devraient se terminer par `~all`** (softfail). La section sur les serveurs de réception ci-dessous explique pourquoi `-all` interagit mal avec le transfert avant l'évaluation DMARC.
- N'autorisez **que les adresses IP strictement nécessaires**. Utilisez les plus petits blocs réseau possibles pour les adresses IP qui envoient au nom du domaine.
- Les domaines qui n'envoient pas d'emails devraient publier **`v=spf1 -all`** (comme le recommande le BCP du M³AAWG *Protecting Parked Domains*).
- Les domaines MAIL FROM devraient être **alignés** avec le domaine RFC5322.From lorsque c'est possible.
- Pour plus de détails, voir *M³AAWG Best Practices for Managing SPF Records* (https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf).

### DKIM

Tout système de réputation fondé sur les domaines a besoin d'une méthode fiable pour confirmer l'identité du domaine qui prend la responsabilité d'un message, et **DKIM est la meilleure méthode disponible aujourd'hui**.

- Signez **tous** les messages sortants avec une clé DKIM dont le domaine `d=` **est aligné avec le domaine RFC5322.From**.
- **Les ESP devraient sérieusement envisager de signer aussi avec leur propre domaine**, afin que les serveurs de réception puissent établir une réputation distincte pour chaque domaine.
- **Les ESP devraient utiliser une clé DKIM différente pour chaque client.**
- Signez un ensemble raisonnable de champs d'en-tête, en prenant pour guide la **section 5.4.1 de la RFC 6376**.
- Pour la gestion des clés, le M³AAWG renvoie à :
  - *DKIM Key Rotation Best Common Practices* (révisé en mars 2019 : https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf)
  - *Best Practices for Implementing DKIM To Avoid Key Length Vulnerability* (révisé en juillet 2017 : https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf)

### DMARC

- **Le M³AAWG recommande `p=reject`** pour les domaines qui publient un enregistrement DMARC. Lorsque cela pose des difficultés opérationnelles, utilisez `p=quarantine`.
- **`p=none`, `sp=none` et `pct<100` ne sont que des états transitoires**, et l'objectif est de les quitter le plus vite possible. (Comparez avec le conseil plus progressif de « commencer par `p=none` » dans [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc). Les deux s'accordent sur la destination, une politique contraignante, guidée par les données des rapports.)
- Fixez la politique en mettant en balance le **profil de risque** du domaine face à l'usurpation d'identité et au phishing, actifs ou potentiels, et la perte possible de messages légitimes due à une signature absente ou cassée.
- **Chaque** enregistrement DMARC publié, même avec `p=none`, doit comporter au minimum une **balise `rua`** qui pointe vers une boîte aux lettres pour les rapports agrégés. Sans la possibilité de recevoir et de traiter les rapports, les propriétaires de domaines ne peuvent pas savoir s'ils peuvent passer sans risque à une politique plus stricte, car ils ne peuvent pas vérifier que tous leurs messages légitimes s'authentifient correctement.
- **`ruf` (rapports d'échec) est facultatif.** En raison des préoccupations de vie privée et du caviardage des données personnelles, la plupart des serveurs de réception n'envoient pas de rapports d'échec, et ceux-ci sont peu utiles à la plupart des propriétaires de domaines.
- Ni la boîte `rua` ni la boîte `ruf` ne devraient envoyer de réponses (réponses automatiques) lorsqu'elles reçoivent un rapport.

## Recommandations pour les intermédiaires

Les intermédiaires sont les *Mediators*, *Relays* et *Gateways* de la RFC 5598 : les services de transfert, les listes de diffusion, les serveurs de groupes de discussion, et toute boîte aux lettres configurée pour transférer tous ses messages vers un autre domaine. SPF, DKIM et DMARC sont conçus d'une façon qui fait que les vérifications d'authentification finales **peuvent échouer pour des messages passés par un intermédiaire**, alors que les mêmes messages auraient réussi s'ils avaient été envoyés directement. Le M³AAWG demande aux intermédiaires de réduire ce risque :

- **Modifier le message le moins possible en transit.** L'authentification dépend du contenu des en-têtes et/ou du corps, donc toute modification (parfois inévitable pour les listes de diffusion) doit rester minimale.
- **Réduire le risque d'échec d'authentification.** L'exemple type est une liste de diffusion qui ajoute un en-tête ou un pied de page à chaque message. Elle devrait réécrire l'en-tête From lorsque le domaine de l'auteur publie DMARC :
  1. un membre publie depuis `john.jones@dmarc.domain.tld` ;
  2. le logiciel de liste constate que `dmarc.domain.tld` publie une politique DMARC ;
  3. la liste réécrit le From en, par exemple, `john.jones=40dmarc.domain.tld@list.domain`, ce qui élimine le risque d'échec DMARC.
- **Mettre en œuvre ARC.** ARC enregistre les résultats d'authentification à chaque saut sans modifier le contenu du message, ce qui protège contre les échecs plus loin sur le parcours causés par le passage par l'intermédiaire. Cela suppose que l'intermédiaire effectue lui-même les vérifications SPF, DKIM et DMARC dont les résultats vont dans l'en-tête `ARC-Authentication-Results`.
- **Générer et envoyer des rapports agrégés DMARC.**

## Recommandations pour les serveurs de réception

Les serveurs de réception sont les domaines qui acceptent et stockent les messages de leurs destinataires. Le terme est plus large que « fournisseur de messagerie », car beaucoup d'emails aboutissent à des domaines qui ne sont pas des fournisseurs de messagerie. Ces mécanismes deviendront vraisemblablement de plus en plus nécessaires. Lorsqu'ils dépassent les compétences informatiques d'un petit domaine, le M³AAWG demande aux services d'hébergement cloud vers lesquels ces domaines migrent de les mettre en œuvre.

- **Effectuer les vérifications d'authentification** (SPF, DKIM, DMARC) sur les messages entrants, et utiliser les résultats pour décider de l'acceptation et du filtrage. C'est une meilleure pratique pour protéger les titulaires de boîtes aux lettres contre les emails frauduleux, que le serveur de réception adopte ou non le principe « no auth, no entry ».
- **Respecter les politiques DMARC.** Lorsqu'un domaine publie DMARC (surtout `p=reject`), les destinataires s'attendent à ce que les messages qui réussissent proviennent réellement du domaine de la ligne From. Les dérogations par politique locale devraient être (a) relativement rares et (b) clairement justifiées et documentées dans les champs de dérogation à la politique et de commentaire du rapport agrégé.
- **Un pass DMARC l'emporte sur un verdict SPF fail.** DMARC n'exige qu'un pass aligné de DKIM **ou** de SPF, et les domaines Return-Path ne sont souvent pas alignés avec le domaine From. Un échec SPF (l'enregistrement se termine par `-all` et la vérification échoue) **ne devrait donc pas entraîner de rejet tant que DMARC n'a pas été évalué et n'a pas réussi**.
  - **La seule exception** est `v=spf1 -all`, un enregistrement qui n'autorise aucun usage. Dans ce cas, le serveur de réception (ou l'intermédiaire) peut agir immédiatement sur l'échec SPF.
- **Envoyer des rapports agrégés DMARC.** Les rapports permettent aux propriétaires de domaines de renforcer leur authentification, qu'ils passent ou non à `p=reject`. Sans rapports, ils ne peuvent ni identifier les flux légitimes qui échouent à l'authentification, ni voir les tentatives d'usurpation et les prestataires mal configurés. Plusieurs grands fournisseurs de messagerie ont conclu que l'envoi de rapports agrégés n'entre pas en conflit avec les lois sur la vie privée. Le M³AAWG recommande aux émetteurs de rapports de tenir compte des avis juridiques actuels (par exemple, le rapport de certified-senders.org sur DMARC et le RGPD).
- **Exploiter les en-têtes ARC** : prendre en compte les ensembles d'en-têtes ARC des messages reçus dans le verdict d'authentification final et dans le traitement du message.

## Références citées par le document

RFC : 5598 (architecture de la messagerie Internet), 6376 (DKIM), 7208 (SPF), 7489 (DMARC), 8617 (ARC).

Documents du M³AAWG associés (voir aussi l'[index des documents](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg)) :

| Document | URL |
|---|---|
| Best Practices for Managing SPF Records (2017-08) | https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf |
| DKIM Key Rotation BCP (2019-03) | https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf |
| Best Practices for Implementing DKIM To Avoid Key Length Vulnerability (2017-07) | https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf |
| Protecting Parked Domains BCP (2015-12) | https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf |
| Trust in Email Begins with Authentication (2015) | https://www.m3aawg.org/sites/default/files/document/M3AAWG_Email_Authentication_Update-2015.pdf |
| Report on the Compliance of DMARC with the EU GDPR | https://certified-senders.org/wp-content/uploads/2018/08/Report_DMARC_and_GDPR.pdf |

## Voir aussi

- [DMARC](https://emailmarketing.net/fr/apprendre/authentification/dmarc), sur l'alignement, la syntaxe de l'enregistrement et le passage d'une politique à l'autre
- [Meilleures pratiques M3AAWG pour les expéditeurs](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/meilleures-pratiques-m3aawg-pour-les-expediteurs), sur les exigences de DNS direct, de DNS inverse et de HELO dont dépend SPF, et sur DKIM par client dans les pools d'adresses IP partagées
- [Index des documents M3AAWG](https://emailmarketing.net/fr/apprendre/meilleures-pratiques-du-secteur/index-des-documents-m3aawg)