Pourquoi l’adresse visible peut être usurpée
Le courrier électronique a été conçu dans un environnement où l’identité affichée n’était pas toujours strictement vérifiée. Un fraudeur peut donc tenter d’utiliser le nom de domaine d’une entreprise dans le champ visible par le destinataire, notamment pour une fraude au président ou un faux changement de coordonnées bancaires.
Les mécanismes d’authentification de domaine ne prouvent pas l’identité humaine de l’expéditeur et ne bloquent pas toutes les imitations. Ils permettent toutefois aux serveurs destinataires d’évaluer si l’usage du domaine correspond aux règles publiées par son propriétaire.
SPF : déclarer les serveurs autorisés
SPF utilise un enregistrement DNS pour indiquer quels serveurs sont autorisés à envoyer des messages pour un domaine utilisé dans l’enveloppe SMTP. Le résultat dépend notamment de l’adresse IP du serveur émetteur et du domaine vérifié.
Une entreprise doit recenser sa messagerie, son outil de facturation, ses plateformes marketing, son support et tous les prestataires qui envoient des messages. Multiplier les enregistrements SPF ou dépasser certaines limites de résolution DNS peut provoquer des erreurs ; la configuration doit donc être consolidée et testée.
DKIM : signer les messages avec une clé liée au domaine
DKIM ajoute une signature cryptographique au message. Le serveur destinataire récupère la clé publique publiée dans le DNS et vérifie que les éléments signés n’ont pas été modifiés depuis la signature. Le domaine de signature peut alors être associé au message.
La gestion comprend la création des sélecteurs, la rotation des clés, l’activation chez chaque expéditeur et la vérification des messages réels. Une signature valide ne signifie pas que le contenu est légitime ; elle indique que le message a été signé par une infrastructure disposant de la clé correspondante.
DMARC : aligner, publier une politique et recevoir des rapports
DMARC évalue l’alignement entre le domaine visible dans le champ From et les domaines validés par SPF ou DKIM. Le propriétaire publie une politique DNS qui peut demander une simple observation, une mise en quarantaine ou un rejet des messages qui échouent, selon les règles du protocole et la décision du destinataire.
Les rapports agrégés aident à identifier les sources légitimes, les erreurs de configuration et les usages non autorisés. Les spécifications DMARC ont été actualisées en mai 2026 avec les RFC 9989, 9990 et 9991, qui remplacent l’ancien document de base RFC 7489.
Commencer par une politique d’observation
Passer directement à une politique de rejet peut bloquer des messages légitimes envoyés par un service oublié. Le déploiement commence généralement par l’inventaire, l’activation de SPF et DKIM, puis une politique DMARC d’observation accompagnée de rapports.
Les rapports doivent être analysés sur une période représentative incluant les campagnes, facturations et envois occasionnels. Les services non conformes doivent être corrigés, remplacés ou isolés sur un sous-domaine avant de renforcer progressivement la politique.
Prendre en compte les sous-domaines et les services tiers
L’entreprise doit décider quels sous-domaines sont utilisés pour la messagerie transactionnelle, le marketing ou les outils internes. Cette séparation peut limiter l’impact d’une erreur et faciliter la gestion des prestataires.
Chaque service tiers doit documenter les domaines d’enveloppe, signatures DKIM, clés, adresses de rapport et procédures de changement. La suppression d’un prestataire doit inclure le retrait de ses autorisations DNS.
Comprendre les limites de ces mécanismes
SPF, DKIM et DMARC ne bloquent pas un domaine ressemblant visuellement au vôtre, un compte réellement compromis ou une fraude conduite depuis une adresse légitime. Ils doivent être associés au MFA, à la protection des comptes, aux procédures de validation des paiements et à la sensibilisation.
La surveillance des rapports ne remplace pas non plus l’analyse des alertes de messagerie. L’objectif est de réduire l’usurpation directe du domaine et d’améliorer la visibilité, pas de déclarer la messagerie invulnérable.
Présenter votre situation de manière factuelle
Décrivez votre environnement, vos priorités et les difficultés rencontrées sans transmettre de mots de passe ni de données sensibles. Avec votre accord, vos coordonnées peuvent être communiquées à un partenaire indépendant, seul responsable de son analyse, de ses tarifs et de ses prestations.
Accéder au formulaireQuestions fréquentes
Faut-il mettre SPF, DKIM et DMARC ensemble ?
Ils remplissent des rôles complémentaires. DMARC s’appuie sur l’alignement de SPF ou DKIM ; déployer les trois de manière coordonnée offre une meilleure maîtrise du domaine.
Peut-on passer immédiatement à p=reject ?
C’est risqué si tous les expéditeurs légitimes ne sont pas recensés et alignés. Une phase d’observation et d’analyse des rapports est généralement nécessaire.
DMARC empêche-t-il toutes les fraudes au faux RIB ?
Non. Il réduit certains scénarios d’usurpation directe du domaine, mais ne bloque pas les domaines ressemblants ni les comptes réellement compromis.
Qui doit gérer les rapports DMARC ?
Une personne ou un prestataire doit être désigné pour les collecter, les interpréter et corriger les sources légitimes non conformes. Sans exploitation, les rapports apportent peu de valeur.
Sources officielles consultées
- IETF — RFC 7208, Sender Policy Framework
- IETF — RFC 6376, DKIM Signatures
- IETF — RFC 9989, DMARC
- IETF — RFC 9990, rapports agrégés DMARC
- IETF — RFC 9991, rapports d’échec DMARC
Sources vérifiées le 28 juillet 2026. Les organismes et spécifications cités peuvent être actualisés.
Guides associés
Cette page ne remplace ni un audit, ni une analyse technique, ni un avis juridique. Les décisions et interventions éventuelles relèvent exclusivement des professionnels saisis.