On a reçu un email (pas si) suspect

On vous raconte comment un simple email reçu chez AZTK nous a amenés à nous intéresser aux limites de l'authentification des messages. Et pourquoi un email parfaitement authentifié n'est pas nécessairement fiable.

Le 7 octobre dernier, nous recevons une demande de devis sur l'adresse de contact d'AZTK. Un potentiel client cherche un professionnel pour l'accompagner sur un projet. Il explique disposer d'un dossier avec ses besoins et ses contraintes techniques, et propose de nous le transmettre pour obtenir notre avis et une estimation.

Jusque-là, rien de bien étonnant. C'est même plutôt le genre de message qu'on aime recevoir. L'email est correctement rédigé, le ton est professionnel et la demande correspond à notre activité. Pas de fautes grossières, pas de lien douteux qui saute aux yeux, ni de demande bizarre.

Pourtant, en regardant les informations de l'expéditeur, quelque chose nous interpelle. On commence à creuser. Et ce qui devait être une simple vérification nous amène à nous intéresser à trois mécanismes dont vous avez peut-être déjà entendu parler : SPF, DKIM et DMARC.

Une demande de devis qui nous a mis la puce à l'oreille

Le premier détail, c'est l'adresse d'expédition. Elle utilise le nom de domaine d'une entreprise qui existe réellement (chouette site sur lequel on aurait eu plaisir à travailler). À première vue, cela donne plutôt confiance. Sauf que le nom de notre interlocuteur ne semble pas correspondre à l'identité associée à cette adresse.

Nous remarquons ensuite que le champ Reply-To, celui qui indique où sera envoyée notre réponse, contient une adresse Gmail personnelle, différente de l'adresse professionnelle affichée comme expéditeur. Ce n'est pas nécessairement suspect en soi. Certaines entreprises utilisent volontairement des adresses différentes pour envoyer et recevoir leurs messages.

Mais cette différence, associée à l'identité qui ne colle pas tout à fait, commence à faire beaucoup de petites incohérences. Et puis il y a cette proposition de nous transmettre un dossier complet dans un second temps.

Là encore, c'est parfaitement normal lorsqu'on travaille dans le développement. On échange régulièrement des cahiers des charges, des documents techniques et des fichiers transmis par de nouveaux interlocuteurs.

C'est aussi un scénario qui pourrait servir de point de départ à une tentative de phishing : engager une conversation crédible, puis proposer de consulter un document ou de récupérer un fichier. À ce moment-là, nous n'avons aucune certitude sur les intentions de l'expéditeur. Simplement assez de questions pour avoir envie de regarder ce qui se passe derrière cet email.

On a creusé et là surprise !

Quand vous recevez un email, votre logiciel de messagerie n'affiche qu'une partie des informations qui l'accompagnent. Derrière le nom de l'expéditeur, l'objet et le contenu, on retrouve tout un ensemble de données techniques : les serveurs par lesquels le message est passé, certaines informations sur son origine et les résultats de plusieurs vérifications. Ce sont les en-têtes, ou headers, de l'email.

Chez AZTK, on passe nos journées à développer des sites, des applications, à faire communiquer des outils entre eux, et à configurer des boites de mail ou d'envoi. Alors quand quelque chose nous semble étrange, on a assez naturellement envie de comprendre comment ça fonctionne.

Nous ouvrons donc les en-têtes du message. Et voici ce que nous découvrons :

• SPF : PASS
• DKIM : PASS
• DMARC : PASS

Les trois contrôles d'authentification ont des résultats positifs. Autrement dit, le serveur qui a reçu le message n'a pas détecté d'échec sur ces vérifications. Pour un email qui nous semblait présenter quelques incohérences, le résultat méritait qu'on s'y intéresse.

SPF, DKIM et DMARC, ça vérifie quoi exactement ?

Ces trois mécanismes contribuent à protéger les échanges par email, notamment contre certaines formes d'usurpation de domaine. Sans entrer dans tous les détails des protocoles, voici leur rôle :

• SPF : Le serveur qui transmet le message est-il autorisé à envoyer des emails pour le domaine technique vérifié ?
• DKIM : Le message possède-t-il une signature valide, permettant notamment de vérifier l'intégrité des éléments signés ?
• DMARC : Le domaine visible dans l'adresse de l'expéditeur est-il aligné avec un domaine correctement authentifié par SPF ou DKIM ?

Petite subtilité : le domaine vérifié par SPF n'est pas forcément celui que vous voyez dans l'adresse de l'expéditeur. Et pour réussir DMARC, il suffit que SPF ou DKIM réussisse avec un domaine aligné. Ces contrôles sont importants. Ils permettent notamment de rendre plus difficile l'envoi de messages usurpant directement le domaine d'une entreprise.

Ils ne permettent pas de déterminer si la personne derrière un message est bien celle qu'elle prétend être, si elle a réellement l'autorisation de faire cette demande ou si ses intentions sont honnêtes. C'est cette distinction qui nous intéressait dans notre cas.

Comment cet email a-t-il pu passer tous les contrôles ?

En examinant les en-têtes, nous repérons un autre élément : le message semble avoir transité par l'infrastructure de Brevo. Brevo est une plateforme qui permet notamment aux entreprises d'envoyer des emails marketing ou transactionnels. Nous connaissons bien le principe de ces services, puisqu'ils sont couramment utilisés pour les formulaires, notifications et fonctionnalités que l'on intègre dans des applications.

Une entreprise peut autoriser un prestataire extérieur à envoyer des emails en utilisant son domaine. Par exemple, lorsqu'un site e-commerce envoie une confirmation de commande, le message peut être expédié par une plateforme spécialisée tout en affichant une adresse appartenant à la boutique. Avec une configuration adaptée, cet email peut passer les vérifications SPF, DKIM et DMARC, et c'est tout à fait normal.

Un domaine authentifié ne garantit pas que l'envoi est légitime

Revenons à notre message, c'est donc via un compte Brevo authentifié que l'email est parti. Comment est-ce donc possible ? Plusieurs scénarios techniques sont envisageables :

• Un compte Brevo compromis : si quelqu'un parvient à accéder au compte d'une entreprise, par exemple avec des identifiants volés, il pourrait utiliser les fonctionnalités d'envoi auxquelles ce compte donne accès. Les emails bénéficieraient alors de la configuration d'authentification déjà en place.
• Une clé API récupérée par une personne non autorisée : Brevo propose une API permettant à un site ou à une application d'envoyer automatiquement des emails. Si une clé disposant des droits nécessaires est exposée, elle pourrait être utilisée pour déclencher des envois sans avoir besoin de se connecter à l'interface Brevo.
• Des identifiants SMTP compromis : Brevo permet également d'envoyer des messages via un relais SMTP, souvent utilisé par les sites et les logiciels métier. Si les identifiants associés à ce service sont récupérés, une personne non autorisée pourrait potentiellement envoyer des emails en utilisant cette configuration.
• Une application ou une intégration détournée : un site web, un CRM ou un outil interne déjà connecté à Brevo pourrait présenter une faille ou permettre le déclenchement d'envois non prévus. Dans ce cas, les emails pourraient partir à travers une intégration existante, sans que le compte Brevo lui-même ait été compromis.
• Un envoi parfaitement autorisé : il reste possible que le message ait été envoyé volontairement par une personne disposant des bons accès, dans un contexte que nous ne connaissons pas. Une situation inhabituelle n'est pas nécessairement frauduleuse.

Nous ne savons pas laquelle de ces situations correspond à notre cas.

Les en-têtes ne nous permettent pas de le déterminer, et nous n'avons aucune preuve d'une compromission. Nous avons donc contacté l'entreprise dont le domaine apparaissait dans le message pour la prévenir et essayer d'en comprendre l'origine.

À notre niveau, nous ne pouvons pas aller beaucoup plus loin sans informations supplémentaires sur les accès et les conditions dans lesquelles l'email a été envoyé. Cette analyse nous a néanmoins permis de mieux comprendre une limite importante : les contrôles d'authentification vérifient certains aspects techniques d'un email, pas la légitimité de toute la conversation.

Et avec l'IA, est-ce que ces emails vont devenir plus difficiles à repérer ?

Cette histoire nous a rappelé une phrase que l'on entend depuis des années lorsqu'on parle de phishing : « Faites attention aux fautes d'orthographe et aux emails mal rédigés. » Ce conseil reste utile, bien entendu. Il faut bien comprendre que maintenant, c'est facile d'écrire un email sans faute et personnalisé. Et c'est là que l'intelligence artificielle nous amène à nous poser quelques questions supplémentaires.

Rédiger un message crédible est devenu beaucoup plus simple

Aujourd'hui, les outils d'IA générative permettent de rédiger facilement un email professionnel, de l'adapter à un secteur d'activité ou de le personnaliser à partir d'informations publiques.

Imaginez quelqu'un qui souhaite contacter plusieurs agences de développement. Il peut récupérer certaines informations présentes sur leurs sites et générer des demandes adaptées à leurs prestations. Une agence recevra une demande de création de site. Une autre, une demande de développement d'application. Une troisième, une question sur une intégration technique.

Chaque message peut être correctement rédigé, avec le vocabulaire et le ton que l'on attend d'un véritable prospect. Ces pratiques de personnalisation n'ont pas été inventées avec ChatGPT. Le phishing ciblé existe depuis longtemps, tout comme les techniques d'ingénierie sociale.

En revanche, l'IA peut réduire considérablement le travail nécessaire pour préparer certains messages et en produire des variantes. Elle peut aussi faciliter la rédaction de réponses au fil d'une conversation. Attention, nous ne savons absolument pas si l'email reçu par AZTK a été écrit avec une IA. Rien ne permet de l'affirmer, et une personne aurait tout à fait pu le rédiger elle-même.

Mais cette expérience montre pourquoi la qualité de l'écriture, à elle seule, devient un critère de confiance assez limité.

Alors, comment savoir si un email est réellement fiable ?

Nous n'avons pas vocation à réaliser des audits de sécurité chez AZTK. En revanche, cette petite exploration technique nous a amenés à revoir quelques réflexes assez simples, utiles bien au-delà de notre métier.

Regardez la cohérence de la demande

Une adresse professionnelle, un nom d'entreprise connu ou un email sans faute ne suffisent pas à établir l'identité d'un interlocuteur. Lorsque plusieurs détails vous semblent étranges, prenez le temps de les rapprocher : qui vous écrit, depuis quelle adresse, pour demander quoi et pourquoi ? Pensez également à regarder le champ Reply-To. Une adresse de réponse différente n'est pas nécessairement anormale, mais elle mérite parfois une explication.

Vérifiez par un autre moyen lorsque c'est nécessaire

Si une demande semble vraiment inhabituelle, vous pouvez contacter l'entreprise concernée à partir des coordonnées disponibles sur son site officiel. C'est particulièrement pertinent lorsqu'un message vous demande de transmettre des informations confidentielles, d'effectuer un paiement ou d'ouvrir un document inattendu. L'important est d'utiliser des coordonnées trouvées indépendamment de l'email reçu.

Ne vous précipitez pas sur les documents

Dans notre métier, recevoir des documents de personnes que l'on ne connaît pas encore est assez courant. Pour autant, si le contexte paraît douteux, mieux vaut vérifier l'identité de l'interlocuteur avant d'ouvrir une pièce jointe ou de récupérer un dossier depuis un lien. Un fichier qui vous demande d'installer un programme, d'activer une fonctionnalité inhabituelle ou de saisir vos identifiants doit particulièrement attirer votre attention.

Et si vous êtes curieux, regardez les en-têtes

Vous pouvez également consulter les informations techniques d'un email. Sur Gmail, par exemple, il suffit d'ouvrir le menu du message et de sélectionner « Afficher l'original » pour retrouver ses en-têtes et les résultats des contrôles d'authentification. C'est intéressant pour comprendre certains aspects de son acheminement, à condition de ne pas considérer les résultats SPF, DKIM et DMARC comme une garantie absolue.

Ce qu'on retient de cette histoire

Nous ne savons toujours pas si cet email cachait réellement une tentative de phishing. Mais cette expérience nous a rappelé qu'un message bien rédigé, envoyé depuis le domaine d'une véritable entreprise et correctement authentifié peut malgré tout mériter quelques vérifications. Et heureusement, pas besoin de savoir analyser des en-têtes ou de comprendre SPF, DKIM et DMARC pour adopter les bons réflexes.

Quand on reçoit un email d'une personne qu'on ne connaît pas, particulièrement s'il contient une pièce jointe ou un lien vers un document, prendre quelques instants pour vérifier son origine peut éviter bien des problèmes. Même lorsque le message paraît parfaitement professionnel.

C'est aussi un sujet dont on devrait parler davantage autour de nous : avec nos collègues, nos proches, et notamment les personnes moins familières avec ces risques. Parce qu'on n'a pas tous les mêmes connaissances techniques, mais qu'on est tous susceptibles de recevoir ce genre de message. On ne pourra pas toujours reconnaître un email malveillant au premier coup d'œil. En revanche, on peut partager les bons réflexes et apprendre à se poser les bonnes questions avant de cliquer.

Sources de l'article

- RFC 7208 — Sender Policy Framework (SPF) — IETF. Spécification officielle du protocole SPF et de la vérification des serveurs d'envoi.

- RFC 6376 — DomainKeys Identified Mail (DKIM) — IETF. Fonctionnement des signatures DKIM et vérification de leur validité.

- RFC 9989 — Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF, mai 2026. Spécification actuelle de DMARC, notamment l'alignement des domaines et les conditions de validation. Elle remplace l'ancienne RFC 7489.

- Mon compte a été compromis, que dois-je faire ? — Brevo. Particulièrement pertinente pour votre article : elle aborde les comptes compromis, les clés API, les identifiants SMTP et les intégrations potentiellement exposées.

- Comment reconnaître un mail de phishing ou d'hameçonnage ? — Cybermalveillance.gouv.fr. Recommandations concernant les expéditeurs inconnus, les pièces jointes, les liens et les signes d'alerte.