Trois mécanismes, trois questions
| Mécanisme | Vérification | Limite |
|---|---|---|
| SPF | Le serveur émetteur est-il autorisé pour le domaine utilisé dans l’enveloppe ? | Ne suffit pas à authentifier l’adresse visible par le lecteur. |
| DKIM | La signature du message est-elle valide pour le domaine signataire ? | Le domaine signataire doit encore être relié à l’expéditeur visible. |
| DMARC | SPF ou DKIM réussit-il avec un domaine aligné sur le From visible ? | Ne bloque ni tous les messages frauduleux ni les domaines ressemblants. |
Lecture d’un message : le destinataire vérifie SPF et DKIM, puis applique DMARC. Un seul mécanisme aligné et valide peut suffire à faire réussir DMARC. Deux enregistrements DNS présents ne prouvent donc pas que vos messages passent ce contrôle.
Inventorier les expéditeurs avant de changer le DNS
Listez la messagerie quotidienne, le CRM, la facturation, les formulaires du site, les newsletters et les équipements qui envoient des messages. Identifiez pour chaque flux le fournisseur, le domaine visible, le domaine de signature et le responsable. Un oubli peut provoquer le rejet d’un e-mail légitime lors du durcissement.
Exemple illustratif : une PME utilise une messagerie cloud et un logiciel de devis. La messagerie signe correctement, mais le logiciel de devis utilise son propre domaine de signature. Il faut vérifier sa configuration d’envoi et l’alignement avant de rendre la politique plus stricte.
Déployer progressivement
- Vérifier le SPF existant et les consignes de chaque fournisseur ; un domaine ne doit pas publier plusieurs politiques SPF concurrentes.
- Activer DKIM avec les clés et sélecteurs fournis par les services d’envoi.
- Observer les flux et résultats DMARC avec une politique adaptée au démarrage.
- Corriger les sources légitimes mal authentifiées avant de renforcer la politique.
- Recontrôler après chaque ajout de service ou changement de fournisseur.
Exemple de départ à adapter
L’enregistrement TXT suivant est un exemple de politique d’observation, à publier sous _dmarc.example.com pour un domaine de démonstration :
v=DMARC1; p=noneIl ne demande aucun rejet et ne désigne aucun destinataire de rapports. Pour exploiter des rapports agrégés, configurez un destinataire autorisé et encadrez le traitement des données. Ne copiez pas une politique p=reject avant d’avoir validé vos flux réels.
Comment vérifier sans envoyer de faux message ?
- Consulter les enregistrements DNS du domaine et le sélecteur DKIM fourni par l’éditeur.
- Examiner les en-têtes d’un message légitime reçu : résultats SPF, DKIM, DMARC et domaines évalués.
- Tester chaque service d’envoi autorisé avec un destinataire de contrôle.
- Conserver la date, le flux et le résultat ; un seul e-mail réussi ne valide pas tous les outils.
Ce que ces protections ne font pas
Un compte réellement compromis peut envoyer des messages authentifiés. Un fraudeur peut aussi utiliser un domaine ressemblant ou tromper avec le nom affiché. Complétez l’authentification du domaine par le MFA, la revue des transferts de messagerie et une procédure de confirmation des changements de RIB via un contact déjà connu.
DMARC protège-t-il toute ma messagerie ?
Non. Il concerne l’authentification des domaines expéditeurs. Les accès aux boîtes, les règles internes et les habitudes de validation des paiements restent des sujets distincts.
Sources et vérification
Sources consultées le 5 novembre 2026. Les recommandations doivent être adaptées à votre environnement.