La sécurité des e-mails repose sur plusieurs couches de protection qui répondent à des menaces fondamentalement différentes. STARTTLS chiffre les messages lors de leur transmission entre serveurs de messagerie, tandis que DMARC authentifie l’identité de l’expéditeur et prévient l’usurpation de domaine. Les organisations supposent souvent que l’un remplace l’autre, mais chaque protocole résout un problème distinct—et ne pas implémenter les deux crée des failles exploitables dans votre infrastructure de messagerie.

Comprendre les différences techniques et opérationnelles entre STARTTLS et DMARC détermine si votre programme de sécurité des e-mails protège réellement contre les menaces auxquelles vous êtes confrontés. Le chiffrement du transport sans authentification permet aux attaquants d’envoyer des messages de phishing convaincants via des canaux chiffrés. L’authentification sans chiffrement expose le contenu des messages à l’interception pendant le transit. Cette comparaison explique comment fonctionne chaque protocole, où chaque protocole peut échouer, et comment déployer les deux ensemble pour une protection complète des e-mails.

I. Ce que fait réellement STARTTLS (et où il échoue)

STARTTLS est une extension SMTP qui améliore une connexion e-mail en texte clair vers une connexion TLS chiffrée pendant la négociation SMTP. Lorsqu’un serveur de messagerie émetteur se connecte à un serveur de messagerie récepteur, STARTTLS négocie le chiffrement avant que le contenu du message ne soit transmis, protégeant les données e-mail en transit contre l’interception au niveau du réseau.

Comment fonctionne STARTTLS :

1. Le serveur émetteur se connecte au serveur récepteur sur le port 587 (soumission) ou le port 25 (relais)
2. Le serveur récepteur annonce la capacité STARTTLS
3. Le serveur émetteur émet la commande STARTTLS
4. Les deux serveurs négocient la version TLS et la suite de chiffrement
5. Une connexion chiffrée est établie pour la transmission du message

Où STARTTLS peut échouer :

STARTTLS est opportuniste par défaut, ce qui signifie que le serveur émetteur tente le chiffrement mais revient en texte clair si le serveur récepteur ne prend pas en charge STARTTLS, si la négociation TLS échoue, ou si un attaquant effectue une attaque de rétrogradation pendant la négociation. Les conditions d’échec courantes incluent :

1. Attaques de suppression STARTTLS : Un attaquant intercepte la session SMTP et supprime l’annonce de capacité STARTTLS, forçant la transmission en texte clair. Le serveur émetteur termine la livraison sans réaliser que le chiffrement a été bloqué.
2. Échecs de validation de certificat : Si le serveur récepteur présente un certificat invalide, expiré ou auto-signé, de nombreux serveurs émetteurs terminent quand même la livraison en texte clair plutôt que de rejeter le message.
3. Échecs de négociation de version TLS et de chiffrement : Des serveurs mal configurés peuvent ne pas parvenir à s’accorder sur les versions TLS prises en charge (par exemple, l’un exige TLS 1.3, l’autre ne prend en charge que TLS 1.0) ou les suites de chiffrement, provoquant le retour de la connexion à une transmission non chiffrée.
4. Comportement de repli silencieux : Sauf configuration explicite contraire, la plupart des serveurs de messagerie n’alertent pas les administrateurs lorsque STARTTLS échoue et que les messages sont envoyés en texte clair.

Ce que STARTTLS ne protège pas :

• STARTTLS n’authentifie pas l’identité de l’expéditeur. Un attaquant peut envoyer des messages usurpés via une connexion chiffrée.
• STARTTLS ne prévient pas le phishing ou la compromission d’e-mails professionnels. Le chiffrement protège le contenu pendant la transmission, pas la légitimité de l’expéditeur.
• STARTTLS n’impose pas le chiffrement au repos. Les messages restent chiffrés uniquement pendant le saut réseau entre serveurs, pas dans les boîtes aux lettres ou les journaux.

II. Ce que fait réellement DMARC (et où il échoue)

DMARC authentifie qu’un message e-mail provient d’une source autorisée en validant les résultats d’authentification SPF et DKIM et en vérifiant l’alignement du domaine. Lorsque DMARC réussit, le serveur de messagerie récepteur dispose de preuves cryptographiques et basées sur DNS que le message a été envoyé par un expéditeur légitime autorisé par le propriétaire du domaine. Lorsque DMARC échoue, le propriétaire du domaine demande au serveur récepteur de mettre en quarantaine ou de rejeter le message.

Comment fonctionne DMARC :

1. Le serveur émetteur livre le message avec authentification SPF (valide l’IP émettrice) et signature DKIM (valide l’intégrité du message)
2. Le serveur récepteur effectue les vérifications SPF et DKIM
3. Le serveur récepteur récupère la politique DMARC depuis le DNS du domaine (_dmarc.exemple.com)
4. Le serveur récepteur vérifie l’alignement : le domaine authentifié SPF ou le domaine DKIM d= doit correspondre au domaine From: visible
5. Si l’alignement réussit, DMARC réussit. Sinon, la politique DMARC (p=none, p=quarantine, p=reject) détermine le traitement

Où DMARC peut échouer :

Le passage de DMARC ne garantit pas le placement en boîte de réception. L’échec de DMARC ne signifie pas toujours un rejet immédiat. L’application dépend du serveur récepteur honorant la politique, et de nombreux scénarios légitimes provoquent des échecs DMARC nécessitant des ajustements opérationnels :

1. Scénarios de transfert : Lorsqu’un message est transféré via une liste de diffusion ou un redirecteur automatique, SPF se casse généralement (l’IP du serveur de transfert n’est pas autorisée pour le domaine d’origine) et DKIM peut se casser si le redirecteur modifie le corps ou l’objet du message. Si DKIM échoue également, DMARC échoue même pour les messages légitimes.
2. Échecs de recherche SPF : SPF peut échouer silencieusement lorsque la recherche DNS expire (temperror), lorsque l’enregistrement dépasse 10 recherches DNS (permerror), ou lorsque l’expéditeur d’enveloppe diffère de l’adresse From de l’en-tête (passe SPF mais ne fournit aucun alignement DMARC).
3. Échecs de signature DKIM : Les signatures DKIM échouent lorsque les clés sont pivotées sans mise à jour du DNS, lorsque le contenu du message est modifié en transit (par des ajouteurs de clauses de non-responsabilité, des scanners antivirus ou des agents de transport), ou lorsque l’en-tête de signature est mal formé.
4. Échecs d’alignement malgré la réussite de l’authentification : Un message peut passer SPF et passer DKIM mais échouer DMARC si ni le domaine authentifié SPF ni le domaine DKIM d= ne s’aligne avec le domaine From: visible. Cela se produit couramment avec des expéditeurs tiers qui signent avec leur propre domaine au lieu du domaine du client.
5. Variabilité de l’application de la politique : DMARC p=reject demande au serveur récepteur de refuser le message pendant la livraison SMTP. Lorsqu’elle est honorée par le serveur récepteur, le message est refusé pendant la livraison SMTP et ne devrait pas atteindre la boîte de réception ou le dossier spam. Cependant, l’application dépend du serveur récepteur honorant la politique—certains redirecteurs, listes de diffusion et récepteurs mal configurés n’appliquent pas DMARC comme spécifié.

Ce que DMARC ne protège pas :

• DMARC ne chiffre pas le contenu des messages. Les messages authentifiés peuvent toujours être interceptés pendant la transmission si STARTTLS n’est pas utilisé.
• DMARC ne valide pas l’exactitude du contenu des messages, seulement l’identité de l’expéditeur.
• DMARC ne prévient pas la compromission de compte. Si un attaquant accède à un compte e-mail légitime, les messages envoyés depuis ce compte passent DMARC.

III. Comparaison technique : STARTTLS vs DMARC

IV. Pourquoi vous avez besoin des deux (pas l’un ou l’autre)

STARTTLS et DMARC ne sont pas des options de sécurité alternatives. Ce sont des protocoles complémentaires qui répondent à différents vecteurs d’attaque :

1. Le chiffrement du transport sans authentification permet aux messages de phishing usurpés d’être livrés via des canaux chiffrés. Un attaquant peut envoyer un message usurpé prétendant provenir de votre entreprise, et si le serveur de messagerie de l’attaquant prend en charge STARTTLS, le message est livré en toute sécurité dans la boîte de réception de la victime—mais la victime n’a aucun moyen de vérifier l’authenticité de l’expéditeur.
2. L’authentification sans chiffrement du transport expose le contenu des messages à l’interception pendant le transit. Même si un message passe DMARC et prouve que l’expéditeur est légitime, le contenu du message peut être intercepté par des attaquants au niveau du réseau si STARTTLS n’est pas appliqué.
3. Les attaques de compromission d’e-mails professionnels exploitent les deux failles simultanément. Les attaquants envoient des messages usurpés depuis des domaines sans application DMARC, via des connexions SMTP non chiffrées ou rétrogradées, pour maximiser le succès de livraison et minimiser les preuves médico-légales.

Les organisations soumises à des cadres de conformité tels que PCI DSS, HIPAA, RGPD et NIS2 implémentent couramment à la fois STARTTLS et DMARC dans le cadre de leurs programmes de sécurité des e-mails. STARTTLS soutient la protection des données pendant la transmission, tandis que DMARC soutient les objectifs anti-phishing, anti-usurpation et de responsabilité de l’expéditeur.

V. Quand STARTTLS seul ne suffit pas

Le déploiement de STARTTLS sur votre infrastructure de messagerie chiffre le contenu des e-mails pendant la transmission, mais ne répond pas à l’authentification de l’expéditeur ou à l’usurpation de domaine. Scénarios où STARTTLS seul fournit une protection incomplète :

1. Attaques de phishing utilisant votre domaine : Un attaquant usurpe votre domaine et envoie des messages de phishing à vos clients. Si le serveur de messagerie de l’attaquant prend en charge STARTTLS, les messages sont livrés via des connexions chiffrées, et les destinataires n’ont aucun signal technique que les messages sont frauduleux.
2. Expéditeurs tiers avec authentification faible : Votre entreprise utilise une plateforme marketing, un système de billetterie de support ou une plateforme RH qui envoie des e-mails en votre nom. Si ces expéditeurs ne sont pas inclus dans votre enregistrement SPF, ne signent pas avec DKIM en utilisant votre domaine, et que votre domaine ne publie pas de politique DMARC, les destinataires ne peuvent pas vérifier que ces messages sont légitimes.
3. Attaques post-livraison : STARTTLS protège les messages pendant la transmission, mais une fois que les messages sont livrés dans la boîte aux lettres du destinataire, ils ne sont plus protégés par le chiffrement du transport. Si un attaquant compromet la boîte aux lettres du destinataire ou la session webmail, STARTTLS ne fournit aucune protection.

VI. Quand DMARC seul ne suffit pas

Le déploiement de DMARC à p=reject empêche les attaquants d’usurper votre domaine, mais ne protège pas le contenu des messages contre l’interception pendant la transmission. Scénarios où DMARC seul fournit une protection incomplète :

1. Exposition de données sensibles pendant le transit : Votre entreprise envoie des relevés financiers, des dossiers médicaux, des documents juridiques ou des informations de paie par e-mail. Si STARTTLS n’est pas appliqué, ces messages peuvent être transmis en texte clair et interceptés par des attaquants au niveau du réseau.
2. Collecte d’identifiants via des canaux non chiffrés : Votre entreprise envoie des liens de réinitialisation de mot de passe, des jetons de vérification de compte ou des codes d’authentification. Si STARTTLS n’est pas appliqué, les attaquants peuvent intercepter ces messages et accéder au compte même si les messages passent DMARC.
3. Lacunes de conformité : De nombreux cadres de conformité mettent l’accent sur la protection des données en transit. DMARC authentifie l’identité de l’expéditeur mais ne chiffre pas le contenu. Les organisations qui se fient uniquement à DMARC peuvent échouer à démontrer une protection adéquate des données pendant la transmission.

VII. Comment déployer STARTTLS et DMARC ensemble

Une architecture de sécurité des e-mails complète utilise à la fois STARTTLS et DMARC, avec des politiques d’application qui réduisent le risque d’attaques de rétrogradation du transport et d’usurpation de domaine.

Liste de contrôle de déploiement STARTTLS

Utilisez la liste de contrôle ci-dessous comme point de départ pratique pour déployer et appliquer STARTTLS sur votre infrastructure de messagerie. Les exigences exactes dépendront de votre plateforme de serveur de messagerie, de la configuration du relais sortant et des objectifs de conformité.

• Vérifiez que les serveurs de messagerie sortants prennent en charge STARTTLS sur le port 587 (soumission) et le port 25 (relais) et sont configurés pour tenter le chiffrement pour toutes les sessions SMTP sortantes.
• Vérifiez que les serveurs de messagerie entrants annoncent la capacité STARTTLS et prennent en charge les versions TLS modernes (TLS 1.2 ou supérieur) avec des suites de chiffrement robustes (évitez RC4, 3DES et les chiffrements d’exportation).
• Déployez des certificats TLS valides pour les noms d’hôtes des serveurs de messagerie, en vous assurant que les certificats sont émis par des autorités de certification de confiance, ne sont pas expirés et incluent les noms alternatifs de sujet (SAN) corrects pour tous les noms d’hôtes des serveurs de messagerie.
• Configurez les serveurs de messagerie émetteurs pour exiger la validation de certificat pour les connexions STARTTLS lorsque c’est possible, en rejetant les connexions si la validation de certificat échoue.
• Publiez une politique MTA-STS (via HTTPS à MTA-STS) pour appliquer STARTTLS pour le courrier entrant, en demandant aux serveurs émetteurs d’exiger le chiffrement et de rejeter la livraison si STARTTLS échoue.
• Publiez un enregistrement TLS-RPT dans DNS (par exemple, _smtp._tls.exemple.com) pour recevoir des rapports lorsque les serveurs émetteurs échouent à livrer via STARTTLS, fournissant une visibilité sur les échecs de connexion, les erreurs de certificat et les tentatives de rétrogradation.
• Surveillez les rapports agrégés TLS-RPT pour identifier les domaines émetteurs qui échouent à se connecter via STARTTLS, enquêtez pour savoir si les échecs indiquent des problèmes d’infrastructure ou des attaques de rétrogradation.
• Testez la configuration STARTTLS en utilisant des outils comme checktls ou en testant manuellement les sessions SMTP (openssl s_client -starttls smtp -connect mail.exemple.com:25).

Liste de contrôle de déploiement DMARC

Utilisez la liste de contrôle ci-dessous comme point de départ pratique pour déployer et appliquer l’authentification DMARC sur vos domaines. Les exigences exactes dépendront de votre écosystème d’expéditeurs autorisés, des intégrations tierces et de la préparation à l’application.

• Auditez tous les expéditeurs autorisés : plateformes marketing, outils de support, systèmes de paie, plateformes RH, systèmes CRM et services d’e-mails transactionnels qui envoient des e-mails en utilisant votre domaine.
• Publiez des enregistrements SPF pour chaque domaine émetteur, incluant toutes les IP émettrices autorisées et les mécanismes d’inclusion SPF pour les expéditeurs tiers (par exemple, include:_spf.google.com pour Google Workspace). Assurez-vous que les enregistrements SPF restent sous la limite de 10 recherches DNS.
• Configurez la signature DKIM pour tous les expéditeurs autorisés, en utilisant votre domaine dans la balise DKIM d= (pas le domaine de l’expéditeur tiers) pour assurer l’alignement avec le domaine From: visible.
• Commencez la surveillance DMARC via Skysnag et obtenez un enregistrement DMARC géré généré pour votre domaine. Skysnag génère un enregistrement DMARC avec la destination de rapport correcte pour votre compte et surveille automatiquement les rapports agrégés.
• Examinez les rapports agrégés DMARC pour identifier les échecs d’authentification, les expéditeurs non authentifiés, les tentatives d’usurpation et les expéditeurs légitimes nécessitant des mises à jour de configuration SPF ou DKIM.
• Résolvez les échecs d’authentification en mettant à jour les enregistrements SPF, en corrigeant la configuration de signature DKIM, en ajustant les paramètres des expéditeurs tiers ou en coordonnant avec les fournisseurs pour signer avec votre domaine.
• Passez la politique DMARC à p=quarantine lorsque les taux de réussite SPF et DKIM sont constamment élevés (95 %+ de taux de réussite sur les expéditeurs autorisés), en demandant aux serveurs récepteurs de filtrer les messages non authentifiés.
• Passez la politique DMARC à p=reject lorsque la confiance opérationnelle est élevée, en bloquant entièrement les messages non authentifiés et en prévenant les attaques d’usurpation de domaine.

Évitez de vous appuyer sur le déploiement basé sur des pourcentages comme stratégie principale. Les programmes actuels conscients de DMARC doivent échelonner l’application par domaine, sous-domaine, groupe d’expéditeurs et fonction commerciale.

VIII. STARTTLS + DMARC + MTA-STS : La pile complète

MTA-STS (Mail Transfer Agent Strict Transport Security) applique STARTTLS pour le courrier entrant, prévenant les attaques de rétrogradation et garantissant que les serveurs de messagerie émetteurs exigent le chiffrement lors de la livraison à votre domaine. Lorsque STARTTLS est opportuniste, les attaquants peuvent supprimer l’annonce de capacité STARTTLS et forcer la livraison en texte clair. MTA-STS élimine ce risque en publiant une politique HTTPS qui demande aux serveurs émetteurs d’exiger le chiffrement et de rejeter la livraison si STARTTLS échoue.

Déploiement MTA-STS :

1. Publiez une politique MTA-STS à https://mta-sts.exemple.com/.well-known/mta-sts.txt avec la structure suivante :version: STSv1 mode: enforce mx: mail.exemple.com max_age: 86400
2. Publiez un enregistrement DNS MTA-STS :_mta-sts.exemple.com. IN TXT "v=STSv1; id=20260115T120000"
3. Mettez à jour la valeur id= chaque fois que la politique change pour forcer les serveurs émetteurs à récupérer à nouveau la politique.

Ce que MTA-STS ne protège pas :

• MTA-STS n’applique STARTTLS que pour le courrier entrant (messages envoyés à votre domaine). Il n’applique pas STARTTLS pour le courrier sortant (messages que vous envoyez à d’autres domaines).
• MTA-STS ne prévient pas l’usurpation—il garantit uniquement le chiffrement. Vous avez toujours besoin de DMARC pour l’authentification.

Déploiement de la pile complète ensemble :

• STARTTLS chiffre le contenu des e-mails pendant la transmission
• DMARC authentifie l’identité de l’expéditeur et prévient l’usurpation
• MTA-STS applique STARTTLS et prévient les attaques de rétrogradation
• TLS-RPT fournit une visibilité sur les échecs de connexion STARTTLS

Cette combinaison garantit que les messages sont à la fois authentifiés et chiffrés, et que les politiques d’application préviennent à la fois l’usurpation et l’interception.

IX. Considérations opérationnelles : Quel protocole prioriser en premier

Les organisations avec des ressources limitées devraient prioriser le déploiement de DMARC avant l’application de STARTTLS, pour deux raisons :

1. DMARC fournit une couverture de menace plus large : Le phishing, la compromission d’e-mails professionnels et les attaques d’usurpation de domaine sont plus courants que l’interception au niveau du réseau pendant le transit des e-mails. DMARC empêche directement les attaquants d’usurper votre domaine.
2. DMARC fournit une visibilité sur votre écosystème d’e-mails : Les rapports agrégés DMARC révèlent tous les expéditeurs utilisant votre domaine, y compris le shadow IT, les services tiers non autorisés et les systèmes hérités dont vous ne connaissez peut-être pas l’existence. Cette visibilité est requise avant de pouvoir appliquer des politiques d’authentification ou de chiffrement.

Cependant, les organisations traitant des données sensibles (services financiers, santé, juridique, gouvernement, entrepreneurs de défense) devraient déployer les deux protocoles en parallèle. Les cadres réglementaires tels que HIPAA, PCI DSS et RGPD mettent l’accent sur la protection des données en transit, et l’application de STARTTLS via MTA-STS démontre que le contenu des e-mails est chiffré pendant la transmission.

X. Comment Skysnag soutient le déploiement de STARTTLS et DMARC

Skysnag Protect automatise la surveillance DMARC, l’application de la politique et la découverte d’expéditeurs, aidant les organisations à passer de p=none à p=reject tout en maintenant la visibilité opérationnelle. Utilisez Skysnag Protect pour identifier les expéditeurs légitimes, détecter les sources non autorisées et progresser vers l’application sans perturber les flux d’e-mails critiques pour l’entreprise.

Capacités de Skysnag Protect :

• Analyse et parsing automatisés des rapports agrégés DMARC
• Alertes en temps réel pour les échecs d’authentification, les tentatives d’usurpation et les erreurs de configuration
• Découverte et classification des expéditeurs (autorisé, non autorisé, tiers)
• Simulation de politique pour tester l’impact de l’application avant de passer à p=quarantine ou p=reject
• Dépannage SPF et DKIM pour résoudre les échecs d’authentification

Pour la surveillance TLS-RPT :
Skysnag prend également en charge les rapports agrégés TLS-RPT, fournissant une visibilité sur les échecs de connexion STARTTLS, les erreurs de certificat et les tentatives de rétrogradation lorsque MTA-STS est déployé.

Commencez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit. Si vous avez besoin de la surveillance TLS-RPT pour l’application MTA-STS, contactez notre équipe pour activer l’analyse et les alertes TLS-RPT.

XI. Points clés à retenir

• STARTTLS chiffre le contenu des e-mails pendant la transmission entre serveurs de messagerie, protégeant contre l’interception au niveau du réseau. DMARC authentifie l’identité de l’expéditeur et prévient l’usurpation de domaine. Les deux protocoles sont requis pour une protection complète des e-mails.
• STARTTLS est opportuniste par défaut, ce qui signifie que les serveurs émetteurs reviennent en texte clair si le chiffrement échoue. MTA-STS applique STARTTLS pour le courrier entrant, prévenant les attaques de rétrogradation et garantissant que les messages sont livrés via des connexions chiffrées.
• Le passage de DMARC ne garantit pas le chiffrement. L’application de STARTTLS ne garantit pas l’authenticité de l’expéditeur. Les organisations qui ne déploient qu’un seul protocole laissent des failles exploitables dans leur architecture de sécurité des e-mails.
• DMARC devrait être priorisé en premier pour la plupart des organisations, car le phishing et les attaques d’usurpation de domaine sont plus courants que l’interception au niveau du réseau. Cependant, les organisations traitant des données sensibles devraient déployer à la fois DMARC et MTA-STS en parallèle.
• STARTTLS peut échouer silencieusement lorsque la validation de certificat est désactivée, lorsque la négociation TLS échoue ou lorsque des attaques de rétrogradation se produisent. DMARC peut échouer lorsque l’authentification SPF ou DKIM se casse en raison du transfert, de la modification de messages ou d’une mauvaise configuration d’expéditeurs tiers.
• Utilisez Skysnag Protect pour automatiser la surveillance DMARC, l’application de la politique et la découverte d’expéditeurs. Commencez la surveillance DMARC avec Skysnag et obtenez votre enregistrement DMARC gratuit.