Defaults.Exposed › Corrections › DMARC (Protection contre l'usurpation d'e-mail)

Comment corriger DMARC (Protection contre l'usurpation d'e-mail)

Le DMARC est le seul réglage qui ordonne réellement aux fournisseurs de messagerie du monde entier de BLOQUER les e-mails qui usurpent le nom de votre entreprise. Le SPF et le DKIM vérifient les serrures ; le DMARC décide de ce qui arrive quand une contrefaçon échoue au contrôle — à la corbeille, signalée, ou laissée passer. Mal réglé, votre domaine est entièrement falsifiable ; bien réglé, l'usurpation s'arrête avant la boîte de réception.

En clair, pour votre entreprise : Sans application du DMARC, un escroc peut envoyer des e-mails qui semblent exactement venir de votre entreprise — à vos clients, vos équipes et vos fournisseurs — et ils atterrissent dans leur boîte de réception, pas dans les spams. Des gens se font arnaquer en votre nom, et c'est vous qu'ils tiennent pour responsable.

Ce que cela peut vous coûter

Un escroc envoie à votre client une facture d'apparence authentique « de la part de votre service comptable » avec ses propres coordonnées bancaires. Le client la paie. Vous l'apprenez des semaines plus tard quand il réclame les marchandises déjà payées — et il vous en tient pour responsable.
Un faux e-mail de « paiement urgent » arrive chez votre responsable financier, semblant venir de vous, le dirigeant. Il vire l'argent avant que quiconque pense à vérifier — et une fois la somme arrivée sur le compte d'un escroc, elle n'est presque jamais récupérée.
L'équipe informatique d'un gros prospect effectue un contrôle de sécurité sur votre domaine avant de signer. Le verdict tombe : « e-mail non protégé — usurpable ». Vous perdez l'affaire au profit d'un concurrent dont le domaine a réussi le test.
Votre domaine est utilisé dans une vague d'hameçonnage. Les clients piégés laissent des avis furieux et préviennent les autres. Les dégâts de réputation survivent des mois à l'attaque.
Même vos vrais e-mails commencent à finir à la corbeille, car Google et Yahoo se méfient de plus en plus — et rejettent désormais parfois — les domaines sans DMARC appliqué.

Pourquoi c'est important. L'e-mail n'a jamais été conçu pour prouver qui l'a réellement envoyé ; falsifier l'adresse d'expéditeur est donc trivial. Le DMARC est le seul contrôle qui transforme « nous pouvons détecter les faux » en « les faux sont bloqués » — et il vous fournit aussi les rapports quotidiens qui révèlent qui envoie des e-mails au nom de votre marque. Les grands fournisseurs de boîtes mail traitent désormais l'absence de DMARC appliqué comme un signal de défiance à votre encontre ; cela affecte donc aussi la distribution de vos propres e-mails.

Ce qu’est le DMARC, en clair

L’e-mail a un sale secret : la ligne « expéditeur » n’est que du texte saisi. N’importe qui, n’importe où, peut inscrire le nom et l’adresse de votre entreprise dans le champ expéditeur d’un e-mail et l’envoyer. Internet n’a jamais été conçu pour l’en empêcher.

Trois réglages, ensemble, corrigent cela. Voyez-les comme la sécurité d’un bâtiment :

SPF est la liste de qui est autorisé à entrer par la porte d’entrée (quels services de messagerie peuvent envoyer en votre nom).
DKIM est un sceau inviolable qui prouve que le message n’a pas été modifié en transit.
DMARC est l’agent de sécurité qui vérifie la liste et le sceau — et, surtout, décide quoi faire quand ils ne correspondent pas : laisser passer, envoyer aux spams, ou refouler à la porte.

Vous pouvez avoir la liste (SPF) et le sceau (DKIM) sans avoir d’agent. C’est la situation la plus courante et la plus dangereuse : les serrures existent, mais rien ne les fait respecter. Le DMARC, c’est l’application. C’est la différence entre « nous pouvons dire que cet e-mail est faux » et « ce faux e-mail n’atteint jamais votre client ».

Ce que cela peut vous coûter

Ce n’est pas théorique. Voici les façons concrètes dont un domaine non protégé se transforme en argent réel et en dégâts réels :

L’arnaque à la fausse facture. Un escroc envoie à votre client ce qui ressemble exactement à une facture authentique de votre service comptable — même nom, même domaine, mise en page soignée — mais avec ses propres coordonnées bancaires. Comme votre domaine n’est pas protégé, elle atterrit dans la boîte de réception, pas dans les spams. Le client paie. Vous le découvrez des semaines plus tard quand il demande où en est sa commande. L’argent est généralement perdu, et le client tient souvent vous pour responsable de la faille.
Le virement frauduleux au dirigeant. Un e-mail semble venir de vous, le dirigeant, à votre responsable financier : « Peux-tu faire passer ce paiement en urgence, je suis en réunion. » Cela paraît totalement réel parce que c’est bien votre adresse — juste falsifiée. Le paiement part. Ce schéma — la fraude au président — est l’une des arnaques les plus coûteuses pour les petites entreprises, précisément parce que l’e-mail vient réellement de votre propre domaine et passe ainsi sous le radar de la méfiance.
Le contrat perdu. Un prospect sérieux effectue un contrôle de sécurité ou d’achat avant de signer. Ses outils signalent votre domaine comme « usurpable — aucune application d’authentification e-mail ». Ce seul signal rouge peut suffire à attribuer le contrat à un concurrent dont le domaine a réussi le test. Vous n’en connaîtrez même jamais la vraie raison.
L’atteinte à la réputation impossible à effacer. Votre domaine est emporté dans une campagne d’hameçonnage. Des dizaines de personnes piégées en votre nom publient des avertissements et des avis. L’attaque dure une semaine ; la question « cette entreprise est-elle seulement fiable ? » persiste des mois.
Vos propres e-mails partant dans les spams. Google et Yahoo se méfient désormais activement des domaines sans DMARC appliqué. Des devis, factures et réponses que vous avez réellement envoyés se mettent à atterrir discrètement dans les spams. Les affaires s’enlisent et vous n’en saurez jamais la raison.

Ce que c’est réellement (et à quoi ressemble le « bon » réglage)

Le DMARC se présente comme une simple ligne de texte dans les réglages de votre domaine — un enregistrement DNS « TXT » publié au nom spécial _dmarc.votredomaine. À l’intérieur se trouvent quelques courtes instructions. Deux d’entre elles comptent le plus, et ce sont exactement les deux choses que cette évaluation vérifie.

1. La politique (p=) — les ordres de l’agent. C’est la partie qui pèse le plus lourd dans le contrôle. Elle peut prendre trois valeurs :

p=none — observer seulement. L’agent note qui est passé mais n’arrête personne. Cela ne vous protège de rien ; c’est une étape de surveillance, pas une configuration achevée. (Notre moteur la note comme un échec — mieux que pas de DMARC du tout, mais ce n’est pas une protection.)
p=quarantine — envoyer les faux aux spams. Une vraie protection, mais un attaquant déterminé mise sur le fait que les gens consultent leur dossier spam. Une bonne étape intermédiaire — elle rapporte environ la moitié des points.
p=reject — refuser les faux à la porte. L’e-mail falsifié n’est jamais distribué. C’est le seul réglage qui vous protège entièrement et obtient la note maximale.

À quoi ressemble le « bon » réglage : p=reject. Tout en deçà laisse une brèche.

Deux détails techniques que notre contrôle examine aussi, bons à connaître pour ne pas vous faire piéger :

La politique de sous-domaine (sp=). Vous pouvez définir une politique forte pour votre domaine principal tout en laissant accidentellement les sous-domaines (comme mail.votredomaine ou news.votredomaine) grands ouverts. Notre moteur pénalise cela durement — un domaine en p=reject mais sp=none est noté presque comme s’il n’avait aucune application, car les attaquants se contenteront d’usurper un sous-domaine. La bonne pratique est de laisser sp hériter de votre politique principale forte, ou de le régler explicitement sur reject.
Le pourcentage (pct=). Lors d’un déploiement prudent, vous pouvez n’appliquer l’application qu’à une fraction des e-mails (par ex. pct=25). C’est un outil de transition légitime, mais un déploiement partiel ne donne qu’une protection partielle, et notre note le reflète — elle monte régulièrement à mesure que vous passez de 25 % vers 100 %, mais la note maximale exige une couverture complète.

2. L’adresse de rapport (rua=) — votre visibilité. C’est le second contrôle de cette page. La balise rua= demande à chaque fournisseur de messagerie du monde de vous envoyer un résumé quotidien de qui a tenté d’envoyer des e-mails au nom de votre domaine — vos propres systèmes et tout usurpateur. Sans elle, vous êtes aveugle : vous ignorez qui abuse de votre nom. Avec elle, les entreprises découvrent couramment entre 5 et 50 expéditeurs non autorisés dès le premier jour.

À quoi ressemble le « bon » réglage côté rapport : une adresse rua=mailto: valide (ou une URL https: de service de rapport) qui reçoit réellement les rapports. Notre contrôle valide le format — une adresse mal saisie ou malformée signifie que les rapports partent silencieusement nulle part, ce qui se note comme un résultat partiel ou en échec même si une balise est techniquement « présente ».

Comment corriger (gratuit, ~30 minutes étalées sur deux semaines)

Transmettez cette section à la personne qui gère votre domaine, votre site web ou votre informatique — la correction est entièrement gratuite. Nous facturons uniquement la surveillance du maintien de la configuration dans le temps, la gestion d’un portefeuille de domaines, ou un audit. La modification elle-même ne coûte rien.

La règle d’or : ne sautez jamais directement à reject. Activez d’abord la surveillance, lisez les rapports, confirmez que vos vrais e-mails sont reconnus, puis durcissez. Fait dans cet ordre, c’est sûr ; fait à la hâte, cela peut envoyer vos propres e-mails à la corbeille.

Étape 1 — Vérifiez d’abord que SPF et DKIM sont en place. Le DMARC s’appuie sur eux. Si l’un manque, réglez-le avant d’appliquer le DMARC (voir les pages SPF et DKIM).

Étape 2 — Publiez un enregistrement de surveillance avec les rapports activés. Ajoutez un enregistrement DNS TXT :

Host / nom : _dmarc.votredomaine (votre fournisseur DNS peut l’afficher simplement comme _dmarc)
Type : TXT
Valeur : v=DMARC1; p=none; rua=mailto:dmarc@votredomaine; adkim=s; aspf=s

Cela observe et rapporte sans encore rien bloquer. Les parties adkim=s; aspf=s demandent un alignement strict — omettez-les au début si vous n’êtes pas sûr, et ajoutez-les une fois vos e-mails confirmés propres.

Étape 3 — Lisez les rapports pendant ~2 semaines. Les rapports DMARC bruts sont du XML dense. Utilisez un service de rapport gratuit (par exemple dmarcian ou l’outil DMARC gratuit de Postmark) pour les transformer en tableau de bord lisible. Confirmez que chaque expéditeur légitime — fournisseur de boîte mail, outil d’infolettre, CRM, service d’assistance, logiciel de facturation — réussit. Corrigez tout expéditeur authentique en échec.

Étape 4 — Passez à quarantine. Une fois vos vrais e-mails propres, changez p=none en p=quarantine. Observez encore quelques jours.

Étape 5 — Passez à reject. Enfin, changez p=quarantine en p=reject. Vous êtes désormais entièrement protégé. L’enregistrement final ressemble à :

v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine; adkim=s; aspf=s

Étape 6 — N’oubliez pas les sous-domaines. Vérifiez que vous n’avez pas laissé sp=none en place. Si vous ne publiez aucun sp, les sous-domaines héritent de votre politique principale p=, ce qui est exactement ce que vous voulez.

Notes par plateforme courante :

Google Workspace / Microsoft 365 : tous deux prennent pleinement en charge le DMARC. L’enregistrement DMARC lui-même se place chez votre fournisseur DNS, pas dans la console d’administration de Google ou de Microsoft — assurez-vous d’abord que SPF et DKIM sont activés dans la console d’administration, puis publiez l’enregistrement DMARC TXT chez votre bureau d’enregistrement / hébergeur DNS.
Cloudflare : DNS > Records > Add record > TXT, nom _dmarc, collez la valeur. Cloudflare propose aussi une gestion DMARC intégrée qui peut la mettre en place et collecter les rapports à votre place.
Hébergeurs / bureaux d’enregistrement courants (GoDaddy, etc.) : cherchez « DNS », « DNS Zone » ou « Advanced DNS », ajoutez un enregistrement TXT avec le nom _dmarc et la valeur ci-dessus. La propagation prend généralement de quelques minutes à une heure.

Erreurs fréquentes

S’arrêter à p=none. L’erreur de loin la plus fréquente. La surveillance est le début, pas la fin — un domaine bloqué sur « none » reste entièrement usurpable. Notre moteur le note comme un échec pour cette raison précise.
Foncer directement vers reject sans surveillance. L’erreur inverse. Sans l’étape de rapport, vous risquez de ne pas remarquer qu’un expéditeur légitime (souvent un outil d’infolettre ou de facturation) n’est pas aligné — et vous commencerez à bloquer vos propres e-mails.
Oublier la politique de sous-domaine. Un p=reject fort avec sp=none laisse une porte latérale grande ouverte ; les attaquants usurpent simplement un sous-domaine.
Une adresse de rapport cassée. Un rua= mal saisi (ou sans le préfixe mailto:) signifie que les rapports partent nulle part et que vous restez aveugle sans le savoir. Le format doit être un URI mailto: ou https: valide, sinon les rapports ne sont jamais distribués.
« Nous n’envoyons pas d’e-mails, donc on saute. » Un domaine n’expédiant rien est une cible de premier choix précisément parce que personne ne le surveille. Publiez une politique stricte « reject » pour le verrouiller entièrement.

Une note sur la notation

Le contrôle de politique (p=) est l’un des items qui pèsent le plus lourd dans toute l’évaluation — parce que c’est le principal facteur déterminant si votre entreprise peut être usurpée. « reject » obtient la note maximale ; « quarantine » environ la moitié ; « none » et un enregistrement absent comptent comme des échecs. Une politique de sous-domaine plus faible ou un déploiement partiel pct= tire la note vers le bas pour refléter le niveau réel de protection dont vous disposez.

Le contrôle de rapport (rua=) pèse aussi un poids réel, mais voyez-le moins comme une case à cocher que comme l’outil qui vous permet d’atteindre « reject » en toute sécurité. Configurez-le en même temps que votre enregistrement de surveillance, et il se rentabilise par la visibilité dès le premier jour.

Configurez-le chez votre hébergeur

Étape par étape pour les fournisseurs courants :

FAQ

Je ne suis pas du tout technique — est-ce vraiment quelque chose que je peux gérer ?

Oui, mais vous n'avez pas à le faire vous-même. La correction tient en quelques lignes ajoutées aux réglages de votre domaine, et c'est gratuit. Le plus simple est de transmettre la section « Comment corriger » ci-dessous à la personne qui gère votre site web ou votre support informatique. Cela lui prend généralement bien moins d'une heure, étalée sur deux semaines de surveillance prudente.

Activer le DMARC risque-t-il d'empêcher mes propres e-mails de passer ?

C'est possible — mais seulement si vous sautez le déploiement progressif. Tout l'intérêt de commencer en « surveillance seule » (p=none) avec les rapports activés est d'observer pendant deux semaines et de confirmer que chaque expéditeur légitime (votre boîte mail, votre outil d'infolettre, votre logiciel de facturation) est correctement reconnu AVANT de passer au blocage. Fait dans cet ordre, vos vrais e-mails ne sont pas affectés. Foncer directement vers « reject » sans lire les rapports est l'erreur courante qui casse la distribution.

J'ai déjà configuré SPF et DKIM. N'est-ce pas suffisant ?

Non — et c'est le point le plus important à comprendre. Le SPF et le DKIM sont les serrures ; le DMARC est l'instruction qui dit « si les serrures ne correspondent pas, refusez l'e-mail ». Sans DMARC en « reject », un serveur destinataire peut remarquer qu'un e-mail est falsifié et le distribuer quand même. Le SPF et le DKIM sont des prérequis au fonctionnement du DMARC, mais à eux seuls ils n'empêchent pas un e-mail falsifié d'atteindre la boîte de réception.

Quelle est la différence entre « none », « quarantine » et « reject » ? De quoi ai-je besoin ?

« none » se contente d'observer et de rapporter — il n'arrête rien, il ne vous protège donc pas. « quarantine » envoie les contrefaçons dans les spams. « reject » les refuse purement et simplement, si bien qu'elles n'arrivent jamais. « reject » est l'objectif et le seul réglage qui obtient la note maximale. « quarantine » est une étape intermédiaire raisonnable ; « none » est un point de départ pour les premières semaines, pas une destination.

C'est quoi ce truc de rapport « rua », et en ai-je besoin ?

La balise rua demande aux fournisseurs de messagerie de vous envoyer un résumé quotidien de chaque système ayant tenté d'envoyer des e-mails au nom de votre domaine — y compris les escrocs. C'est ainsi que les entreprises découvrent les 5 à 50 expéditeurs non autorisés qui abusent généralement d'un domaine dès le premier jour. À elle seule, elle pèse moins lourd que la politique, mais c'est ce qui vous permet de passer à « reject » en toute sécurité sans casser vos vrais e-mails — alors configurez-la en même temps.

Nous envoyons à peine d'e-mails, ou nous n'en envoyons pas du tout depuis ce domaine. Avons-nous quand même besoin du DMARC ?

Surtout dans ce cas. Un domaine qui envoie peu ou pas de vrais e-mails est une cible parfaite et discrète pour les escrocs qui veulent l'usurper, car personne ne surveille. Un domaine d'où vous n'envoyez jamais d'e-mails devrait publier une politique stricte « reject » — c'est un gain propre et à faible risque qui claque la porte entièrement.