Aller au contenu

(Cours/TP) Les mecanimes de messagerie - Mise en oeuvre et sécurisation d’une solution mail

Solution : Mailcow + serveur DNS

Objectifs pédagogiques

À l’issue de cet atelier, vous serez capable de :

  • Comprendre l’architecture complète d’une messagerie professionnelle.

  • Comprendre les flux de la messagerie.

  • Administrer un domaine de messagerie.

  • Configurer correctement SMTP et IMAP.

  • Mettre en place SPF, DKIM et DMARC pour sécuriser et assurer la délivérabilité des mails.

  • Tester une messagerie avec des clients réels.

  • Diagnostiquer un problème de délivrabilité (spam, rejet).

Les mécanismes de messagerie sont standards et universels !

Les mécanismes étudiés dans cet atelier sont standards et universels ! Ils s’appliquent aussi bien à Mailcow qu’à Microsoft 365, Google Workspace ou toute autre solution de messagerie professionnelle.

Contexte

Vous intervenez dans un environnement mutualisé.
Un serveur mail centralisé est hébergé sur un VPS dans le Cloud.

Chaque personne est responsable de son sous-domaine de messagerie du domaine labmail.cloud.

Architecture globale

  • VPS Debian (fourni).

  • Mailcow (Postfix, Dovecot, DKIM, Webmail...)

  • Un serveur DNS autoritatif.

  • Clients mail : SOGo / Thunderbird.

Mailcow et serveur DNS autoritatif

Mailcow est une solution de messagerie clé en main basée sur Docker et des composants open-source reconnus. Elle regroupe notamment :

  • Postfix (SMTP / MTA - envoi des mails);

  • Dovecot (IMAP / POP - consultation des mails);

  • DKIM (signature des messages);

  • un webmail (SOGo);

  • des outils de sécurité et d’administration (Redis, Fail2Ban, Rspamd, PHP, Nginx, ACME, ClamAV, MariaDB).

Mailcow est conçue pour des environnements de production.

Un serveur DNS autoritatif est responsable de la publication des zones DNS pour fournir des réponses aux requêtes directement liées à ces zones, notamment :

  • enregistrements MX (réception des mails)

  • enregistrements SPF, DKIM et DMARC

  • enregistrements liés à l’autodiscover

Dans cet atelier, le serveur DNS joue un rôle central : sans DNS correct, aucune messagerie ne peut fonctionner correctement.

Etape 1 - Comprendre le flux de la messagerie

Processus_envoi_et_verification_mails illustration générée par IA

MUA > MSA

Un client mail (ex : Thunderbird) envoie un message à son serveur Mail Submission Agent (MSA).
C’est à ce moment que l’utilisateur s’authentifie (identifiants, chiffrement TLS) et que le mail est accepté pour envoi. Le MSA est souvent assuré par le même logiciel que le MTA, mais le rôle est différent.

Analogie courrier postal

  • Le MUA est la personne qui dépose une lettre au guichet.

  • Le MSA est le guichet de La Poste qui vérifie votre identité avant d’accepter le courrier.

DNS (MX / SPF / DKIM / DMARC)

mail_spf_dkim_dmarc illustration générée par IA

Avant que le mail ne soit accepté par le serveur destinataire, plusieurs vérifications DNS sont effectuées :

  • MX : Où livrer le message ?

  • SPF : Ce serveur est-il autorisé à envoyer des mails pour ce domaine ?

  • DKIM : Le message a-t-il été modifié depuis son envoi ?

  • DMARC : Que faire si SPF et/ou DKIM échouent ?

💡 Ces informations sont publiées dans le DNS et consultées par le serveur de réception.

Analogie courrier postal

Le DNS est l’annuaire officiel qui indique

  • MX : à quelle adresse livrer le courrier

  • SPF : qui a le droit d’envoyer au nom de l’entreprise

  • DKIM : le cachet de cire intact sur l’enveloppe

  • DMARC : les consignes en cas de doute (livrer, mettre de côté, refuser)

💡 Un mail est avant tout une transaction réseau basée sur le DNS.

MTA > MTA

Le transport du message se fait à travers un ou plusieurs serveurs de messagerie appelés
Mail Transfer Agents (MTA) en utilisant le protocole SMTP.

Un mail peut transiter par plusieurs MTA intermédiaires avant d’arriver à destination.

Analogie courrier postal
  • Le courrier passe par plusieurs centres de tri avant d’arriver au bon bureau de poste.

MTA > MDA

Le serveur de réception (MTA final) remet le message à un
Mail Delivery Agent (MDA) chargé de le stocker dans la boîte du destinataire.

C’est ici que le message est physiquement déposé sur le serveur.

Analogie courrier postal
  • Le MDA est le facteur qui met le courrier dans la boîte aux lettres.

MDA > MUA

Enfin, le message devient accessible au destinataire via un client mail
en utilisant IMAP ou POP.

  • IMAP : le mail reste sur le serveur.

  • POP : le mail est rapatrié localement.

Analogie courrier postal
  • Le MUA est la personne qui ouvre sa boîte aux lettres pour lire le courrier.

💡 DNS n’est pas juste une "résolution d’adresse". Il est au coeur de la chaîne de confiance de la messagerie.

💡 SPF, DKIM et DMARC sont consultés avant que le mail ne soit accepté.

💡 Les rôles (MSA, MTA, MDA) peuvent être répartis sur plusieurs serveurs ou assurés par un seul de messagerie, comme c’est souvent le cas en pratique.

Interro !
  • Pourquoi un serveur de messagerie ne peut-il pas fonctionner correctement sans DNS ?

Etape 2 - Mise en oeuvre du domaine de messagerie - Attribution des ressources

Chaque personne reçoit :

  • Un sous-domaine dédié prenom.labmail.cloud.

  • Un accès à l’interface Mailcow et à l’interface du serveur DNS pour sa zone DNS.

  • Chaque personne dispose déjà de son domaine configuré dans Mailcow ainsi que d’un compte administrateur associé.

Etape 3 - Mise en oeuvre du domaine de messagerie - Déclaration du domaine dans Mailcow

Dans l’interface Mailcow, pour le domaine prenom.labmail.cloud :

1) Accédez au menu Courriel > Configuration > Domaines et sélectionnez votre domaine prenom.labmail.cloud ;

2) Consultez les paramètres générés automatiquement en cliquant sur le bouton DNS :

  • les recommandations DNS fournies par Mailcow (MX, SPF, DKIM, DMARC);

  • la clé DKIM du domaine.

👉 Ces informations serviront à configurer correctement la zone DNS du domaine et à garantir la sécurité et la délivrabilité des emails...

Etape 4 - Mise en oeuvre du domaine de messagerie - Configuration des DNS

Dans votre zone prenom.labmail.cloud du serveur DNS, créez les enregistrements suivants :

Enregistrement MX indispensable

Selon les recommandations DNS fournies par Mailcow (cf étape 3), 

prenom.labmail.cloud. MX 10 mailcow.labmail.cloud.

Validation

Vérifiez dans Mailcow que le MX est détecté comme valide (cf étape 3).

💡 Sans MX valide, aucun mail entrant n’est possible.

Interro !
  • A quoi sert la priorité dans un enregistrement MX ?

Etape 5 - Création des boîtes mail

Dans Mailcow, créez les boîtes depuis le menu Courriel > Configuration > Boite de réception > Ajouter une boite de réception :

  • tintin@prenom.labmail.cloud

  • milou@prenom.labmail.cloud

Testez :

  • Envoi d’un mail entre Tintin et Milou.

  • Consultation via SOGo.

👉 Les mails fonctionnent en interne, mais pas encore correctement à l’extérieur...

Interro
  • Quel protocole est utilisé pour l’envoi ? Pour la consultation ?

Etape 6 - Test avec un client de messagerie (Thunderbird)

L’objectif de cette étape est de valider la messagerie du point de vue utilisateur, comme en entreprise,
et de comparer les comportements des protocoles IMAP et POP.

Configuration des comptes dans Thunderbird

Sur un poste client, installez Thunderbird et ajoutez les deux comptes suivants :

Compte 1 - Tintin (IMAP)

  • Adresse mail : tintin@prenom.labmail.cloud
  • Type de compte : IMAP
  • Serveur entrant :
  • Serveur : mailcow.labmail.cloud
  • Port : 993
  • Sécurité : SSL/TLS
  • Serveur sortant (SMTP) :
  • Serveur : mailcow.labmail.cloud
  • Port : 587
  • Sécurité : STARTTLS
  • Authentification requise : oui

Compte 2 - Milou (POP)

  • Adresse mail : milou@prenom.labmail.cloud
  • Type de compte : POP
  • Serveur entrant :
  • Serveur : mailcow.labmail.cloud
  • Port : 995
  • Sécurité : SSL/TLS
  • Serveur sortant (SMTP) :
  • Serveur : mailcow.labmail.cloud
  • Port : 587
  • Sécurité : STARTTLS
  • Authentification requise : oui

Tests à réaliser - Comparaison POP / IMAP

L’objectif de ces tests est d’observer le comportement réel des messages selon le protocole utilisé pour la consultation.

Scénario 1 - Réception avec POP (Milou)

Objectif : observer ce qu’il se passe sur le serveur lorsqu’un mail est relevé en POP.

1) Envoyez un mail depuis Tintin (IMAP) dans Thunderbird vers
milou@prenom.labmail.cloud;

2) Relevez le mail avec le compte Milou (POP) dans Thunderbird;

3) Consultez la boîte mail de Milou depuis SOGo;

4) Supprimez le mail dans la boîte Thunderbird de Milou (POP);

5) Actualisez la boîte mail de Milou dans SOGo.

Observation attendue : Selon la configuration du compte POP dans Thunderbird, le message peut être supprimé du serveur après sa récupération ou conservé sur le serveur. Si l’option Laisser les messages sur le serveur est désactivée, le mail disparait de SOGo après consultation via POP. Si l’option est activée, le mail reste visible sur le serveur et dans SOGo pendant le temps indiqué. Ce paramètre se trouve dans Thunderbird : Paramètres du compte > Paramètres serveur > Laisser les messages sur le serveur.

Scénario 2 - Réception avec IMAP (Tintin)

Objectif : observer la synchronisation complète entre clients.

1) Envoyez un mail depuis Milou (POP) dans Thunderbird vers
tintin@prenom.labmail.cloud;

2) Relevez le mail avec le compte Tintin (IMAP) dans Thunderbird;

3) Consultez la boîte mail de Tintin depuis SOGo;

4) Supprimez le mail dans la boîte Thunderbird de Tintin (IMAP);

5) Actualisez la boîte mail de Tintin dans SOGo;

Observation attendue : La suppression est immédiatement répercutée sur tous les clients.

Question complémentaire - Envoi avec POP

  • Retrouvez-vous le mail envoyé depuis Milou (POP) dans le dossier Éléments envoyés de SOGo Milou ?
Interro

  • Quelle différence fondamentale de fonctionnement observez-vous entre POP et IMAP du point de vue du serveur ?

  • Pourquoi IMAP est-il privilégié en entreprise ?

  • Dans quel cas POP pourrait-il encore être utilisé ?

Tâche pédagogique - Analyse des ports et protocoles

A l’aide de la configuration Thunderbird :

Identifiez : - le protocole utilisé pour l’envoi. - le protocole utilisé pour la réception.

Associez chaque protocole à : - son port. - son mécanisme de sécurité.

Interro
  • Pourquoi SMTP et IMAP/POP utilisent-ils des ports et des mécanismes de sécurité différents ?

Etape 7 - Sécurité et délivrabilité - Test d’envoi vers l’extérieur

Envoyez un mail vers :

  • une adresse Microsoft viacesi.fr.

  • une adresse Google de votre choix.

✋ Mail reçu en spam ou avec un avertissement

Interro
  • Pourquoi les grands fournisseurs ne font-ils pas confiance à votre domaine ?

Etape 8 - Sécurité et délivrabilité - Analyse des en-têtes du mail

mail-headers

Dans le mail reçu, affichez la source du mail pour voir les headers complets et repérez :

  • Authentication-Results

  • spf=

  • dkim=

  • dmarc=

🤔 Le domaine n’est pas encore authentifié.

Interro
  • Pourquoi l’analyse des headers est-elle essentielle pour diagnostiquer un problème mail ?

Etape 8bis - Sécurité et délivrabilité - Diagnostic pédagogique avec LearnDMARC

Bon ok, savoir analyser les headers, c'est la classe ! Mais visualiser la manière dont les serveurs de mails comuniquent grâce au site LeanDMARC c'est vraiment coooool !

  • Allez-y, testez : https://www.learndmarc.com/

Etape 9 - Sécurité et délivrabilité - Mise en oeuvre de SPF

Dans votre zone prenom.labmail.cloud du serveur DNS, ajoutez l'enregistrement TXT suivant :

prenom.labmail.cloud. TXT "v=spf1 ip4:ADRESSE_IP_SERVEUR -all"
Syntaxe SPF

Exemple :

IN TXT "v=spf1 a mx ip4:203.0.113.10 include:mail1.com include:mail2.com -all"

  • v=spf1 : version du protocole SPF.

  • a : autorise l’IP du (des) serveur(s) pointés par l’enregistrement A du domaine à envoyer des mails.

  • mx : autorise les serveurs listés dans les enregistrements MX.

  • ip4:203.0.113.10 : autorise explicitement une adresse IPv4 précise à envoyer des emails pour le domaine.

  • include : mail1.com / include:mail2.com : dit "fais aussi confiance aux serveurs déclarés dans les SPF de ces domaines".

  • ~all : tout le reste est suspect (soft‑fail) : le mail passe mais sera marqué comme potentiellement frauduleux, suivant la politique DMARC. Variante : -all = rejet strict ; ?all = neutre.

  • Testez à nouveau l’envoi externe, visualisez avec LearnDMARC et analysez quand même le header. LearnDMARC n'est peut être pas éternel, le header oui ! ;) Si la validation SPF échoue, vérifiez que votre enregistrement DNS est correcte : dig TXT prenom.labmail.cloud ou nslookup -type=TXT prenom.labmail.cloud

Résultat attendu : spf=pass

Interro

  • Que protège SPF ?

  • Pourquoi SPF seul n’est-il pas suffisant ?

Etape 10 - Sécurité et délivrabilité - Mise en oeuvre de DKIM

1) Copiez la clé DKIM fournie par Mailcow (cf étape 3);

2) Ajoutez la dans votre zone DNS du serveur DNS;

dkim._domainkey.prenom.labmail.cloud TXT v=DKIM1;k=rsa;t=s;s=email;p=LA_CLE

3) Envoyez un nouveau mail;

4) Testez avec LearnDMARC et vérifiez la présence de dkim=pass dans le header.

💡 DKIM garantit l’intégrité du message.

Interro
  • Quelle différence fondamentale existe-t-il entre SPF et DKIM ?

Etape 11 - Sécurité et délivrabilité - Mise en oeuvre de DMARC

Ajoutez :

_dmarc.prenom.labmail.cloud. TXT "v=DMARC1; p=quarantine"
  • Testez à nouveau l’envoi + LearnDMARC + header, z'avez compris là !

💡 Évolution possible : none, quarantine ou reject

Interro
  • Quel est le rôle exact de DMARC dans la chaîne de confiance ?

Etape 12 - Sécurité et délivrabilité - Validation finale

Le mail envoyé vers Gmail / Outlook doit indiquer :

  • spf=pass

  • dkim=pass

  • dmarc=pass

Bonus - Autodiscover

...ou comment éviter que les utilisateurs vous appellent !

Jusqu’ici, vous avez configuré et sécurisé une messagerie fonctionnelle et légitime. En production, cela fonctionne très bien... tant que vous configurez les clients mail.

Mais dans la vraie vie :

  • Les utilisateurs peuvent changer de téléphone...

  • Peuvent connecter leur boite mail sur Outlook, Thunderbird ou autres clients mails (tant que c'est autorisé dans l'entreprise)...

  • Ne connaissent que leur adresse mail et leur mot de passe mais ni IMAP, ni SMTP...

... Et à ce moment-là, le support est sollicité !

L’autodiscover permet aux clients mail de :

  • Détecter automatiquement les serveurs IMAP et SMTP.

  • Appliquer les bons ports et mécanismes de sécurité

  • Réduire les erreurs de configuration utilisateur

💡 L’autodiscover repose exclusivement sur le DNS.

Mailcow intègre déjà les services nécessaires (des fichiers configuration contenant les infos IMAP/SMTP).
Il suffit d’indiquer aux clients où chercher l’information...dans le DNS !

Voici la version modifiée, alignée avec les valeurs réellement fournies par Mailcow :

Configuration Autodiscover / Autoconfig dans le DNS

Dans le serveur DNS, ajoutez les enregistrements recommandés par Mailcow (cf étape 3) pour permettre la configuration automatique des clients mail.

Autodiscover (clients Microsoft et clients génériques)

autodiscover.prenom.labmail.cloud.        CNAME   mailcow.labmail.cloud.
_autodiscover._tcp.prenom.labmail.cloud.  SRV     0 0 443 mailcow.labmail.cloud.

Autoconfig (Thunderbird)

autoconfig.prenom.labmail.cloud.          CNAME   mailcow.labmail.cloud.

Test de l’autodiscover

1) Supprimez le compte tintin@prenom.labmail.cloud de Thunderbird;

2) Ajoutez-le à nouveau;

3) Renseignez uniquement l’adresse mail et le mot de passe;

4) Laissez le client configurer automatiquement le compte.

👏 Les paramètres IMAP et SMTP sont détectés automatiquement. Aucune configuration manuelle n’est nécessaire. Vous venez de gagner du temps et d’éviter quelques tickets !

Interro
  • Pourquoi l’autodiscover est-il souvent considéré comme optionnel alors qu’il a un impact direct sur la charge du support ?