SPF, DKIM et DMARC : le guide complet de l'authentification e-mail

L'e-mail a été conçu à une époque où personne n'imaginait que l'adresse d'expéditeur puisse être un mensonge. Rien dans le protocole d'origine n'empêche une machine quelconque sur internet de se connecter à un serveur de messagerie en prétendant être vous. C'est cette faille qui fait fonctionner le phishing, et c'est pourquoi trois standards fondés sur le DNS, SPF, DKIM et DMARC, décident aujourd'hui si votre courrier arrive dans la boîte de réception ou dans les indésirables.

Les trois vivent dans les enregistrements DNS de votre domaine : vous pouvez donc inspecter la configuration d'authentification de n'importe quel domaine, y compris le vôtre, avec une simple recherche DNS. Ce guide explique le rôle de chaque enregistrement, comment le lire, et comment atteindre une politique DMARC stricte sans bloquer par accident vos propres factures.

Pour vérifier les trois enregistrements d’un coup, y compris le nombre de requêtes SPF et la taille de votre clé DKIM, utilisez notre vérificateur SPF, DKIM et DMARC.

Pourquoi l'authentification e-mail compte

Deux choses ont changé ces dernières années. Les attaquants imitent les marques de confiance avec beaucoup plus d'efficacité, et les grands fournisseurs de messagerie ont réagi en rendant l'authentification pratiquement obligatoire. Gmail et Yahoo exigent désormais SPF, DKIM et DMARC des expéditeurs en volume, et Microsoft a suivi. Si vos enregistrements sont absents ou cassés, les conséquences sont immédiates et concrètes :

• Votre courrier est filtré. Les messages non authentifiés sont bien plus souvent mis en quarantaine, et parfois rejetés avant même d'atteindre une boîte.
• N'importe qui peut usurper votre domaine. Sans politique DMARC, le serveur destinataire n'a aucune instruction pour rejeter un courrier falsifié portant votre nom.
• Vous ne voyez pas les abus. Les rapports DMARC sont le seul moyen d'apprendre que quelqu'un envoie du phishing en votre nom.
• Les dossiers se bloquent. Les questionnaires de sécurité et les revues fournisseurs réclament une politique DMARC, et « none » est de plus en plus traité comme un défaut.

Les trois enregistrements en un coup d'œil

Ce sont des couches, pas des alternatives. SPF vérifie le serveur émetteur, DKIM vérifie le message, et DMARC relie les deux au domaine que l'humain voit réellement dans l'en-tête From, puis dit quoi faire en cas d'échec. Les trois sont nécessaires.

SPF : qui peut envoyer pour votre domaine

Sender Policy Framework est une liste publique des serveurs autorisés à envoyer du courrier pour votre domaine. Le serveur destinataire prend l'adresse IP qui s'est connectée, consulte votre enregistrement SPF et vérifie si cette adresse figure sur la liste.

Lire un enregistrement SPF

Un enregistrement typique ressemble à ceci :

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

Il se lit de gauche à droite. v=spf1 est la version et doit venir en premier. Chaque include: intègre l'enregistrement SPF d'un autre domaine : c'est ainsi qu'on autorise un prestataire comme Google Workspace ou un service d'e-mail transactionnel. ip4: et ip6: autorisent des adresses ou des plages précises, en général votre propre serveur. Le dernier mécanisme est le fourre-tout, et c'est celui que l'on rate le plus souvent :

• -all est un échec strict. Tout ce qui n'est pas listé n'est pas autorisé, et le destinataire est censé le rejeter.
• ~all est un échec souple. Les expéditeurs non listés sont suspects mais acceptés, généralement avec une pénalité de spam.
• ?all est neutre et n'apprend rien au destinataire, ce qui ôte tout intérêt à la publication de l'enregistrement.

Commencez par ~all pendant que vous vérifiez que chaque expéditeur légitime est listé, puis resserrez vers -all une fois vos rapports DMARC propres.

La limite de dix requêtes

SPF autorise au maximum dix requêtes DNS pendant l'évaluation d'un enregistrement. Chaque include:, a, mx et redirect compte, y compris ceux imbriqués. Au-delà, le résultat est une erreur permanente, que la plupart des destinataires traitent comme une absence totale de SPF. Trois ou quatre prestataires suffisent souvent à dépasser la limite : auditez l'enregistrement chaque fois que vous ajoutez un service d'envoi, et retirez les prestataires que vous n'utilisez plus.

Autre règle qui surprend : un domaine ne peut publier qu'un seul enregistrement SPF. Deux enregistrements TXT v=spf1 sur le même nom constituent une erreur permanente, pas une fusion.

DKIM : signer votre courrier

DomainKeys Identified Mail ajoute une signature cryptographique à chaque message sortant. Votre serveur détient une clé privée et signe certains en-têtes ainsi que le corps ; la clé publique correspondante est publiée dans le DNS. Le destinataire récupère la clé publique, vérifie la signature et apprend deux choses : le message a bien été signé par votre domaine, et rien de ce qu'elle couvrait n'a été modifié en chemin.

La clé publique se trouve à un nom construit à partir d'un sélecteur, par exemple google._domainkey.example.com ou s1._domainkey.example.com. Les sélecteurs permettent d'avoir plusieurs clés en parallèle, ce qui rend la rotation indolore : publiez un nouveau sélecteur, basculez la signature dessus, retirez l'ancien plus tard.

Comme la signature voyage avec le message, DKIM survit au transfert là où SPF échoue. Si une liste de diffusion relaie votre courrier, l'IP qui se connecte change et SPF échoue, mais la signature DKIM reste valide tant que la liste n'a pas réécrit les en-têtes signés ni le corps. Cette robustesse est la raison principale pour laquelle DKIM compte même quand SPF est déjà en place.

DMARC : dire au destinataire quoi faire

SPF et DKIM produisent chacun un succès ou un échec, mais aucun ne dit ce que le destinataire doit en faire, et aucun ne regarde l'adresse From que votre correspondant lit réellement. DMARC comble les deux manques. Un enregistrement ressemble à ceci :

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; adkim=s; aspf=r

p= est la politique : none (surveillance seule), quarantine (traiter les échecs comme du spam) ou reject (les refuser à la porte). rua= est l'adresse qui reçoit les rapports agrégés quotidiens, et c'est la partie la plus précieuse de l'enregistrement. pct= permet d'appliquer la politique à un pourcentage du courrier pendant le déploiement.

L'alignement, ce que presque tout le monde oublie

DMARC n'exige pas seulement que SPF ou DKIM réussisse. Il exige que le domaine qui réussit soit aligné avec celui de l'en-tête From visible. Un message peut réussir SPF pour mailer.vendor.com et échouer tout de même à DMARC pour example.com, parce que les deux ne correspondent pas. C'est de loin la raison la plus fréquente pour laquelle une configuration qui semble correcte échoue quand même.

adkim et aspf règlent la rigueur de la correspondance. Souple (r, la valeur par défaut) accepte un sous-domaine comme mail.example.com ; stricte (s) exige une correspondance exacte. Commencez en souple. DMARC réussit si l'un ou l'autre de SPF et DKIM réussit et s'aligne : une seule signature DKIM alignée suffit donc.

Déployer une politique sans risque

1. Publiez p=none avec une adresse de rapport. Rien ne change pour votre flux de courrier, mais les rapports commencent à arriver.
2. Lisez les rapports pendant deux à quatre semaines. Ils révéleront des services d'envoi oubliés : le CRM, le support, l'outil de facturation, l'ancienne plateforme marketing.
3. Comblez les trous. Ajoutez chaque expéditeur légitime à SPF, activez la signature DKIM avec un domaine aligné, et confirmez le changement dans le rapport suivant.
4. Passez à p=quarantine. Utilisez pct= pour monter progressivement si vous envoyez en volume.
5. Terminez par p=reject. Seulement quand les rapports ne montrent plus aucun courrier légitime en échec. C'est la politique qui stoppe réellement l'usurpation.

Vérifier vos propres enregistrements

Les trois enregistrements sont des enregistrements TXT publics : les vérifier prend quelques secondes.

1. SPF. Lancez une requête TXT sur votre domaine nu avec l'outil de recherche DNS et repérez la chaîne commençant par v=spf1. Vérifiez qu'il n'y en a qu'une, et comptez les requêtes.
2. DMARC. Lancez une requête TXT sur _dmarc. suivi de votre domaine. Si rien ne revient, vous n'avez ni politique ni rapport.
3. DKIM. Lancez une requête TXT sur selecteur._domainkey. suivi de votre domaine. La documentation de votre prestataire indique le sélecteur utilisé.
4. Vérifiez de bout en bout. Envoyez un message vers un compte chez un grand fournisseur et inspectez les en-têtes reçus. La vue « Afficher l'original » de Gmail indique les résultats SPF, DKIM et DMARC du message que vous venez d'envoyer : c'est le seul test qui couvre toute la chaîne.

Tant que vous êtes dans le DNS, confirmez le reste de votre configuration de messagerie : vérifiez que vos enregistrements MX pointent là où vous le pensez, et que le nom présent dans le certificat de votre serveur correspond, ce que vous pouvez contrôler avec le vérificateur de certificat SSL.

Les erreurs courantes à éviter

• Deux enregistrements SPF. Fusionnez-les en un seul. Deux, c'est une erreur permanente.
• Rester sur p=none indéfiniment. La surveillance est un point de départ, pas une destination. Seuls quarantine et reject empêchent l'usurpation.
• Omettre l'adresse de rapport. Un enregistrement DMARC sans rua= jette l'information dont vous avez besoin pour durcir la politique sans casse.
• Oublier les domaines parqués. Les domaines qui n'envoient aucun courrier devraient publier v=spf1 -all et p=reject, précisément parce que les attaquants préfèrent les domaines inutilisés.
• Passer directement à l'alignement strict. adkim=s et aspf=s avant d'avoir des rapports propres casseront du courrier légitime venu de sous-domaines.
• Ignorer le TTL. Un TTL élevé sur un enregistrement TXT fait qu'un correctif met des heures à se propager. Baissez-le avant une migration, remontez-le après.

Authentifiez votre e-mail dès aujourd'hui

L'authentification e-mail est l'une des rares tâches de sécurité au bénéfice sans ambiguïté : meilleure délivrabilité, visibilité sur les abus, et un domaine qu'on n'usurpe pas à la légère. Elle est en plus entièrement lisible depuis l'extérieur : aucune raison de deviner votre propre configuration. Commencez par une requête TXT sur votre domaine avec l'outil gratuit de recherche DNS, lisez ce qui est réellement publié, et suivez le déploiement ci-dessus étape par étape.

Outils et guides associés :

• Recherche DNS : interrogez les enregistrements TXT, MX, SPF et tous les autres de n'importe quel domaine.
• Recherche DNS : le guide complet : chaque type d'enregistrement expliqué simplement.
• Vérificateur de certificat SSL : inspectez le certificat de votre serveur de messagerie ou web.
• Codes de statut HTTP : une référence rapide pour chaque code de réponse.
• Pourquoi votre enregistrement SPF échoue (et comment le corriger) - la limite de dix requêtes, les include cassés et les autres causes d'échec de SPF.

Questions fréquentes