Quand une entreprise envoie un devis ou une confirmation de commande, les serveurs destinataires vérifient aussi l’origine du message. Une authentification défaillante peut conduire à un rejet, à un classement en courrier indésirable ou à une usurpation de son domaine.
SPF, DKIM et DMARC forment une chaîne complémentaire de sécurité de la messagerie. Leur configuration DNS aide les fournisseurs à reconnaître les envois légitimes et donne à l’entreprise des moyens concrets de renforcer sa cybersécurité professionnelle.
A retenir : sécuriser les e-mails professionnels
- SPF : autorisation des serveurs émetteurs du domaine
- DKIM : signature numérique et intégrité des messages
- DMARC : alignement des domaines et consigne de traitement
- Déploiement progressif : observation avant tout rejet automatique
SPF, DKIM et DMARC : trois contrôles complémentaires
Ces mécanismes répondent à des questions différentes, mais leur combinaison renforce la protection contre l’usurpation d’identité. Selon Google et Yahoo, les expéditeurs doivent authentifier leurs messages, et les expéditeurs en masse sont soumis à des exigences supplémentaires.
SPF autorise les serveurs d’envoi
Dans cette chaîne, SPF indique quels serveurs peuvent envoyer des messages au nom d’un domaine. Le serveur destinataire compare l’adresse IP émettrice aux autorisations publiées dans un enregistrement TXT.
Une PME qui utilise une messagerie cloud, un logiciel de facturation et un site marchand doit inventorier ces sources. Si l’outil de facturation est oublié, ses messages risquent d’échouer au contrôle SPF.
Pour éviter les erreurs, l’entreprise consolide ses émetteurs dans un seul enregistrement SPF. La norme limite à dix les recherches DNS déclenchées par certains mécanismes, notamment « include » ; un dépassement peut invalider le contrôle.
DKIM signe les messages, DMARC fixe la politique
À la vérification de l’expéditeur s’ajoute la signature DKIM, créée avec une clé privée et vérifiée grâce à une clé publique publiée dans le DNS. Elle permet de détecter certaines modifications du message pendant son acheminement.
DMARC complète ces contrôles en vérifiant l’alignement entre le domaine authentifié par SPF ou DKIM et celui visible dans le champ « De ». Selon Microsoft, les exigences applicables aux expéditeurs de gros volumes vers Outlook.com ont été renforcées en 2025.
Le tableau distingue le rôle de chaque protocole ; cette répartition aide à repérer les réglages manquants avant leur mise en place.
Repères des protocoles :
| Protocole | Vérification principale | Emplacement de configuration | Limite à connaître |
|---|---|---|---|
| SPF | Autorisation du serveur d’envoi | Enregistrement TXT du domaine | Un seul enregistrement SPF par domaine |
| DKIM | Signature et intégrité du message | Service d’envoi et clé publique DNS | Chaque service peut nécessiter son sélecteur |
| DMARC | Alignement et traitement des échecs | Enregistrement TXT sous _dmarc | Dépend d’un SPF ou DKIM correctement configuré |
| Ensemble | Authentification des e-mails | Configuration coordonnée des trois protocoles | Ne garantit pas à lui seul la délivrabilité |
Configuration DNS : déployer les protections sans bloquer les envois
Une fois les rôles compris, l’inventaire des expéditeurs devient la première mesure opérationnelle. Un déploiement précipité peut bloquer des messages légitimes ; une progression contrôlée limite ce risque.
Recenser les services et publier SPF et DKIM
Pour chaque domaine, l’équipe recense la messagerie, le site web, le CRM, les outils RH et les plateformes marketing. Elle demande ensuite à chaque fournisseur les valeurs SPF et DKIM adaptées à son service.
Voici l’ordre de travail qui réduit les oublis et facilite les vérifications. Les modifications doivent être réalisées par une personne ayant accès à la zone DNS, ou par le prestataire qui l’administre.
Étapes de déploiement DNS :
- Inventaire des plateformes envoyant des messages au nom du domaine
- Consolidation du SPF existant sans créer de doublon
- Publication de chaque clé DKIM fournie par les services utilisés
- Contrôle des enregistrements après leur propagation DNS
Une boutique utilisant Google Workspace et un outil de commandes doit autoriser les deux services. Elle doit aussi vérifier que ses messages affichent le domaine attendu, faute de quoi DMARC peut échouer à l’alignement.
Commencer DMARC en mode observation
Après validation de SPF et DKIM, l’entreprise publie DMARC avec une politique « p=none ». Cette étape collecte des rapports sans demander le rejet des messages non conformes.
Selon les rapports, l’administrateur distingue les flux légitimes mal configurés des sources inconnues. Il peut ensuite passer progressivement à « quarantine », puis à « reject », lorsque les envois légitimes sont correctement authentifiés.
Le tableau précise l’effet de chaque politique ; l’observation préalable évite de transformer une protection contre le phishing en panne de communication.
Politiques DMARC disponibles :
| Politique | Action demandée | Usage courant |
|---|---|---|
| p=none | Surveillance sans rejet imposé | Inventaire initial des sources d’envoi |
| p=quarantine | Traitement suspect, souvent en courrier indésirable | Étape intermédiaire après analyse des rapports |
| p=reject | Refus des messages non conformes | Protection renforcée après vérification des flux |
| Rapports rua | Transmission de résultats agrégés | Suivi des sources et des échecs d’authentification |
Vérifier les résultats et préserver la délivrabilité des e-mails
Après la publication des enregistrements, il faut contrôler les messages réels et examiner les résultats dans la durée. Cette vérification relie la configuration technique à la délivrabilité des e-mails.
Contrôler chaque flux professionnel
Un test utile consiste à envoyer un message depuis chaque service recensé, puis à consulter ses en-têtes. Les résultats attendus indiquent généralement « pass » pour SPF, DKIM et DMARC, avec un domaine cohérent.
Les outils de diagnostic DNS peuvent repérer une erreur de syntaxe ou un enregistrement absent. Les rapports DMARC, eux, donnent une vue plus large des sources qui utilisent le domaine, y compris celles que l’équipe avait oubliées.
Vérifications après configuration :
- Test d’un message provenant de chaque plateforme répertoriée
- Contrôle des résultats SPF, DKIM et DMARC dans les en-têtes
- Examen régulier des rapports agrégés transmis à l’adresse prévue
- Nouvel audit DNS après une migration ou un changement de fournisseur
Éviter les erreurs qui fragilisent l’authentification
Deux enregistrements SPF pour un même domaine, une clé DKIM mal copiée ou un prestataire oublié peuvent compromettre la validation. Une migration d’hébergeur mérite aussi une vérification, car certains enregistrements TXT peuvent être omis.
Enfin, l’authentification ne suffit pas à garantir l’arrivée en boîte de réception. La qualité des listes, le consentement des destinataires et la réputation d’envoi influencent également les filtres ; SPF, DKIM et DMARC en constituent un socle technique essentiel.
Transformer l’analyse en décision
Les meilleures décisions reposent sur un cadre compréhensible, quelques critères vérifiables et une étape suivante clairement définie. Testez la méthode à petite échelle, mesurez le résultat puis ajustez avant de généraliser.
Votre checklist
- Définir le résultat attendu
- Identifier trois critères prioritaires
- Prévoir une mesure de contrôle
- Fixer une date de réévaluation
