L’e-mail : comment il fonctionne, d’où il vient, où il va

Plus de 50 ans et toujours l’outil le plus important du monde des affaires : comment un e-mail trouve son chemin, pourquoi les falsifications étaient si faciles et ce qui change actuellement.

Architecture et rôles

MUA → MSA (soumission 587/465) → MTA → résolution MX dans le DNS → MTA du destinataire (25, STARTTLS) → MDA → IMAP 993 vers le MUA — MUA, MSA, MTA, MDA : les rôles dans le système de messagerie.

Rôle	Tâche	Protocole / port
MUA (Mail User Agent)	programme de messagerie, webmail, application	soumission 587 (STARTTLS) ou 465 (TLS implicite, RFC 8314)
MSA / MTA	acceptation authentifiée, relais entre serveurs	SMTP 25, STARTTLS opportuniste (RFC 3207)
MDA	dépôt dans la boîte, filtres (p. ex. Sieve)	local, LMTP
Accès	lecture et synchronisation	IMAP 993 (IMAP4rev2, RFC 9051), POP3 995, JMAP (RFC 8620/8621)

Remise : le MTA expéditeur résout l’enregistrement MX du domaine destinataire (repli sur A/AAAA en l’absence de MX ; un « null MX » selon la RFC 7505 déclare qu’un domaine ne reçoit pas de courrier) et essaie les serveurs par ordre de priorité. Les erreurs temporaires (4xx) entraînent des nouvelles tentatives pendant des heures ou des jours, les erreurs permanentes (5xx) un avis de non-remise.

Enveloppe et en-tête : deux expéditeurs

SMTP sépare l’enveloppe (MAIL FROM, aussi Return-Path ou RFC5321.MailFrom) de l’en-tête du message (From:, RFC5322.From). L’humain ne voit que l’en-tête. C’est précisément cette lacune qu’exploitent les falsifications, et c’est là qu’intervient l’alignement de DMARC.

S: 220 mx.example.ch ESMTP
C: EHLO mail.eam.ch
S: 250-STARTTLS
C: STARTTLS
   … poignée de main TLS …
C: MAIL FROM:<bounce@eam.ch>
C: RCPT TO:<client@example.ch>
C: DATA
   From: eam.ch <noreply@eam.ch>
   Subject: …

Histoire et normes

1971 Ray Tomlinson, BBN : courrier entre ordinateurs sur l’ARPANET, séparateur @.
1982 RFC 821 (SMTP) et RFC 822 (format des messages).
1984/1988 POP (RFC 918), IMAP (Mark Crispin, 1986 ; IMAP2 RFC 1064, 1988).
1992/1996 MIME (RFC 1341, aujourd’hui RFC 2045–2049) : pièces jointes, jeux de caractères, messages en plusieurs parties.
1995 ESMTP (RFC 1869) : extensions telles que SIZE, 8BITMIME, plus tard AUTH.
1999/2002 STARTTLS pour SMTP (RFC 2487, aujourd’hui RFC 3207).
2008 Les RFC 5321/5322 remplacent les RFC 2821/2822 (norme SMTP actuelle).
2006–2015 SPF (RFC 4408 → 7208, 2014), DKIM (RFC 4871 → 6376, 2011), DMARC (RFC 7489, 2015, informative).
2012 Adresses internationalisées (SMTPUTF8, RFC 6531).
2015–2019 DANE pour SMTP (RFC 7672), MTA-STS (RFC 8461) et TLS-RPT (RFC 8460, toutes deux 2018), ARC (RFC 8617, expérimentale).
2018 RFC 8314 : TLS implicite recommandé pour la soumission et l’accès (465, 993, 995).
2021 IMAP4rev2 (RFC 9051).
2024/2025 Google et Yahoo (dès février 2024) ainsi que Microsoft pour Outlook.com, Hotmail et Live (dès le 5 mai 2025, plus de 5000 e-mails par jour) : SPF, DKIM et DMARC sont obligatoires, sinon refus.
2026 DMARCbis sur la voie des normes : RFC 9989 (protocole), 9990 (rapports agrégés), 9991 (rapports d’échec) ; la RFC 7489 est remplacée.

L’authentification en détail

SPF vérifie l’IP par rapport à l’expéditeur de l’enveloppe, DKIM la signature avec le domaine d= et le sélecteur s=, DMARC exige l’alignement avec l’en-tête From — SPF et DKIM fournissent le résultat, DMARC le relie à l’expéditeur visible.

SPF (RFC 7208)

Enregistrement TXT sur le domaine de l’enveloppe, p. ex. v=spf1 mx include:spf.protection.outlook.com -all. Limites : au maximum 10 requêtes DNS (include, a, mx, redirect …), les transferts cassent SPF, et SPF ne vérifie pas l’expéditeur visible.

DKIM (RFC 6376)

Signature sur des champs d’en-tête choisis et le corps ; la clé publique est publiée sous <sélecteur>._domainkey.<domaine>. Recommandé : RSA 2048 bits (ou en plus Ed25519, RFC 8463), changement régulier des clés, signer From plusieurs fois (oversigning).

DMARC (RFC 7489 et RFC 9989)

_dmarc.example.ch. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.ch; adkim=s; aspf=s"

DMARC est réussi si SPF ou DKIM réussit et correspond au domaine de From: (alignement, relaxed ou strict).
Politique p=none (rapports seulement), quarantine, reject ; sp= pour les sous-domaines.
DMARCbis (RFC 9989) : pct, rf et ri sont historiques ; nouveaux : t=y (mode test, un niveau en dessous), np= pour les sous-domaines inexistants, psd= pour les domaines de suffixe public ; le domaine organisationnel est déterminé par un « tree walk » DNS (au plus huit requêtes) au lieu de la Public Suffix List.
Les rapports agrégés (rua) montrent qui envoie au nom du domaine – la base pour aller vers p=reject.

ARC et transferts

Les listes de diffusion et les transferts modifient les messages ou l’enveloppe. ARC (RFC 8617) consigne les résultats d’authentification en chemin, afin que des intermédiaires de confiance puissent expliquer les échecs DMARC.

Chiffrement du transport

Méthode	Effet	Prérequis
STARTTLS (opportuniste)	chiffré si les deux parties le supportent ; un attaquant sur le réseau peut le supprimer (downgrade)	certificat sur le MX
MTA-STS (RFC 8461)	les expéditeurs exigent un certificat valide et TLS ; politique via HTTPS sous `mta-sts.<domaine>`	TXT `_mta-sts`, fichier de politique, certificats valides
DANE (RFC 7672)	certificat épinglé via un enregistrement TLSA dans le DNS	DNSSEC pour le domaine et le MX
TLS-RPT (RFC 8460)	rapports quotidiens sur les remises chiffrées échouées	TXT `_smtp._tls`

État actuel (2026)

Les grands fournisseurs de messagerie imposent SPF, DKIM, DMARC (au moins p=none, alignement), des enregistrements PTR valides, TLS et – pour les envois en masse – la désinscription en un clic (RFC 8058) ainsi que de faibles taux de plaintes pour spam.
La part des domaines en p=reject augmente, mais reste faible, surtout chez les PME et les administrations.
La soumission via le port 465 (TLS implicite) s’impose ; le port 25 est bloqué pour les terminaux chez de nombreux fournisseurs.
Le chiffrement de bout en bout (S/MIME, OpenPGP) reste une niche ; les contenus confidentiels passent souvent par des portails.
La compromission de messagerie d’entreprise (BEC) et le phishing restent, dans de nombreux rapports de situation, parmi les vecteurs d’attaque les plus fréquents ; les expéditeurs falsifiés et les domaines similaires (typosquatting) y jouent un rôle central.

Évolutions

DMARCbis dans la pratique : tree walk, np=, t= ; les analyses et outils doivent suivre.
Cryptographie post-quantique : les accords de clés hybrides (p. ex. X25519MLKEM768) sont arrivés dans les bibliothèques TLS et s’imposeront aussi entre serveurs de messagerie ; des signatures résistantes au quantique sont discutées pour DKIM.
Chiffrement de transport imposé avec MTA-STS ou DANE au lieu du STARTTLS opportuniste.
BIMI (logo de marque pour les expéditeurs vérifiés, avec certificat VMC/CMC) comme incitation à p=quarantine/reject.
JMAP, protocole d’accès moderne basé sur JSON, à côté d’IMAP.
L’IA des deux côtés : de meilleurs filtres, mais aussi des e-mails de phishing d’apparence authentique sans fautes – l’authentification technique devient une obligation.

Ce que vérifie eam.ch

SPF (présent, trop permissif, erreurs), DMARC (présent, politique, adresse de rapport), DKIM (sélecteurs courants).
MX : STARTTLS et certificat ; MTA-STS et TLS-RPT ; domaines sans messagerie non protégés contre la falsification.
Domaines similaires pouvant envoyer des e-mails (domaines contrefaits) et serveurs de messagerie sur des listes de blocage (réputation).

Sources : RFC 821, 822, 1341, 2045, 3207, 5321, 5322, 6376, 6531, 7208, 7489, 7505, 7672, 8058, 8314, 8460, 8461, 8463, 8617, 8620, 8621, 9051, 9989–9991 (rfc-editor.org) ; Microsoft Tech Community, « Strengthening Email Security: Outlook’s New Requirements for High-Volume Senders » (2025) ; Google, « Email sender guidelines » (2024).

En bref

L’e-mail voyage en trois étapes : envoi (SMTP), transmission entre serveurs (SMTP via l’enregistrement MX) et relève (IMAP).
Les expéditeurs peuvent être falsifiés, car SMTP ne les vérifie pas.
SPF, DKIM et DMARC rendent les e-mails vérifiables ; seul p=reject protège efficacement.
Depuis 2024/2025, Google, Yahoo et Microsoft exigent ces enregistrements ; en 2026, DMARCbis paraît comme nouvelle norme.
MTA-STS et DANE imposent une remise chiffrée.