Différences entre SPF, DKIM et DMARC expliquées pour les MSP

Résumé exécutif : Les MSP qui gèrent les environnements de messagerie de leurs clients ont besoin d’une combinaison de SPF, DKIM et DMARC pour se protéger des attaques par usurpation d’identité et se conformer aux exigences des fournisseurs de boîtes de réception. Ce guide explique comment fonctionne chaque protocole, pourquoi la combinaison des trois est essentielle, et comment les MSP peuvent déployer efficacement l’authentification des emails pour l’ensemble de leurs clients.

Points clés :

• SPF valide les adresses IP des serveurs d’envoi, DKIM vérifie l’intégrité des messages via des signatures cryptographiques, et DMARC applique la politique définie en cas d’échec de l’authentification
• Google et Yahoo exigent désormais SPF et DKIM pour les expéditeurs de masse, rendant l’authentification des emails essentielle pour la délivrabilité des clients
• Les MSP doivent implémenter SPF en premier, puis DKIM, enfin DMARC en mode p=none avant de passer progressivement à l’application stricte
• L’architecture multi-locataire de Red Sift OnDMARC permet aux MSP de gérer l’authentification sur tous les domaines clients depuis un tableau de bord unique, atteignant l’application stricte en 6 à 8 semaines contre 6 à 12 mois manuellement

Vous envoyez ce qui semble être un email professionnel habituel pour le compte d’un client, mais il revient en erreur ou aboutit en spam. Pire encore, les clients de votre client reçoivent des emails de phishing qui semblent émaner de son domaine, entachant sa réputation avant même qu’il n’ait connaissance du problème. Ces scénarios se produisent car l’email, par conception, ne vérifie pas l’identité de l’expéditeur.

Les protocoles d’email d’origine des années 1980 reposaient sur la confiance entre serveurs de messagerie. N’importe qui pouvait prétendre envoyer un email depuis n’importe quel domaine, et les serveurs destinataires n’avaient aucun moyen fiable de vérifier ces revendications. Cette faiblesse fondamentale rend possibles les attaques par usurpation, lors desquelles les attaquants falsifient l’adresse De pour usurper l’identité d’expéditeurs de confiance.

Les protocoles d’authentification email existent pour combler cette faille de sécurité. SPF, DKIM et DMARC travaillent ensemble pour vérifier que les emails prétendant provenir des domaines clients sont légitimes. Pour les MSP qui gèrent de nombreux environnements clients, comprendre le fonctionnement de chaque protocole et l’intérêt des trois est déterminant pour garantir une infrastructure email sécurisée et éviter les attaques de type usurpation ou phishing.

SPF (Sender Policy Framework) est une norme d’authentification email qui permet aux propriétaires de domaine de spécifier quelles adresses IP sont autorisées à envoyer des emails en leur nom. Lorsqu’un serveur de messagerie reçoit un mail se réclamant du domaine du client, il vérifie l’enregistrement SPF pour confirmer que l’IP de l’expéditeur figure dans la liste des serveurs autorisés.

Pensez à SPF comme à une liste d’invités à l’entrée d’un bâtiment sécurisé. Le serveur destinataire vérifie si l’IP de l’expéditeur figure sur la liste des expéditeurs autorisés publiée. Si c’est le cas, l’authentification SPF est réussie. Sinon, elle échoue.

DKIM (DomainKeys Identified Mail) utilise une autre approche en ajoutant une signature numérique dans les en-têtes du mail. Cette signature cryptographique prouve que le message n’a pas été altéré durant l’acheminement et qu’il provient d’un serveur ayant accès à la clé privée DKIM. Le serveur destinataire valide cette signature à l’aide de la clé publique publiée dans le DNS.

Là où SPF s’intéresse à l’identité du serveur d’envoi, DKIM vérifie le message en lui-même. La signature couvre à la fois les en-têtes et le corps du message, toute modification en transit entraîne donc un échec de la vérification.

DMARC (Domain-based Message Authentication, Reporting and Conformance) s’appuie sur SPF et DKIM en ajoutant une couche de politique et de reporting [1]. Tandis que SPF et DKIM valident des aspects différents d’un email, DMARC rattache ces contrôles au domaine visible dans la boîte de réception du destinataire et indique aux serveurs destinataires quoi faire en cas d’échec de l’authentification.

La différence essentielle est que DMARC vous donne le contrôle sur les emails ayant échoué à l’authentification. C’est vous qui choisissez : livrer quand même, placer en spam ou rejeter totalement. Pour les MSP, cela signifie que vous pouvez définir des politiques cohérentes sur l’ensemble des domaines clients.

Le guide sur la sécurité email de Red Sift fournit plus de contexte sur la façon dont DMARC coordonne SPF et DKIM pour offrir une protection complète des domaines.

La validation SPF survient lorsque le serveur destinataire consulte le DNS pour l’enregistrement SPF du domaine. Ce champ TXT liste les adresses IP autorisées et inclut des mécanismes comme « include » pour les services tiers. Le serveur compare l’IP de l’expéditeur à cette liste et retourne un résultat positif, négatif ou neutre [2].

• SPF : le serveur destinataire interroge le DNS, compare l’IP d’envoi à la liste autorisée, puis retourne passe/échoue/neutre
• DKIM : le serveur de messagerie signe le message avec une clé privée, le serveur destinataire récupère la clé publique via DNS puis valide la signature
• DMARC : contrôle les résultats SPF ou DKIM, vérifie l’alignement du domaine avec l’en-tête From, applique la politique selon la configuration

DKIM fonctionne via la cryptographie à clé publique. Le serveur de messagerie signe les messages sortants avec une clé privée, et les serveurs destinataires vérifient la signature à l’aide de la clé publique publiée dans le DNS. Si même un seul caractère du corps du mail est modifié en transit, la validation DKIM échoue.

DMARC coordonne ces deux méthodes d’authentification et ajoute des fonctionnalités essentielles. Lorsque vous publiez un enregistrement DMARC, vous définissez une politique (none, quarantine ou reject) qui indique aux serveurs destinataires comment traiter les emails n’ayant pas passé SPF ou DKIM. DMARC requiert aussi l’alignement, ce qui signifie que le domaine dans l’en-tête From doit correspondre au domaine authentifié par SPF ou DKIM.

La ressource guide complet DKIM et SPF expose en détail les aspects techniques permettant à ces protocoles de base de valider l’authenticité des emails.

Les attaques par usurpation d’identité coûtent en moyenne 1,6 million de dollars par incident aux organisations, selon le FBI. Sans protocoles d’authentification, les attaquants falsifient aisément les domaines clients dans l’en-tête From, usurpant dirigeants, clients ou partenaires. Ces compromissions business sont possibles car les protocoles email standards n’intègrent pas de vérification native d’expéditeur.

Pour les MSP, l’enjeu s’étend à l’ensemble de la clientèle. Un seul incident impactant un client nuit à votre réputation et génère l’inquiétude de l’ensemble des clients sur leur sécurité propre. L’impact financier va au-delà des pertes directes : gestion de crise, expertise forensique, frais juridiques, régulation, notifications clients… Les dégâts sur la réputation persistent souvent longtemps après la crise immédiate.

Les protocoles d’authentification protègent la réputation et la délivrabilité du domaine sur l’ensemble de votre portefeuille client. Les grands fournisseurs comme Google, Microsoft et Yahoo exigent désormais SPF et DKIM pour les expéditeurs de masse, et évaluent le respect de DMARC pour déterminer si les emails arrivent dans la boîte de réception ou en spam [3].

Au-delà de la protection des envois sortant, ces protocoles défendent les clients et partenaires de vos clients contre la réception de messages usurpés. Les rapports DMARC vous offrent une visibilité sur qui envoie des emails au nom de chaque domaine, qu’il s’agisse de services légitimes ou de tentatives malveillantes. Pour un MSP, cette visibilité centralisée sur tous les domaines clients est un atout stratégique majeur.

SPF et DKIM ont des rôles complémentaires. SPF valide l’autorisation du serveur d’envoi via l’IP, mais ne vérifie ni le contenu ni l’adresse From visible dans la boîte de réception. DKIM assure l’intégrité du message et l’authentification cryptographique, mais n’exige pas que le domaine de signature corresponde au From affiché.

C’est là que DMARC devient incontournable. DMARC impose « l’alignement » entre le domaine authentifié par SPF ou DKIM et celui affiché dans l’en-tête From. Ce contrôle bloque une méthode fréquente d’usurpation où les attaquants passent le SPF en utilisant leur propre domaine dans le mail-from tout en affichant celui du client dans le From visible.

• Couche 1 : Validation d’infrastructure (SPF) Valide l’adresse IP du serveur d’émission. Validation rapide à travers une requête DNS. Échoue lors d’un transfert de messagerie.
• Couche 2 : Validation des messages (DKIM) Garantit que le message n’a pas été modifié. Utilise une signature cryptographique. Résiste au transfert d’email.
• Couche 3 : Application de politique (DMARC) Impose l’alignement sur le From. Applique les politiques passe/quarantaine/rejet. Coordonne les résultats SPF et DKIM.

Les MSP mettent généralement en œuvre les trois protocoles par étapes. On commence par publier les enregistrements SPF et DKIM, puis on ajoute DMARC avec une politique « none » pour collecter des données sans impacter les flux. À mesure que vous identifiez et autorisez toutes les sources d’envoi client, vous progressez vers des politiques plus strictes.

Les protocoles ont aussi une valeur différente selon les flux. SPF fonctionne bien pour l’envoi direct depuis l’infrastructure client, mais montre ses limites lors d’un transfert. DKIM, lui, tient dans le transfert car la signature accompagne le message.

La mise en place de SPF commence par l’identification de chaque service et serveur utilisant le domaine client pour l’envoi de mails. Cela englobe serveurs de messagerie, plateformes marketing, CRM et services tiers. Chaque expéditeur légitime doit être inclus dans l’enregistrement SPF via son adresse IP ou un mécanisme « include ».

La phase d’inventaire révèle souvent des sources d’envoi inattendues. Les MSP constatent généralement que leurs clients utilisent plus de services email qu’ils ne le croyaient : notifications automatiques, help desk, outils RH, etc. Documenter cela sur l’ensemble de vos clients permet d’identifier des schémas récurrents à répliquer.

L’enregistrement SPF prend la forme d’un champ TXT dans le DNS, et suit une syntaxe précise. Un exemple : « v=spf1 ip4:192.0.2.1 include:_spf.google.com -all », où « -all » signifie que les IP non autorisées doivent échouer à l’authentification. L’enregistrement doit rester sous 255 caractères et ne pas dépasser 10 requêtes DNS sous peine d’échec.

La limite de 10 requêtes DNS est un piège fréquent qui casse subrepticement l’authentification. Chaque « include » compte, et certains services en chaînent plusieurs. Au-delà de cette limite, les serveurs de destination jugent l’enregistrement comme toujours en échec, bloquant ainsi la messagerie légitime. Il faut donc parfois « aplatir » les SPF en traduisant les includes en adresses IP, ou rationnaliser le nombre de services utilisés. Pour un MSP multi-clients, suivre ces compteurs devient indispensable au quotidien.

L’implémentation DKIM nécessite de générer une paire de clés publique/privée puis de configurer le serveur de messagerie pour signer les messages sortants avec la clé privée. La clé publique est publiée dans un champ DNS TXT sur un sous-domaine selector du type « selector1._domainkey.clientdomain.com ». La plupart des plateformes proposent des outils pour générer les clés et mettre en place la signature DKIM.

Phase de paramétrage SPF

• Auditez tous les services d’envoi pour chaque client
• Documentez les adresses IP et les mécanismes include
• Créez un enregistrement SPF avec le préfixe v=spf1
• Vérifiez que le nombre de requêtes reste sous 10
• Testez avec un outil de validation SPF
• Publiez dans le DNS et vérifiez la propagation

Phase de paramétrage DKIM

• Générez une paire de clés 2048 bits
• Configurez le serveur de messagerie avec la clé privée
• Publiez la clé publique dans le DNS
• Activez la signature DKIM pour tous les mails sortants
• Envoyez des tests et vérifiez les en-têtes
• Coordonnez-vous avec les services tiers

Phase de paramétrage DMARC

• Démarrez avec une politique p=none (veille seulement)
• Configurez l’adresse de rapport agrégé (rua=)
• Publiez l’enregistrement DMARC dans le DNS
• Analysez les rapports pendant 2 à 4 semaines
• Identifiez et corrigez les échecs d’authentification
• Progressez vers p=quarantine puis p=reject

La longueur de clé compte pour la sécurité DKIM : utilisez au moins du 1024 bits, voire 2048 bits pour anticiper les attaques futures. Certains MSP pratiquent une rotation des clés DKIM à intervalles réguliers sur l’ensemble des environnements clients.

Pour DMARC, créez un champ TXT sur « _dmarc.clientdomain.com » indiquant la politique et les préférences de reporting. Commencez par « v=DMARC1; p=none; rua=mailto:dmarc-reports@yourmsp.com » afin de recueillir les données sans bloquer. Le tag rua indique dans quelle boîte cibler les rapports agrégés afin de visualiser en un point les statistiques d’authentification sur tous les clients.

Les rapports arrivent sous forme de fichiers XML détaillant l’authentification de chaque email envoyé par chaque domaine client. Sans analyse automatisée, leur lecture est complexe à grande échelle. Vous verrez ainsi exactement quelles sources passent ou échouent SPF/DKIM, ce qui aide à identifier et corriger les erreurs avant d’appliquer des politiques strictes.

Le guide complet de mise en œuvre DMARC détaille chaque étape, du démarrage à l’application stricte (p=reject).

La question n’est pas de choisir un protocole, mais de déterminer l’ordre de leur mise en place. Les trois sont nécessaires à une sécurité email complète : SPF et DKIM fournissent les mécanismes d’authentification, DMARC orchestre l’ensemble avec l’application de politique et la visibilité.

Démarrez par SPF car il est le plus simple à implémenter. En quelques heures, vous identifiez les sources d’envoi et publiez l’enregistrement DNS. SPF seul procure déjà une protection de base et améliore la délivrabilité auprès des grands prestataires.

Ajoutez DKIM ensuite, pour une authentification plus robuste. Les signatures cryptographiques DKIM ne peuvent être facilement usurpées et, contrairement à SPF, DKIM fonctionne même avec le transfert d’email. Ensemble, SPF et DKIM offrent deux mécanismes indépendants sur lesquels DMARC s’appuie.

Implémentez DMARC en dernier car son efficacité dépend de SPF et DKIM. Commencez par une politique uniquement de supervision (p=none) pour identifier toutes les sources légitimes, puis montez progressivement vers les politiques de quarantaine puis de rejet au fil de votre maîtrise de la configuration.

Certains MSP se demandent s’ils peuvent économiser du temps en ne paramétrant qu’un ou deux protocoles chez les clients. Cette approche laisse d’importantes failles. SPF seul ne prévient pas certains types d’usurpation. DKIM seul n’impose pas d’alignement du From. Seul DMARC permet l’application de politique réellement bloquante pour les emails usurpés.

L’authentification manuelle sur des dizaines ou centaines de domaines clients suppose de suivre de nombreux enregistrements DNS, d’analyser des rapports XML complexes, et de coordonner chaque service tiers pour chaque client. La plateforme Red Sift OnDMARC automatise ce processus, permettant aux MSP d’atteindre l’application DMARC sur tout leur portefeuille en 6 à 8 semaines au lieu de 6 à 12 mois manuellement.

La plateforme commence par surveiller l’ensemble de l’écosystème : elle identifie d’emblée toutes les sources d’envoi pour chaque client. Au lieu d’analyser manuellement les rapports DMARC bruts, vous disposez d’un tableau de bord visuel qui montre quelles sources sont authentifiées et lesquelles nécessitent une action, sur tous vos clients.

OnDMARC catégorise automatiquement les sources d’envoi : serveurs de messagerie, services tiers autorisés, sources potentiellement malveillantes. La plateforme indique exactement quels services passent l’authentification et lesquels nécessitent un ajustement pour chaque client.

La solution détecte les erreurs de configuration SPF, DKIM, DMARC et propose des actions correctives claires. Lors de la montée en enforcement DMARC, OnDMARC surveille l’impact et vous alerte si des mails légitimes risquent d’être bloqués. La plateforme prédit même les conséquences des changements avant leur mise en production, ce qui réduit le risque de blocage de légitimes pour vos clients.

Pour les MSP avec de nombreux clients et des environnements complexes, OnDMARC offre une gestion et un reporting centralisés. Vous visualisez l’état de l’authentification sur tout votre portefeuille et appliquez facilement des politiques homogènes. L’architecture multi-locataire permet une gestion globale dans une seule interface, tout en gardant la séparation des données nécessaire.

La plateforme Red Sift OnDMARC s’adapte des MSP de petite taille jusqu’aux plus grands prestataires MSSP gérant des centaines de domaines clients.

[1] « DMARC vs SPF vs DKIM - The Ultimate Comparison. » courier.com. https://www.courier.com/guides/dmarc-vs-spf-vs-dkim

[2] « What are DMARC, DKIM, and SPF ? » Cloudflare. https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/

[3] « SPF, DKIM, DMARC : The 3 Pillars of Email Authentication. » higherlogic.com, 2024-01-01. https://www.higherlogic.com/blog/spf-dkim-dmarc-email-authentication/