Sécuriser les emails envoyés par un SaaS
La sécurité concerne à la fois l'identité du domaine expéditeur et le contenu des messages sensibles. SPF, DKIM et DMARC réduisent les possibilités d'usurpation ; les liens de connexion, les données personnelles, les rôles d'accès et les clés API demandent des contrôles complémentaires.
Une politique DNS cohérente aide les serveurs destinataires à évaluer les messages qui prétendent venir de votre marque. Elle ne remplace ni la protection des comptes d'envoi, ni l'expiration des liens, ni la journalisation des actions dans votre plateforme.
Vous trouverez une méthode progressive pour publier SPF, DKIM et DMARC, choisir une politique de traitement, limiter l'usurpation de marque et protéger les emails transactionnels, l'accès à l'outil d'envoi et ses secrets.
Comparer les services d'envoi transactionnel
Un fournisseur d'envoi facilite l'expédition et l'observation des messages ; il ne remplace pas la politique DNS, la sécurité applicative ou la gestion interne des accès. Vérifiez le volume inclus, les options d'authentification et les journaux disponibles dans le périmètre de votre équipe.
| Outil | Usage | Tarif et volume | Limite |
|---|---|---|---|
| Postmark | Envois transactionnels applicatifs | Basic : 15 $/mois, à partir de 10 000 emails mensuels | Vérifier les fonctions et volumes nécessaires au-delà de l'offre d'entrée. |
| Mailgun | Intégration d'envoi par API ou SMTP | Basic : 15 $/mois, 10 000 emails mensuels | La configuration et la supervision demandent une équipe technique. |
| Brevo | Campagnes et emails de service | Starter : 9 $/mois, à partir de 5 000 emails mensuels | Le palier d'entrée stocke jusqu'à 500 contacts. |
Pour choisir, séparez d'abord le besoin transactionnel du marketing. Les messages de connexion et de sécurité devraient avoir un chemin d'envoi prévisible, une surveillance distincte et des règles de publication plus strictes que les campagnes ordinaires. Confirmez si l'outil distingue les flux, permet des permissions par rôle et conserve des événements utiles sans exposer les secrets ou le contenu sensible.
Vérifiez ensuite la propriété du domaine et des clés. Identifiez qui gère le DNS, où les secrets sont stockés et comment les révoquer. Demandez comment le fournisseur présente les erreurs, les rebonds et les événements de livraison, et quels rôles peuvent consulter les journaux. Les fonctions de sécurité annoncées ne dispensent pas d'une configuration correcte et d'une surveillance régulière.
Pour une décision SaaS, documentez aussi la continuité : possibilité de basculer vers un autre service, récupération des modèles, gestion des files d'attente et procédure en cas d'indisponibilité. Testez le parcours de récupération du compte et le comportement de l'application lorsque l'envoi échoue. Gardez les messages essentiels simples et prévoyez une alternative sûre plutôt que de journaliser le lien complet pour diagnostiquer un incident.
Authentifier le domaine et réduire l'usurpation
Un SaaS envoie souvent des messages depuis plusieurs systèmes : produit, facturation, support, marketing et prestataires d'envoi. Avant de modifier le DNS, inventorie les domaines et sous-domaines, les expéditeurs, les plateformes autorisées et les propriétaires opérationnels. Un ancien outil oublié peut continuer à envoyer au nom de la marque ; à l'inverse, une règle SPF assemblée sans inventaire peut exclure un service encore utilisé. Centralise les responsables et prévois un processus de changement, car chaque nouvelle source doit être revue avant sa mise en production.
SPF : déclarer les expéditeurs autorisés
SPF publie dans le DNS la liste des systèmes autorisés à envoyer pour un domaine d'enveloppe. Les fournisseurs qui expédient pour votre SaaS doivent être recensés et inclus dans la politique appropriée. SPF ne valide pas à lui seul le nom visible dans le champ « De » et il ne chiffre pas le message. Il faut aussi surveiller les limites et les mécanismes de recherche DNS, éviter de multiplier les enregistrements SPF au même nom et retirer les sources abandonnées après vérification. Une entrée temporaire ajoutée pour résoudre une urgence peut devenir une autorisation permanente si personne ne la documente.
DKIM : signer les messages
DKIM ajoute une signature vérifiable à un message. Le destinataire peut consulter la clé publique publiée dans le DNS et vérifier que certains éléments signés n'ont pas été modifiés. Chaque service peut demander son sélecteur et sa clé ; conservez l'inventaire, protégez l'accès au compte fournisseur et planifiez la rotation selon les capacités du service. La signature ne prouve pas que le contenu est légitime ni que le compte d'envoi n'a pas été compromis. Elle fournit un signal d'authentification qui doit être combiné aux autres contrôles.
DMARC : aligner et appliquer progressivement
DMARC s'appuie sur l'alignement entre le domaine visible et l'authentification SPF ou DKIM. Commencez par publier une politique p=none afin d'observer les rapports et découvrir les sources légitimes qui échouent. Traitez les rapports comme des données opérationnelles : associez les expéditeurs inconnus à un propriétaire, corrigez les configurations et vérifiez plusieurs cycles d'envoi. Lorsque les flux attendus sont identifiés et alignés, une politique p=quarantine demande aux destinataires de traiter avec prudence les messages non conformes. Après contrôle, p=reject demande le rejet de ces messages. La transition doit être graduelle, avec des exceptions et des sous-domaines évalués séparément selon les besoins réels.
Ne passe pas de none à reject uniquement pour afficher une politique stricte. Les messages provenant d'une plateforme de support ou d'un outil financier peuvent échouer si l'alignement n'est pas configuré. Garde une procédure de retour arrière et surveille les rapports après chaque changement DNS. Le but est d'empêcher les tiers non autorisés de se faire passer pour votre domaine tout en préservant les envois légitimes.
BIMI et confiance visuelle
BIMI peut permettre l'affichage du logo de marque par certains fournisseurs, sous réserve de leurs critères et de la configuration requise. Il s'appuie notamment sur une politique DMARC appliquée et sur un logo conforme ; dans certains cas, un certificat de marque est demandé. BIMI ne remplace pas l'authentification et ne garantit pas l'affichage du logo dans chaque boîte de réception. Traitez-le comme une couche de cohérence visuelle après la mise en place des contrôles précédents, et protégez le processus d'approbation du logo contre les modifications non autorisées.
Ces mécanismes protègent l'identité du domaine, mais la sécurité des emails SaaS dépend aussi des comptes de plateforme, des secrets API et du contenu transactionnel. Réservez des identités d'envoi par usage, limitez les permissions des intégrations et désactivez rapidement les accès inutilisés. Ainsi, un compte marketing compromis ne devrait pas avoir automatiquement le droit de modifier les emails de réinitialisation de mot de passe. Documentez qui peut modifier les enregistrements DNS et qui peut valider les changements de configuration chez les fournisseurs.
Questions fréquentes — Sécurité email
Quelle est la différence entre SPF, DKIM et DMARC ?
SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting & Conformance) sont trois mécanismes d'authentification email complémentaires qui forment ensemble la défense standard contre l'usurpation d'identité email. Comprendre leur rôle respectif est essentiel pour configurer une sécurité email robuste.
SPF permet au propriétaire d'un domaine de déclarer explicitement quels serveurs d'envoi sont autorisés à envoyer des emails au nom de ce domaine. Configuré via un enregistrement TXT dans le DNS, SPF permet aux serveurs de réception de vérifier que l'email provient bien d'un serveur autorisé. Si un email est envoyé depuis un serveur non listé dans le SPF, les serveurs récepteurs peuvent le rejeter ou le marquer comme suspect.
DKIM ajoute une signature cryptographique à chaque email envoyé, permettant au serveur de réception de vérifier que le contenu de l'email n'a pas été modifié en transit et qu'il provient bien du domaine déclaré. DKIM utilise un mécanisme de clés publique/privée : la clé publique est publiée dans le DNS du domaine, et chaque email est signé avec la clé privée. Un email avec une signature DKIM valide est authentifié comme intact et provenant du bon expéditeur.
DMARC s'appuie sur SPF et DKIM pour définir la politique à appliquer aux emails qui échouent à l'authentification. Il permet au propriétaire du domaine de dire : « Si un email prétend venir de mon domaine mais échoue à l'authentification SPF ou DKIM, voici ce qu'il faut faire : le livrer normalement (none), le placer en quarantaine (quarantine), ou le rejeter (reject). » DMARC inclut également un mécanisme de reporting qui envoie au propriétaire du domaine des rapports sur les tentatives d'envoi frauduleuses détectées, fournissant une visibilité précieuse sur les tentatives d'usurpation.
Comment configurer DMARC pour son domaine sans expertise DNS ?
La configuration de DMARC peut sembler intimidante pour les non-techniciens, mais elle suit un processus progressif qui commence par une politique de surveillance (p=none) avant d'évoluer vers une politique d'enforcement (p=quarantine puis p=reject). La première étape est d'ajouter un enregistrement TXT dans votre DNS avec une politique none qui ne bloque rien mais génère des rapports : _dmarc.votredomaine.com avec la valeur « v=DMARC1; p=none; rua=mailto:votre-email-de-rapport@votredomaine.com ».
Pendant la phase d'observation sous p=none, examinez les rapports DMARC pour identifier les systèmes légitimes qui utilisent votre domaine : outil marketing, CRM, envoi transactionnel ou plateforme de support. Attribuez chaque source à son responsable et corrigez SPF, DKIM et l'alignement avant de passer à une politique plus restrictive.
Une fois que tous vos services légitimes sont correctement authentifiés et apparaissent comme conformes dans vos rapports DMARC, passez progressivement à p=quarantine (les emails non conformes vont en spam plutôt qu'en boîte de réception) puis à p=reject (les emails non conformes sont complètement rejetés). Cette progression graduelle permet d'éviter de bloquer accidentellement des emails légitimes pendant le processus de configuration.
Des services d'analyse DMARC peuvent agréger les rapports et aider à comprendre les sources observées. Ils ne remplacent pas la vérification des systèmes métier ni la validation DNS par les propriétaires concernés. Contrôlez les changements après leur propagation et gardez une trace des décisions qui motivent le passage de none à quarantine, puis à reject.
Pourquoi la sécurité email est-elle critique pour un SaaS ?
Pour un SaaS, la sécurité email est critique à deux niveaux distincts. Premièrement, les emails transactionnels — confirmations d'inscription, réinitialisations de mot de passe, alertes de facturation, notifications de sécurité — sont souvent des éléments critiques du fonctionnement du produit. Si ces emails ne sont pas délivrés (en raison de problèmes d'authentification ou de réputation), les utilisateurs ne peuvent pas accéder à leur compte ou sont mis en danger. Une mauvaise sécurité email devient directement un problème d'expérience produit.
Deuxièmement, la réputation de la marque est en jeu : si des cybercriminels parviennent à usurper votre domaine pour envoyer des emails de phishing à vos clients ou prospects, les dommages réputationnels peuvent être considérables et durables. Les victimes de phishing qui pensaient recevoir un email de votre part peuvent perdre des données personnelles ou financières, et vous en tiendront responsables même si l'attaque était externe. L'implémentation de DMARC avec une politique de rejet est le seul moyen technique de prévenir cette usurpation.
La délivrabilité des emails marketing est également un enjeu commercial direct. Les modifications des politiques d'envoi de Google et Yahoo en 2024, qui ont rendu l'authentification DKIM, SPF et DMARC obligatoire pour les expéditeurs en volume, illustrent la tendance de fond : les fournisseurs de messagerie durcissent progressivement leurs exigences en matière de sécurité email. Les SaaS qui n'ont pas encore mis en place une authentification complète risquent de voir leurs emails de marketing bloqués ou classés en spam.
Enfin, les données des abonnés email doivent être limitées aux besoins du service et accessibles aux seules personnes autorisées. Définissez les durées de conservation, protégez les exports et consignez les changements d'accès. Les équipes doivent savoir à qui signaler une exposition et quelles étapes appliquer pour contenir l'incident.
Comment protéger son domaine contre le phishing et l'usurpation d'identité ?
La protection complète contre le phishing et l'usurpation d'identité email repose sur une combinaison de mesures techniques et organisationnelles. Sur le plan technique, l'implémentation de DMARC avec une politique p=reject est la mesure la plus efficace contre l'usurpation directe de votre domaine principal. Cette configuration empêche techniquement les serveurs de messagerie conformes de délivrer des emails non authentifiés qui prétendent venir de votre domaine.
Cependant, DMARC ne protège pas contre les typosquatting (domaines similaires mais pas identiques : votreentreprise vs votre-entreprise) ni contre les attaques de phishing qui n'utilisent pas votre domaine exact. Pour ces menaces, des outils comme Agari ou les fonctionnalités de protection de marque de Proofpoint peuvent monitorer en temps réel les usurpations de votre identité de marque sur internet, permettant des actions de prise down rapides.
Sur le plan organisationnel, la formation des employés à la détection du phishing est aussi importante que les mesures techniques. Des programmes de simulation de phishing comme ceux proposés par Proofpoint ou KnowBe4 permettent d'évaluer régulièrement la sensibilité des équipes aux attaques et de cibler la formation sur les employés les plus vulnérables. Les employés bien formés constituent une défense humaine complémentaire aux filtres techniques.
Une checklist de départ peut couvrir SPF, DKIM et DMARC sur les domaines d'envoi, l'authentification multifacteur sur les consoles, des sous-domaines séparés selon les usages et une revue régulière des sources. Assignez chaque contrôle à une personne capable de confirmer la configuration et de traiter les alertes.
Comment évaluer la sécurité d'un prestataire d'envoi ?
Demandez le périmètre des données traitées, les rôles disponibles, les modalités de chiffrement et la façon dont les incidents sont communiqués. Associez ces réponses à vos exigences internes et au niveau de sensibilité des messages.
Évaluez aussi le contrôle des clés et des domaines : qui les crée, comment leur utilisation est limitée et comment les révoquer. Un fournisseur doit permettre de comprendre les événements d'envoi sans exposer les jetons ou les données complètes des destinataires dans les journaux.
Pour une organisation soumise à des exigences particulières, vérifiez les documents de sécurité et les mécanismes contractuels applicables avec les équipes juridique et sécurité. Une fonctionnalité affichée dans une console ne prouve pas à elle seule que la configuration de votre compte répond à ces exigences.
Choisissez enfin selon les tâches de l'équipe : une API transactionnelle peut convenir à un flux produit contrôlé par des développeurs, tandis qu'une solution plus intégrée peut simplifier les opérations marketing. Dans les deux cas, gardez les emails sensibles distincts des campagnes promotionnelles et définissez une revue régulière des accès.
Guides connexes
Protéger les liens de connexion et les données des messages
Les emails transactionnels donnent accès au compte ou déclenchent une action importante. Concevez leur sécurité depuis le flux applicatif jusqu'à la console qui les envoie.
Réinitialisation de mot de passe, liens magiques et codes à usage unique doivent répondre à une demande explicite et être associés au bon compte. Générez les jetons côté serveur avec une entropie adaptée, liez-les à une action précise et invalidez-les après usage. Un code ne doit pas rester valable une fois remplacé par un nouveau. Évitez d'insérer dans le message une information qui révèle si une adresse est enregistrée ; une réponse uniforme réduit les indices accessibles à une personne qui teste les formulaires.
Définissez une durée d'expiration proportionnée au parcours. Un lien de connexion qui reste valide des jours après son envoi peut être transféré ou retrouvé dans une boîte partagée. À l'inverse, un délai trop court pénalise les personnes qui utilisent un client email retardant la livraison ou qui doivent faire approuver leur connexion. Indiquez clairement l'action attendue et, lorsque c'est utile, la marche à suivre pour demander un nouveau lien. Affichez une page d'expiration neutre qui ne divulgue pas d'informations de compte.
Gardez les données personnelles hors des URL et du corps du message lorsqu'elles ne sont pas indispensables. N'incluez pas de mot de passe, de secret durable, de données de paiement complètes ou de détails de compte sensibles dans un lien traçable. Les paramètres d'URL peuvent être conservés par des journaux, des outils d'analyse, des proxys ou des captures d'écran. Préférez un identifiant opaque à durée de vie courte, puis chargez les détails après authentification dans l'application.
Les codes transmis par email restent exposés à toute personne qui peut lire la boîte concernée. Pour une action à risque, tenez compte de cette limite et proposez une authentification plus forte lorsque le modèle de menace l'exige. Ne demandez jamais au destinataire de répondre avec son code. Masquez les codes dans les aperçus lorsque c'est possible et rédigez les sujets de façon à éviter d'exposer l'action sensible sur un écran verrouillé.
Dans la plateforme d'envoi, appliquez le principe du moindre privilège. Séparez les rôles qui peuvent rédiger, approuver, publier, gérer les domaines ou créer des clés. Réservez l'accès administrateur aux personnes qui en ont besoin, utilisez des comptes nominatifs et retirez rapidement les accès lors d'un départ ou d'un changement d'équipe. Activez l'authentification multifacteur si elle est proposée et vérifiez périodiquement les utilisateurs, les sessions et les connexions SSO.
Traitez chaque clé API comme un secret de production. Stockez-la dans un gestionnaire de secrets, associez-la à un environnement et à des permissions minimales, et évitez de la copier dans un dépôt, un ticket ou un document partagé. Préparez sa rotation et son révocation avant un incident. Si une clé apparaît dans un journal ou une capture, considérez-la exposée, révoquez-la et vérifiez les événements qui suivent. Une clé de développement ne doit jamais autoriser l'envoi en production.
La journalisation permet de reconstituer les actions sans enregistrer inutilement le contenu personnel des messages. Conservez qui a changé un modèle, une politique DNS, un rôle ou une clé, à quel moment et depuis quel environnement. Limitez l'accès aux journaux, définissez une durée de conservation cohérente avec vos obligations internes et évitez d'y inscrire des liens magiques complets, des jetons ou des codes. Des événements structurés facilitent l'investigation sans exposer les secrets aux personnes qui consultent les traces ordinaires.
Enfin, préparez les réponses opérationnelles : qui suspend l'envoi, qui révoque les clés, qui contacte le fournisseur et qui évalue les comptes concernés ? Faites figurer ces responsabilités dans un runbook accessible aux équipes de sécurité, produit et support. Une procédure courte, avec les accès d'urgence contrôlés et les étapes de communication définies, réduit les hésitations lorsqu'un compte d'envoi ou un domaine semble compromis.
Organiser les accès, les secrets et la réponse aux incidents
| Contrôle | Pratique opérationnelle | À documenter |
|---|---|---|
| Rôles de console | Accorder des permissions distinctes pour rédiger, approuver, publier et gérer le DNS. | Propriétaire de chaque rôle et revue périodique. |
| Secrets API | Stocker les clés dans un coffre, avec portée et environnement limités. | Responsable, rotation et révocation. |
| Liens à usage unique | Invalider un jeton après usage ou expiration et éviter sa présence dans les journaux. | Durée, invalidation et parcours de nouvel envoi. |
| Journalisation | Tracer les modifications de modèles, domaines, rôles et clés sans consigner les jetons. | Accès, conservation et alertes. |
| Réponse d'urgence | Pouvoir suspendre les envois et révoquer un secret compromis rapidement. | Contacts, étapes de reprise et validation. |
Erreurs fréquentes dans la sécurisation des emails SaaS
Passer DMARC directement en rejet
Une source légitime oubliée peut alors être bloquée. Inventoriez les expéditeurs, observez les rapports sous none et progressez vers quarantine puis reject après correction.
Mettre un jeton durable dans une URL
Les URL sont susceptibles d'être conservées dans des journaux et des historiques. Utilisez des liens opaques, à durée limitée, et excluez les secrets des paramètres.
Partager un compte administrateur et une clé sans propriétaire
Des accès nominatifs, limités et révocables facilitent le contrôle des changements. Assignez un responsable et consignez l'usage des clés sensibles.
Questions fréquentes sur la sécurité des emails SaaS
À quoi servent SPF et DKIM pour un SaaS ?
SPF déclare les systèmes autorisés à envoyer pour le domaine d'enveloppe. DKIM signe le message pour permettre au destinataire de vérifier sa signature. Ils répondent à des contrôles différents et ne chiffrent pas le contenu.
Quelle politique DMARC choisir au début ?
Commencez généralement par p=none pour observer les rapports et recenser les expéditeurs légitimes. Corrigez l'alignement avant de demander quarantine puis reject.
Que signifient quarantine et reject dans DMARC ?
Quarantine demande au destinataire de traiter avec prudence les messages qui échouent à DMARC. Reject demande leur rejet. Le traitement réel dépend du destinataire, d'où l'intérêt d'une transition contrôlée.
DMARC empêche-t-il tout phishing de marque ?
Non. Il aide les destinataires à traiter les messages qui usurpent votre domaine, mais ne bloque pas les domaines ressemblants, les comptes compromis ou les messages frauduleux envoyés depuis un autre domaine.
BIMI remplace-t-il SPF, DKIM ou DMARC ?
Non. BIMI peut afficher un logo dans certains services si leurs critères sont remplis. Il vient après l'authentification et une politique DMARC appliquée.
Combien de temps un lien magique doit-il rester actif ?
Choisissez une durée adaptée au parcours et au risque. Le lien devrait expirer, être lié à une action précise et devenir invalide après usage ; proposez un moyen sûr d'en obtenir un nouveau.
Peut-on inclure des informations personnelles dans un email transactionnel ?
Limitez le contenu aux informations nécessaires. Évitez les mots de passe, secrets durables et données sensibles dans le corps ou les URL, qui peuvent être conservées ou transférées.
Comment protéger les codes de connexion envoyés par email ?
Rendez-les temporaires et à usage limité, ne demandez jamais au destinataire de répondre avec le code et tenez compte du fait que toute personne ayant accès à la boîte peut le lire.
Qui devrait pouvoir publier un email transactionnel ?
Attribuez des rôles distincts pour rédaction, approbation, publication et administration. Limitez les droits au besoin réel et révisez les accès lors des changements d'équipe.
Où stocker les clés API de la plateforme d'envoi ?
Conservez-les dans un gestionnaire de secrets, hors du code source et des documents partagés. Limitez leur portée, associez-les à un environnement et prévoyez révocation et rotation.
Que faut-il conserver dans les journaux d'envoi ?
Tracez les actions de configuration et les événements utiles à l'investigation, avec un accès contrôlé. N'inscrivez pas les jetons de connexion, codes ou URL magiques complets.
Que faire en cas de suspicion de compromission d'une clé ?
Révoquez la clé, créez-en une nouvelle avec les permissions nécessaires, vérifiez les événements associés et évaluez les envois concernés selon votre procédure d'incident.