Messagerie : SMTP, IMAP, MX, SPF, DKIM et DMARC

La messagerie électronique repose sur deux familles de protocoles : SMTP pour envoyer et transporter les courriels de serveur en serveur, IMAP (ou POP3) pour les lire dans sa boîte. Le DNS y tient un rôle central : l'enregistrement MX dit où livrer les courriels d'un domaine, et trois enregistrements TXT, SPF, DKIM et DMARC, permettent au destinataire de vérifier qu'un courriel vient bien du domaine qu'il affiche. Ce chapitre suit le trajet d'un courriel, détaille ports et protocoles, explique SPF, DKIM et DMARC avec les exigences actuelles des grandes messageries, et configure un relais Postfix pour les notifications internes.

Les acteurs d'un courriel

Le trajet d'un courriel

Julie Lefèvre, comptable chez Sorbier, écrit à un transporteur partenaire, contact@transporteur.example. La messagerie de Sorbier est hébergée chez un prestataire, sur le serveur mail.sorbier.example (198.51.100.25).

1. Soumission. L'Outlook de Julie (MUA) envoie le message au service de soumission de mail.sorbier.example, sur le port 587 avec STARTTLS (ou 465 en TLS direct), en s'authentifiant avec le compte de Julie.
2. Recherche du destinataire. Le serveur de Sorbier, devenu MTA, demande au DNS l'enregistrement MX de transporteur.example.
3. Le DNS répond : mx.transporteur.example, préférence 10.
4. Transport. Le serveur de Sorbier ouvre une connexion SMTP sur le port 25 du serveur du transporteur, chiffrée par STARTTLS si les deux serveurs le proposent, et lui transmet le message.
5. Vérifications. Le serveur du transporteur contrôle l'expéditeur : SPF (l'adresse qui lui parle a-t-elle le droit d'envoyer pour sorbier.example ?), DKIM (la signature du message est-elle valide ?), DMARC (que veut le propriétaire du domaine en cas d'échec ?). Il passe aussi le message à l'antispam et à l'antivirus.
6. Remise. Le MDA range le message dans la boîte du destinataire.
7. Lecture. Le destinataire le lit en IMAP sur le port 993.

Les protocoles et leurs ports

IMAP ou POP3 ? IMAP laisse les messages sur le serveur et synchronise les dossiers entre tous les appareils de l'utilisateur : c'est le choix normal aujourd'hui. POP3 télécharge les messages sur un seul appareil ; il ne survit que dans de vieilles configurations. Les messageries d'entreprise hébergées utilisent souvent leurs propres protocoles (Exchange, API web) en plus d'IMAP.

Le dialogue SMTP, l'enveloppe et l'en-tête

SMTP est un protocole texte. Voici un échange entre deux serveurs, simplifié (S: le serveur qui reçoit, C: celui qui envoie) :

S: 220 mx.transporteur.example ESMTP
C: EHLO mail.sorbier.example
S: 250-mx.transporteur.example
S: 250-STARTTLS
S: 250 SIZE 52428800
C: STARTTLS
S: 220 Ready to start TLS
   (la suite est chiffrée ; le client renvoie EHLO)
C: MAIL FROM:<julie.lefevre@sorbier.example>
S: 250 OK
C: RCPT TO:<contact@transporteur.example>
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Julie Lefèvre <julie.lefevre@sorbier.example>
C: To: contact@transporteur.example
C: Subject: Livraison du 4 novembre
C:
C: Bonjour, ...
C: .
S: 250 OK queued as 4F2A1
C: QUIT

Deux « expéditeurs » apparaissent, et la différence compte pour la sécurité :

• l'enveloppe (MAIL FROM, appelée aussi Return-Path) sert au transport et aux messages d'erreur ; l'utilisateur ne la voit pas ;
• l'en-tête From: est l'adresse affichée par le logiciel du destinataire.

Rien, dans SMTP, n'oblige les deux à être cohérents, ni à être vrais : un escroc peut écrire n'importe quel From:. C'est exactement le problème que DMARC résout.

SPF : qui a le droit d'envoyer pour le domaine

SPF (Sender Policy Framework, RFC 7208) est un enregistrement TXT, à l'apex du domaine, qui liste les serveurs autorisés à envoyer des courriels pour ce domaine. Le serveur qui reçoit vérifie si l'adresse IP qui lui parle figure dans la liste du domaine de l'enveloppe (MAIL FROM).

sorbier.example.  IN TXT  "v=spf1 mx include:_spf.emailing.example -all"

Un domaine qui n'envoie jamais de courriel (un domaine racheté pour protéger une marque) se protège avec "v=spf1 -all" : personne n'a le droit d'envoyer pour lui.

DKIM : une signature dans chaque message

DKIM (DomainKeys Identified Mail, RFC 6376) signe chaque message sortant avec une clé privée du serveur d'envoi. La signature, placée dans l'en-tête DKIM-Signature, porte sur le corps et sur les principaux en-têtes (From, Subject, Date…). Le destinataire récupère la clé publique dans le DNS et vérifie la signature : le message vient bien d'un serveur qui détient la clé du domaine, et il n'a pas été modifié en route.

L'en-tête de signature indique où chercher la clé :

DKIM-Signature: v=1; a=rsa-sha256; d=sorbier.example; s=2026a; ...

d= est le domaine signataire, s= le sélecteur, un nom libre qui permet d'avoir plusieurs clés (une par prestataire, ou une nouvelle à chaque changement). La clé publique est publiée sous le nom <sélecteur>._domainkey.<domaine> :

2026a._domainkey.sorbier.example.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

(la valeur p= est tronquée ici ; une clé RSA de 2 048 bits fait près de 400 caractères). C'est l'hébergeur de la messagerie qui génère la paire de clés et te donne l'enregistrement à publier. Change de clé régulièrement (une fois par an, par exemple) : publie le nouveau sélecteur, bascule la signature, puis retire l'ancien.

DMARC : la politique du domaine et l'alignement

SPF vérifie l'enveloppe, DKIM le domaine d= de la signature. Aucun des deux ne vérifie l'adresse affichée au destinataire. Un escroc peut donc envoyer depuis son propre domaine (SPF et DKIM valides pour son domaine) tout en affichant From: comptabilite@sorbier.example.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 9989, qui remplace depuis 2026 la RFC 7489) comble ce trou par l'alignement : le message ne passe DMARC que si SPF ou DKIM réussit pour le domaine du From: affiché. Il publie aussi la politique à appliquer en cas d'échec et une adresse pour recevoir des rapports.

_dmarc.sorbier.example.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@sorbier.example; adkim=r; aspf=r"

La démarche se fait par étapes : publier p=none, lire les rapports pendant quelques semaines pour découvrir tous les services qui envoient au nom du domaine (le logiciel de facturation, l'outil de lettres d'information, le copieur), les autoriser dans SPF ou leur faire signer DKIM, puis passer à quarantine, et enfin à reject.

Les exigences des grandes messageries

Les grands services de messagerie ont transformé ces bonnes pratiques en conditions d'acceptation.

Même en dessous de ces seuils, Gmail demande à tous les expéditeurs au moins SPF ou DKIM, un PTR cohérent pour l'adresse d'envoi et des connexions chiffrées. Une PME comme Sorbier n'envoie pas 5 000 messages par jour, mais ses factures et ses notifications doivent arriver : publier les trois enregistrements est aujourd'hui le minimum.

Lire le résultat des vérifications

Le serveur destinataire écrit le résultat de ses contrôles dans l'en-tête Authentication-Results du message. Dans Outlook, il se lit dans les propriétés du message ; dans Gmail, avec Afficher l'original.

Authentication-Results: mx.transporteur.example;
    spf=pass smtp.mailfrom=sorbier.example;
    dkim=pass header.d=sorbier.example header.s=2026a;
    dmarc=pass header.from=sorbier.example

Les valeurs possibles : pass, fail, softfail (SPF ~all), neutral, none (pas d'enregistrement), temperror (DNS injoignable), permerror (enregistrement invalide). L'analyse des en-têtes d'un courriel d'hameçonnage, étape par étape, est un exercice classique de l'E7 (cours Réponse à incident).

Le relais des notifications internes avec Postfix

Les applications et les appareils de Sorbier envoient des courriels : les notifications de GLPI, les alertes de la supervision, les copieurs qui numérisent vers une adresse. Ils ne doivent pas parler directement à Internet (le port 25 est bloqué en sortie). Ils déposent leurs messages sur un relais interne, Postfix sur srv-intranet, qui les transmet au serveur de messagerie de l'hébergeur en s'authentifiant sur le port 587.

sudo apt install postfix libsasl2-modules
# À la question du type de configuration, choisir « Système satellite » ; on règle le reste ci-dessous

Dans /etc/postfix/main.cf, les lignes utiles :

myhostname = srv-intranet.ad.sorbier.example
myorigin = sorbier.example
inet_interfaces = all
mydestination =
mynetworks = 127.0.0.0/8, 192.168.10.176/28, 192.168.10.116/30
relayhost = [mail.sorbier.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

# Le compte de service, lisible par root seulement
echo "[mail.sorbier.example]:587 notifications@sorbier.example:MotDePasseLong" | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd

sudo postfix check                      # vérifier la configuration
sudo systemctl reload postfix
postconf -n                             # les paramètres modifiés
mailq                                   # la file d'attente
journalctl -u postfix@- -f              # les journaux, en direct

Sous Debian 13, les journaux de Postfix sont dans le journal système (journalctl -u postfix@- : l'unité postfix.service ne fait que lancer l'instance postfix@-.service, qui tourne vraiment) ; le fichier /var/log/mail.log n'existe que si rsyslog est installé.

Exercices