Configuration DKIM SPF DMARC pour un domaine

Configuration DKIM SPF DMARC pour un domaine : un guide complet sur l'authentification des e-mails

L'e-mail est toujours l'une des parties les plus vulnérables de tout domaine, et un site Web peut être soigneusement construit et le serveur bien protégé. Si les messages envoyés au nom de l'entreprise sont faciles à falsifier, les problèmes commencent rapidement : campagnes de phishing, plaintes des utilisateurs, perte de confiance et, dans le pire des cas, une moins bonne délivrabilité pour vos propres e-mails. C'est pourquoi Configuration DKIM SPF DMARC pour le domaine n'est pas un « petit détail technique » — c'est une question d'hygiène de l'infrastructure email de base et une partie importante de l'authentification des emails.

Si vous avez déjà eu des emails qui atterrissent dans les spams sans raison évidente, ou qu'un client demande : « Avez-vous vraiment envoyé cela ? » — il est déjà temps de travailler sur l'authentification de domaine. Et plus tôt, c'est mieux. En ce sens, l'email fonctionne beaucoup comme un site web : sans attention régulière, même un système solide commence à se comporter de manière imprévisible. Nous en parlons souvent dans le contexte de la sécurité des sites web: la protection n'est pas un plugin ou un paramètre, mais un ensemble de mesures qui fonctionnent ensemble. Si vous vous demandez comment configurer SPF DKIM DMARC, la clé est de les traiter comme un processus coordonné plutôt que comme des solutions séparées.

Ce que sont DKIM, SPF et DMARC et pourquoi ils sont importants

DKIM, SPF et DMARC résolvent un problème similaire, mais ils le font de différentes manières. Il est important de ne pas confondre leurs rôles si vous prévoyez la configuration de l'authentification des emails pour le domaine.

SPF répond à la question : « Quels serveurs sont réellement autorisés à envoyer des mails au nom de ce domaine ? » Dans le DNS, vous publiez une liste d'expéditeurs approuvés, et le serveur de messagerie du destinataire la compare avec l'adresse IP réelle d'où le message provient.

DKIM ajoute une signature cryptographique au message. Le destinataire vérifie si l'email a vraiment été signé par votre domaine et s'il a été modifié en cours de route. C'est plus qu'une simple liste d'autorisation — c'est la preuve de l'identité de l'expéditeur et de l'intégrité du message.

DMARC lie SPF et DKIM ensemble dans une seule politique, et il indique aux systèmes de messagerie quoi faire si un message échoue aux vérifications : le livrer, l'envoyer en quarantaine ou le rejeter complètement. DMARC vous permet également de recevoir des rapports sur qui essaie d'envoyer des mails depuis votre domaine et comment.

C'est pourquoi ces mécanismes ne concernent pas seulement la prévention des e-mails falsifiés. Ils affectent directement la délivrabilité. Les services de messagerie examinent de plus en plus non seulement le contenu d'un message, mais aussi la qualité de son authentification. Pour un domaine professionnel, c'est critique : perdre quelques messages est une chose, mais se retrouver systématiquement dans les spams pour les clients, partenaires et services en est une autre.

Comment DKIM SPF DMARC fonctionnent ensemble

Chaque protocole est utile en soi, mais ensemble, ils créent un système de vérification beaucoup plus fiable.

SPF confirme que le message provient d'un serveur approuvé. Mais il a une limitation : si l'e-mail est transféré, SPF peut « se briser » car l'adresse IP du dernier expéditeur change. DKIM aide souvent dans ces cas car la signature reste valide même après le transfert, tant que le message lui-même n'a pas été modifié.

DMARC, à son tour, vérifie non seulement si SPF et DKIM existent, mais aussi s'ils sont alignés avec le domaine dans le champ From. Cela a de l'importance. Un message peut être techniquement signé, mais l'utilisateur voit un domaine complètement différent dans le nom de l'expéditeur, et DMARC aide à prévenir cette confusion et bloque les usurpations évidentes.

Pour le dire simplement : SPF est une liste d'invités à l'entrée, DKIM est un sceau sur le document, et DMARC est la règle de sécurité pour ce qu'il faut faire avec les visiteurs qui n'ont ni pass ni sceau. Une mesure sans les autres laisse une lacune.

C'est pourquoi ils doivent être mis en œuvre ensemble. Cela est particulièrement important pour les entreprises qui utilisent plusieurs sources d'e-mails : systèmes CRM, services de newsletters, plateformes de billetterie, formulaires de contact, notifications transactionnelles. Si ces éléments ne sont pas alignés, l'infrastructure e-mail commence à se comporter comme un ensemble d'îles déconnectées.

Préparation à la configuration : domaine, DNS et service de messagerie

Avant de créer des enregistrements, vous devez comprendre qui envoie exactement des e-mails au nom du domaine. Cela peut être un service de messagerie, ou plusieurs : e-mail d'entreprise, plateforme de mailing, système de notification, un service SMTP séparé pour le site web. Sans cette vue d'ensemble, vous risquez de permettre trop ou, au contraire, de bloquer accidentellement un expéditeur nécessaire.

Vous aurez besoin d'accéder au panneau DNS du domaine. En général, c'est l'interface du registraire, de votre fournisseur d'hébergement ou d'un fournisseur DNS séparé. Il est important de savoir exactement où les enregistrements sont modifiés : parfois, une personne cherche le problème dans le service de messagerie, alors que l'enregistrement se trouve en réalité chez un autre fournisseur.

Une autre étape essentielle consiste à collecter des détails auprès du fournisseur de messagerie. En général, vous aurez besoin de :

• données SPF ou un enregistrement SPF recommandé ;
• une clé DKIM ou des instructions pour en générer une ;
• le nom du sélecteur DKIM, si le fournisseur en utilise un ;
• recommandations DMARC ;
• une liste de domaines et de sous-domaines utilisés pour l'envoi ;
• une compréhension des services qui envoient des e-mails maintenant et de ceux qui seront ajoutés plus tard.

Si vous ne travaillez pas avec un nouveau domaine, il est judicieux de revoir d'abord la configuration actuelle. Parfois, le SPF existe déjà, mais il répertorie encore d'anciens services. Parfois, le DKIM a été activé à un moment donné, mais le système de messagerie a ensuite été transféré à un autre fournisseur. Et parfois, le DMARC est présent, mais seulement « pour la forme », sans rapports et sans politique significative, et il est préférable de repérer ces choses avant de faire des changements, pas après des plaintes d'utilisateurs.

Configuration de SPF pour le domaine

Un enregistrement SPF est publié dans le DNS sous forme d'enregistrement TXT. Son rôle est de lister les sources d'envoi approuvées. L'idée de base est simple : vous spécifiez quels services et serveurs sont autorisés à envoyer des mails au nom du domaine, et tout le reste est considéré comme non autorisé.

Lors de sa configuration, rappelez-vous ceci : un domaine doit avoir un enregistrement SPF. Pas deux, pas trois — un. Si vous ajoutez plusieurs enregistrements TXT avec SPF, de nombreux destinataires considéreront cela comme une erreur. C'est l'un des problèmes les plus courants dans le support de l'infrastructure email, et la configuration de l'authentification des emails pour le domaine est particulièrement sensible aux détails ici.

La logique SPF typique est construite autour de mécanismes tels que include, ip4, ip6 et mx. En pratique, cela signifie que vous pouvez inclure un service de mailing tiers, des adresses IP spécifiques ou les serveurs de mail du domaine. Mais il y a un piège : chaque entrée supplémentaire rend l'enregistrement plus long et plus complexe.

Une autre erreur courante est d'être trop large. Parfois, les gens utilisent des règles trop laxistes juste pour « éviter de casser quoi que ce soit ». En conséquence, plus d'expéditeurs sont autorisés que nécessaire. C'est pratique au début, mais pire pour la sécurité, et si la protection contre les messages falsifiés est importante pour vous, le SPF doit être précis, pas juste « à peu près correct ».

Après avoir publié l'enregistrement, vérifiez qu'il est effectivement visible dans le DNS et qu'il correspond à vos sources d'envoi actuelles. Si vous envoyez des mails via plusieurs plateformes, vérifiez chacune d'elles. Sinon, vous pouvez facilement vous retrouver dans une situation où les emails CRM passent, mais les notifications du site web ne le font pas.

Configuration de DKIM : génération d'une clé et publication de l'enregistrement DNS

DKIM fonctionne avec une paire de clés : la clé privée reste avec l'expéditeur, et la clé publique est publiée dans le DNS. Lorsque un message est envoyé, le serveur le signe avec la clé privée. Le destinataire prend la clé publique du DNS et vérifie la signature. Si tout correspond, le message est considéré comme authentique.

DKIM est généralement configuré via le service de messagerie. Dans le tableau de bord du fournisseur, vous sélectionnez le domaine, générez une clé ou recevez des paramètres prêts à l'emploi, puis publiez un enregistrement TXT avec la partie publique de la clé. Un sélecteur est souvent inclus dans l'enregistrement — un nom spécial qui aide à distinguer une clé d'une autre. Cela est particulièrement utile si le domaine a plusieurs systèmes d'envoi ou si vous prévoyez de faire tourner les clés.

Après avoir publié l'enregistrement DNS, vous devez activer la signature pour les messages sortants dans le service lui-même, et sans cela, l'enregistrement DNS est inutile : la clé sera dans la zone, mais les e-mails resteront non signés. D'un point de vue dépannage, c'est un piège courant : « L'enregistrement a été ajouté, mais DKIM ne fonctionne pas. » En réalité, la signature n'a tout simplement pas été activée du côté de l'expéditeur, donc le la configuration de l'authentification des emails pour le domaine reste incomplet.

Techniquement, il est important de vérifier :

• si le sélecteur correspond entre le DNS et les paramètres du service ;
• si l'enregistrement TXT a été publié correctement ;
• si la clé a été accidentellement coupée lors du collage ;
• si tous les types de messages nécessaires sont signés, pas seulement certains d'entre eux ;
• si le message change après la signature, par exemple à cause d'un traitement supplémentaire par un service intermédiaire.

DKIM est particulièrement utile pour les e-mails transactionnels : confirmations d'inscription, réinitialisations de mot de passe, notifications de commande. Ces messages doivent arriver de manière cohérente. Si le site a une structure bien organisée et un bon support après le lancement, comme support du site après le lancement, l'authentification par e-mail est généralement l'une des choses qui ne sont pas reportées « à plus tard ». Et c'est la bonne approche.

Configuration de la politique et des rapports DMARC

DMARC ajoute du contrôle. Sans cela, vous pouvez voir SPF et DKIM séparément, mais vous n'avez pas de règle claire sur ce qu'il faut faire avec les messages suspects. Un enregistrement DMARC est également publié dans le DNS sous forme d'enregistrement TXT, généralement sous le sous-domaine _dmarc.

Au début, de nombreuses personnes choisissent une politique none. C'est un mode de surveillance : les messages ne sont pas bloqués, mais le propriétaire du domaine reçoit des rapports et peut voir qui envoie des e-mails, si les vérifications passent et où se trouvent les lacunes. C'est une première étape sensée, surtout si l'infrastructure est complexe et que vous ne voulez pas soudainement couper des messages légitimes.

Après une période de surveillance, la politique peut être renforcée : la quarantaine envoie les messages suspects dans le spam ou la quarantaine, tandis que le rejet les bloque complètement. Le choix de l'option dépend de la maturité de votre configuration e-mail et de votre confiance dans le fait que toutes les sources légitimes sont déjà prises en compte.

Dans les rapports DMARC, il est utile de rechercher non seulement des erreurs, mais aussi des sources d'envoi inattendues, et parfois de vieux services, des plateformes de test ou des intégrations oubliées apparaissent là. C'est une bonne occasion de faire le ménage.

Si vous mettez en œuvre DMARC pour un domaine d'entreprise, il vaut la peine de vérifier si des processus importants dépendent de services tiers. Par exemple, si le site utilise activement des formulaires et des notifications par e-mail, et que la structure du site est construite de manière à ce que les messages passent par plusieurs modules, il est utile d'aligner chaque point d'envoi à l'avance. Nous couvrons également des questions connexes dans le sujet de la structure du site web d'entreprise: plus l'architecture est claire, moins il y a de surprises au niveau des e-mails, et plus la configuration de l'authentification des e-mails est fluide.

Vérification et dépannage après déploiement

Après la configuration, ne comptez pas sur le sentiment que « cela semble fonctionner ». La vérification doit être délibérée et méthodique.

Tout d'abord, assurez-vous que l'enregistrement SPF est visible dans le DNS et ne contient que des sources actuelles. Ensuite, envoyez un message test et vérifiez les en-têtes du côté du destinataire : ils montrent généralement si le SPF a réussi, s'il y a une signature DKIM et si le DMARC a été déclenché.

Si le message échoue à la vérification, recherchez la cause étape par étape :

1. les enregistrements DNS sont-ils saisis correctement ;
2. suffisamment de temps s'est-il écoulé pour la propagation DNS ;
3. le domaine dans From correspond-il au domaine de signature ;
4. le message est-il signé par le service que vous attendez ;
5. un système intermédiaire modifie-t-il le message après la signature.

Il est très utile de tester non pas un seul message, mais plusieurs scénarios : un formulaire sur le site web, un e-mail CRM, une notification d'inscription, une newsletter envoyée par un service de marketing par e-mail. Parfois, le problème apparaît dans un seul canal tandis que les autres semblent parfaits.

Il vaut également la peine de vérifier comment les enregistrements DNS sont interprétés. Les erreurs peuvent être triviales : un espace supplémentaire, une mauvaise citation, un sélecteur incorrect, plusieurs enregistrements SPF au lieu d'un seul. De petits détails comme ceux-ci peuvent ruiner le résultat, même lorsque tout semble correct à première vue.

Questions courantes et recommandations pour maintenir la configuration en bonne santé

Que devez-vous faire si votre service de messagerie change ? Tout d'abord, ajoutez le nouvel expéditeur à SPF, configurez DKIM avec le nouveau fournisseur, testez l'envoi, et seulement ensuite éteignez l'ancien, et vous ne pouvez pas simplement « changer » de services et espérer que les anciens enregistrements cesseront d'avoir de l'importance d'eux-mêmes. L'infrastructure de messagerie aime la précision, et la configuration de l'authentification des emails pour le domaine nécessite une séquence.

Que se passe-t-il si plusieurs messages sont envoyés, et que certains proviennent du site web tandis que d'autres proviennent d'une plateforme externe ? Il est alors important de dresser une liste complète de tous les expéditeurs. Pour un site web, cela pourrait inclure un plugin SMTP, un système de notification, un service de mailing, et même un outil de formulaire de contact séparé. Plus la liste est claire, plus il est facile de maintenir SPF et DMARC sans conflits.

Les paramètres ont-ils besoin de vérifications régulières ? Oui. Surtout si vous avez changé d'hébergement, déplacé le domaine, connecté un nouveau CRM, ou mis à jour votre système de mailing. Parfois, les enregistrements DNS restent obsolètes simplement parce que personne ne s'en souvient plus. Et les enregistrements oubliés sont souvent une source cachée d'erreurs.

Si vous n'êtes pas sûr que votre configuration d'envoi d'e-mails actuelle soit transparente, il est logique de l'examiner dans son ensemble : qui envoie, qui signe, où les enregistrements sont stockés, et qui est responsable des changements. Dans des projets plus complexes, cela devient une partie de l'architecture de support et technique globale, pas une « tâche informatique » de cinq minutes.

Et un dernier conseil pratique : ne vous précipitez pas pour activer une politique de rejet stricte si le domaine est ancien et a de nombreux expéditeurs non liés. Commencez par collecter les données, activez les rapports, supprimez ce qui est inutile, et seulement ensuite, resserrez progressivement la politique. Dans l'authentification des e-mails, se précipiter conduit presque toujours à bloquer le mail dont vous avez réellement besoin.

Si vous voulez un domaine qui non seulement a fière allure dans la barre d'adresse mais qui passe également les vérifications de mail avec confiance, SPF, DKIM et DMARC doivent être considérés comme une partie obligatoire du projet. Ce n'est pas une mesure décorative — c'est un moyen de protéger votre marque, de bâtir la confiance et de rendre la livraison des e-mails prévisible. Et la prévisibilité, comme le montre la pratique, vaut plus que n'importe quelle configuration flashy mais fragile.