Guide de configuration de l'authentification par e-mail : SPF et DKIM expliqués

Si vous envoyez des e-mails depuis un domaine qui vous tient à cœur, l'authentification n'est pas optionnelle. C'est la partie de votre configuration qui indique aux serveurs de messagerie récepteurs : « Oui, ce message vient vraiment de nous. » Sans cela, votre e-mail peut sembler suspect même lorsque le contenu est parfaitement légitime. Avec cela, vous donnez aux fournisseurs de boîtes de réception un signal plus clair, réduisez les chances de falsification et rendez la vie un peu plus difficile aux fraudeurs qui essaient d'emprunter le nom de votre marque pour leurs propres schémas.

SPF et DKIM sont les deux piliers que la plupart des équipes mettent en place en premier. Ils ont des rôles différents et sont plus efficaces lorsqu'ils sont utilisés ensemble. SPF vérifie si le serveur envoyant le message est autorisé à envoyer pour votre domaine. DKIM vérifie si le message a été signé par votre domaine et s'il a été modifié en cours de route. DMARC se situe au-dessus et indique aux récepteurs comment traiter les messages qui échouent à ces vérifications. Si vous souhaitez une vue d'ensemble de la manière dont l'authentification s'intègre dans le placement global des e-mails, il est utile de lire Meilleures pratiques de délivrabilité des e-mails en parallèle de ce guide.

C'est la version courte. La version longue est plus pratique : vous devez savoir quoi publier dans le DNS, ce que votre fournisseur de messagerie attend de vous et comment confirmer que la configuration fonctionne réellement une fois qu'elle est en ligne.

Ce qu'est l'authentification des e-mails et pourquoi cela compte

L'authentification des e-mails est un ensemble de vérifications techniques qui aident les systèmes récepteurs à décider si un message est réellement associé au domaine dont il prétend provenir. Pensez-y comme une chaîne de preuves. Un message peut dire qu'il provient de votre entreprise, mais si l'IP de l'expéditeur n'est pas autorisée, que le contenu a été modifié ou que le message échoue aux vérifications de politique, la revendication devient moins fiable.

Pourquoi cela compte-t-il autant ? Parce que l'e-mail reste l'un des canaux les plus faciles à usurper. Un message falsifié avec votre domaine dans le champ De peut semer la confusion chez les clients, endommager la confiance et créer des maux de tête en matière de support. L'authentification ne stoppe pas chaque tentative d'abus, mais elle fournit aux fournisseurs de boîtes aux lettres et aux filtres de sécurité des preuves beaucoup plus solides. Le résultat est généralement moins d'opportunités de falsification et un chemin plus sain vers le placement dans la boîte de réception.

Cela compte également pour des raisons ordinaires et non malveillantes. Les grands fournisseurs traitent souvent les e-mails non authentifiés avec prudence. Une newsletter légitime, une réinitialisation de mot de passe ou une confirmation de commande peuvent se retrouver dans les spams ou être rejetées si l'histoire d'authentification semble faible. C'est particulièrement douloureux pour les e-mails transactionnels, où la rapidité et la fiabilité comptent. Si votre application envoie des messages système, vous voudrez peut-être également consulter Configuration DKIM SPF DMARC pour les transactions pour une perspective plus axée sur les transactions.

Une façon utile de penser à l'authentification est la suivante : il ne s'agit pas seulement de sécurité, et il ne s'agit pas seulement de délivrabilité. C'est les deux. Lorsque la preuve technique est claire, les serveurs de messagerie peuvent vous faire confiance plus rapidement, et les attaquants ont plus de mal à prétendre être vous.

Comment fonctionne l'authentification des e-mails à travers SPF, DKIM et DMARC

SPF, DKIM et DMARC sont liés, mais ils ne font pas la même chose. Chaque norme vérifie une partie différente du parcours du message.

SPF, ou Sender Policy Framework, vérifie si l'IP d'envoi est autorisée à envoyer des e-mails pour un domaine. Cela fonctionne en publiant une liste de sources d'envoi autorisées dans le DNS. Lorsqu'un serveur récepteur reçoit un message, il compare l'IP de l'expéditeur à cette liste.

DKIM, ou DomainKeys Identified Mail, signe le message avec une clé privée. Le serveur récepteur récupère la clé publique depuis le DNS et l'utilise pour valider la signature. Si la signature correspond, le message est prouvé avoir été signé par un domaine qui contrôle cette clé, et les parties signées de l'email n'ont pas été altérées en transit.

DMARC, ou Domain-based Message Authentication, Reporting, and Conformance, relie SPF et DKIM ensemble. Il vérifie si le domaine visible par l'utilisateur correspond aux domaines qui ont passé SPF ou DKIM. Ensuite, il indique au récepteur quoi faire lorsque les choses ne s'alignent pas : surveiller, mettre en quarantaine ou rejeter.

La valeur pratique d'utiliser les trois est simple. SPF aide à l'autorisation de la source. DKIM aide à l'intégrité et à l'identité. DMARC aide les récepteurs à appliquer la politique de manière cohérente. Si une méthode échoue, une autre peut encore réussir, ce qui est utile car l'email n'est pas un système parfaitement ordonné. Les messages passent par des relais, des passerelles et des filtres, et tous les chemins ne se comportent pas de la même manière.

Dans la plupart des configurations, SPF et DKIM sont les premiers enregistrements à bien configurer. Une fois ceux-ci stables, DMARC devient beaucoup plus utile car il a des signaux authentiques à évaluer.

Configuration SPF : Ajoutez des sources d'envoi autorisées à votre DNS

La configuration SPF commence par une question : qui est réellement autorisé à envoyer des mails pour votre domaine ? Cela semble évident, mais en pratique, cela inclut souvent plus d'un système. Votre site web pourrait envoyer des réinitialisations de mot de passe via un fournisseur, votre équipe marketing pourrait utiliser une autre plateforme, et votre logiciel de support pourrait envoyer des réponses de support d'un troisième service.

Commencez par lister chaque expéditeur légitime. Incluez votre hôte de mail principal, votre fournisseur transactionnel, votre plateforme CRM, et toute infrastructure qui envoie au nom de votre domaine. Soyez prudent ici. Si vous oubliez une source, le mail de ce système peut échouer au SPF. Si vous ajoutez une source que vous n'utilisez plus, vous ouvrez une porte dont vous n'avez pas besoin.

Ensuite, construisez un seul enregistrement SPF pour le domaine. SPF est publié dans le DNS sous forme d'enregistrement TXT. Le contenu est une déclaration de politique qui commence généralement par v=spf1 et inclut ensuite des mécanismes autorisés tels que ip4, ip6, include, ou a, se terminant par un qualificateur de politique comme -all ou ~all. La syntaxe exacte dépend de votre environnement, mais l'idée est toujours la même : définir qui peut envoyer, puis spécifier ce qui doit se passer pour tout le reste.

Il y a une règle à retenir : utilisez un seul enregistrement SPF par domaine. Plusieurs enregistrements TXT SPF peuvent causer des problèmes car les récepteurs s'attendent à une seule déclaration de politique. Si vous devez autoriser plus d'un service, combinez-les en un seul enregistrement plutôt que de créer des entrées séparées.

Un flux de travail de base ressemble à ceci :

1. Inventoriez chaque plateforme qui envoie des e-mails pour le domaine.
2. Collectez les instructions SPF de chaque fournisseur.
3. Fusionnez-les en un seul enregistrement SPF TXT.
4. Publiez l'enregistrement dans le DNS.
5. Attendez la propagation DNS et testez le résultat.

Une précaution : le SPF a une limite sur les recherches DNS lors de l'évaluation. Cela signifie que vous devez éviter d'empiler trop d'inclusions et d'aides imbriquées dans un seul enregistrement. Il est tentant d'ajouter simplement la chaîne d'inclusion de chaque fournisseur et de considérer cela comme terminé. Résistez à cela. Des enregistrements SPF propres vieillissent mieux et sont plus faciles à dépanner.

Si vous gérez également le comportement des rebonds, le SPF et la gestion des rebonds vont souvent de pair dans la même conversation opérationnelle. L'authentification rend le courrier plus fiable, tandis que la suppression et la gestion des rebonds maintiennent votre liste en bonne santé. Pour cet aspect du travail, Meilleures pratiques pour la gestion des rebonds d'e-mails est une lecture complémentaire sensée.

Configuration DKIM : signer les e-mails sortants avec des clés cryptographiques

DKIM est la partie de la configuration qui semble un peu plus technique, mais le concept est simple. Votre système de messagerie signe les messages sortants avec une clé privée. Vous publiez la clé publique correspondante dans le DNS. Lorsqu'un message arrive, le destinataire vérifie si la signature correspond à la clé publiée et si les parties signées du message sont intactes.

La première étape est la génération de clés. De nombreuses plateformes de messagerie génèrent des clés DKIM pour vous, ce qui est souvent la solution la plus simple. Si vous gérez votre propre infrastructure de messagerie, vous devrez peut-être créer la paire de clés vous-même. L'important est que la clé privée reste du côté de l'expéditeur, et seule la clé publique est publiée dans le DNS.

Une fois que vous avez la clé publique, vous créez un enregistrement DNS TXT sous un sélecteur. Le sélecteur est une étiquette qui identifie la clé spécifique utilisée. Cela vous permet de faire tourner les clés plus tard sans tout casser d'un coup. Un enregistrement DKIM typique comprend le sélecteur, le domaine et la valeur de la clé publique.

Après la publication de l'enregistrement DNS, activez la signature DKIM dans votre fournisseur de messagerie ou MTA. Cette étape varie selon la plateforme. Certains services vous demandent de coller le sélecteur et la clé privée dans leur tableau de bord. D'autres vous permettent d'activer la signature avec un simple interrupteur après la vérification du DNS. Quoi qu'il en soit, assurez-vous que le système signe le bon domaine From ou un domaine étroitement aligné, selon votre configuration.

Ensuite, envoyez un message de test. Ouvrez les en-têtes bruts et recherchez un en-tête DKIM-Signature. S'il est présent, le message a été signé. Si le système récepteur signale un passage DKIM, vous êtes proche. S'il échoue, la cause est généralement l'une des trois choses : le sélecteur est incorrect, la clé publique dans le DNS ne correspond pas à la clé privée, ou le message a changé d'une manière qui casse la signature.

DKIM est particulièrement précieux car il survit à plus que des vérifications d'IP de l'expéditeur. Si un message est transféré ou relayé, le SPF peut échouer même lorsque le message est légitime. DKIM peut toujours passer si le contenu signé reste intact. Cette flexibilité est l'une des raisons pour lesquelles c'est un pilier de l'authentification par e-mail.

Comment tester et vérifier vos enregistrements

Le test est l'endroit où la théorie devient réalité. Un enregistrement peut sembler parfait sur le papier et échouer quand même à cause d'une erreur de syntaxe, d'un retard DNS ou d'un paramètre de fournisseur qui a été négligé.

Commencez par une inspection DNS de base. Vous pouvez interroger directement les enregistrements SPF et DKIM TXT pour confirmer qu'ils existent et contiennent les valeurs que vous attendez. Vérifiez le domaine, le sélecteur et le texte réel de l'enregistrement. De petites fautes de frappe comptent. Un caractère errant dans une clé publique DKIM peut rendre toute la signature inutile.

Ensuite, envoyez un message à une boîte aux lettres que vous contrôlez et inspectez les en-têtes complets. La plupart des principaux fournisseurs de boîtes aux lettres incluent les résultats d'authentification dans les détails du message. Recherchez un SPF réussi ou échoué, un DKIM réussi ou échoué, et tout résultat DMARC qui fait référence à l'alignement.

Vous pouvez également utiliser des outils de test externes pour voir votre configuration du côté de la réception. Ces outils résument souvent si vos enregistrements se résolvent correctement et si le message passe les vérifications d'authentification. Pour des flux de travail de test plus structurés, les outils de test de délivrabilité des e-mails peuvent être utiles lorsque vous avez besoin d'un second avis.

Lorsque vous examinez les résultats, ne vous arrêtez pas à « réussi » ou « échoué ». Regardez la raison. Un succès avec des avertissements peut encore indiquer un problème futur, surtout si vous êtes sur le point de changer de fournisseur ou d'ajouter une nouvelle source d'envoi. Un échec peut indiquer une propagation DNS, des problèmes d'alignement ou un expéditeur inattendu.

Si vous utilisez des rapports DMARC, ils sont particulièrement utiles pour voir ce qui se passe dans votre écosystème de messagerie. Ils peuvent révéler des services oubliés, des adresses IP obsolètes ou un trafic non autorisé que vous ne repéreriez jamais à partir d'un seul message de test.

Erreurs de configuration courantes et comment les corriger

La plupart des problèmes d'authentification ne sont pas mystérieux. Ils résultent généralement d'une poignée d'erreurs familières.

Un problème courant est la publication de plusieurs enregistrements SPF pour le même domaine. C'est facile à faire lorsque différentes équipes gèrent différents systèmes. La solution est simple : combinez les sources autorisées en un seul enregistrement.

Un autre problème fréquent est de dépasser la limite de recherche SPF. Cela se produit lorsque votre enregistrement SPF enchaîne trop d'inclusions et de mécanismes qui nécessitent chacun une évaluation DNS. Si vous rencontrez cela, simplifiez l'enregistrement, supprimez les expéditeurs inutilisés ou demandez à un fournisseur une configuration SPF plus plate.

Des sélecteurs DKIM manquants ou incorrects sont une autre erreur classique. Si le sélecteur dans DNS ne correspond pas au sélecteur que votre système de messagerie utilise lors de la signature, la vérification échouera même si la clé publique elle-même est correcte. Vérifiez le nom du sélecteur, le domaine et le chemin exact de l'enregistrement.

Les incompatibilités de clés sont également courantes. Parfois, un fournisseur fait tourner les clés, ou quelqu'un copie la mauvaise clé dans DNS. Le résultat est une signature qui semble valide mais ne vérifie pas. Régénérez la paire si nécessaire, puis republiez et retestez.

Les problèmes d'alignement peuvent également perturber DMARC. Un message peut passer SPF ou DKIM dans un sens technique, mais si le domaine authentifié ne s'aligne pas avec le domaine visible de l'expéditeur, DMARC peut toujours le considérer comme un échec. C'est pourquoi il est important de tester le domaine exact que les utilisateurs voient, pas seulement le domaine d'envoi en arrière-plan.

Enfin, ne négligez pas le formatage DNS. Les guillemets, les sauts de ligne et les espaces superflus peuvent tous affecter la façon dont les enregistrements sont interprétés. En cas de doute, comparez votre enregistrement avec l'exemple recommandé par le fournisseur caractère par caractère.

Liste de contrôle recommandée pour le déploiement et la maintenance

L'authentification n'est pas un projet ponctuel. C'est une configuration que vous maintenez à mesure que votre pile de messagerie évolue.

• Inventoriez chaque expéditeur avant d'apporter des modifications.
• Gardez un enregistrement SPF par domaine.
• Utilisez DKIM pour tous les flux sortants importants.
• Testez les nouveaux enregistrements dans une boîte aux lettres contrôlée avant un large déploiement.
• Surveillez les résultats d'authentification après des changements de fournisseur ou des mises à jour d'infrastructure.
• Faites tourner les clés DKIM lorsque votre politique de sécurité ou la configuration de votre fournisseur l'exige.
• Examinez régulièrement les rapports DMARC afin de pouvoir repérer rapidement les expéditeurs inconnus.
• Mettez à jour DNS chaque fois que vous ajoutez, supprimez ou changez de services de messagerie.

Un déploiement soigneux est important. Si vous passez d'une plateforme à une autre, publiez les nouveaux paramètres SPF ou DKIM avant de faire la transition, puis testez à la fois les anciens et les nouveaux chemins pendant la transition. Cela réduit le risque d'un échec d'authentification soudain sur le trafic en direct.

Il est également judicieux de coordonner l'authentification avec d'autres travaux de délivrabilité. Si vous réchauffez un nouveau domaine ou une nouvelle adresse IP, l'authentification doit être en place avant le début du réchauffement, et non après. Et si votre programme de messagerie inclut des notifications push ou d'autres canaux de messagerie, il peut être utile de comparer votre hygiène des e-mails avec les pratiques dans Meilleures Pratiques de Notification Push Web afin que votre pile de communication reste cohérente.

Au fil du temps, l'objectif est simple : rendre votre domaine facile à faire confiance. SPF indique au monde quels systèmes sont autorisés à parler en votre nom. DKIM prouve que le message a été signé par vous et est resté intact. Ensemble, ils construisent une base plus solide pour la délivrabilité, la sécurité et la protection de la marque. C'est le genre de plomberie que personne ne remarque quand ça fonctionne, ce qui est généralement le meilleur compliment que l'authentification puisse recevoir.