Introduction : Le mirage de l’envoi d’email
Dans l’imaginaire collectif des développeurs, envoyer un email applicatif semble être l’opération la plus triviale qui soit : un socket TCP ouvert sur le port 587, un appel de fonction SMTP, et le message part dans les tuyaux du Web.
Pourtant, la réalité de 2026 est brutale : l’écosystème de la messagerie est devenu un réseau Zero-Trust impitoyable.
Chaque jour, des milliards de spams et de campagnes de phishing inondent la planète. En réaction, les géants de la réception (Google Workspace / Gmail, Microsoft 365, Proton, Yahoo) ont érigé des forteresses algorithmiques. Pour franchir leurs portes sans finir dans les limbes du dossier SPAM, votre email doit réussir une véritable course d’obstacles cryptographique, réseau et protocolaire.
Récemment, lors de la mise en place d’un serveur de messagerie d’entreprise auto-hébergé avec Stalwart Mail Server (une pépite moderne écrite en Rust), nous avons été confrontés à ce cas d’école : des emails transactionnels légitimes de confirmation de rendez-vous atterrissant systématiquement dans les spams de Gmail, malgré un certificat TLS immaculé et un serveur parfaitement sain.
Voici l’analyse post-mortem complète et le guide d’ingénierie pour comprendre pourquoi vos emails finissent en SPAM et comment verrouiller votre infrastructure de délivrabilité.
1. La forteresse moderne : Le parcours de vérification d’un email
Avant d’analyser les pièges, visualisons ce qui se produit réellement lorsqu’un serveur expéditeur (comme votre instance Stalwart) remet un email aux serveurs MX de Gmail :
+---------------------------------------------------------------------------------------+
| LE CORRIDOR DE VÉRIFICATION INBOUND (GMAIL / OUTLOOK) |
+---------------------------------------------------------------------------------------+
[ Serveur Stalwart ]
IP: 198.51.100.42
IPv6: 2001:db8:a1b2::42
│
│ 1. Connexion TCP port 25 & Handshake SMTP
▼
+───────────────────────────────────────────────────────────+
| ÉTAPE 1 : Validation Réseau (FCrDNS / PTR) |
| - Résolution inverse de l'IP appelante (IPv4 ET IPv6) | ──► Mismatch ? ──► [ SPAM / REJECT ]
| - Vérification de la cohérence avec le domaine A/AAAA |
+──────────────────────────┬────────────────────────────────+
│ OK (email.votre-domaine.fr)
▼
+───────────────────────────────────────────────────────────+
| ÉTAPE 2 : Négociation SMTP & Salutation EHLO |
| - Le client annonce son FQDN : EHLO email.votre-domaine.fr ──► "EHLO localhost" ? ──► [ SUSPECT ]
+──────────────────────────┬────────────────────────────────+
│ OK
▼
+───────────────────────────────────────────────────────────+
| ÉTAPE 3 : Contrôle SPF (RFC 7208) |
| - Interrogation DNS du domaine de l'enveloppe Return-Path| ──► Plus d'1 TXT spf1 ? ──► PermError
| - L'IP appelante est-elle autorisée ? | ──► IP absente ? ──► SoftFail / Fail
+──────────────────────────┬────────────────────────────────+
│ PASS
▼
+───────────────────────────────────────────────────────────+
| ÉTAPE 4 : Contrôle Cryptographique DKIM |
| - Récupération de la clé publique via DNS TXT (selector) | ──► Signature invalide ? ──► FAIL
| - Vérification de l'intégrité du corps et des en-têtes |
+──────────────────────────┬────────────────────────────────+
│ PASS
▼
+───────────────────────────────────────────────────────────+
| ÉTAPE 5 : Alignement DMARC |
| - Domaine du header visible 'From:' aligné avec SPF/DKIM ?| ──► Désaligné ? ──► Quarantine/Reject
+──────────────────────────┬────────────────────────────────+
│ PASS
▼
+───────────────────────────────────────────────────────────+
| ÉTAPE 6 : Hygiène MIME & Heuristiques de Contenu |
| - Présence de multipart/alternative (text/plain obligatoire) ──► HTML seul ? ──► Score SPAM +
| - Message-ID canonique (RFC 5322) & en-têtes légitimes |
+──────────────────────────┬────────────────────────────────+
│ CONFORME
▼
┌───────────────────┐
│ BOÎTE DE RÉCEPTION │
│ (100% INBOX) │
└───────────────────┘Si le moindre maillon de cette chaîne fléchit, votre email ne franchira jamais la boîte principale.
2. Les 5 pièges invisibles qui envoient vos emails au purgatoire
Piège n°1 : Le Forward-Confirmed Reverse DNS (FCrDNS) et la surprise IPv6
Le FCrDNS est la première ligne de défense de tout serveur de réception. L’algorithme vérifie que :
- L’IP source qui se connecte possède un enregistrement DNS inverse (
PTR) pointant vers un nom de domaine d’hôte (FQDN), par exempleemail.votre-domaine.fr. - Ce nom de domaine
email.votre-domaine.frrésout bien vers cette même adresse IP en retour.
+-----------------------------------------------------------------------+
| LA BOUCLE DE CONFIANCE FCrDNS (FORWARD-CONFIRMED REVERSE DNS) |
+-----------------------------------------------------------------------+
Direct (A / AAAA)
email.votre-domaine.fr ──────► 198.51.100.42 (IPv4)
──────► 2001:db8:a1b2::42 (IPv6)
▲ │
│ │
│ PTR (Reverse) │
└──────────────────┘Le piège classique OVH / Cloud Provider :
Par défaut, lors de la création d’un VPS ou d’une instance cloud, le reverse DNS est assigné à un nom générique du fournisseur (ex : vps-xxxxxx.vps.ovh.net). Si vous n’avez pas configuré explicitement le reverse DNS sur votre domaine de messagerie (email.votre-domaine.fr), Gmail détectera une discordance immédiate.
Le double piège de l’IPv6 :
C’est l’erreur la plus fréquente : vous configurez méticuleusement le reverse DNS pour votre adresse IPv4, mais vous oubliez l’IPv6 !
Or, les serveurs de Google privilégient nativement les connexions IPv6 lorsque l’enregistrement AAAA est publié. Stalwart se connecte en IPv6, Gmail effectue la requête PTR sur l’IPv6, trouve le nom générique d’OVH ou une absence de PTR, et sanctionne immédiatement le message avec un SPF: SOFTFAIL.
Règle d’or : Tout serveur de messagerie moderne doit posséder son PTR configuré à la fois pour son IPv4 ET son IPv6 vers son FQDN d’envoi.
Piège n°2 : L’unicité stricte du SPF (RFC 7208) et les résidus historiques
SPF (Sender Policy Framework) permet aux propriétaires de domaines de publier la liste des serveurs autorisés à émettre des emails en leur nom.
Mais savez-vous ce que stipule l’article 3.2 de la norme RFC 7208 ?
“A domain name MUST NOT have multiple records that would cause an authorization check to find more than one SPF record of version 1. If a domain name has multiple records, the result of the authorization check MUST be PermError.”
En clair : si votre zone DNS contient plus d’un enregistrement TXT commençant par v=spf1, le serveur récepteur est légitimement en droit de rejeter immédiatement tous vos emails en erreur permanente (PermError).
Dans la pratique, lorsqu’on migre ou qu’on auto-héberge une nouvelle solution, on se retrouve fréquemment avec ce cas désastreux dans la zone DNS :
- Un ancien enregistrement
v=spf1 include:mx.ovh.com ~all - Un enregistrement ajouté par un assistant Stalwart :
v=spf1 a -all - Des doublons créés par mégarde
- L’ancien type d’enregistrement DNS dédié
SPF(Type 99, déprécié depuis la RFC 7208 de 2014) encore présent !
La solution : L’unification chirurgicale
Il faut purger tous les enregistrements parasites et déclarer un seul et unique enregistrement TXT SPF complet :
; Domaine racine (votre-domaine.fr)
votre-domaine.fr. 300 IN TXT "v=spf1 mx a:email.votre-domaine.fr ip4:198.51.100.42 ip6:2001:db8:a1b2::42 ~all"
; Domaine d'hôte d'envoi (email.votre-domaine.fr)
email.votre-domaine.fr. 300 IN TXT "v=spf1 a ip4:198.51.100.42 ip6:2001:db8:a1b2::42 -all"Piège n°3 : L’EHLO fantôme (EHLO localhost)
Quand votre application web (Node.js, Go, Python, PHP) ou votre script de réservation contacte Stalwart ou relaie un email, la première commande SMTP envoyée est la salutation EHLO :
C: EHLO localhost
S: 250-email.votre-domaine.fr Hello localhost [127.0.0.1], pleased to meet youDire EHLO localhost ou EHLO [127.0.0.1] à un relais SMTP externe est un signal d’alarme immédiat pour les moteurs d’analyse heuristique comme SpamAssassin ou Google Postmaster. Un spammeur amateur oublie toujours de configurer le hostname du client SMTP.
La bonne pratique consiste à toujours fournir un FQDN valide et résoluble lors de la commande EHLO :
// Exemple en TypeScript / Node.js
const senderDomain = 'votre-domaine.fr'; // ou 'email.votre-domaine.fr'
await client.write(`EHLO ${senderDomain}\r\n`);Piège n°4 : DKIM et l’alignement DMARC
Avoir un enregistrement DKIM valide ne suffit pas. Encore faut-il que le domaine signataire corresponde au domaine de l’expéditeur visible par l’utilisateur. C’est le rôle fondamental de DMARC :
Header 'From:': contact@votre-domaine.fr (Domaine d'affichage)
DKIM-Signature: d=votre-domaine.fr; s=stalwart;... (Domaine cryptographique)
SPF Return-Path: bounce@email.votre-domaine.fr (Domaine d'enveloppe)En mode d’alignement relaxé (aspf=r, adkim=r), DMARC accepte que le sous-domaine email.votre-domaine.fr valide le domaine organisationnel votre-domaine.fr. Mais si votre application envoie un email avec le header From: contact@aivo.fr depuis un serveur configuré uniquement pour signer d=votre-domaine.fr, l’alignement DMARC échoue et l’email est envoyé en quarantaine.
Stalwart excelle sur ce point : son moteur multi-tenant permet de configurer des clés DKIM distinctes (Ed25519 ou RSA 2048) avec sélecteurs automatiques pour chaque domaine géré.
Piège n°5 : L’anatomie MIME et le respect de la RFC 5322
Même avec un score DNS de 10/10, un email peut être relégué aux spams si son contenu technique est mal formé.
- Le format
multipart/alternativeobligatoire : Envoyer un email uniquement au format HTML (Content-Type: text/html) sans version texte brut (text/plain) est l’un des marqueurs de spam les plus pénalisants. Un client légitime doit toujours fournir les deux versions. - Le
Message-IDcanonique : Le headerMessage-IDdoit respecter la norme RFC 5322 (<random-uuid@domaine-expediteur.com>). UnMessage-IDmanquant, forgé ou dont le domaine pointe verslocalhostou une IP nue est immédiatement dégradé. - Les en-têtes d’automatisation :
Pour les emails transactionnels (notifications de rendez-vous, confirmations de commande), l’ajout de l’en-tête
Auto-Submitted: auto-generatedinforme les filtres qu’il s’agit d’une communication automatique attendue, réduisant le risque de faux positif.
3. Pourquoi Stalwart Mail Server change la donne
Pendant des décennies, l’auto-hébergement d’un serveur mail imposait d’assembler une “usine à gaz” hétérogène : Postfix pour le MTA, Dovecot pour l’IMAP, OpenDKIM pour les signatures, SpamAssassin pour le filtrage, et MySQL ou OpenLDAP pour le stockage des comptes.
Cette complexité opérationnelle était la première cause des failles de délivrabilité : un fichier de configuration désynchronisé, un service qui redémarre mal, et vos emails se perdaient.
Stalwart Mail Server réinvente complètement cette approche :
- Développé en 100% Rust : Zéro vulnérabilité mémoire, consommation CPU et RAM infinitésimale.
- Architecture Tout-en-Un : SMTP, JMAP, IMAP4, POP3, SPF, DKIM, DMARC, DANE et gestion de certificats ACME (Let’s Encrypt) intégrés dans un binaire unique.
- Sécurité native : Support natif des clés Ed25519 pour DKIM, validation DMARC intégrée avec génération automatique des rapports d’échec (RUF/RUA).
- Interface d’administration moderne : Gestion unifiée des domaines, des comptes et des clés cryptographiques.
4. Checklist d’ingénierie : Le test des 60 secondes pour votre domaine
Pour vérifier la santé de votre serveur de messagerie, exécutez ces vérifications depuis votre terminal :
# 1. Vérifier que vous n'avez QU'UN SEUL enregistrement SPF TXT
dig TXT votre-domaine.fr +short | grep -i "v=spf1"
# 2. Vérifier la cohérence de l'IPv4 directe et inverse (PTR)
dig A email.votre-domaine.fr +short
dig -x 198.51.100.42 +short
# 3. Vérifier la cohérence de l'IPv6 directe et inverse (PTR)
dig AAAA email.votre-domaine.fr +short
dig -x 2001:db8:a1b2::42 +short
# 4. Vérifier la clé publique DKIM
dig TXT stalwart._domainkey.votre-domaine.fr +short
# 5. Vérifier la politique DMARC
dig TXT _dmarc.votre-domaine.fr +shortSi le résultat du reverse DNS (PTR) correspond exactement au FQDN de votre serveur, que votre SPF est unifié, et que DMARC est aligné, vos emails ne verront plus jamais le dossier SPAM.
Conclusion : Souveraineté numérique et rigueur technique
L’auto-hébergement de services critiques comme la messagerie n’est pas réservé aux géants du Web. Avec des technologies modernes comme Stalwart et une compréhension rigoureuse des standards Internet, il est parfaitement possible de s’émanciper des solutions SaaS propriétaires tout en garantissant un taux de délivrabilité de 100% en boîte de réception.
La souveraineté numérique ne se décrète pas dans des discours : elle se construit brique par brique, dans la précision des configurations DNS et l’élégance de nos architectures logicielles.
Nicolas BAUD
Architecte de solutions et Fractional CTO fort de plus de 15 ans d'expérience, Nicolas BAUD accompagne les organisations dans la sécurisation de leur SI, le déploiement d'architectures d'IA souveraines et la sobriété numérique.