Le guide définitif de la sécurité des e-mails de Red Sift
Quelles sont les obligations et recommandations mondiales pour DMARC en 2026 ?
Pour les équipes cybersécurité, sécurité des emails et informatique, comprendre et respecter les exigences mondiales DMARC (Domain-based Message Authentication, Reporting, and Conformance) est indispensable.
Chez Red Sift, nous avons établi une vue d'ensemble sous forme de tableau des obligations et recommandations DMARC appliquées dans différentes régions du monde. Notre objectif est de fournir un guide clair et sans ambiguïté, centralisant les différentes exigences mondiales dans un format accessible à tous.
Que vous soyez professionnel de la sécurité IT, administrateur d'emails ou responsable conformité, ce tableau constitue un outil essentiel pour garantir que la sécurité email de votre organisation soit conforme aux meilleures pratiques et exigences internationales.
Obligations et recommandations mondiales DMARC
Zone concernée | Nom | Description | Type d’obligation | En savoir plus |
Global | Nouvelles exigences pour les expéditeurs en masse | Les entités envoyant plus de 5 000 emails par jour doivent authentifier les domaines d'envoi d'email avec TLS, DKIM, SPF, DKIM ou SPF alignment et disposer d'une politique DMARC de p=none. | Obligation pour le secteur privé | |
Global | PCI DDS v4.0 Exigence 5.4.1 | Des “mécanismes automatisés” doivent être déployés pour détecter et se protéger contre le phishing. Bien que cette exigence vise des “processus et mécanismes” sans désigner de solution précise, les bonnes pratiques recommandent DMARC, SPF et DKIM. | Obligation de conformité | |
Canada | Exigences de configuration des services de gestion de courriels | Veiller à ce que l’expéditeur ou le destinataire de courriels du gouvernement soit vérifiable à l’aide du Sender Policy Framework ; Domain Keys Identified Mail (DKIM) ; et Domain-based Message Authentication, Reporting and Conformance (DMARC). | Obligation pour agences gouvernementales | |
Danemark | Exigences techniques minimales pour les autorités gouvernementales 2023 | Toutes les agences gouvernementales sont tenues de mettre en place une politique DMARC de p=reject sur tous leurs domaines. | Obligation pour agences gouvernementales | |
Nouvelle-Zélande | 2022 New Zealand Information Security Manual, v3.6, section 15.2 | Le futur remplaçant de SEEMail utilisera DMARC ; par conséquent, les fournisseurs et agences devront être conformes : 1. Passage du contrôle de conformité DMARC de SHOULD à MUST [CID:6019] [CID:6021] 2. Passage de la politique DMARC de p=“none” à p=“reject” [CID:6020] 3. Passage du contrôle de conformité DKIM de SHOULD à MUST [CID:1797] [CID:1798] | Obligation pour agences gouvernementales | |
Irlande | Normes de base de cybersécurité pour le secteur public, section 2.9 | Les organismes du secteur public doivent mettre en œuvre TLS, SPF, DKIM et appliquer une politique DMARC sur tous les emails entrants. | Obligation pour agences gouvernementales | |
Pays-Bas | Normes “Comply or Explain” | Des directives obligatoires pour les agences gouvernementales imposent DKIM, SPF, et DMARC ainsi que STARTTLS et DANE. | Obligation pour agences gouvernementales | |
Arabie Saoudite | Guide de mise en œuvre des contrôles essentiels de cybersécurité (ECC), section 2-4-3 | Les organisations nationales doivent mettre en œuvre toutes mesures nécessaires pour analyser et filtrer les messages emails (notamment phishing et spam) par des techniques de protection avancées et à jour. Les approches recommandées incluent DKIM, SPF et DMARC. | Obligation pour agences gouvernementales | |
Royaume-Uni | Manuel de politique de cybersécurité gouvernemental Principe : B3 Sécurité des données | Les départements gouvernementaux doivent avoir des enregistrements DMARC, DKIM et SPF pour leurs domaines. Ceci doit être accompagné du MTA-STS et du TLS Reporting. Cette exigence provient du Minimum Cybersecurity Standard de 2018. | Obligation pour agences gouvernementales | |
Royaume-Uni | Sécurisation de l’email gouvernemental | Tous les emails issus d’organisations du secteur public sur Internet doivent être cryptés et authentifiés, au minimum via TLS et DMARC. | Obligation pour agences gouvernementales | |
Royaume-Uni | Actualisation de nos recommandations de sécurité pour les services numériques | Tout service fonctionnant sur service.gov.uk doit publier une politique DMARC. | Obligation pour agences gouvernementales | |
États-Unis | Directive opérationnelle contraignante 18-01 : Renforcer la sécurité email et web | Exige que toutes les agences fédérales renforcent la sécurité web avec STARTTLS, SPF, DKIM et DMARC, avec une politique p=reject. | Obligation pour agences gouvernementales | |
Australie | Recommandations cybersécurité : Directives pour l’email | Recommande la mise en œuvre de SPF, DKIM et DMARC avec une politique p=reject | Recommandation | |
Australie | Comment lutter contre les faux emails | Suggère d’utiliser SPF, DKIM et DMARC pour empêcher l’utilisation des domaines comme source de faux emails. | Recommandation | |
Australie | Stratégies d’atténuation des emails malveillants | Recommande les méthodes les plus efficaces pour protéger les organisations des attaques véhiculées par email, notamment le déploiement de DKIM, SPF et DMARC avec une politique “p=reject”. | Recommandation | |
Canada | Guide de mise en œuvre : protection des domaines email (ITSP.40.065 v1.1) | Pour une protection complète contre l’usurpation, les organisations doivent mettre en œuvre SPF, DKIM et DMARC. | Recommandation | |
UE | Normes de sécurité pour la communication email | Recommande l’usage de STARTTLS, SPF, DKIM, DMARC et DANE pour protéger les communications email. | Recommandation | |
Allemagne | Mesures de défense contre le spam et le phishing, Section 3.1 | Mesures proposées aux fournisseurs d’accès internet pour réduire le problème des malwares et du spam via SPF, DKIM et DMARC. | Recommandation | |
Arabie Saoudite | Campagnes de phishing pour le malware Emotet | Implémentez l’authentification, le reporting et la conformité des messages basés sur le domaine (DMARC) pour détecter l’usurpation d’email à l’aide des enregistrements du Domain Name System (DNS) et de signatures numériques. | Recommandations | |
Ecosse | Une stratégie de cyber-résilience pour l'Écosse : Plan d’action du secteur public 2017-2018, v2 | Les organismes publics devraient bénéficier de la protection anti-usurpation de DMARC. | Recommandations | |
Royaume-Uni | Sécurité de l’email et anti-usurpation v2 | Rendez difficile l’envoi de faux emails depuis les domaines de votre organisation en utilisant SPF, DKIM, et DMARC avec une politique d’au moins p=none, y compris pour les domaines non utilisés. Protégez vos emails en transit avec TLS. | Recommandations | |
Royaume-Uni | Attaques de phishing : défendre votre organisation v1.1 | DMARC, SPF et DKIM sont des défenses de niveau 1 pour stopper les emails usurpés utilisés pour attaquer une organisation. | Recommandations | |
États-Unis | CIS Contrôles de sécurité critiques v8.0, IG2-9.5 | Implémentez la politique et la vérification DMARC, en commençant par Sender Policy Framework (SPF) et les standards DomainKeys Identified Mail (DKIM). | Recommandations | |
États-Unis | CISA INSIGHTS Améliorez la sécurité des emails & du web | Activez DKIM, SPF et DMARC avec une politique p=reject. | Recommandations | |
États-Unis | Guide sur le ransomware du Multi-State Information Sharing and Analysis Center (MS-ISAC) | Pour réduire le risque de courriels usurpés ou modifiés à partir de domaines valides, mettez en œuvre une politique DMARC et sa vérification. | Recommandations | |
États-Unis | NIST 800-53 Catalogue de contrôles de sécurité - Révision 5 : SI-08 | Utilisez des mécanismes de protection anti-spam aux points d’entrée et de sortie du système afin de détecter et d’agir sur les messages non sollicités. DMARC, SPF et DKIM sont l’une des manières d’y parvenir. | Recommandations | |
États-Unis | NIST Special Publication 800-177Révision 1 : Email de confiance | Recommande la mise en œuvre de SPF, DKIM et DMARC, entre autres contrôles, pour renforcer la confiance dans les courriels. | Recommandations |
Où aller à partir d’ici ?
Le paysage de la sécurité et de l’authentification des emails évolue en permanence.
Chez Red Sift, nous comprenons les complexités liées à la mise en œuvre et à la gestion de DMARC. Notre solution Red Sift OnDMARC, primée, est conçue pour simplifier l’application de DMARC, en vous offrant une technologie de pointe et une expertise reconnue.
Foire aux questions : Guide de la sécurité des e-mails
Toutes les mesures de sécurité des e-mails (à l'exception de DMARC) sont inefficaces pour détecter qu'un e-mail malveillant semble provenir d'un domaine légitime. Cela s'explique par une faille dans le protocole Simple Mail Transfer Protocol (SMTP). En octobre 2008, le Network Working Group a officiellement qualifié ce protocole d'« intrinsèquement non sécurisé », déclarant que n'importe qui pouvait usurper un domaine et l'utiliser pour envoyer des e-mails frauduleux en se faisant passer pour le propriétaire du domaine.
Une personne ayant des connaissances très basiques en codage peut facilement trouver les étapes nécessaires pour usurper l'identité e-mail de quelqu'un via une simple recherche Google. Le résultat est un e-mail qui semble légitime et ne montre aucun signe classique de phishing. Avec 3,4 milliards d'e-mails de phishing envoyés chaque jour, les systèmes de messagerie restent une cible de choix pour les cybercriminels.
SPF (Sender Policy Framework) vérifie qu'un e-mail est envoyé depuis une adresse IP autorisée par l'enregistrement SPF du domaine expéditeur grâce à un enregistrement DNS TXT listant les serveurs d'envoi autorisés.
DKIM (DomainKeys Identified Mail) utilise une signature cryptographique, validée via une clé publique dans le DNS, pour confirmer que le contenu de l'e-mail n'a pas été modifié et qu'il provient d'un domaine autorisé. Les deux sont essentiels à la sécurité des e-mails, mais aucun ne permet d'empêcher l'usurpation exacte d'un domaine.
Alors que ces protocoles informent le destinataire de l'origine de l'e-mail, ce dernier ne dispose d'aucune instruction sur la marche à suivre avec cette information. Les principaux fournisseurs de boîtes mail exigent désormais SPF et DKIM pour les expéditeurs d'e-mails en masse en 2026.
DMARC signifie "Domain-based Message Authentication, Reporting and Conformance". Il s'agit d'un protocole de sécurité pour les e-mails sortants qui permet aux propriétaires de domaine d'indiquer aux boîtes de réception de refuser les e-mails usurpés. DMARC fonctionne en combinant les résultats de SPF et DKIM pour déterminer si votre e-mail est authentique et autorisé.
La politique DMARC (définie par le tag "p=" dans votre enregistrement DNS) indique ensuite aux serveurs destinataires comment agir. DMARC empêche l’usurpation exacte de domaine en instruisant les serveurs à ne pas accepter les e-mails non authentifiés. En 2026, DMARC est devenu une exigence standard pour les organisations effectuant des envois en masse.
La spécification SPF limite les recherches DNS à 10. Si votre enregistrement SPF dépasse ce nombre, SPF échouera. Les mécanismes SPF comptabilisés sont : a, ptr, mx, include, redirect et exists. En réalité, 10 recherches DNS ne suffisent pas car la plupart des entreprises utilisent plusieurs outils d'envoi d'e-mails.
G Suite à lui seul consomme 4 recherches DNS ; en ajoutant HubSpot pour le marketing, qui en utilise 7, vous dépassez déjà la limite. Dès que vous dépassez 10 recherches SPF, le trafic e-mail commence à échouer aléatoirement la validation. C'est pourquoi, en 2026, les organisations passent à une gestion dynamique de SPF au lieu d'essayer de maintenir manuellement des enregistrements plats.
Mail Transfer Agent Strict Transport Security (MTA-STS) est une norme qui permet le chiffrement des messages entre deux serveurs de messagerie. Elle spécifie que les e-mails ne peuvent être envoyés que via une connexion chiffrée Transport Layer Security (TLS), ce qui empêche l'interception par les cybercriminels. SMTP seul n'apporte pas de sécurité, le rendant vulnérable aux attaques de type "man-in-the-middle" où la communication est interceptée (et potentiellement modifiée).
De plus, le chiffrement avec SMTP est optionnel, ce qui signifie que les e-mails peuvent être envoyés en clair. Sans MTA-STS, un attaquant peut intercepter la communication et forcer l'envoi du message en clair. En 2026, MTA-STS est devenu un contrôle de sécurité standard pour les organisations traitant des communications sensibles.
La mise en œuvre de DMARC vous permet de bloquer les tentatives de phishing qui semblent provenir de vous, d'instaurer une confiance accrue auprès de vos clients, de réduire le risque cyber et de répondre aux exigences d’expéditeurs en masse de Google, Yahoo ou Microsoft.
DMARC renforce la conformité avec PCI DSS 4.0 et accroît la résilience organisationnelle face à l’évolution des menaces cyber. Une fois à p=reject (enforcement), DMARC bloque la fraude aux fournisseurs, la prise de contrôle de comptes et l'usurpation d’e-mail en empêchant les acteurs malveillants d’utiliser votre domaine pour envoyer des messages de phishing et opérer des compromissions de messagerie d’entreprise (BEC). Selon le rapport Data Breach Investigations Report 2025 de Verizon, les attaques BEC représentent plus de 17 à 22 % de tous les incidents d’ingénierie sociale.
Red Sift OnDMARC accélère le déploiement de DMARC grâce à la découverte de vos expéditeurs, des recommandations prescriptives, la détection d’anomalies et des accès par rôle pour les équipes mondiales. Dès 2026, les principales plateformes permettent aux entreprises d’atteindre le niveau p=reject (enforcement) en 6 à 8 semaines alors que cela prenait parfois six mois auparavant.
L’un des bénéfices les plus souvent cités d’OnDMARC est un délai moyen de 6 à 8 semaines pour obtenir le plein enforcement. La puissante automatisation de la plateforme analyse en continu l’activité de votre domaine, affichant des alertes sur les zones nécessitant des changements. Dès l’ajout de votre enregistrement DMARC unique dans le DNS, OnDMARC commence sous 24h à collecter et afficher les rapports DMARC dans des tableaux de bord clairs.
Les principaux fournisseurs de messagerie tels que Microsoft, Google et Yahoo rendent désormais DMARC obligatoire pour les expéditeurs en masse (organisations envoyant plus de 5 000 e-mails par jour) depuis 2024-2025, et ces exigences se sont généralisées en 2026.
Au-delà des exigences des fournisseurs de messagerie, certains secteurs et réglementations gouvernementales tendent également à rendre DMARC obligatoire. Les agences fédérales américaines doivent utiliser DMARC, tout comme les établissements de paiement régulés par DORA. En outre, la mise en place de DMARC renforce la conformité avec PCI DSS 4.0, le RGPD et NIS2. Pour les équipes cybersécurité, sécurité email et IT, il est essentiel de garantir que la sécurité e-mail de votre organisation soit conforme aux pratiques et exigences internationales de référence.