Protocoles email : SMTP, IMAP, POP3

Les emails utilisent plusieurs protocoles : SMTP pour l'envoi, IMAP ou POP3 pour la réception. Pour éviter que vos emails arrivent en spam, vous devez configurer SPF, DKIM et DMARC. Ce guide vous explique l'architecture email complète, les ports à utiliser, et comment diagnostiquer les problèmes de délivrabilité courants.

TL;DR, L'essentiel en 30 secondes

Quatre repères suffisent à comprendre 90 % des incidents de messagerie que vous rencontrerez : le protocole utilisé pour chaque sens de circulation, l'enregistrement DNS qui désigne le serveur de réception, les trois mécanismes d'authentification qui décident si votre message atterrit en boîte de réception ou en spam, et le blocage du port 25 qui explique la moitié des envois qui ne partent jamais.

• SMTP (port 587) = envoi d'emails, IMAP (port 993) = réception synchronisée
• MX = enregistrement DNS qui indique le serveur mail d'un domaine
• SPF/DKIM/DMARC = mécanismes anti-spam (vérifiez-les si vos mails arrivent en spam)
• Port 25 souvent bloqué par les FAI pour éviter le spam

Je sais que c'est bon si...

Ces trois points forment le seuil d'entrée du reste du guide. Le premier prouve que le domaine sait recevoir, le deuxième qu'il déclare qui a le droit d'émettre en son nom, le troisième que vous distinguez les deux usages de SMTP. Tant que l'un des trois résiste, les sections sur DKIM et DMARC seront difficiles à suivre.

• dig MX domaine.com +short retourne des serveurs mail
• dig TXT domaine.com montre un enregistrement SPF (v=spf1...)
• Je sais que 587 = submission (avec auth), 25 = relay entre serveurs

Commandes minimales à retenir

Ces trois commandes sont non destructives : elles interrogent le DNS public et ouvrent une connexion en lecture, sans rien envoyer. Vous pouvez donc les lancer contre n'importe quel domaine, y compris ceux de vos fournisseurs, pour comparer une configuration saine à la vôtre. La troisième s'arrête après le handshake TLS ; tapez QUIT pour rendre la main.

# 1. Trouver le serveur mail d'un domaine
dig MX gmail.com +short

# 2. Vérifier l'enregistrement SPF
dig TXT gmail.com +short | grep spf

# 3. Tester la connexion SMTP (port 587)
openssl s_client -starttls smtp -connect smtp.gmail.com:587

Port 25 souvent bloqué

La plupart des FAI et hébergeurs bloquent le port 25 sortant pour éviter le spam. Si vous devez envoyer des emails depuis votre serveur :

• Utilisez un relais SMTP (SendGrid, Mailgun, SES)
• Ou demandez le déblocage du port à votre hébergeur

Ce que vous allez apprendre

• Distinguer SMTP, IMAP et POP3 : qui envoie, qui reçoit, et comment.
• Lire les enregistrements DNS de messagerie : MX, SPF, DKIM, DMARC.
• Authentifier vos emails pour ne pas finir en spam (exigences Google et Yahoo depuis 2024).
• Choisir les bons ports et le bon chiffrement (STARTTLS contre TLS implicite).
• Diagnostiquer la délivrabilité avec dig, openssl et les en-têtes d'authentification.

Prérequis

• Connaissances de base en DNS (enregistrements TXT, MX)
• Un terminal avec dig ou nslookup
• Optionnel : telnet ou nc pour tester SMTP

Pourquoi comprendre l'email ?

En DevOps, vous configurez souvent des serveurs qui envoient des emails (alertes, notifications, mails transactionnels). Comprendre l'architecture email vous permet de diagnostiquer pourquoi vos emails arrivent en spam ou ne partent pas du tout.

Architecture email : les acteurs

Un email traverse plusieurs composants avant d'arriver à destination. Comprendre cette chaîne est essentiel pour diagnostiquer les problèmes.

Les composants

Ces quatre sigles reviennent dans tous les journaux de messagerie et dans la documentation de Postfix comme de Dovecot. Retenez surtout la frontière entre le MSA et le MTA : le premier accepte du courrier d'un client authentifié sur le port 587, le second échange avec d'autres serveurs sur le port 25. Confondre les deux, c'est configurer un relais ouvert que les spammeurs trouveront en quelques heures. Le MDA n'apparaît que du côté réception : il écrit le message dans la boîte, et c'est lui qui applique les règles de tri et les quotas.

Composant	Nom complet	Rôle	Exemple
MUA	Mail User Agent	Client email de l'utilisateur	Thunderbird, Gmail, Outlook
MTA	Mail Transfer Agent	Serveur qui transfère les emails	Postfix, Sendmail, Exchange
MDA	Mail Delivery Agent	Stocke l'email dans la boîte	Dovecot, Cyrus
MSA	Mail Submission Agent	Reçoit les emails du MUA	Souvent intégré au MTA

Glissez pour voir

Le parcours d'un email

Suivez ces six étapes en gardant en tête une question : où le message est-il stocké à cet instant ? Entre l'étape 2 et l'étape 5, il vit dans une file d'attente sur un serveur, pas chez vous et pas chez le destinataire. C'est ce qui explique qu'un message puisse mettre plusieurs heures à arriver sans qu'aucune erreur ne remonte : le MTA destinataire a répondu 450 et l'émetteur réessaie. Notez aussi le changement de protocole à l'étape 6 : tout ce qui précède est du SMTP, la consultation relève d'IMAP ou de POP3.

1. Rédaction

   L'utilisateur écrit son email dans son MUA (Thunderbird, Gmail...).

2. Soumission (SMTP)

   Le MUA envoie l'email au serveur SMTP de l'expéditeur (port 587).

3. Routage (SMTP)

   Le MTA de l'expéditeur consulte le DNS (enregistrement MX) pour trouver le serveur de destination.

4. Transfert (SMTP)

   L'email est transmis au MTA du destinataire (port 25).

5. Livraison locale

   Le MTA transmet l'email au MDA qui le stocke dans la boîte aux lettres.

6. Consultation (IMAP/POP3)

   Le destinataire récupère l'email avec son MUA via IMAP ou POP3.

SMTP : le protocole d'envoi

SMTP (Simple Mail Transfer Protocol) est le protocole utilisé pour envoyer des emails. Il fonctionne en mode texte, avec une série de commandes simples.

Les ports SMTP

La colonne qui décide, c'est Authentification. Un port qui exige une authentification est un port de soumission, réservé à vos applications et à vos clients de messagerie ; un port qui n'en exige pas est un port de relais entre serveurs, où l'autorisation se joue sur l'adresse IP et les enregistrements DNS. Quand vous configurez une application, la seule question à vous poser est donc « ai-je un identifiant et un mot de passe ? ». Si oui, c'est 587 ou 465, jamais 25.

Port	Usage	Chiffrement	Authentification
25	MTA → MTA (relay)	STARTTLS optionnel	Non requise
587	Client → serveur (submission)	STARTTLS requis	Requise
465	Client → serveur (submissions)	TLS implicite	Requise

Glissez pour voir

Submission (587/465) vs Relay (25)

Port 25 = communication entre serveurs mail (MTA↔MTA). Votre application n'a pas à l'utiliser.

Port 587 (submission) = votre application ou MUA envoie au serveur SMTP avec authentification. C'est le port recommandé (RFC 6409).

Port 465 (submissions) = même usage que 587, mais avec TLS dès la connexion (pas de STARTTLS). Re-standardisé par RFC 8314.

Cette répartition a une conséquence directe sur l'hébergement : puisque le port 25 sortant est filtré par la plupart des fournisseurs d'accès et des hébergeurs cloud, un serveur de messagerie autohébergé ne peut pas livrer directement chez les grands opérateurs. Il faut alors passer par un relais SMTP joignable en 587, ou obtenir du fournisseur une levée du filtrage, généralement soumise à justification.

Le dialogue SMTP

SMTP est un protocole texte ligne à ligne, ce qui le rend lisible et testable à la main. Dans l'échange ci-dessous, regardez d'abord la réponse 250-AUTH LOGIN PLAIN : c'est elle qui vous dit quelles méthodes d'authentification le serveur accepte. Ensuite, notez que MAIL FROM: et le From: situé après DATA sont deux adresses distinctes ; la première est l'enveloppe utilisée pour les rebonds et évaluée par SPF, la seconde est celle qu'affiche le client de messagerie. Toute la logique de DMARC repose sur cet écart. Enfin, la ligne contenant un point seul termine le corps du message.

Client: EHLO mail.example.com
Serveur: 250-smtp.destinataire.com Hello
         250-SIZE 52428800
         250 AUTH LOGIN PLAIN

Client: MAIL FROM:<expediteur@example.com>
Serveur: 250 OK

Client: RCPT TO:<destinataire@autre.com>
Serveur: 250 OK

Client: DATA
Serveur: 354 Start mail input

Client: Subject: Test
        From: expediteur@example.com
        To: destinataire@autre.com

        Ceci est le contenu de l'email.
        .
Serveur: 250 OK: queued

Client: QUIT
Serveur: 221 Bye

Tester SMTP

Trois tests, du plus rapide au plus complet. Le premier répond à « le port est-il joignable ? », le deuxième à « le chiffrement négocié fonctionne-t-il ? », le troisième à « le serveur chiffre-t-il dès la connexion ? ». Faites-les dans cet ordre : inutile de déboguer un certificat si le paquet TCP n'arrive même pas.

Vérifier que le port répond (bannière uniquement)

Ce test coûte une seconde et élimine d'emblée la cause la plus fréquente, un filtrage réseau. Avec -z, nc ferme la connexion sans envoyer de données ; il valide donc la traversée du pare-feu, pas le service derrière. Avec telnet, vous voyez en plus la bannière que le serveur annonce, ce qui confirme qu'un vrai service SMTP écoute et pas un équipement intermédiaire.

nc -zv smtp.example.com 587
# ou
telnet smtp.example.com 587

Réponse attendue : 220 smtp.example.com ESMTP. Un Connection timed out désigne un filtrage, un Connection refused désigne un service arrêté : les deux causes n'ont pas le même correctif.

nc/telnet ne valide pas TLS

nc et telnet permettent de vérifier que le port répond, mais pas que STARTTLS fonctionne. Pour un diagnostic complet, utilisez openssl.

Tester STARTTLS (port 587)

openssl s_client -starttls smtp -connect smtp.example.com:587

Vous verrez le certificat du serveur et pourrez taper des commandes SMTP après le handshake TLS.

Tester TLS implicite (port 465)

openssl s_client -connect smtp.example.com:465

La connexion TLS s'établit immédiatement, sans commande STARTTLS.

IMAP vs POP3 : les protocoles de réception

Pour récupérer vos emails, deux protocoles existent : IMAP et POP3.

La ligne qui commande toutes les autres est Stockage. IMAP laisse les messages sur le serveur et n'y télécharge que ce que vous consultez, POP3 les rapatrie puis, par défaut, les efface du serveur. Le comportement multi-appareils, la gestion des dossiers et la consommation de bande passante découlent mécaniquement de ce choix, ce ne sont pas des fonctionnalités indépendantes.

Aspect	IMAP	POP3
Port standard	143 (993 avec TLS)	110 (995 avec TLS)
Stockage	Emails sur le serveur	Emails téléchargés localement
Multi-appareils	Synchronisé	Problématique
Dossiers	Gérés sur le serveur	Locaux uniquement
Hors ligne	Partiel (cache)	Complet (téléchargé)
Bande passante	Plus élevée	Plus faible

Glissez pour voir

Préférez IMAP

IMAP est le choix moderne pour la plupart des usages. Il permet de consulter vos emails sur plusieurs appareils (téléphone, PC, webmail) avec une synchronisation parfaite. POP3 reste utile si vous voulez archiver localement et avez une connexion limitée.

Vérifier qu'IMAP/POP3 répondent

Contrairement au port 587, les ports 993 et 995 négocient TLS dès l'ouverture de la connexion. Il n'y a donc pas de bannière en clair à lire, et un test en telnet ne produira rien d'exploitable. openssl s_client est l'outil adapté : il termine le handshake puis vous rend une session texte dans laquelle les commandes du protocole redeviennent lisibles.

Les ports 993/995 utilisent TLS implicite

nc -v imap.example.com 993 affichera du binaire TLS incompréhensible. Utilisez openssl pour ces ports.

# IMAP avec TLS (port 993)
openssl s_client -connect imap.example.com:993

# POP3 avec TLS (port 995)
openssl s_client -connect pop.example.com:995

Après le handshake TLS, vous pouvez taper des commandes IMAP (A001 LOGIN user pass) ou POP3 (USER xxx).

Note : IMAP4rev2 (RFC 9051) est la version moderne du protocole, mais IMAP4rev1 reste largement déployé.

Niveau 2 : SPF, DKIM, DMARC, la délivrabilité

Section intermédiaire

Cette section s'adresse à ceux qui doivent configurer ou diagnostiquer des problèmes d'emails en spam. Si vous débutez, concentrez-vous d'abord sur les flux SMTP/IMAP ci-dessus et revenez ici plus tard.

Ces trois mécanismes protègent contre le spam et le phishing en vérifiant l'authenticité des emails.

SPF (Sender Policy Framework)

SPF (RFC 7208) liste les serveurs autorisés à envoyer des emails pour votre domaine. C'est un enregistrement DNS TXT évalué sur l'envelope-from (MAIL FROM / Return-Path), pas sur le header From: visible.

Exemple d'enregistrement SPF :

v=spf1 include:_spf.google.com include:sendgrid.net -all

Élément	Signification
v=spf1	Version du protocole SPF
include:...	Serveurs autorisés (ex: Google, SendGrid)
ip4:203.0.113.5	IP spécifique autorisée
-all	Rejeter (hard fail)
~all	Marquer suspect (soft fail), recommandé au début
?all	Neutre (pas de politique)

Glissez pour voir

Limites SPF à connaître

Limite de 10 DNS lookups : chaque include:, a:, mx:, redirect= compte. Au-delà, SPF échoue avec permerror. Utilisez ip4:/ip6: pour réduire les lookups.

Le forwarding casse SPF : quand un email est transféré, l'IP d'envoi change mais l'envelope-from reste le même → SPF fail. C'est pourquoi DKIM est indispensable.

Vérifier le SPF d'un domaine :

dig TXT example.com +short | grep spf

Stratégie de déploiement : commencez par ~all (soft fail) pour monitorer, puis passez à -all une fois la configuration validée.

DKIM (DomainKeys Identified Mail)

DKIM (RFC 6376) ajoute une signature cryptographique à chaque email. Le destinataire vérifie cette signature avec une clé publique publiée dans le DNS.

Ce que DKIM signe :

• Certains headers (From, To, Subject, Date...) après canonisation
• Le body de l'email (ou un hash partiel)

Fonctionnement :

1. Le serveur expéditeur signe l'email avec sa clé privée
2. La signature est ajoutée dans le header DKIM-Signature
3. Le destinataire récupère la clé publique dans le DNS
4. Il vérifie que la signature correspond au contenu

Trouver le selector dans un email :

Dans les headers de l'email, cherchez DKIM-Signature :

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;

Le champ s= indique le selector (ici selector1).

Vérifier la clé DKIM :

# Format : selector._domainkey.domaine
dig TXT selector1._domainkey.example.com +short

Selectors courants : google, default, s1, s2, selector1, k1.

Rotation des clés DKIM

Le selector permet d'avoir plusieurs clés DKIM simultanément. Lors d'une rotation, vous publiez une nouvelle clé avec un nouveau selector avant de supprimer l'ancien.

DMARC (Domain-based Message Authentication)

DMARC (RFC 7489) définit la politique à appliquer si SPF ou DKIM échoue. Mais surtout, il introduit le concept d'alignment : le domaine validé par SPF/DKIM doit correspondre au domaine du header From:.

Le concept clé : l'alignment

DMARC ne dit pas simplement "SPF ou DKIM doivent passer". Il exige que le domaine validé soit aligné avec le domaine visible dans le header From:.

Exemple de "SPF pass mais DMARC fail" :

• Email envoyé par newsletter.example.com (SPF pass)
• Header From: contact@example.com
• → SPF valide newsletter.example.com mais le From: est example.com → pas d'alignment → DMARC fail

Paramètre	Valeur	Signification
adkim	r (relaxed)	Sous-domaine DKIM accepté
adkim	s (strict)	Domaine exact requis
aspf	r (relaxed)	Sous-domaine SPF accepté
aspf	s (strict)	Domaine exact requis

Glissez pour voir

Exemple d'enregistrement DMARC

L'enregistrement se lit comme une suite de paires clé=valeur séparées par des points-virgules, publiée sur le nom _dmarc.<domaine>. Deux champs méritent votre attention immédiate. p= porte la politique appliquée aux messages qui échouent, et c'est le seul paramètre qui a un effet visible pour vos destinataires. rua= désigne l'adresse qui recevra les rapports agrégés quotidiens, envoyés au format XML compressé par les opérateurs : sans cette adresse, vous passez en p=reject à l'aveugle.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=r; aspf=r

Le tableau ci-dessous liste toutes les valeurs possibles de ces champs, y compris les trois politiques mutuellement exclusives de p=. Un enregistrement réel n'en contient évidemment qu'une seule.

Élément	Signification
v=DMARC1	Version
p=none	Pas d'action (monitoring)
p=quarantine	Mettre en spam
p=reject	Rejeter l'email
rua=mailto:...	Rapports agrégés (quotidiens)
ruf=mailto:...	Rapports forensic (par échec)
pct=100	Appliquer à 100% des emails

Glissez pour voir

Vérifier le DMARC :

dig TXT _dmarc.example.com +short

Déploiement progressif DMARC

1. p=none : collectez les rapports pendant 2-4 semaines
2. p=quarantine; pct=10 : testez sur 10% du trafic
3. p=quarantine; pct=100 : appliquez à tout le trafic
4. p=reject : une fois confiant, rejetez les emails non conformes

Prérequis délivrabilité (checklist)

Avant de diagnostiquer des problèmes de spam, vérifiez ces fondamentaux souvent oubliés. Les deux premières lignes du tableau concernent l'identité du serveur et se règlent une fois pour toutes chez l'hébergeur ; les trois suivantes concernent l'identité du domaine et vivent dans votre zone DNS ; la dernière ne dépend que de votre historique d'envoi. Traitez-les dans cet ordre : publier un DMARC strict sur une IP sans reverse DNS ne fera pas remonter votre taux de délivrance.

Élément	Vérification	Commande
PTR (reverse DNS)	L'IP d'envoi a un PTR cohérent	dig -x 203.0.113.5 +short
HELO/EHLO	Le serveur s'annonce avec un FQDN valide	Logs Postfix/Exim
SPF	Enregistrement publié et valide	dig TXT example.com
DKIM	Clé publiée et signature active	dig TXT selector._domainkey.example.com
DMARC	Politique définie	dig TXT _dmarc.example.com
Réputation IP	IP non blacklistée	MXToolbox, multirbl.valli.org

Glissez pour voir

Le PTR, grand oublié

Le reverse DNS (PTR) de votre IP d'envoi doit pointer vers un nom cohérent (ex: mail.example.com). Beaucoup de serveurs rejettent les emails venant d'IP sans PTR ou avec un PTR générique (123-45-67-89.isp.com).

# Vérifier le PTR de votre IP
dig -x $(curl -s ifconfig.me) +short

Diagnostic des problèmes de délivrabilité

Vos emails arrivent en spam

Ces cinq vérifications suivent l'ordre dans lequel un serveur destinataire prend sa décision, ce qui évite de perdre du temps sur la mauvaise piste. Ne sautez pas l'étape 5 : le header Authentication-Results du message reçu contient le verdict réel rendu par l'opérateur, alors que les quatre premières étapes ne montrent que votre configuration déclarée. Une configuration DNS parfaite et un dmarc=fail dans les headers signent presque toujours un problème d'alignment, pas un problème de publication.

1. Vérifier SPF

   dig TXT votredomaine.com +short | grep spf

   Assurez-vous que le serveur d'envoi est listé.

2. Vérifier DKIM

   dig TXT selector._domainkey.votredomaine.com +short

   Une clé publique doit être retournée.

3. Vérifier DMARC

   dig TXT _dmarc.votredomaine.com +short

   Une politique doit être définie.

4. Vérifier la réputation de l'IP

   Utilisez des outils comme MXToolbox ou mail-tester.com pour vérifier si votre IP est blacklistée.

5. Analyser les headers de l'email

   Dans l'email reçu, examinez le header Authentication-Results :

   Authentication-Results: mx.google.com;
       dkim=pass header.d=example.com header.s=selector1;
       spf=pass (google.com: domain of bounce@example.com designates 203.0.113.5 as permitted sender);
       dmarc=pass (p=QUARANTINE sp=QUARANTINE) header.from=example.com

   Interprétation :

   • dkim=pass : signature DKIM valide
   • spf=pass : IP autorisée par SPF
   • dmarc=pass : alignment OK + politique respectée

   Si vous voyez dmarc=fail avec spf=pass, c'est probablement un problème d'alignment.

Erreurs SMTP courantes

Le premier chiffre du code vaut plus que le reste : un 4xx est temporaire et le message reste en file d'attente pour être retenté, un 5xx est définitif et déclenche un rapport de non-remise. Concrètement, un 421 ou un 450 ne demande aucune action de votre part avant plusieurs heures, alors qu'un 550 exige une correction immédiate. Le cas le plus trompeur est le 554 : le libellé parle d'échec de transaction, mais le motif réel est presque toujours un rejet pour réputation ou pour présence sur une liste noire, information que le serveur ne détaillera pas.

Code	Signification	Solution
421	Service temporairement indisponible	Réessayer plus tard
450	Boîte mail temporairement indisponible	Greylisting, réessayer
550	Adresse email n'existe pas	Vérifier l'adresse
551	Utilisateur non local	Mauvais serveur de destination
552	Quota dépassé	Boîte pleine
553	Syntaxe incorrecte	Vérifier le format de l'adresse
554	Transaction échouée	Souvent lié au spam/blacklist

Glissez pour voir

Codes DSN (Delivery Status Notification)

Les codes DSN étendus (format X.Y.Z) accompagnent le code à trois chiffres et lèvent son ambiguïté. Leur découpage est normalisé par la RFC 3463 : le X reprend la temporalité (4 temporaire, 5 définitif), le Y désigne la classe de problème (1 adresse, 2 boîte aux lettres, 7 sécurité et politique), le Z le détail. La classe 7 est celle qui vous concernera le plus, car c'est là que les codes d'authentification de la RFC 7372 ont été enregistrés. Les libellés ci-dessous sont ceux du registre IANA, à ne pas confondre avec le texte libre que chaque opérateur ajoute derrière.

Code DSN	Signification	Action
5.1.1	Adresse destinataire inexistante	Vérifier l'adresse destinataire
5.2.2	Boîte pleine	Attendre ou contacter le destinataire
5.7.1	Envoi non autorisé, message refusé (relaying denied, rejet DMARC)	Configurer l'authentification SMTP, vérifier la politique DMARC
5.7.23	Échec de validation SPF	Vérifier l'enregistrement SPF
5.7.25	Échec de validation du reverse DNS	Publier un PTR cohérent pour l'IP d'envoi
5.7.26	Plusieurs contrôles d'authentification en échec	Vérifier SPF et DKIM, puis l'alignment DMARC
4.7.0	Statut de sécurité temporaire non précisé (greylisting typique)	Réessayer dans 5-15 min

Glissez pour voir

Email non reçu du tout

Un message qui n'arrive pas se range dans deux familles : soit vous avez reçu un rapport de non-remise et le diagnostic est écrit dedans, soit vous n'avez rien reçu du tout et il faut chercher. La première ligne du tableau est de loin la plus fréquente, et aussi la plus mal comprise : un message accepté par le serveur destinataire puis classé en spam ou en quarantaine ne génère aucune erreur côté émetteur. Vos journaux affichent status=sent, et pourtant personne ne le lira. Commencez donc toujours par faire vérifier le dossier indésirables avant de soupçonner le réseau.

Symptôme	Cause probable	Vérification
Aucune erreur, email disparu	Filtré en spam ou quarantaine	Vérifier les dossiers spam
Bounce "550 User unknown"	Adresse invalide	Confirmer l'adresse avec le destinataire
Timeout à la connexion	Port bloqué	nc -zv smtp.dest.com 25
"421 Too many connections"	Rate limiting	Espacer les envois
"550 5.7.1 Relaying denied"	Auth manquante	Activer l'authentification SMTP
SPF pass, DMARC fail	Problème d'alignment	Vérifier que le From: correspond au domaine SPF/DKIM

Glissez pour voir

Enregistrements DNS email

Pour configurer les emails d'un domaine, vous avez besoin de plusieurs enregistrements DNS :

Type	Nom	Exemple	Rôle
MX	example.com	10 mail.example.com	Serveur de réception
A	mail.example.com	203.0.113.5	IP du serveur mail
TXT	example.com	v=spf1 ...	Politique SPF
TXT	selector._domainkey.example.com	v=DKIM1; k=rsa; p=...	Clé DKIM
TXT	_dmarc.example.com	v=DMARC1; p=...	Politique DMARC

Glissez pour voir

Vérifier l'enregistrement MX :

dig MX example.com +short

Résultat typique :

10 mail.example.com.
20 backup.example.com.

Le nombre (10, 20) est la priorité : le plus bas est essayé en premier.

Scénarios courants en production

Scénario 1 : Application → SMTP submission → Gmail/Outlook (spam)

Symptôme : Vos emails transactionnels arrivent en spam chez les destinataires Gmail/Outlook.

Diagnostic :

# 1. Vérifier SPF
dig TXT votredomaine.com +short | grep spf

# 2. Vérifier DKIM (trouvez le selector dans vos emails)
dig TXT selector._domainkey.votredomaine.com +short

# 3. Vérifier DMARC
dig TXT _dmarc.votredomaine.com +short

# 4. Vérifier le PTR de l'IP d'envoi
dig -x VOTRE_IP_SMTP +short

Solutions courantes :

• Ajouter l'IP/domaine du service d'envoi dans SPF
• Activer DKIM sur votre provider (SendGrid, SES...)
• Passer de p=none à p=quarantine une fois configuré

Scénario 2 : Serveur on-prem → Port 25 bloqué

Symptôme : Timeout ou connexion refusée sur le port 25.

nc -zv smtp.destinataire.com 25
# Connection timed out ou refused

Cause : La plupart des FAI/cloud providers bloquent le port 25 sortant pour éviter le spam.

Solutions :

• Utiliser un relais SMTP externe (SendGrid, Mailgun, SES) sur le port 587
• Demander le déblocage du port 25 à votre provider (justification requise)
• Utiliser un VPS dédié à l'envoi d'emails

Configurer un relais SMTP

Pour une application qui doit envoyer des emails (alertes, mails transactionnels), vous avez plusieurs options :

Service externe

Recommandé pour la plupart des cas.

Utilisez un service comme SendGrid, Mailgun, SES :

# Variables d'environnement typiques
SMTP_HOST=smtp.sendgrid.net
SMTP_PORT=587
SMTP_USER=apikey
SMTP_PASSWORD=SG.xxxxxxxxxxxxx

Ne jamais hardcoder les credentials SMTP

Utilisez des variables d'environnement ou un secret manager (Vault, AWS Secrets Manager, Kubernetes Secrets). Ne commitez jamais de credentials SMTP dans le code.

Avantages :

• Délivrabilité optimisée
• Réputation d'IP gérée
• Statistiques et tracking

Serveur Postfix

Pour un contrôle total ou des contraintes spécifiques.

Configuration /etc/postfix/main.cf minimale :

myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost =

Avantages :

• Contrôle total
• Pas de dépendance externe

Inconvénients :

• Gestion de la réputation IP
• Maintenance du serveur

Validation des acquis

Ces trois manipulations se font sur des domaines publics, sans aucun compte ni configuration préalable. Elles vérifient que vous savez lire une configuration de messagerie existante, ce qui est la compétence utile au quotidien : avant de corriger la vôtre, vous aurez toujours besoin de comparer avec un domaine dont vous savez qu'il délivre correctement.

1. Vérifier les enregistrements email d'un domaine

   dig MX github.com +short
   dig TXT github.com +short | grep spf
   dig TXT _dmarc.github.com +short

2. Tester la connectivité SMTP

   nc -zv smtp.gmail.com 587

   Attendu : Connection to smtp.gmail.com port 587 [tcp/submission] succeeded!

3. Analyser un header d'email

   Ouvrez un email reçu, affichez les headers complets et cherchez Authentication-Results pour voir le statut SPF/DKIM/DMARC.

Dépannage rapide

Ce tableau condense les cinq incidents qui reviennent le plus souvent sur des serveurs applicatifs. Trois d'entre eux se règlent en changeant la configuration d'envoi de l'application, deux exigent une intervention sur le DNS ou auprès d'un tiers. Le délistage d'une IP en liste noire est le seul cas où le délai ne dépend pas de vous : comptez de quelques heures à plusieurs jours selon l'organisme, ce qui rend le passage par un relais tiers souvent plus rapide que l'attente.

Symptôme	Cause probable	Solution
Emails en spam	SPF/DKIM/DMARC manquants	Configurer les enregistrements DNS
"550 5.7.1 Relaying denied"	Authentification manquante	Activer l'auth SMTP
IP blacklistée	Spam envoyé depuis cette IP	Demander le delist, utiliser un relais
Timeout port 25	Bloqué par le FAI	Utiliser port 587 ou un relais
"DKIM signature invalid"	Clé mal configurée	Vérifier le sélecteur et la clé publique

Glissez pour voir

Outils avancés (pour aller plus loin)

swaks : Swiss Army Knife for SMTP

swaks est l'outil de référence pour tester SMTP en détail :

# Test basique avec AUTH
swaks --to dest@example.com --from exp@votredomaine.com \
      --server smtp.example.com:587 --tls --auth-user apikey --auth-password "$SMTP_PASSWORD"

# Test STARTTLS explicite
swaks --to dest@example.com --server smtp.example.com:587 --tls

Installation : apt install swaks ou brew install swaks

Analyser les logs serveur

Sur un serveur Postfix, les logs sont dans /var/log/mail.log :

# Suivre les envois en temps réel
tail -f /var/log/mail.log | grep -E "(status=|reject|warning)"

# Chercher un email par queue ID
grep "QUEUE_ID" /var/log/mail.log

À retenir

• SMTP (port 587 submission, 465 submissions) sert à envoyer des emails ; le port 25 est réservé au relay MTA↔MTA
• IMAP (port 993) est préféré à POP3 pour la réception multi-appareils synchronisée
• SPF déclare les serveurs autorisés (attention : limite de 10 DNS lookups, cassé par le forwarding)
• DKIM signe cryptographiquement les emails ; le selector permet la rotation de clés
• DMARC exige l'alignment entre le domaine du From: et celui validé par SPF/DKIM
• Le PTR (reverse DNS) de l'IP d'envoi est souvent vérifié par les serveurs destinataires
• Utilisez openssl s_client -starttls smtp pour tester STARTTLS, pas juste nc

Testez vos connaissances

Dix questions tirées de la banque réseau, à traiter en dix minutes avec un seuil de réussite fixé à 80 %. Elles portent volontairement sur les points qui se confondent : la distinction entre soumission et relais, le champ évalué par SPF, et la condition d'alignment de DMARC. Un échec sur une question d'alignment renvoie à la section DMARC plus haut, pas à la section SPF.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

FAQ : questions fréquentes sur l'email

Les questions rassemblées ici sont celles qui reviennent quand une équipe met en place ses premiers envois transactionnels. Elles complètent le guide sans le répéter : chaque réponse tient en quelques lignes et renvoie au besoin vers la section détaillée correspondante.

Quelle différence entre SMTP, IMAP et POP3 ?

SMTP sert à envoyer le courrier. IMAP et POP3 servent à le recevoir. IMAP synchronise les messages, qui restent sur le serveur et sont lisibles depuis plusieurs appareils. POP3 télécharge les messages et les efface souvent du serveur, ce qui les lie à un seul appareil.

Qu'est-ce que SPF, DKIM et DMARC ?

Trois enregistrements DNS qui authentifient vos emails et conditionnent leur délivrabilité. SPF liste les serveurs autorisés à envoyer. DKIM signe cryptographiquement chaque message. DMARC indique quoi faire si SPF ou DKIM échouent (none, quarantine, reject) et où envoyer les rapports.

Pourquoi mes emails partent-ils en spam ?

La cause la plus fréquente est un défaut d'authentification : SPF, DKIM ou DMARC manquant ou mal configuré. Depuis 2024, Google et Yahoo rejettent ou classent en spam les messages non authentifiés. Vérifiez aussi la réputation de l'IP d'envoi, l'absence de reverse DNS (PTR) et le contenu du message.

Quels ports utiliser pour l'email ?

Pour l'envoi : port 587 (soumission client avec STARTTLS) ou 465 (TLS implicite, de nouveau standard depuis la RFC 8314) ; le port 25 sert au transfert entre serveurs et est souvent bloqué en sortie par les FAI. Pour la réception : IMAP sur 993 et POP3 sur 995, tous deux en TLS.

STARTTLS ou TLS implicite : quelle différence ?

STARTTLS démarre en clair (ports 587, 143) puis bascule en TLS via une commande : il est vulnérable au stripping si un attaquant retire l'offre TLS. Le TLS implicite (465, 993, 995) chiffre dès l'ouverture de la connexion. La RFC 8314 recommande désormais le TLS implicite.

Prochaines étapes

DNS : résolution de noms Comprenez le DNS qui sous-tend les enregistrements MX, SPF et DKIM

HTTP et HTTPS L'autre protocole applicatif majeur du quotidien DevOps

Commandes réseau de base Maîtrisez dig, nc et les outils de diagnostic

TCP vs UDP Comprenez les protocoles de transport sous SMTP et IMAP

Ressources et références

• SMTP : RFC 5321 (protocole de base)
• Message Submission : RFC 6409 (port 587)
• TLS pour email : RFC 8314 (cleartext obsolète)
• SPF : RFC 7208
• DKIM : RFC 6376
• DMARC : RFC 7489
• IMAP4rev2 : RFC 9051
• POP3 : RFC 1939
• Ports IANA : Service Names and Port Numbers

×

📖 Voir la documentation →