SPF, DKIM et DMARC : sécuriser l’authentification de vos e-mails

Un e-mail affichant votre nom de domaine peut être envoyé par un serveur qui ne vous appartient pas. Cette usurpation, appelée spoofing, alimente les campagnes de phishing, dégrade la réputation du domaine et peut conduire vos correspondants à faire confiance à un message frauduleux. SPF, DKIM et DMARC forment un ensemble complémentaire pour réduire ce risque.

Ces mécanismes ne garantissent pas qu’un message est légitime et ne remplacent ni un filtre antispam ni une politique de sécurité. Ils permettent toutefois aux serveurs destinataires de vérifier l’origine technique d’un message, son intégrité et la cohérence entre son expéditeur affiché et son domaine d’envoi.

SPF : autoriser les serveurs qui envoient vos e-mails

SPF, pour Sender Policy Framework, est une règle publiée dans le DNS sous la forme d’un enregistrement TXT. Elle indique quels serveurs ou services sont autorisés à envoyer des messages pour un domaine donné.

Lorsqu’un serveur reçoit un e-mail, il consulte le domaine utilisé dans l’enveloppe SMTP, généralement appelé MAIL FROM ou Return-Path. Il compare ensuite l’adresse IP du serveur expéditeur avec la politique SPF publiée par ce domaine.

Un exemple simplifié pourrait ressembler à ceci :

example.fr. IN TXT "v=spf1 ip4:203.0.113.10 include:spf.exemple-mail.com -all"

• ip4:203.0.113.10 autorise une adresse IP précise ;
• include: délègue l’autorisation à la politique d’un prestataire d’envoi ;
• -all indique que les autres serveurs ne sont pas autorisés.

SPF permet donc de détecter un serveur non autorisé, mais il ne signe pas le contenu du message. Il présente aussi des limites : les transferts d’e-mails peuvent modifier l’adresse IP apparente et faire échouer le contrôle. De plus, la norme SPF limite à dix le nombre de recherches DNS effectuées pendant l’évaluation d’une politique, ce qui peut poser problème avec des politiques trop complexes.

DKIM : signer le message et vérifier son intégrité

DKIM, pour DomainKeys Identified Mail, ajoute une signature cryptographique aux e-mails sortants. Le serveur d’envoi conserve une clé privée, tandis que la clé publique correspondante est publiée dans le DNS.

La signature contient notamment un sélecteur, le domaine signataire et une empreinte calculée à partir de certains en-têtes et du corps du message. Le serveur destinataire récupère la clé publique à une adresse DNS de ce type :

selector1._domainkey.example.fr

Il peut alors vérifier deux éléments :

• le message a bien été signé par un serveur possédant la clé privée ;
• les parties signées n’ont pas été modifiées après l’envoi.

DKIM résiste mieux que SPF à certains transferts, car la signature reste attachée au message. Elle peut néanmoins devenir invalide si un intermédiaire modifie une partie signée, par exemple en réécrivant le contenu ou certains en-têtes. La gestion des clés doit également être rigoureuse : rotation régulière, protection de la clé privée et suppression des anciens sélecteurs devenus inutiles.

DMARC : relier l’authentification à l’adresse visible

DMARC, pour Domain-based Message Authentication, Reporting and Conformance, ajoute une politique au-dessus de SPF et DKIM. Son objectif principal est d’empêcher qu’un attaquant utilise votre domaine dans le champ From: visible par le destinataire.

DMARC vérifie l’alignement entre le domaine visible dans From: et le domaine validé par SPF ou DKIM. Pour qu’un message passe DMARC, au moins l’un des deux contrôles doit réussir et être aligné avec le domaine affiché.

La politique DMARC est également publiée dans le DNS, sous un nom comme :

_dmarc.example.fr. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.fr"

Le paramètre p définit la décision à appliquer aux messages qui échouent :

• p=none : observer et recevoir des rapports, sans demander de blocage ;
• p=quarantine : considérer les messages suspects comme indésirables ;
• p=reject : demander le rejet des messages non conformes.

Une mise en œuvre progressive commence généralement par p=none. Les rapports agrégés reçus via rua permettent d’identifier les services légitimes qui envoient pour le domaine : plateforme marketing, outil de facturation, CRM, formulaire web ou logiciel métier. Après correction des sources légitimes, la politique peut évoluer vers quarantine, puis éventuellement reject.

Pourquoi activer les trois mécanismes ?

SPF, DKIM et DMARC ne font pas exactement le même travail. SPF vérifie l’autorisation de l’infrastructure d’envoi. DKIM vérifie une signature et l’intégrité du message. DMARC exploite ces résultats pour appliquer une règle cohérente au domaine visible par l’utilisateur.

Cette combinaison apporte plusieurs bénéfices concrets :

• réduire l’usurpation du domaine dans les campagnes de phishing ;
• améliorer la probabilité que les messages légitimes soient correctement identifiés ;
• obtenir une visibilité sur les services qui envoient des e-mails au nom de l’organisation ;
• protéger la réputation du domaine en limitant les messages frauduleux qui lui sont associés ;
• répondre aux exigences croissantes de certains grands fournisseurs de messagerie.

Il faut cependant éviter une erreur fréquente : publier une politique p=reject avant d’avoir recensé les expéditeurs réels. Une newsletter oubliée, un ticket automatique ou une application interne peut alors ne plus parvenir à ses destinataires.

Vérifier la configuration avec le test DMARC de MXToolbox

Pour effectuer un premier contrôle, ouvrez MXToolbox, recherchez l’outil de test DMARC, puis saisissez votre nom de domaine, sans adresse e-mail complète. Le service interroge le DNS et signale généralement la présence ou l’absence de l’enregistrement DMARC ainsi que plusieurs erreurs courantes.

Une vérification utile ne consiste pas seulement à rechercher la mention « DMARC record published ». Contrôlez aussi :

1. que l’enregistrement commence par v=DMARC1 ;
2. que le domaine utilise une seule politique DMARC valide ;
3. que la valeur de p correspond à la phase de déploiement choisie ;
4. que l’adresse rua est surveillée et capable de recevoir les rapports ;
5. que SPF et DKIM sont également publiés et configurés chez les prestataires utilisés ;
6. que les domaines sont alignés avec le domaine visible dans From:.

Le test MXToolbox est un contrôle externe pratique, mais il ne remplace pas l’analyse de messages réels. Envoyez des e-mails depuis chaque service légitime, puis examinez les en-têtes reçus. Les champs Authentication-Results, Received-SPF et DKIM-Signature indiquent les résultats observés par le serveur destinataire.

Les risques d’une absence de configuration

Sans SPF, un destinataire ne dispose d’aucune liste publiée des serveurs autorisés pour votre domaine. Sans DKIM, il ne peut pas s’appuyer sur une signature cryptographique durable. Sans DMARC, même un échec SPF ou DKIM ne s’accompagne d’aucune instruction claire concernant le message.

Les conséquences possibles sont une usurpation plus facile, des attaques ciblées contre les clients ou les salariés, une perte de confiance et une dégradation de la délivrabilité. Votre domaine peut aussi apparaître dans des campagnes frauduleuses sans que vous disposiez de rapports permettant d’en mesurer l’ampleur.

À l’inverse, une configuration incorrecte présente un risque opérationnel : messages légitimes rejetés, rapports envoyés vers une boîte non surveillée, dépassement des recherches DNS SPF ou dépendance à un prestataire dont les paramètres changent. La sécurité doit donc être déployée avec inventaire, tests et suivi.

Plan d’action recommandé

1. Recenser tous les services qui envoient des e-mails pour le domaine.
2. Publier une politique SPF unique et limitée aux sources réellement utilisées.
3. Activer DKIM chez chaque prestataire et vérifier les sélecteurs DNS.
4. Publier DMARC avec p=none et une adresse de rapports dédiée.
5. Analyser les rapports et les en-têtes pendant une période représentative.
6. Corriger les problèmes d’alignement, puis renforcer progressivement vers quarantine et reject.

Les définitions et le fonctionnement de ces mécanismes sont documentés dans les standards RFC 7208 pour SPF, RFC 6376 pour DKIM et RFC 7489 pour DMARC.

Conclusion

SPF, DKIM et DMARC constituent une base pragmatique pour réduire l’usurpation d’identité par e-mail. La bonne méthode consiste à commencer par observer, à identifier toutes les sources légitimes, puis à renforcer progressivement la politique. Utilisez le test DMARC de MXToolbox pour repérer les erreurs DNS, mais validez toujours le résultat avec des envois réels et une surveillance régulière des rapports.