Aller au contenu

(Cours/TP) Les mécanismes 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élivrabilité 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 serveur 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...

💡 Mailcow ne peut pas écrire dans votre zone DNS à votre place : il ne fait que recommander les enregistrements. C'est à vous, administrateur, de les publier sur le serveur DNS. Cette séparation des rôles (serveur de messagerie d'un côté, DNS de l'autre) est exactement celle que vous retrouverez en entreprise.

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.

💡 Concrètement, cet enregistrement dit au monde entier : « pour livrer un mail à quelqu'un de prenom.labmail.cloud, adressez-vous au serveur mailcow.labmail.cloud ». C'est l'adresse de livraison officielle de votre domaine.

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.

« J'ai modifié mon DNS mais rien ne change ! » - le cache et les TTL

Frustration classique de cet atelier (et du métier !) : vous corrigez un enregistrement, mais le test échoue toujours. En cause : le cache DNS. Chaque enregistrement porte un TTL (Time To Live) qui indique aux résolveurs combien de temps ils peuvent mémoriser la réponse sans redemander. Tant que le TTL n'a pas expiré, les serveurs du monde entier continuent de servir l'ancienne valeur.

Deux réflexes de technicien :

  • Interroger directement le serveur autoritatif pour voir la valeur réellement publiée, en court-circuitant tous les caches : dig TXT prenom.labmail.cloud @IP_DU_SERVEUR_DNS

  • Pendant une phase de configuration ou de migration, publier les enregistrements avec un TTL court (ex. 300 s), quitte à le rallonger une fois la configuration stabilisée.

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...

💡 C'est logique : entre Tintin et Milou, le message ne quitte jamais votre serveur, qui se fait confiance à lui-même. Les mécanismes de vérification (SPF, DKIM, DMARC) n'entrent en jeu que lorsqu'un serveur tiers doit décider s'il accepte ou non votre mail.

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.

💡 Pour retenir la différence : POP fonctionne comme un relevé de boîte aux lettres (on emporte le courrier chez soi, la boîte se vide), IMAP comme une consultation au bureau de poste (le courrier reste au bureau, et tout le monde voit le même état, depuis n'importe quel guichet).

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é.

Mémo des ports standards de la messagerie (à consulter après votre analyse !)
Protocole Rôle Port Sécurité
SMTP (MTA ↔ MTA) Transport entre serveurs de messagerie 25 STARTTLS opportuniste
SMTP soumission (MSA) Dépôt d'un mail par le client, avec authentification 587 STARTTLS obligatoire
SMTPS (MSA) Variante du dépôt en TLS implicite 465 SSL/TLS
IMAP / IMAPS Consultation synchronisée sur le serveur 143 / 993 STARTTLS / SSL/TLS
POP3 / POP3S Rapatriement local des messages 110 / 995 STARTTLS / SSL/TLS

💡 Notez la distinction essentielle côté SMTP : le port 25 sert aux échanges entre serveurs (les centres de tri qui se transmettent le courrier), tandis que le port 587 est le guichet de dépôt réservé aux clients authentifiés. C'est d'ailleurs pour lutter contre le spam que la plupart des FAI et hébergeurs bloquent le port 25 sortant des machines grand public.

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

💡 Rien d'anormal : pour l'instant, votre serveur est un parfait inconnu. Du point de vue de Google ou Microsoft, n'importe qui pourrait prétendre envoyer des mails au nom de prenom.labmail.cloud. Tant que le DNS ne prouve pas le contraire, la méfiance est la règle. Les étapes suivantes vont justement construire cette preuve de légitimité.

Et le reverse DNS (PTR) dans tout ça ?

En plus de SPF, DKIM et DMARC, les grands fournisseurs vérifient que l'adresse IP du serveur émetteur possède un enregistrement PTR (reverse DNS) cohérent avec son nom (mailcow.labmail.cloud).

Particularité : c'est le seul enregistrement que vous ne gérez pas dans votre zone DNS. Le PTR appartient à la zone inverse de l'adresse IP, gérée par l'hébergeur du VPS (dans son interface d'administration).

Un PTR absent ou incohérent est l'une des causes les plus fréquentes de classement en spam, même avec SPF, DKIM et DMARC parfaitement configurés. À garder en tête pour vos futurs diagnostics en entreprise !

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=

💡 Les headers sont le carnet de voyage du mail : chaque serveur traversé y ajoute une ligne, et le serveur de destination y consigne le résultat de ses vérifications. C'est la première chose qu'un technicien consulte pour diagnostiquer un problème de messagerie.

🤔 Le domaine n'est pas encore authentifié.

Interro

  • Mise en situation : un comptable reçoit un mail « du directeur » demandant un virement urgent (la fameuse fraude au président). Quels éléments des headers permettraient de démasquer l'usurpation ?

  • Plus généralement, pourquoi l'analyse des headers est-elle le premier réflexe 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 communiquent grâce au site LearnDMARC c'est vraiment coooool !

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

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

💡 SPF (Sender Policy Framework) est la liste des expéditeurs officiels de votre domaine, publiée dans le DNS. Quand un serveur reçoit un mail prétendant venir de prenom.labmail.cloud, il consulte cette liste et vérifie que l'adresse IP de l'expéditeur y figure.

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".

  • Le qualificateur final définit le sort de tous les autres expéditeurs :

    • -all : rejet strict (hard fail), recommandé quand on maîtrise la liste de ses expéditeurs (notre cas ici) ;

    • ~all : soft fail, le mail passe mais est marqué comme suspect, suivant la politique DMARC ;

    • ?all : neutre.

Enveloppe SMTP vs en-tête : deux « expéditeurs » différents !

Subtilité essentielle : un mail comporte deux adresses d'expéditeur. Celle de l'enveloppe SMTP (le MAIL FROM de la transaction entre serveurs) et celle de l'en-tête (le From: affiché à l'utilisateur dans son client mail). Et elles peuvent être différentes !

Reprenons l'analogie postale : l'adresse d'expéditeur écrite sur l'enveloppe n'est pas forcément celle qui signe la lettre à l'intérieur. Le facteur (le serveur) ne regarde que l'enveloppe ; le destinataire ne lit que la lettre.

Or SPF ne vérifie que l'enveloppe (MAIL FROM). Un fraudeur peut donc passer SPF avec une enveloppe honnête à son nom... tout en affichant From: direction@votre-entreprise.fr dans la lettre. C'est précisément cette faille que viendra fermer l'alignement DMARC (étape 11), qui exige que le domaine vérifié corresponde au From: visible., 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 correct : 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 ?

  • Mise en situation : six mois plus tard, l'entreprise souscrit à un service d'envoi de newsletters (Brevo, Mailchimp...). Que se passera-t-il si personne ne modifie l'enregistrement SPF ?

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

💡 Là où SPF vérifie d'où vient le mail, DKIM vérifie que son contenu n'a pas été altéré en route : le serveur émetteur signe chaque message avec sa clé privée, et publie la clé publique dans le DNS pour que les destinataires puissent vérifier la signature. C'est le cachet de cire de notre analogie postale.

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"
Clé DKIM trop longue ?

Une clé RSA 2048 bits dépasse la limite de 255 caractères d'une chaîne TXT. Selon votre serveur DNS, il faudra peut-être découper la valeur en plusieurs chaînes entre guillemets, qui seront concaténées :

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

C'est une cause très fréquente de dkim=fail inexpliqué : la clé publiée est tronquée ou contient des espaces parasites. En cas de doute, comparez le résultat de dig TXT dkim._domainkey.prenom.labmail.cloud avec la clé affichée dans Mailcow.

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

💡 SPF et DKIM font des vérifications, mais aucun des deux ne dit au serveur destinataire quoi faire en cas d'échec. C'est le rôle de DMARC : publier la politique du domaine (ne rien faire, mettre en quarantaine, rejeter) et permettre de recevoir des rapports.

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

Recevoir des rapports DMARC (tag rua)

Ajoutez le tag rua pour recevoir des rapports agrégés envoyés par les serveurs destinataires (Gmail, Outlook...) :

_dmarc.prenom.labmail.cloud. TXT "v=DMARC1; p=quarantine; rua=mailto:postmaster@prenom.labmail.cloud"

Ces rapports listent qui envoie des mails au nom de votre domaine et avec quel résultat SPF/DKIM. C'est grâce à eux que les administrateurs pilotent, en production, le passage progressif de p=none (on observe sans rien bloquer) à p=quarantine puis p=reject : on ne durcit la politique qu'une fois certain de ne pas bloquer un expéditeur légitime oublié (un serveur applicatif, un service de newsletters...).

L'alignement DMARC

DMARC ne se contente pas de vérifier que SPF ou DKIM passent : il vérifie aussi que le domaine validé correspond au domaine affiché dans le champ From: visible par l'utilisateur (c'est ce qu'on appelle l'alignement).

Sans cela, un spammeur pourrait envoyer un mail affichant From: direction@votre-entreprise.fr tout en le signant avec le DKIM parfaitement valide de son propre domaine pirate.com. L'alignement ferme cette porte : c'est ce qui fait de DMARC la vraie protection anti-usurpation d'identité.

Interro

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

  • Pourquoi les bonnes pratiques recommandent-elles de démarrer avec p=none en production, avant de passer à quarantine puis reject ?

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

Le mail envoyé vers Gmail / Outlook doit indiquer :

  • spf=pass

  • dkim=pass

  • dmarc=pass

Vous pouvez aussi valider votre analyse avec un outil comme SenderAudit :

1) Allez sur https://senderaudit.com ;

2) Générez une adresse de test et envoyez un mail ;

3) Analysez le rapport généré et identifiez d'éventuelles erreurs ou recommandations afin d'améliorer votre délivrabilité et votre sécurité.

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 de configuration contenant les infos IMAP/SMTP).
Il suffit d'indiquer aux clients où chercher l'information...dans le DNS !

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 ?

Auto-évaluation - Compétences visées (RNCP36501)

Avant de considérer cet atelier comme acquis, vérifiez que vous savez faire et expliquer chacun des points suivants. Ils correspondent aux compétences du référentiel TSR que vous pouvez être ammener à démontrer devant un jury.

  • [ ] Je sais expliquer le voyage complet d'un mail et le rôle de chaque acteur (MUA, MSA, MTA, MDA)
  • [ ] Je sais installer et configurer un serveur de messagerie et déclarer un domaine (4.1.1)
  • [ ] Je sais créer et administrer des boîtes aux lettres utilisateurs (4.1.2)
  • [ ] Je sais publier les enregistrements DNS d'un domaine de messagerie (MX, SPF, DKIM, DMARC) et expliquer le rôle de chacun
  • [ ] Je sais configurer un client de messagerie (IMAP/POP/SMTP, ports, mécanismes de sécurité) et expliquer la différence POP / IMAP
  • [ ] Je sais diagnostiquer un problème de délivrabilité en analysant les headers d'un mail (Authentication-Results, spf=, dkim=, dmarc=)
  • [ ] Je sais expliquer pourquoi le DNS est au coeur de la chaîne de confiance de la messagerie
  • [ ] Je sais mettre en place l'autodiscover et expliquer son intérêt pour le support