SPF, DKIM et DMARC : comprendre l’authentification des e-mails

Un e-mail peut afficher le nom d’un fournisseur habituel et une adresse familière tout en provenant d’un serveur contrôlé par un fraudeur. Pour réduire ce risque, l’authentification des e-mails s’appuie notamment sur trois mécanismes : SPF, DKIM et DMARC. Ils permettent de vérifier l’autorisation d’envoi, de contrôler une signature numérique et de définir le traitement des messages qui échouent aux vérifications. Leur efficacité dépend toutefois de leur configuration et des protections qui les accompagnent.

Pourquoi l’adresse affichée ne suffit pas

Un message possède plusieurs informations d’expédition. L’adresse du champ « De », visible dans votre messagerie, peut différer de l’adresse technique utilisée pendant son transport, notamment pour gérer les erreurs de livraison.

Cette distinction explique une partie du problème : une adresse affichée n’est pas, à elle seule, une preuve d’origine. Le nom « Service comptabilité » l’est encore moins, puisqu’un expéditeur peut le choisir librement.

SPF, DKIM et DMARC ajoutent des vérifications fondées sur des informations publiées dans le DNS, le système qui contient notamment les paramètres techniques des noms de domaine. Chaque mécanisme examine un aspect différent du message.

SPF, DKIM et DMARC : trois rôles complémentaires

SPF : vérifier les serveurs autorisés à envoyer

SPF permet au responsable d’un domaine de déclarer les serveurs autorisés à l’utiliser pour expédier des e-mails. Cette déclaration prend généralement la forme d’un enregistrement DNS de type TXT.

À la réception, le serveur destinataire compare l’adresse IP du serveur qui lui transmet le message aux autorisations publiées.

La nuance essentielle concerne l’identité contrôlée : SPF vérifie principalement le domaine de l’adresse d’enveloppe, utilisée dans la commande technique MAIL FROM. Il ne vérifie pas directement l’adresse du champ « De » affichée au lecteur.

Un résultat SPF positif ne suffit donc pas à garantir que le domaine visible est légitime. Par ailleurs, une redirection peut provoquer un échec SPF : le serveur intermédiaire qui retransmet le message n’est pas nécessairement autorisé par le domaine d’origine.

DKIM : vérifier une signature liée à un domaine

DKIM ajoute une signature cryptographique aux messages sortants. Le système d’envoi signe le message avec une clé privée ; le destinataire récupère la clé publique correspondante dans le DNS pour vérifier cette signature.

Une signature valide permet d’associer le message au domaine signataire et de vérifier l’intégrité des éléments couverts, notamment certains en-têtes et le corps du message.

DKIM peut rester valide après une redirection si les éléments signés sont préservés. En revanche, une liste de diffusion qui modifie l’objet ou ajoute un pied de page peut invalider la signature.

Cette signature ne chiffre pas le contenu et ne certifie pas l’identité de la personne qui écrit. Le domaine signataire peut aussi être différent de celui affiché dans le champ « De ».

DMARC : relier les vérifications au domaine visible

DMARC utilise les résultats de SPF et de DKIM pour protéger le domaine du champ « De ». Il introduit une notion centrale : l’alignement des domaines.

Pour réussir DMARC, il faut au moins l’une de ces deux conditions :

• SPF réussit et le domaine qu’il authentifie est aligné avec celui du champ « De » ;
• une signature DKIM est valide et son domaine signataire est aligné avec celui du champ « De ».

L’alignement peut exiger une correspondance exacte ou accepter des domaines rattachés au même domaine organisationnel, selon le réglage choisi. Les deux mécanismes n’ont donc pas besoin de réussir simultanément pour que DMARC réussisse.

Le propriétaire publie également une politique :

• p=none : aucune mesure particulière demandée au titre de DMARC ;
• p=quarantine : demander un traitement comme message suspect, par exemple un classement en indésirables ;
• p=reject : demander le rejet des messages qui échouent à DMARC.

Le serveur destinataire conserve la décision finale selon ses propres règles.

Un exemple d’usurpation d’adresse e-mail

Supposons qu’un fraudeur affiche [email protected] dans le champ « De », mais utilise son propre domaine pour l’enveloppe et la signature DKIM.

Ses contrôles SPF et DKIM peuvent réussir pour son domaine. Pourtant, ils ne sont pas alignés avec entreprise.example : DMARC échoue.

Si le domaine usurpé publie une politique de rejet et que le destinataire l’applique, le message peut être refusé avant d’atteindre la boîte du lecteur.

À l’inverse, un message envoyé depuis un compte réellement compromis peut réussir les trois contrôles. Il emprunte alors une infrastructure autorisée, même si son contenu est frauduleux.

Pourquoi l’antivirus et l’antispam restent nécessaires

L’authentification examine l’origine technique du message. L’antivirus recherche des éléments malveillants, notamment dans les pièces jointes. L’antispam évalue d’autres indices : réputation de l’expéditeur, caractéristiques du contenu, liens ou comportements d’envoi.

Ces contrôles répondent à des questions différentes. Une pièce jointe infectée peut accompagner un message correctement authentifié. Un fraudeur peut également enregistrer son propre domaine, configurer SPF, DKIM et DMARC, puis envoyer une fausse demande de paiement.

Un résultat DMARC positif ne justifie donc pas de désactiver les autres analyses. Il fournit un signal utile parmi ceux que la protection de messagerie doit examiner.

Les limites à connaître

Ces mécanismes réduisent certaines formes d’usurpation de domaine, mais plusieurs situations restent possibles :

• Un domaine ressemblant au vrai : une lettre remplacée ou un mot ajouté peut tromper le lecteur, même avec une authentification valide.
• Un nom d’expéditeur trompeur : afficher le nom d’un dirigeant ne nécessite pas d’utiliser son domaine.
• Un compte ou un prestataire compromis : les messages peuvent partir par les circuits autorisés.
• Un message légitime modifié en transit : certaines redirections et listes de diffusion perturbent les vérifications.

Une authentification réussie ne garantit pas non plus l’arrivée en boîte principale. Les filtres peuvent toujours classer le message comme indésirable.

Pour une demande sensible, comme un changement de coordonnées bancaires, une vérification par un canal déjà connu reste indispensable.

Déployer ces protections sans bloquer les envois légitimes

Le déploiement commence par un inventaire : messagerie principale, outil de facturation, formulaires du site, plateforme d’envoi de lettres d’information et autres prestataires. Oublier une source peut entraîner le rejet de messages utiles.

Le guide de configuration de DMARC proposé par Cybermalveillance.gouv.fr accompagne les organisations dans cette démarche de protection de leur domaine.

Une progression pratique consiste à :

1. Configurer SPF et activer DKIM sur chaque service d’envoi, en vérifiant l’alignement.
2. Publier une politique DMARC d’observation avec p=none et configurer la réception des rapports agrégés.
3. Analyser les rapports transmis par les destinataires participants pour repérer les sources oubliées et les échecs.
4. Passer progressivement à une politique de quarantaine, puis de rejet, après validation des flux légitimes.
5. Recontrôler la configuration lors de tout changement de prestataire.

Publier ces paramètres protège vos envois ; votre service de réception doit également vérifier les messages entrants. Pour un utilisateur sans domaine personnel, ces réglages relèvent généralement du fournisseur de messagerie. La vigilance face aux liens, aux pièces jointes et aux demandes inhabituelles reste complémentaire de ce travail technique.