SPF, DKIM, DMARC : empêcher l'usurpation d'e-mail

Le protocole qui transporte les e-mails a été conçu à une époque où toutes les machines du réseau étaient connues et de confiance. Il ne comporte aucun moyen natif de vérifier d'où vient réellement un message. L'adresse « De » que vous voyez dans votre logiciel de messagerie n'est qu'un champ que l'expéditeur a choisi de remplir — rien de plus.

N'importe qui, depuis n'importe où, peut donc y inscrire votre domaine. Tant que vous ne publiez pas d'enregistrements indiquant quels serveurs sont autorisés à envoyer en votre nom, un serveur destinataire n'a aucun moyen de distinguer votre vraie facture d'une fausse.

C'est pourquoi la fraude au président et la fraude au virement fonctionnent si bien et restent si rentables. L'attaquant n'a besoin de pénétrer nulle part : un domaine non protégé lui offre gratuitement une identité crédible.

Trois enregistrements, trois rôles distincts - SPF déclare quels serveurs peuvent envoyer du courrier pour votre domaine. - DKIM signe cryptographiquement vos messages, rendant détectables la falsification et la contrefaçon. - DMARC relie les deux, indique aux destinataires quoi faire en cas d’échec, et vous envoie des rapports.

Ce ne sont pas des alternatives. SPF et DKIM sans DMARC produisent un verdict que personne n'applique ; DMARC sans SPF ni DKIM n'a rien à vérifier.

SPF est un unique enregistrement DNS de type TXT qui liste les serveurs autorisés à envoyer des e-mails pour votre domaine. Vous pouvez lire le vôtre en une commande :

dig +short TXT exemple.com | grep spf1
"v=spf1 include:_spf.google.com include:sendgrid.net -all"

Il se lit de gauche à droite : la version, puis chaque source autorisée, puis la politique pour tout le reste. C'est ce dernier mécanisme qui décide si l'enregistrement sert à quelque chose.

• -all est un échec strict. Tout ce qui n'est pas listé n'est pas autorisé. C'est ce qu'il vous faut.
• ~all est un échec souple : non autorisé, délivré quand même, signalé. Utile en phase de test, pas comme destination.
• +all autorise Internet entier à envoyer en votre nom. Ce n'est jamais correct.

La limite des dix résolutions C'est le piège qui rattrape la plupart des organisations, et il se déclenche sans le moindre avertissement.

SPF autorise au maximum dix résolutions DNS lors de l'évaluation d'un enregistrement. Chaque include: compte, y compris ceux imbriqués dans les enregistrements de vos propres prestataires. Google Workspace en consomme déjà plusieurs à lui seul. Ajoutez Microsoft 365, un expéditeur transactionnel et une plateforme marketing : vous dépassez dix sans avoir rien fait d'inhabituel.

Au-delà de la limite, l'enregistrement ne se dégrade pas progressivement. Il renvoie permerror, et les destinataires traitent un permerror comme ils traitent un domaine sans aucun SPF. Votre enregistrement, lui, continue de paraître parfaitement valide quand vous le lisez.

Retirez les include: des services que vous n'utilisez plus, prenez l'include le plus étroit que documente chaque prestataire, et si vous dépassez encore, aplatissez l'enregistrement en plages d'adresses explicites. L'aplatissement fonctionne, mais il transforme un enregistrement entretenu en un enregistrement qu'il faut désormais revérifier à chaque changement de plages chez un prestataire.

DKIM ajoute une signature cryptographique aux en-têtes de chaque message que vous envoyez. Votre prestataire signe avec une clé privée, la clé publique correspondante est publiée dans votre DNS, et le destinataire récupère cette clé pour vérifier la signature. Il en tire deux informations : le message a bien été autorisé par votre domaine, et il n'a pas été altéré en chemin.

Lire votre propre clé DKIM suppose de connaître le sélecteur, qui dépend du prestataire. Google Workspace utilise google par défaut ; Microsoft 365 utilise selector1 et selector2.

dig +short TXT google._domainkey.exemple.com
dig +short TXT selector1._domainkey.exemple.com

Le sélecteur est ce qui permet à plusieurs clés de coexister : c'est lui qui rend possible la rotation sans interruption, et qui laisse chaque prestataire signer indépendamment.

Pourquoi DKIM compte plus que SPF sur le courrier transféré Quand un message est transféré, le serveur d'envoi change. SPF échoue, et il échoue à juste titre : le serveur qui transfère ne figure effectivement pas dans votre liste d'autorisation. La signature DKIM, elle, voyage avec le message et reste valide.

Un domaine qui ne repose que sur SPF voit donc du courrier légitime transféré échouer à l'authentification. Les listes de diffusion, les redirections d'anciens élèves et les adresses de fonction qui renvoient ailleurs tombent toutes dans ce cas. C'est la première raison pour laquelle un déploiement DMARC est abandonné à mi-parcours : les échecs ont l'air réels et personne ne sait les expliquer.

Activez DKIM chez chaque prestataire qui envoie en votre nom. Un prestataire incapable de signer votre courrier est un prestataire qui continuera d'échouer à DMARC.

SPF et DKIM produisent des verdicts. À eux seuls, rien n'oblige un serveur destinataire à en tenir compte. DMARC est l'enregistrement qui dit quoi faire, et qui demande aux destinataires de vous faire un retour.

dig +short TXT _dmarc.exemple.com
"v=DMARC1; p=reject; rua=mailto:dmarc@exemple.com; adkim=s; aspf=s"

• p=none : observation seule. Rien n’est bloqué, vous recevez simplement des rapports.
• p=quarantine : le courrier en échec part dans les indésirables.
• p=reject : le courrier en échec est refusé. C’est la destination.
• rua : l’adresse qui reçoit les rapports agrégés. Sans elle, vous déployez à l’aveugle.

L'alignement, et le faux vert qu'il produit DMARC ne demande pas seulement si SPF ou DKIM a réussi. Il demande si le domaine qui a réussi est bien celui que votre lecteur voit dans le champ « De ».

Un message peut réussir SPF pour le domaine propre d'un prestataire et échouer malgré tout à DMARC, parce que ce domaine n'est pas le vôtre. C'est volontaire. Sans alignement, n'importe qui pourrait réussir SPF pour un domaine qu'il contrôle tout en affichant le vôtre.

C'est aussi la raison pour laquelle un domaine ressort au vert sur un vérificateur SPF ou DKIM générique tout en restant parfaitement usurpable. Ces outils répondent à « cet enregistrement est-il syntaxiquement valide », ce qui n'est pas la même question que « cet enregistrement protège-t-il l'adresse que mes clients voient réellement ». ReconScope évalue les trois enregistrements comme le ferait un serveur destinataire, face au domaine visible dans le champ « De » : c'est pourquoi son verdict contredit parfois un vérificateur qui annonçait que tout allait bien.

Une dernière chose qu'il vaut mieux dire sans détour : p=none n'apporte aucune protection. Un domaine resté en p=none est exactement aussi usurpable qu'un domaine sans enregistrement DMARC. Il génère seulement des rapports à ce sujet.

La crainte est légitime : un p=reject précipité bloque de vraies factures, de vraies infolettres, de vrais e-mails de recrutement. Le déploiement par étapes existe précisément pour l'éviter, et il n'est pas optionnel.

1. Inventoriez ce qui envoie en votre nom Presque toujours plus que prévu : votre plateforme de messagerie, le CRM, l'outil de facturation, la billetterie, la plateforme marketing, les alertes de supervision, le logiciel de recrutement. Chacun doit être autorisé dans SPF et signer en DKIM.

2. Publiez SPF et DKIM, puis DMARC en p=none Rien n'est bloqué à ce stade. Vous ouvrez le canal de reporting.

3. Lisez les rapports pendant deux à quatre semaines Les rapports agrégés arrivent en XML et sont pénibles à lire bruts ; un analyseur de rapports vaut le temps de sa mise en place. Ce que vous cherchez, c'est une source légitime qui échoue : c'est un prestataire que vous aviez oublié d'autoriser.

4. Corrigez les échecs, puis passez en quarantine N'avancez pas tant que des sources légitimes échouent encore. C'est en avançant trop tôt qu'on casse du courrier réel.

5. Passez en p=reject une fois les rapports propres Comptez généralement deux à trois mois de bout en bout pour une organisation qui a plusieurs expéditeurs. Il n'y a aucun bénéfice à se précipiter, et un dommage réel à le faire.

Une étape intermédiaire utile : pct=25 applique la politique à un quart du courrier en échec, ce qui permet de monter progressivement plutôt que d'un coup.

DMARC protège votre domaine. Il ne fait rien contre un domaine différent qui se contente de lui ressembler.

Un attaquant qui ne peut pas envoyer depuis exemple.com enregistre à la place exemp1e.com, exemple-support.com ou exemple.co. Pour un lecteur qui parcourt sa boîte de réception, la différence est invisible, et l'attaquant contrôle entièrement ce domaine : il peut donc y publier des enregistrements SPF, DKIM et DMARC irréprochables.

Tous les voisins ne sont pas des menaces N'importe quel domaine a des dizaines de voisins orthographiques, et les traiter tous comme des attaques produit une liste que personne n'exploite. ReconScope ne compte un sosie que si deux conditions sont réunies : il peut réellement être pris pour le vôtre, c'est-à-dire votre nom de marque exact sous une autre extension ou une variante que l'œil ne rattrape pas, et il a été enregistré après votre propre domaine.

Un voisin d'orthographe antérieur à votre marque ne vous vise pas. Il est listé à part et ne pénalise jamais votre score. Un serveur mail seul non plus, puisque toute entreprise réelle en a un.

Restent les deux formes qui comptent :

• Votre nom de marque exact sous une autre extension. La plus convaincante de toutes, parce que le nom, lui, est juste.
• Des caractères qui ne se distinguent pas à l’œil : un l minuscule pour un i, rn pour m, une lettre doublée.

Un sosie devient dangereux quand il est configuré pour envoyer des e-mails, car il peut alors facturer vos clients en votre nom, ou quand il héberge une page de connexion : il collecte alors les identifiants de vos clients et de vos équipes.

Que faire Signalez le domaine à son bureau d'enregistrement et aux services anti-phishing, Google Safe Browsing en premier lieu. Prévenez vos équipes, et vos clients quand le risque est concret. Maintenez DMARC en p=reject pour qu'un sosie ne puisse pas en plus usurper votre vrai domaine. Puis envisagez l'enregistrement défensif des variantes les plus proches que vous ne possédez pas encore. Un domaine coûte une dizaine d'euros par an, soit moins cher qu'une seule facture frauduleuse.

L'authentification décide si un destinataire fait confiance à votre identité. La réputation décide s'il accepte votre courrier tout court. Les deux sont liées mais distinctes, et un domaine parfaitement authentifié peut malgré tout finir en indésirable.

Les listes noires Si votre IP d'envoi ou votre domaine figure sur une liste comme Spamhaus, SpamCop ou SURBL, le courrier légitime part en spam ou est rejeté. La cause est presque toujours l'une de trois : une boîte compromise qui envoie en votre nom, un relais ouvert, ou une erreur de configuration.

Trouvez la cause et corrigez-la avant de demander le retrait. Une demande de retrait sur un problème non corrigé vous fait réinscrire quelques jours plus tard, et les demandes répétées abîment votre crédit auprès de l'opérateur de la liste.

Les signalements malware et phishing Si une page de votre domaine est signalée pour hébergement de phishing ou de malware, les conséquences dépassent largement l'e-mail : les navigateurs affichent un avertissement rouge à chaque visiteur, et cet avertissement s'affiche avant votre site.

Une seule page compromise suffit à faire signaler tout un domaine, et elle arrive généralement par une extension de CMS obsolète ou par des identifiants qui ont fuité ailleurs. Nettoyez la page, demandez la réévaluation, puis cherchez comment elle a pu être publiée. C'est parce qu'on saute cette dernière étape qu'un même domaine se fait signaler deux fois.