Le guide définitif de Red Sift sur la sécurité de l’email
MTA-STS
What is MTA-STS?
Mail Transfer Agent Strict Transport Security (MTA-STS) is a standard that enables the encryption of messages being sent between two mail servers. It specifies to sending servers that emails can only be sent over a Transport Layer Security (TLS) encrypted connection which prevents emails from being intercepted by cybercriminals.
Why do you need it?
The Simple Mail Transfer Protocol (SMTP) alone does not provide security, making it vulnerable to malicious attacks such as man-in-the-middle attacks. A man-in-the-middle attack is where communication between two servers is intercepted and possibly changed without detection by the recipient.
In addition, encryption is optional in SMTP, which means that emails can be sent in plaintext. If a plaintext email was intercepted in transit, it could easily be read and manipulated. Without MTA-STS, an attacker can intercept the communication and force the sending service to send the message in plain text.
By enabling MTA-STS, a TLS connection is required which ensures encryption and keeps your emails private. The MTA-STS standard is so critical to improving the security of SMTP that it has widespread support among major mail service providers such as Google and Microsoft.
For more technical details, visit the MTA-STS and TLS chapter in our Technical Configuration Guide.
Questions fréquentes : Guide de la sécurité de l’email
Toutes les mesures de sécurité des emails (à l’exception de DMARC) sont inefficaces pour détecter un email malveillant lorsqu’il semble provenir d’un domaine légitime. Cela s’explique par une faille dans le Simple Mail Transfer Protocol (SMTP). En octobre 2008, le Network Working Group l’a officiellement qualifié « d’intrinsèquement non sécurisé », indiquant que quiconque pouvait usurper un domaine et l’utiliser pour envoyer des emails frauduleux en se faisant passer pour le propriétaire du domaine.
Quiconque possède quelques connaissances de base en codage peut apprendre, en quelques recherches sur Google, les étapes nécessaires pour usurper l’identité d’un email. Le résultat est un email qui semble légitime sans les indicateurs typiques de phishing. Avec 3,4 milliards d’emails de phishing envoyés chaque jour, les systèmes de messagerie restent la cible privilégiée des cybercriminels.
SPF (Sender Policy Framework) vérifie qu’un email est envoyé à partir d’une adresse IP autorisée par l’enregistrement SPF du domaine expéditeur, via un enregistrement TXT DNS qui liste les serveurs de messagerie autorisés.
DKIM (DomainKeys Identified Mail) utilise une signature cryptographique, validée par une clé publique dans le DNS, pour confirmer que le contenu de l’email n’a pas été modifié et provient d’un domaine autorisé. Tous deux sont essentiels à la sécurité de l’email, mais aucun ne prévient l’usurpation exacte d’un domaine.
Si ces protocoles informent le destinataire de l’origine d’un email, celui-ci n’a aucune instruction sur la façon d’agir sur cette information. Les principaux fournisseurs de messagerie exigent désormais SPF et DKIM pour les expéditeurs d’emails en masse en 2026.
DMARC signifie Domain-based Message Authentication, Reporting, and Conformance. C’est un protocole de sécurité sortante de l’email qui permet aux propriétaires de domaines d’indiquer aux boîtes de réception de rejeter les emails usurpés. DMARC fonctionne en combinant les résultats de SPF et DKIM pour déterminer si votre email est authentique et autorisé.
La politique DMARC (définie par le tag « p= » dans votre enregistrement DNS) indique ensuite aux serveurs destinataires ce qu’ils doivent en faire. DMARC empêche l’usurpation exacte d’un domaine en demandant aux serveurs destinataires de ne pas accepter les emails qui ne sont pas authentifiés. En 2026, DMARC est devenu une exigence standard pour les organisations envoyant des emails en masse.
La spécification SPF limite les recherches DNS à 10. Si votre enregistrement SPF dépasse cette limite, le SPF échouera. Les mécanismes SPF comptabilisés sont : a, ptr, mx, include, redirect et exists. En réalité, 10 recherches ne suffisent pas car la plupart des entreprises utilisent plusieurs outils d’envoi d’emails.
G Suite utilise à lui seul 4 recherches DNS. Ajoutez HubSpot pour le marketing, qui en utilise 7, et vous dépassez déjà la limite. Dès que vous dépassez les 10 recherches SPF, votre trafic d’emails commencera à échouer aléatoirement à la validation. C’est pourquoi les organisations en 2026 passent à une gestion dynamique du SPF plutôt que de tenter de maintenir manuellement des enregistrements aplanis.
Mail Transfer Agent Strict Transport Security (MTA-STS) est une norme qui permet de chiffrer les messages envoyés entre deux serveurs de messagerie. Elle spécifie que les emails ne peuvent être envoyés que via une connexion chiffrée Transport Layer Security (TLS), ce qui empêche l’interception par des cybercriminels. SMTP seul ne fournit aucune sécurité, ce qui le rend vulnérable aux attaques de type man-in-the-middle où les communications sont interceptées et potentiellement modifiées.
De plus, le chiffrement est optionnel dans SMTP, ce qui signifie que les emails peuvent être envoyés en clair. Sans MTA-STS, un attaquant peut intercepter la communication et forcer l’envoi du message en texte clair. En 2026, MTA-STS est devenu un contrôle de sécurité standard pour les organisations traitant des communications sensibles.
En mettant en place DMARC, vous bénéficiez de l’arrêt des tentatives de phishing paraissant provenir de votre domaine, d’une confiance renforcée de vos clients, d’un risque cyber réduit ainsi que du respect des exigences des plateformes d’envoi en masse, comme Google, Yahoo et Microsoft.
DMARC renforce la conformité avec PCI DSS 4.0 et améliore la résilience globale de l’organisation face à l’évolution des menaces cyber. Une fois la politique en p=reject (application), DMARC bloque la fraude fournisseurs, la prise de contrôle de comptes et l’usurpation d’identité par email en empêchant les acteurs malveillants d’utiliser votre domaine pour envoyer des emails de phishing ou réaliser des attaques de fraude au Président (BEC). Selon le rapport Data Breach Investigations Report de Verizon 2025, les attaques BEC constituent plus de 17 à 22% de tous les incidents d’ingénierie sociale.
Red Sift OnDMARC accélère le parcours DMARC grâce à la découverte automatisée des expéditeurs, à des corrections préconisées, à la détection des anomalies et à des accès par rôle pour les équipes globales. À partir de 2026, les principales plateformes permettent aux entreprises d’atteindre l’application p=reject (enforcement) en 6 à 8 semaines, contre six mois auparavant.
L’un des bénéfices les plus fréquemment rapportés d’OnDMARC est le délai moyen de 6 à 8 semaines pour atteindre l’application totale. La puissante automatisation de la plateforme analyse en continu ce qui se passe sur votre domaine, mettant en avant des alertes précises sur les changements à effectuer et où. En 24 heures après l’ajout de votre enregistrement DMARC spécifique dans le DNS, OnDMARC commence à analyser et afficher les rapports DMARC dans des tableaux de bord clairs.
Les principaux fournisseurs d’email, dont Microsoft, Google et Yahoo, exigent désormais la mise en place de DMARC pour les expéditeurs d’emails en masse (organisations envoyant plus de 5 000 emails par jour) depuis 2024-2025, et ces exigences sont devenues standard en 2026.
En plus des exigences des fournisseurs de boîtes de réception, certains secteurs et réglementations gouvernementales tendent vers l’obligation de DMARC. Les agences fédérales américaines sont tenues d’utiliser DMARC, tout comme les établissements de paiement réglementés par DORA. De plus, la mise en œuvre de DMARC renforce la conformité avec PCI DSS 4.0, le RGPD, et NIS2. Pour la cybersécurité, la sécurité des emails et les équipes IT, s’assurer que la sécurité des emails de votre organisation soit conforme aux bonnes pratiques internationales et aux exigences en vigueur est essentiel.