Qu'est-ce que le DMARC ? Définition, fonctionnement et importance

DMARC (Domain-based Message Authentication, Reporting, and Conformance) est un protocole d'authentification des e-mails qui permet aux propriétaires de domaines de contrôler le sort des e-mails qui échouent aux vérifications SPF DKIM. Il protège votre domaine contre le phishing, l'usurpation d'identité et la compromission des e-mails professionnels en demandant aux serveurs de messagerie destinataires de surveiller, quarantine ou de rejeter les e-mails non authentifiés.

Le protocole DMARC est désormais régi par la norme RFC 9989 (mai 2026), qui a remplacé la norme RFC 7489 initiale. Il est important de noter que les enregistrements existants qui étaient correctement configurés avant la mise à jour de la norme RFC restent valides ; il n'y a donc rien à migrer.

Que signifie l'acronyme DMARC ? Signification complète

DMARC est l'acronyme de « Domain-based Message Authentication, Reporting, and Conformance » (authentification, rapport et conformité des messages basés sur le domaine). Chaque partie de ce nom correspond à une fonctionnalité concrète du protocole :

• Au niveau du domaine : DMARC fonctionne au niveau du domaine, et non au niveau de chaque message individuel. Vous publiez une seule politique DNS qui régit tous les e-mails prétendant provenir de votre domaine.
• Authentification des messages : ce système vérifie qu'un e-mail provient bien de votre domaine en contrôlant les résultats SPF DKIM et en s'assurant qu'ils correspondent à l'adresse « De : » affichée.
• Rapports : les serveurs de réception vous envoient des rapports indiquant qui envoie des e-mails via votre domaine et les résultats obtenus en matière d'authentification.
• Conformité : vous publiez une politique (aucune action, quarantine ou rejet) indiquant aux destinataires comment traiter les e-mails non conformes, et ceux-ci s'y conforment.

Comment fonctionne DMARC ?

DMARC fonctionne en vérifiant si un e-mail entrant est conforme SPF DKIM, afin de s'assurer que le résultat correspond bien au domaine indiqué dans le champ « De : ». Il applique ensuite la politique que vous avez publiée dans le DNS. Il s'appuie sur SPF DKIM, et apporte les deux éléments qui leur font défaut pris isolément.

Lorsqu'un e-mail prétendant provenir de votre domaine arrive, le serveur destinataire effectue ces deux vérifications, vérifie si l'une ou l'autre correspond à votre domaine « De : », puis applique la politique que vous avez publiée dans le DNS. Enfin, il vous envoie un rapport afin que vous puissiez voir exactement ce qui s'est passé.

Le processus d'authentification des e-mails : SPF, DKIM et DMARC

Voici le déroulement complet, depuis l'envoi d'un e-mail jusqu'à la réception du rapport dans votre boîte de réception :

1. Envoi d'un e-mail : un serveur envoie un message en utilisant votre domaine dans le champ « De : ».
2. SPF : le serveur destinataire vérifie si l'adresse IP de l'expéditeur est autorisée dans SPF de votre domaine.
3. Vérification DKIM : le destinataire vérifie la signature DKIM du message à l'aide de la clé publique publiée dans votre DNS, ce qui permet de confirmer que le message n'a pas été altéré pendant son acheminement.
4. Évaluation et concordance DMARC : DMARC évalue les résultats et vérifie que le domaine authentifié par SPF DKIM correspond au domaine figurant dans l'en-tête « From: » visible. Au moins l'un des deux doit être validé et correspondre.
5. Application de la politique : en fonction de la politique que vous avez définie, le destinataire reçoit le message normalement (aucune action), le redirige vers le dossier « Spam » (quarantine) ou le bloque (rejet).
6. Envoi du rapport : le destinataire vous renvoie un rapport récapitulatif, généralement dans les 24 heures, résumant ce qu’il a constaté.

Qu'est-ce que l'alignement DMARC ?

L'alignement est le mécanisme qui établit un lien entre la validation SPF DKIM et le domaine que votre destinataire voit effectivement dans le champ « De : ». Un message peut être validé par SPF DKIM pour un certain domaine tout en affichant votre domaine dans l'en-tête « De : ». L'alignement comble cette lacune en exigeant que le domaine authentifié corresponde au domaine indiqué dans le champ « De : ».

Il existe deux modes d'alignement :

• L'alignement souple (par défaut) autorise une correspondance au niveau du domaine de l'organisation ; ainsi, mail.example.com correspond à example.com.
• Un alignement strict nécessite une correspondance exacte.

Sans alignement, un attaquant pourrait contourner SPF un domaine qu'il contrôle tout en usurpant votre adresse « De : », ce qui correspond précisément à la faille que le protocole DMARC a été conçu pour combler.

Pour en savoir plus sur les deux types d'alignement, les paramètres à configurer et à quel moment, consultez notre guide sur l'alignement DMARC.

DMARC, SPF et DKIM : comment ils fonctionnent ensemble

DMARC ne remplace pas SPF DKIM ; il en dépend. Ces trois protocoles traitent chacun un aspect différent du problème d'authentification, et DMARC les relie entre eux.

Pour en savoir plus sur chacun de ces protocoles, consultez notre guide consacré aux protocoles DMARC, SPF et DKIM.

À quoi SPF ?

SPF Sender Policy Framework) définit les adresses IP et les serveurs autorisés à envoyer des e-mails au nom de votre domaine. Le serveur destinataire vérifie l'adresse « envelope-from » (Return-Path) par rapport à votre SPF publié. Sa limite : SPF protège SPF l'en-tête « From: » visible que les destinataires lisent effectivement ; ainsi, un message peut passer SPF affichant un domaine « From: » usurpé.

Le rôle de DKIM

Le protocole DKIM (DomainKeys Identified Mail) appose une signature cryptographique à chaque message. Les destinataires vérifient cette signature à l'aide d'une clé publique enregistrée dans votre DNS, ce qui leur permet de s'assurer que le message n'a pas été altéré pendant son acheminement et d'identifier le domaine émetteur. Sa limite : à l'instar SPF, le protocole DKIM peut valider un domaine différent de celui indiqué dans l'en-tête « From: » ; il ne permet donc pas, à lui seul, d'empêcher l'usurpation de l'en-tête « From: ».

Pourquoi le protocole DMARC est-il indispensable ?

Les mécanismes SPF DKIM assurent chacun une authentification distincte, mais aucun des deux n'indique au destinataire comment réagir en cas d'échec de la vérification, ni ne relie le résultat au domaine « From: » visible. DMARC comble ces lacunes : il relie SPF DKIM entre eux, exige une cohérence avec le domaine « From: », publie une politique d'application et active la génération de rapports. Sans DMARC, l'usurpation d'identité peut toujours aboutir, même lorsque SPF DKIM sont tous deux en place.

Tableau comparatif : SPF DKIM et DMARC

Politiques DMARC : Aucune, Quarantine et Rejet

Votre politique DMARC indique aux serveurs destinataires comment traiter les e-mails qui ne passent pas les contrôles d'authentification et de conformité. Il existe trois niveaux de politique DMARC, chacun correspondant à un niveau d'application plus strict que le précédent.

p=aucun (Moniteur)

Aucune mesure coercitive n'est prise ; les e-mails en échec sont toujours distribués, et des rapports vous sont envoyés afin que vous puissiez identifier les expéditeurs agissant en votre nom. Il s'agit là de la première étape idéale pour tout nouveau déploiement.

Remarque relative à la conformité : la valeur « p=none » ne répond pas aux exigences de Gmail et Yahoo en matière d'envoi en masse, ni aux exigences anti-hameçonnage de la norme PCI DSS v4.0, dont l'application est obligatoire.

p =quarantine application souple)

Les e-mails rejetés sont redirigés vers le dossier « spam » ou « courrier indésirable » plutôt que vers la boîte de réception. Les e-mails légitimes et authentifiés ne sont pas affectés. Remarque relative à la conformité : quarantine aux exigences de Gmail, Yahoo, Microsoft et de la norme PCI DSS v4.0.

p = rejet (application intégrale)

Les e-mails qui ne passent pas le filtrage sont rejetés d'emblée et n'atteignent jamais la boîte de réception ni le dossier de spam. Il s'agit du niveau de protection le plus élevé. Remarque relative à la conformité : l'option « reject » répond à toutes les exigences actuelles. Une mise en garde issue de la RFC 9989 : pour les domaines dont les utilisateurs publient sur des listes de diffusion, quarantine peut constituer une politique permanente plus sûre, car les listes de diffusion présentent souvent des failles d'authentification qui entraînent le rejet d'e-mails légitimes.

Que sont les rapports DMARC ?

DMARC est le seul protocole d'authentification des e-mails qui vous fournit des données de visibilité. Ces rapports constituent la raison même pour laquelle il est recommandé de publier une configuration DMARC avec p=none avant de passer à la phase d'application : ils vous permettent d'identifier toutes les sources envoyant des e-mails au nom de votre domaine, ce qui vous permet de vous assurer que vos expéditeurs légitimes sont tous validés avant de commencer à bloquer quoi que ce soit.

Rapports agrégés (RUA)

Les rapports agrégés sont des résumés quotidiens au format XML envoyés par chaque serveur de messagerie destinataire ayant traité des e-mails provenant de votre domaine. Chaque rapport répertorie les adresses IP d'envoi, le volume de messages, SPF , les résultats DKIM (réussite/échec), le résultat DMARC global et la mesure appliquée. Ces rapports sont essentiels, car vous ne pouvez pas faire évoluer votre politique en toute sécurité sans eux : vous devez vous assurer que chaque expéditeur légitime est validé avant de passer à quarantine au rejet. L'analyse manuelle du code XML brut n'est pas viable à grande échelle ; c'est pourquoi la plupart des équipes utilisent notre outil DMARC Report Analyzer pour transformer ces rapports en tableaux de bord lisibles.

Si vous débutez dans le domaine des rapports, consultez notre guide étape par étape sur la lecture des rapports DMARC pour une explication simplifiée.

Rapports d'anomalie (RUF)

Les rapports d'échec (anciennement appelés « rapports d'analyse ») sont des notifications envoyées message par message lorsqu'un e-mail individuel échoue au test DMARC. Ils sont plus détaillés que les rapports agrégés. Remarque relative à la confidentialité : Google, Microsoft et Yahoo n'envoient plus de rapports d'échec ; par conséquent, si votre domaine en reçoit, ils proviennent de fournisseurs de moindre envergure. N'incluez la balise `ruf=` dans votre enregistrement que si vous avez configuré un processeur capable de les traiter.

Contre quoi le protocole DMARC assure-t-il une protection ?

Le rôle principal du protocole DMARC est d'empêcher les pirates d'envoyer des e-mails qui semblent provenir de votre domaine exact. Cela couvre trois des types d'attaques par e-mail les plus destructrices.

Usurpation d'identité par courrier électronique

Lors d'une attaque par usurpation d'identité, une personne envoie un e-mail qui semble provenir exactement de votre domaine, par exemple [email protected]. Le paramètre DMARC « p=reject » bloque ces messages avant qu'ils n'atteignent la boîte de réception, car ils ne parviennent pas à passer les contrôles d'authentification et de conformité pour votre domaine.

Attaques de phishing

Les e-mails de hameçonnage usurpent l'identité de votre marque pour inciter vos clients ou vos employés à divulguer leurs identifiants ou à verser de l'argent. Lorsque le protocole DMARC est activé, les pirates ne peuvent pas utiliser votre domaine comme expéditeur, ce qui élimine la version la plus convaincante d'un e-mail de hameçonnage: celle qui semble véritablement provenir de vous.

Compromission du courrier électronique des entreprises (BEC)

Les attaques BEC consistent à usurper l'identité d'un PDG, d'un directeur financier ou d'un fournisseur de confiance afin de solliciter des virements bancaires ou des données sensibles. Le protocole DMARC bloque les attaques BEC par domaine exact, dans lesquelles l'attaquant usurpe votre domaine réel. Notez que l'usurpation du nom d'affichage, où le nom visible indique « Nom du PDG » mais où le domaine sous-jacent n'a aucun rapport, n'est pas bloquée par DMARC, car l'attaquant n'utilise pas du tout votre domaine.

Avantages de la mise en œuvre du protocole DMARC

1. Empêche le phishing et l'usurpation de domaine : l'usurpation de domaine est bloquée avant même d'atteindre les destinataires, éliminant ainsi les attaques les plus convaincantes visant vos clients et votre personnel.
2. Protège la réputation de votre marque : les clients ne reçoivent plus de courriels frauduleux qui semblent provenir de vous, ce qui permet de préserver la confiance accordée à votre marque.
3. Améliore la délivrabilité des e-mails : les e-mails authentifiés inspirent confiance aux destinataires et ont plus de chances d'arriver dans la boîte de réception, tandis que les e-mails non authentifiés sont signalés comme indésirables.
4. Offre une visibilité totale : les rapports agrégés répertorient toutes les sources envoyant des e-mails depuis votre domaine, y compris les services oubliés et les expéditeurs non autorisés.
5. Activer BIMI: une politique «quarantine « p=reject » est indispensable pour que le logo de votre marque BIMI s'affiche à côté de vos messages dans les boîtes de réception compatibles.
6. Répond aux exigences de conformité : le protocole DMARC en mode « Enforcement » permet de se conformer à la norme PCI DSS v4.0, aux règles de Google, Yahoo et Microsoft relatives aux expéditeurs de messages en masse, ainsi qu'à la directive CISA BOD 18-01.

Exigences de conformité DMARC en 2026

La conformité est désormais la principale raison pour laquelle les organisations mettent en œuvre le protocole DMARC. Au cours des deux dernières années, les principaux fournisseurs de messagerie et plusieurs autorités de régulation ont fait passer le protocole DMARC du statut de « bonne pratique » à celui d’« exigence ». Il est essentiel de noter que la valeur « p=none » ne satisfait à aucune des exigences ci-dessous, et que ces autorités attendent une mise en œuvre stricte (quarantine rejet).

Gmail et Yahoo (depuis février 2024)

Depuis février 2024, Gmail et Yahoo exigent des expéditeurs en masse, c'est-à-dire ceux qui envoient 5 000 messages ou plus par jour, qu'ils utilisent SPF et DKIM, ainsi qu'un enregistrement DMARC publié. Gmail a progressivement mis en place le rejet définitif des e-mails non conformes à partir de novembre 2025. Un enregistrement « p=none » répond au strict minimum requis pour la publication d'un enregistrement DMARC, mais c'est l'application de ces mesures (quarantine rejet) qui offre une véritable protection.

Microsoft Outlook (depuis mai 2025)

Microsoft a commencé à appliquer les exigences d'authentification des expéditeurs de masse le 5 mai 2025, rejetant d'emblée, au niveau SMTP, les e-mails à fort volume qui ne passent pas l'authentification, au lieu de les acheminer vers le dossier « Courrier indésirable ». Le protocole DMARC fait partie des exigences d'authentification de Microsoft pour les expéditeurs envoyant plus de 5 000 messages par jour.

PCI DSS v4.0 (à compter de mars 2025)

L'exigence 5.4.1 de la norme PCI DSS v4.0.1 impose la mise en place de mécanismes automatisés de lutte contre le phishing, notamment DMARC en complément de SPF DKIM, pour les organisations qui traitent des données de cartes de paiement. Cette exigence est entrée en vigueur le 31 mars 2025. Un enregistrement « p=none » à des fins de surveillance uniquement ne satisfait pas à cette exigence ; les auditeurs s'attendent à ce qu'une politique de mise en œuvre soit mise en place.

CISA BOD 18-01 (Domaines fédéraux américains)

La directive opérationnelle contraignante n° 18-01 (CISA BOD 18-01) de l’Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA) impose à tous les domaines du pouvoir exécutif fédéral de mettre en œuvre le protocole DMARC avec le paramètre p=reject. Il s’agissait de la première directive gouvernementale exigeant une politique de mise en application effective, plutôt qu’une simple adoption.

Pour en savoir plus sur les exigences et recommandations mondiales en matière de conformité, consultez notre guide complet sur les exigences de conformité DMARC.

Adoption du protocole DMARC en 2026 : statistiques clés

Les statistiques de PowerDMARC pour 2026 concernant le hameçonnage par e-mail et le protocole DMARC révèlent une tendance mondiale claire : le hameçonnage ne cesse de progresser, l’adoption du protocole DMARC est en hausse mais reste loin d’être généralisée, et la plupart des domaines qui l’adoptent n’atteignent jamais le niveau d’application nécessaire pour bloquer efficacement l’usurpation d’identité.

• Seuls environ 18 % des 10 millions de domaines les plus visités au monde publient un enregistrement DMARC valide, et à peine 4 % d'entre eux appliquent pleinement une politique de rejet (analyse du deuxième trimestre 2025), ce qui expose la grande majorité des domaines à l'usurpation d'identité et à l'usurpation de marque.
• Parmi les domaines qui publient effectivement des règles DMARC, la plupart ne vont pas jusqu’à les appliquer : 68,2 % utilisent « p=none », 12,1 % utilisentquarantine et seuls 19,6 % appliquent une politique stricte de type « p=reject ».
• La volonté de mise en œuvre est également faible : seuls 25,5 % des expéditeurs ayant répondu « p=none » prévoient de renforcer leur politique d'ici un an, tandis que 61 % déclarent qu'ils ne le feront que si une réglementation ou un besoin commercial les y oblige.
• Les mesures d'authentification portent leurs fruits là où elles sont le plus efficaces : après que Google et Yahoo ont mis en place des exigences pour les expéditeurs en masse, Google a signalé une baisse de 65 % du nombre de messages non authentifiés parvenant à Gmail, soit 265 milliards de messages non authentifiés en moins pour la seule année 2024.
• Les enjeux sont considérables : une violation liée au hameçonnage coûte en moyenne environ 4,88 millions de dollars, et les attaques par usurpation de compte de messagerie professionnelle ont entraîné environ 2,9 milliards de dollars de pertes déclarées.

RFC 9989 : Mise à jour de la norme DMARC 2026

En mai 2026, la RFC 9989 a remplacé la RFC 7489 en tant que norme DMARC ; il s'agit de la première mise à jour majeure depuis la publication de la spécification initiale en 2015. Les enregistrements existants restant valides, aucune migration n'est nécessaire. Toutefois, les propriétaires de domaines utilisant des balises obsolètes peuvent envisager de mettre à jour leurs enregistrements afin de tenir compte des nouvelles améliorations.

Les changements apportés consistent en une série de petites améliorations pratiques concernant les balises que vous pouvez publier dans une fiche. Voici quelques-uns des principaux changements :

• La balise « pct= » est désormais obsolète. L'ancienne balise de pourcentage, qui indiquait aux destinataires d'appliquer votre politique uniquement à une partie des e-mails rejetés, a été supprimée car son comportement variait de manière imprévisible d'un fournisseur à l'autre.
• « np= » a été ajouté afin de définir une politique distincte pour les sous-domaines inexistants, c'est-à-dire ceux qui n'envoient absolument aucun courrier légitime. Cela vous permet de rejeter les courriers provenant de sous-domaines que des pirates pourraient inventer, sans affecter vos sous-domaines actifs qui envoient des courriers.
• La balise « t= » a été ajoutée pour signaler un déploiement à titre d'essai ou par étapes, vous offrant ainsi un moyen plus clair et standardisé de passer à la mise en application que ne le faisait la balise « pct= », désormais obsolète.

Pour un aperçu complet des modifications, vous pouvez consulter notre guide sur la norme DMARC RFC 9989.

Limites du protocole DMARC : contre quoi il n'offre-t-il pas de protection ?

Le protocole DMARC est très efficace contre l'usurpation de domaine exacte, mais il ne constitue pas une solution anti-fraude complète, et il convient de préciser clairement ce qu'il ne couvre pas :

• Il ne protège pas contre les attaques par domaines similaires, dans lesquelles un pirate enregistre un domaine dont le nom ressemble à celui de votre site, comme « paypa1.com » ou « paypal-secure.com », car le protocole DMARC appliqué à votre domaine n'a aucune autorité sur un autre domaine.
• Cela n'empêche pas les abus liés au nom d'affichage, c'est-à-dire lorsque le nom de l'expéditeur qui s'affiche ressemble à celui de votre marque, mais que le domaine de messagerie sous-jacent n'a aucun rapport avec celle-ci.
• Cette mesure ne permet pas de remédier au problème des comptes légitimes piratés, car les e-mails envoyés depuis un compte authentique mais piraté sont validés correctement.

Pour les menaces qui ne relèvent pas du champ d'application de DMARC, vous pouvez utiliser notre outil « Lookalike Domain Checker » afin de lancer votre enquête et de détecter les domaines similaires, le typosquatting et les attaques par homoglyphes.

Comment se lancer avec DMARC

Vous n'avez pas besoin de procéder à des réglages complexes pour commencer. Les étapes suivantes vous permettront de vous lancer :

1. Vérifiez vos enregistrements SPF, DKIM et DMARC: comme expliqué précédemment, DMARC nécessite la configuration SPF DKIM pour fonctionner (de préférence les deux). Avant de commencer, vous devez donc vérifier si ces enregistrements existent. Passez votre domaine dans notre outil d’analyse de domaine pour vérifier en une seule fois si vous disposez d’enregistrements SPF, DKIM et DMARC et connaître votre politique actuelle en matière d’enregistrements.

2. Créez un enregistrement si vous n’en avez pas : utilisez notre outil « DMARC Generator » pour générer une syntaxe valide, puis publiez cet enregistrement dans votre DNS afin d’activer le protocole. Pour commencer, réglez toujours votre politique sur « none », puis passez progressivement à l’application (enforcement) une fois que vous êtes sûr de la qualité de votre délivrabilité.

3. Ajoutez un enregistrement à votre DNS : ouvrez votre console de gestion DNS et publiez l'enregistrement DMARC sous _dmarc.votredomaine.com en tant qu'enregistrement TXT.

4. Vérification à l'aide de l'outil de vérification DMARC : enfin, au bout de 24 heures, soumettez votre domaine à notre outil de vérification DMARC afin de vérifier si l'enregistrement que vous avez publié est valide et ne comporte aucune erreur.

Pour un guide complet sur la configuration de DMARC, consultez l'article de blog indiqué ci-dessous, qui propose un tutoriel détaillé étape par étape.

En conclusion

Le protocole DMARC est passé du statut de simple recommandation de sécurité à celui d'exigence fondamentale. C'est ce qui permet de garantir au monde entier que les e-mails émis sous votre domaine vous appartiennent bel et bien, et il est de plus en plus exigé par les fournisseurs de messagerie et les autorités de régulation auxquels votre entreprise doit déjà se conformer. Le protocole en lui-même n'est pas compliqué : publiez un enregistrement, consultez vos rapports et renforcez votre politique à mesure que vos expéditeurs légitimes s'y conforment. Le véritable défi consiste à passer de la surveillance à l'application stricte de cette politique.

PowerDMARC est une plateforme de gestion DMARC « full-stack » qui prend en charge pour vous l'ensemble du processus de surveillance et d'application des règles, en transformant les rapports bruts en informations exploitables et en vous aidant à atteindre le taux de rejet « p » sans bloquer les e-mails légitimes.

Foire aux questions

Qu'est-ce que le DMARC ?

Un enregistrement DMARC est un enregistrement DNS de type TXT publié à l'adresse _dmarc.votredomaine.com. Il contient votre politique DMARC ainsi que les adresses e-mail auxquelles les rapports doivent être envoyés. La création et la publication d'un enregistrement DMARC constituent la première étape de la mise en œuvre du protocole DMARC pour votre domaine.

Le protocole DMARC sera-t-il obligatoire en 2026 ?

Oui, pour les expéditeurs en masse. Gmail et Yahoo imposent le protocole DMARC depuis février 2024 aux domaines envoyant au moins 5 000 e-mails par jour, et Microsoft a commencé à appliquer cette exigence en mai 2025. La norme PCI DSS v4.0 impose le protocole DMARC aux prestataires de services de traitement des données de cartes de paiement depuis mars 2025. Même pour les expéditeurs qui n’envoient pas d’e-mails en masse, le protocole DMARC est vivement recommandé afin de protéger votre domaine contre l’usurpation d’identité.

Quelle est la différence entre DMARC, SPF et DKIM ?

SPF quelles adresses IP sont autorisées à envoyer des e-mails pour un domaine. Le DKIM vérifie l'intégrité des messages à l'aide d'une signature cryptographique. Le DMARC associe ces deux mécanismes, les aligne avec le domaine affiché dans le champ « De: », ajoute une politique d'application et permet la génération de rapports. Ces trois éléments sont indispensables pour une authentification complète des e-mails.

Que permet d'empêcher le protocole DMARC ?

Le protocole DMARC empêche l'usurpation d'adresse e-mail au niveau du domaine exact, c'est-à-dire lorsqu'un pirate envoie un e-mail qui semble provenir de votre domaine. Cela concerne les e-mails de hameçonnage, l'usurpation d'identité de marque et la compromission des e-mails professionnels. Il n'empêche toutefois pas les attaques par domaine similaire ni l'usurpation du nom d'affichage, dans lesquelles un domaine différent est utilisé.

Que se passe-t-il si je n'ai pas de DMARC ?

Sans DMARC, les serveurs de réception ne disposent d'aucune instruction concernant les e-mails provenant de votre domaine qui ne respectent pas SPF DKIM ; votre domaine peut donc être facilement usurpé dans le cadre d'attaques de hameçonnage. Depuis 2024, l'absence de DMARC affecte également la délivrabilité pour les expéditeurs en masse, car Gmail et Yahoo peuvent rejeter ou déclassifier vos e-mails légitimes.

Le protocole DMARC permet-il de bloquer toutes les attaques de hameçonnage ?

Non. Le protocole DMARC permet de bloquer les tentatives d'hameçonnage qui usurpent votre domaine exact, mais il ne peut pas empêcher l'utilisation de domaines similaires, l'utilisation abusive des noms d'affichage ni les attaques provenant de comptes légitimes compromis. Le protocole DMARC doit constituer l'un des volets d'une stratégie globale de sécurité des e-mails, et non le seul.

• À propos de
• Derniers messages

Maitham Al Lawati

Expert en cybersécurité, PDG de PowerDMARC

Maitham est un entrepreneur technologique, expert en cybersécurité, PDG et fondateur de PowerDMARC avec plus de 15 ans d'expérience dans l'industrie. Maitham est titulaire d'un Global MBA de l'Université de Manchester et de diverses certifications professionnelles, notamment CISSP, CISM, CRISC et ISC2 CCSP.

Derniers messages de Maitham Al Lawati (voir tous)

• Comment lire les rapports DMARC : guide complet sur les indicateurs RUA et RUF - 10 juin 2026
• Qu'est-ce que le DMARC ? Définition, fonctionnement et importance - 28 avril 2026
• Statistiques sur le phishing et le DMARC : tendances 2026 en matière de sécurité des e-mails - 6 janvier 2026