Protégez votre messagerie en configurant DMARC facilement

La messagerie professionnelle est devenue une infrastructure stratégique : elle transporte des contrats, des factures, des informations clients et des liens d’accès parfois très sensibles. Pourtant, une adresse d’expéditeur peut être imitée avec une facilité déconcertante par un fraudeur qui cherche à contourner les filtres, à diffuser du spam ou à lancer une campagne d’antiphishing au nom d’une entreprise légitime. DMARC apporte une réponse structurée à cette menace en permettant au propriétaire d’un domaine d’indiquer comment traiter les emails qui échouent aux contrôles SPF ou DKIM, tout en recevant des rapports sur les usages légitimes et frauduleux de son identité numérique.

La configuration ne consiste pas à copier une ligne DNS au hasard. Elle suppose d’identifier les plateformes qui envoient des messages, de vérifier leur authentification, d’observer les résultats pendant une période suffisante, puis de renforcer progressivement la politique appliquée. Une entreprise fictive comme Atelier Nova peut ainsi commencer par surveiller les anomalies, corriger son outil de facturation et ses campagnes marketing, puis imposer le rejet des messages usurpés. Cette démarche progressive transforme DMARC en véritable méthode de protection, et non en simple réglage technique.

Comprendre DMARC et son rôle dans la sécurité de la messagerie

DMARC signifie Domain-based Message Authentication, Reporting and Conformance. Ce protocole s’appuie sur SPF et DKIM pour aider les serveurs destinataires à déterminer si un email présenté comme provenant d’un domaine est réellement autorisé. Il ne chiffre pas le contenu et ne remplace pas un antivirus : son objectif est de lutter contre l’usurpation d’identité dans la messagerie, notamment lorsque le champ « De » affiche une adresse connue du destinataire.

SPF publie dans le DNS les serveurs autorisés à envoyer des courriels pour un domaine donné. DKIM ajoute une signature cryptographique aux messages ; le serveur de réception peut vérifier cette signature grâce à une clé publique publiée dans le DNS. DMARC intervient ensuite comme une couche de gouvernance : il demande au serveur destinataire d’examiner les résultats SPF et DKIM, leur alignement avec le domaine visible dans l’adresse de l’expéditeur, puis d’appliquer une politique déterminée par l’organisation.

L’alignement est essentiel, car une authentification isolée ne suffit pas toujours. Un prestataire peut envoyer un message correctement signé avec son propre domaine, alors que l’adresse visible affiche celui d’un client. Avec un alignement souple, les domaines doivent appartenir à la même organisation logique ou partager un domaine parent ; avec un alignement strict, la correspondance doit être exacte. Les balises aspf et adkim permettent de choisir le niveau de rigueur souhaité.

Pour qu’un email soit validé par DMARC, il suffit qu’au moins un des deux mécanismes, SPF ou DKIM, réussisse à la fois son authentification et son alignement. Si SPF échoue ou n’est pas aligné, tandis que DKIM échoue ou ne correspond pas au domaine affiché, le message ne satisfait pas DMARC. Cette logique évite de bloquer systématiquement une communication lorsqu’un seul mécanisme rencontre un incident temporaire, tout en renforçant la protection contre le spoofing.

La politique est définie par la balise p. Avec p=none, le serveur laisse généralement passer le message et transmet les informations dans les rapports ; cette phase est utile pour observer les flux sans perturber les utilisateurs. Avec p=quarantine, le message suspect est orienté vers le dossier spam ou soumis à une mesure équivalente. Avec p=reject, le serveur destinataire refuse le message, ce qui constitue le niveau de protection le plus ferme contre l’usurpation.

Imaginons qu’un fraudeur envoie une fausse demande de virement depuis « direction@atelier-nova.fr ». Le domaine est visuellement correct, mais le serveur utilisé n’est pas autorisé par SPF et la signature DKIM est absente. Sans DMARC, le message peut atteindre la boîte de réception ; avec une règle de rejet correctement déployée, il est interrompu avant de devenir une menace opérationnelle. DMARC transforme donc l’identité du domaine en signal de sécurité exploitable par les filtres.

Préparer SPF, DKIM et les services d’envoi avant la configuration DMARC

La réussite d’un déploiement DMARC dépend d’abord de la cartographie des expéditeurs. Une organisation envoie rarement tous ses messages depuis une seule plateforme : Google Workspace ou Microsoft 365 pour les échanges quotidiens, un logiciel de marketing pour les newsletters, un outil de facturation pour les reçus, un CRM pour les notifications et parfois un prestataire de support. Chacun de ces services peut utiliser une infrastructure différente, avec des domaines d’enveloppe et des signatures spécifiques.

Avant toute modification, il faut recenser les adresses et les applications qui génèrent des emails au nom du domaine. Cette étape pédagogique est souvent l’occasion de faire travailler ensemble l’équipe informatique, le marketing, la comptabilité et le service client. Chez Atelier Nova, l’audit révèle que les messages transactionnels partent d’un domaine secondaire oublié, tandis que les campagnes commerciales utilisent une plateforme dont la signature DKIM n’a jamais été activée. Sans cette analyse, une règle stricte pourrait bloquer des communications légitimes.

SPF doit être publié comme un enregistrement TXT sur le domaine concerné. Il indique les serveurs autorisés, mais il possède une limite importante : les recherches DNS sont soumises à une contrainte technique, ce qui rend les enregistrements SPF trop longs ou excessivement imbriqués difficiles à maintenir. Il est préférable de demander aux fournisseurs leurs mécanismes d’inclusion officiels, d’éviter les doublons et de supprimer progressivement les anciennes infrastructures qui ne servent plus.

DKIM fonctionne différemment. Le service d’envoi génère une paire de clés, conserve la clé privée et ajoute une signature à chaque message ; l’organisation publie la clé publique dans un enregistrement DNS associé à un sélecteur. La rotation des clés, la conservation des sélecteurs documentés et la vérification régulière des signatures font partie d’une bonne hygiène de sécurité. Un prestataire qui refuse de signer les messages ou qui utilise exclusivement son propre domaine devra être examiné avant le passage à une politique restrictive.

Il faut également vérifier le domaine de l’enveloppe, parfois appelé Return-Path ou adresse MAIL FROM. Le domaine affiché dans l’interface de messagerie ne correspond pas toujours à celui utilisé par le protocole SMTP. Or DMARC compare précisément ces identités afin d’évaluer l’alignement SPF. Une plateforme peut donc réussir SPF tout en échouant au contrôle DMARC si son domaine technique n’est pas cohérent avec celui présenté au destinataire.

Après l’activation de SPF et DKIM, une période d’observation d’au moins 48 heures permet de recueillir des signaux plus représentatifs. Des tests doivent être réalisés vers plusieurs fournisseurs, sur des messages simples, des pièces jointes, des campagnes automatisées et des notifications. Cette attente n’est pas une formalité : elle laisse le temps à la propagation DNS et révèle les flux rarement utilisés, comme une alerte mensuelle ou une facture envoyée en fin de période.

La préparation est réussie lorsque chaque expéditeur connu dispose d’un chemin d’authentification documenté, lorsque les domaines sont alignés et lorsque les anciennes configurations ont été retirées. Un DMARC robuste commence donc bien avant l’enregistrement _dmarc : il repose sur une vision complète du système d’envoi.

Créer et publier un enregistrement DMARC sans erreur DNS

L’enregistrement DMARC est un enregistrement TXT placé à l’adresse _dmarc.votredomaine.fr, ou sous la forme équivalente selon le domaine utilisé. Il ne se configure généralement pas dans la console de messagerie, mais chez le registrar ou l’hébergeur DNS. L’interface varie selon les fournisseurs : certains demandent uniquement « _dmarc », tandis que d’autres attendent le nom complet. Une vérification attentive est donc indispensable pour éviter un doublon ou un nom de zone incorrect.

Une valeur de départ adaptée à une phase d’observation peut ressembler à ceci : v=DMARC1; p=none; rua=mailto:dmarc-reports@atelier-nova.fr; pct=100; adkim=r; aspf=r. La balise v indique la version du protocole et doit apparaître en premier. La balise p définit le traitement des messages non conformes, tandis que rua désigne l’adresse destinée aux rapports agrégés.

Les rapports peuvent représenter plusieurs dizaines, voire plusieurs centaines de fichiers ou de messages par jour pour un domaine très actif. Il est préférable de créer une boîte dédiée ou un groupe réservé à cette fonction, plutôt que d’utiliser l’adresse personnelle d’un administrateur. Ces données contiennent des informations techniques sur les sources d’envoi et doivent être intégrées dans une procédure de traitement, avec des droits d’accès limités.

La balise pct permet de faire varier le pourcentage de messages soumis à la règle. Elle peut être utile pendant un déploiement progressif, même si une politique à 100 % est l’objectif final. Les balises sp, adkim et aspf apportent un contrôle supplémentaire : la première concerne les sous-domaines, les deux autres déterminent le caractère strict ou souple de l’alignement DKIM et SPF.

Un exemple plus ferme pourrait être : v=DMARC1; p=reject; rua=mailto:dmarc-reports@atelier-nova.fr; pct=100; adkim=s; aspf=s. Cette ligne ne doit toutefois pas être publiée sans analyse préalable. Si un outil légitime utilise encore un domaine d’enveloppe différent, l’alignement strict entraînera des échecs alors que le message est attendu par le destinataire.

Les rapports DMARC agrégés sont généralement transmis sous une forme structurée, souvent XML. Ils indiquent les volumes observés, les résultats SPF et DKIM, les domaines sources et l’action appliquée. Leur lecture demande parfois un outil spécialisé, car une analyse manuelle devient rapidement fastidieuse. Un rapport peut révéler une adresse IP inconnue qui usurpe le domaine, mais aussi une plateforme parfaitement légitime mal documentée par l’équipe interne.

Si les rapports doivent être envoyés vers un domaine différent, une autorisation DNS supplémentaire peut être nécessaire sur le domaine destinataire. Cette précaution limite les détournements de rapports et permet au serveur émetteur de vérifier que la réception est explicitement autorisée. Après l’enregistrement, il faut contrôler sa présence avec un outil DNS ou un service de diagnostic DMARC, puis vérifier que la chaîne complète est syntaxiquement valide.

Une erreur de ponctuation peut suffire à rendre la politique inopérante : guillemets mal placés, virgule oubliée, préfixe mailto: absent ou nom d’hôte ajouté deux fois par l’interface. La configuration DMARC doit être traitée comme une modification de production : préparée, relue, testée et documentée avant validation.

Déployer progressivement une politique DMARC efficace contre le phishing

Passer immédiatement de l’absence de règle à p=reject peut sembler idéal, mais cette décision présente un risque si les flux d’envoi n’ont pas été inventoriés. Un message commercial légitime pourrait être rejeté, une facture ne pas parvenir à son destinataire ou une notification critique disparaître sans que l’émetteur en soit informé. La méthode la plus sûre consiste à commencer par l’observation, puis à renforcer progressivement la politique grâce aux données collectées.

Durant la phase p=none, les utilisateurs continuent de recevoir les messages comme auparavant, tandis que l’équipe analyse les rapports. Chaque source est classée : expéditeur connu et correctement authentifié, expéditeur connu mais mal aligné, adresse suspecte ou infrastructure obsolète. Cette classification permet de traiter les causes plutôt que les symptômes. Chez Atelier Nova, le service marketing corrige son domaine personnalisé, puis l’outil de facturation active DKIM après échange avec son éditeur.

Lorsque les principaux flux réussissent SPF ou DKIM avec alignement, l’entreprise peut appliquer p=quarantine. Les messages non conformes sont alors dirigés vers le spam ou une zone de contrôle, ce qui offre une période de validation opérationnelle. Les équipes support doivent surveiller les signalements, car un email placé en quarantaine n’est pas forcément frauduleux : il peut révéler une intégration oubliée ou une erreur de configuration chez un partenaire.

Le passage à p=reject intervient lorsque les anomalies résiduelles sont comprises et que les exceptions légitimes ont été corrigées. Cette politique ne bloque pas simplement les emails qui échouent à un filtre isolé : elle vise les messages qui ne satisfont pas l’authentification et l’alignement nécessaires. Elle devient ainsi une barrière efficace contre les campagnes d’usurpation, les fausses demandes de paiement et les invitations piégées diffusées au nom de la direction.

Le paramètre pct peut accompagner cette montée en puissance. Une organisation peut appliquer d’abord la règle à une partie des messages non conformes, puis augmenter progressivement la couverture. Cette approche est particulièrement pertinente pour les domaines volumineux ou les structures qui possèdent de nombreux sous-domaines, car elle limite l’impact d’une mauvaise hypothèse tout en maintenant une trajectoire claire.

Les sous-domaines méritent une attention spécifique. Un domaine principal bien protégé peut encore être exploité par un sous-domaine utilisé pour des campagnes ponctuelles, des événements ou des applications historiques. La balise sp permet de définir une règle dédiée à ces sous-domaines ; sans cette balise, ils héritent généralement de la politique du domaine parent. L’organisation doit donc décider si ces espaces sont contrôlés en interne, confiés à un prestataire ou abandonnés.

La norme BIMI, lorsqu’elle est envisagée pour afficher un logo vérifié dans certaines boîtes de réception, exige une politique DMARC suffisamment stricte. Une règle p=none ou une couverture inférieure à 100 % ne répond pas à cette logique de confiance renforcée. La visibilité de marque ne doit cependant jamais être le seul motif d’activation : elle doit découler d’une authentification maîtrisée.

Le déploiement progressif associe technologie, gouvernance et pédagogie. La meilleure politique DMARC est celle qui protège réellement les destinataires sans interrompre les flux légitimes, grâce à une montée en contrainte fondée sur les preuves.

Surveiller les rapports DMARC et maintenir la protection de la messagerie

La publication d’un enregistrement ne marque pas la fin du projet. Les environnements numériques évoluent : un service marketing change de plateforme, un prestataire de paiement renouvelle ses serveurs, une filiale adopte un nouveau domaine ou une ancienne application est remise en service. Sans surveillance, une configuration correcte peut devenir progressivement incomplète. La protection DMARC doit donc s’inscrire dans une routine de contrôle comparable au suivi des certificats ou des sauvegardes.

Les rapports agrégés fournissent une vision statistique des messages observés par les domaines destinataires. Ils permettent d’identifier les adresses IP d’envoi, les volumes, les résultats SPF et DKIM ainsi que la décision appliquée. Une hausse soudaine d’émissions depuis un pays ou un fournisseur inconnu peut signaler une campagne de spoofing, tandis qu’une chute du taux d’alignement peut indiquer une modification chez un prestataire légitime.

Il faut éviter d’interpréter chaque anomalie comme une attaque. Certains services utilisent des relais, des passerelles de sécurité ou des mécanismes de transfert qui modifient le chemin technique du message. Un email peut donc avoir un résultat SPF inattendu tout en conservant une signature DKIM valide et alignée. L’analyse doit croiser les rapports, les journaux internes, les factures de fournisseurs et les changements récents de configuration.

Les rapports ne doivent pas être stockés dans une boîte personnelle sans traitement. Une boîte ou un groupe dédié facilite la centralisation, tandis qu’un service spécialisé peut transformer les données XML en graphiques compréhensibles : taux de conformité, sources inconnues, domaines concernés et évolution par période. Pour une équipe de formation digitale, ces tableaux de bord constituent aussi un excellent support pédagogique afin d’expliquer concrètement la relation entre DNS, authentification et délivrabilité.

Des contrôles externes peuvent compléter l’analyse. Un outil de vérification permet de lire l’enregistrement publié, de détecter une syntaxe incorrecte, d’identifier l’absence de SPF ou DKIM et de contrôler la politique déclarée. Dans un environnement de supervision, le domaine peut être testé régulièrement, mais il faut tenir compte du cache : certains services ne rafraîchissent leurs résultats qu’après plusieurs jours, parfois près d’une semaine.

La documentation interne doit préciser qui possède chaque domaine, quels prestataires sont autorisés, où se trouvent les clés DKIM, quelles adresses reçoivent les rapports et selon quelle procédure une nouvelle plateforme est approuvée. Lorsqu’un service est supprimé, son entrée SPF, son sélecteur DKIM et ses accès associés doivent être réévalués. Une ancienne autorisation laissée dans le DNS élargit inutilement la surface d’attaque.

Enfin, la sécurité technique doit être accompagnée d’une vigilance humaine. DMARC réduit la probabilité qu’un fraudeur livre un message usurpé, mais il ne remplace ni la sensibilisation aux liens suspects ni la validation des demandes financières par un second canal. Les collaborateurs doivent comprendre qu’un email authentifié peut toujours contenir une compromission issue d’un compte légitime ou d’un domaine ressemblant visuellement au leur.

La qualité de la messagerie se mesure donc à la fois par la délivrabilité des communications attendues et par la capacité à interrompre les messages frauduleux. Une surveillance régulière, une documentation à jour et une réévaluation après chaque changement de fournisseur maintiennent DMARC au niveau de protection attendu.