Authentification e-mail : SPF, DKIM et DMARC expliqués

Si vos e-mails atterrissent dans les spams, sont supprimés silencieusement ou arrivent avec un avertissement « via », la cause est souvent la même : une authentification e-mail absente ou défaillante. SPF, DKIM et DMARC sont les trois enregistrements qui prouvent qu’un e-mail provient réellement de votre domaine. Bien configurés, ils protègent à la fois votre placement en boîte de réception et votre marque contre l’usurpation. Mal configurés, même des campagnes légitimes peinent à atteindre les destinataires.

Ce guide explique comment fonctionnent SPF, DKIM et DMARC, comment ils s’articulent via l’alignement et la politique, où la plupart des configurations échouent, et propose une approche générique pas à pas applicable à n’importe quelle messagerie ou plateforme d’envoi. Voyez cela comme apprendre à votre domaine à porter une lettre scellée et vérifiable — le genre qu’un vaillant pigeon voyageur livre sans que personne ne mette en doute l’expéditeur.

Pourquoi l’authentification e-mail compte pour la délivrabilité

Les fournisseurs de messagerie comme Gmail, Outlook et Yahoo reçoivent un volume considérable de courrier, dont une large part est du spam ou de la fraude pure. Pour décider de ce qui atteint la boîte de réception, ils s’appuient fortement sur la capacité d’un message à être rattaché de façon cryptographique et administrative à un domaine réel et responsable.

L’authentification fait trois choses pour vous :

• Elle construit la réputation d’expéditeur. La réputation est suivie par domaine et par IP. Sans authentification, les fournisseurs ne peuvent pas attribuer de façon fiable votre bon comportement, et vous n’accumulez jamais la confiance qui vous vaut le placement en boîte de réception.
• Elle empêche l’usurpation et le phishing. N’importe qui peut mettre votre adresse dans le champ « De ». L’authentification est ce qui empêche un escroc d’usurper de façon convaincante votre marque.
• Elle répond aux exigences des expéditeurs en masse. Les grands fournisseurs attendent désormais des expéditeurs en masse une authentification correcte. Les domaines non conformes voient de plus en plus leur courrier rejeté ou filtré.

En bref : l’authentification n’est plus une finition optionnelle. C’est le socle sur lequel repose tout le reste de la délivrabilité. Pour approfondir la vue d’ensemble, consultez notre guide de la délivrabilité e-mail.

Comment fonctionne SPF

SPF (Sender Policy Framework) répond à une seule question : ce serveur est-il autorisé à envoyer du courrier pour ce domaine ?

Vous publiez un enregistrement SPF sous forme d’enregistrement TXT dans le DNS de votre domaine. Il liste les serveurs et services autorisés à envoyer en votre nom. Lorsqu’un serveur destinataire reçoit votre message, il vérifie l’adresse IP du serveur d’envoi par rapport à cette liste.

Un enregistrement SPF simplifié ressemble à ceci :

v=spf1 include:_spf.example-esp.com include:servers.mailservice.com -all

Décortiquons-le :

• v=spf1 déclare la version de l’enregistrement.
• include: délègue l’autorisation à l’enregistrement SPF d’un autre domaine. C’est ainsi que vous autorisez une plateforme d’e-mailing, votre CRM, votre service d’assistance, etc. — chaque fournisseur vous donne la valeur include à ajouter.
• -all est le mécanisme d’application. -all (échec strict) signifie « tout ce qui n’est pas listé n’est pas autorisé ». ~all (échec souple) est plus permissif et marque les sources non listées comme suspectes plutôt que de les rejeter d’emblée.

Limites clés de SPF à connaître

• La limite des dix requêtes. SPF autorise un maximum de dix requêtes DNS. Chaque include peut en enchaîner d’autres, et dépasser dix entraîne une erreur permerror qui casse entièrement SPF. Empiler trop de services est la cause la plus fréquente d’un échec silencieux de SPF.
• SPF casse au transfert. Lorsqu’un message est transféré, l’IP du serveur de transfert ne figure généralement pas dans votre enregistrement SPF, donc la vérification échoue. C’est précisément pour cela qu’existent DKIM et DMARC — SPF seul ne suffit pas.
• Un seul enregistrement SPF par domaine. Vous fusionnez toutes les sources dans un unique enregistrement. Publier deux enregistrements SPF TXT séparés est invalide.

Comment fonctionne DKIM

DKIM (DomainKeys Identified Mail) ajoute à chaque message une signature qui révèle toute altération. Là où SPF vérifie le chemin, DKIM vérifie le contenu et l’origine à l’aide d’une cryptographie à clé publique.

Voici le mécanisme :

1. Votre plateforme d’envoi détient une clé privée et l’utilise pour signer les messages sortants. La signature couvre les en-têtes et le corps.
2. Vous publiez la clé publique correspondante dans le DNS sous forme d’enregistrement TXT, sous un nom qui inclut un sélecteur — par exemple selector1._domainkey.votredomaine.com. Le sélecteur vous permet d’utiliser plusieurs clés à la fois (pratique pour la rotation des clés ou plusieurs fournisseurs).
3. Le serveur destinataire lit l’en-tête DKIM-Signature, récupère votre clé publique dans le DNS et vérifie la signature.

Si la signature est validée, deux choses sont prouvées : le message provient réellement d’un domaine qui contrôle la clé privée, et il n’a pas été altéré en transit. Comme DKIM signe le message lui-même plutôt que de vérifier l’IP de connexion, il survit au transfert dans la plupart des cas — un avantage décisif sur SPF.

Aspects pratiques de DKIM

• Utilisez des clés robustes. Les clés plus longues (souvent 2048 bits) sont la norme moderne. Certaines configurations anciennes utilisent encore des clés plus faibles, auxquelles les fournisseurs peuvent ne pas faire confiance.
• Les sélecteurs permettent la rotation. Faire tourner les clés périodiquement est une bonne hygiène, et les sélecteurs la rendent possible sans interruption : publiez une nouvelle clé sous un nouveau sélecteur, basculez la signature, puis retirez l’ancienne.
• Votre plateforme gère la signature. En pratique, vous touchez rarement à la clé privée — votre service e-mail génère la paire de clés et vous fournit l’enregistrement DNS de clé publique à publier.

Comment DMARC relie le tout

SPF et DKIM prouvent chacun quelque chose d’utile, mais à eux seuls ils ne disent pas au serveur destinataire quoi faire lorsque les vérifications échouent, et ils ne garantissent pas que ces vérifications portent sur l’adresse que votre destinataire voit réellement. DMARC (Domain-based Message Authentication, Reporting and Conformance) comble ces deux lacunes.

DMARC est également un enregistrement TXT, publié à _dmarc.votredomaine.com. Il introduit trois concepts : l’alignement, la politique et le reporting.

L’alignement

C’est le cœur de DMARC. Un message passe DMARC lorsque SPF ou DKIM passe et que le domaine concerné s’aligne avec le domaine de l’en-tête From visible.

• L’alignement SPF compare le domaine From avec le domaine validé par SPF.
• L’alignement DKIM compare le domaine From avec le domaine de la signature DKIM.

L’alignement est crucial car un spammeur pourrait passer SPF pour son propre domaine tout en usurpant votre adresse dans la ligne From. L’exigence d’alignement de DMARC est ce qui rend cela impossible. Il suffit que l’un des deux, SPF ou DKIM, passe et s’aligne pour que DMARC passe.

La politique

La balise p= indique aux destinataires comment traiter le courrier qui échoue à DMARC :

• p=none — surveillance seule. Rien n’est bloqué ; vous collectez simplement des données. C’est là que tout domaine devrait commencer.
• p=quarantine — le courrier en échec est traité comme suspect, généralement dirigé vers les spams.
• p=reject — le courrier en échec est rejeté d’emblée. C’est la protection la plus forte contre l’usurpation et l’état final recommandé une fois que vous êtes certain que votre courrier légitime est aligné.

Un enregistrement de base ressemble à :

v=DMARC1; p=none; rua=mailto:dmarc-reports@votredomaine.com

Les rapports agrégés

La balise rua= indique aux destinataires où envoyer les rapports agrégés — des résumés XML indiquant qui envoie du courrier en utilisant votre domaine et si SPF, DKIM et l’alignement ont réussi. Ces rapports vous permettent de découvrir les services légitimes que vous avez oublié d’autoriser avant de durcir votre politique. Les rapports sont du XML dense, alors la plupart des équipes les injectent dans un outil de reporting DMARC qui les transforme en tableaux de bord lisibles.

Le parcours recommandé est une montée en charge progressive : commencez à p=none, lisez les rapports, corrigez chaque source légitime jusqu’à ce qu’elle soit alignée, passez à p=quarantine, vérifiez que rien ne casse, puis passez à p=reject.

BIMI, en bref

BIMI (Brand Indicators for Message Identification) permet à votre logo de marque vérifié d’apparaître à côté de vos messages dans les boîtes de réception compatibles. C’est une récompense de réputation, pas une vérification d’authentification en soi — et il y a un prérequis strict : vous devez d’abord disposer de DMARC à une politique appliquée (quarantine ou reject). Certaines boîtes de réception exigent aussi un Verified Mark Certificate. Considérez BIMI comme un bonus que vous gagnez une fois le socle SPF/DKIM/DMARC solide, pas comme un point de départ.

Erreurs courantes

• Dépasser la limite des dix requêtes SPF. Ajouter service après service vous fait silencieusement franchir la limite et casse SPF pour tout le monde.
• Publier deux enregistrements SPF. Un seul est valide ; un second invalide la vérification.
• Oublier une source d’envoi. Votre CRM, votre outil de facturation, votre service d’assistance et votre plateforme de newsletter peuvent tous envoyer au nom de votre domaine. En oublier un, et il échoue à l’authentification — parfois découvert seulement après avoir atteint p=reject.
• Sauter directement à p=reject. Appliquer la politique avant d’avoir vérifié chaque source légitime est le moyen le plus rapide de bloquer votre propre courrier transactionnel.
• Clés DKIM faibles ou jamais renouvelées. Des clés anciennes et courtes sapent la confiance que DKIM est censé bâtir.
• Ignorer les rapports DMARC. Les rapports existent pour vous guider ; les ignorer revient à durcir la politique à l’aveugle.

Approche de configuration pas à pas

Cette séquence est indépendante du fournisseur — les valeurs DNS exactes proviennent de votre plateforme e-mail, mais l’ordre est le même partout.

1. Inventoriez chaque source d’envoi. Listez tout ce qui envoie du courrier au nom de votre domaine : plateforme marketing, CRM, service d’assistance, système de facturation, et votre propre serveur de messagerie.
2. Publiez ou mettez à jour SPF. Créez un unique enregistrement SPF TXT qui inclut chaque service autorisé. Surveillez le nombre de requêtes. Commencez avec ~all, passez à -all une fois que vous êtes en confiance.
3. Activez DKIM sur chaque source. Dans chaque plateforme, activez DKIM et publiez l’enregistrement TXT de clé publique fourni, en utilisant le sélecteur qu’elle indique. Confirmez que chacune signe bien votre courrier sortant.
4. Publiez DMARC à p=none. Ajoutez l’enregistrement TXT _dmarc avec p=none et une adresse rua= pour que les rapports commencent à affluer.
5. Lisez les rapports et corrigez l’alignement. Sur quelques semaines, identifiez toute source légitime qui ne passe pas ou ne s’aligne pas, et corrigez-la.
6. Montez en charge la politique. Passez à p=quarantine, surveillez, puis à p=reject une fois tout propre.
7. Envisagez BIMI. Avec l’application en place, évaluez l’ajout d’un enregistrement BIMI pour afficher votre logo.

Comment vérifier

• Envoyez un message de test vers un compte chez un grand fournisseur et affichez les en-têtes du message (dans Gmail, « Afficher l’original »). Cherchez spf=pass, dkim=pass et dmarc=pass.
• Vérifiez le DNS directement. Interrogez les enregistrements TXT de votre domaine pour confirmer que les enregistrements SPF, le sélecteur DKIM et DMARC se résolvent comme prévu.
• Utilisez un outil de requête ou de test. Les vérificateurs gratuits SPF, DKIM et DMARC signalent les erreurs de syntaxe, le dépassement des dix requêtes et l’absence d’alignement.
• Surveillez vos rapports DMARC. Les rapports agrégés continus sont votre système d’alerte précoce pour les nouvelles sources non autorisées — ou légitimes oubliées.

L’authentification n’est pas une tâche ponctuelle. Les sources changent, des services sont ajoutés, les clés doivent être renouvelées. Revoyez vos enregistrements chaque fois que vous ajoutez un nouvel outil qui envoie en votre nom, et continuez à lire ces rapports.

FAQ

Ai-je besoin des trois, SPF, DKIM et DMARC ?

Oui. SPF et DKIM prouvent chacun des choses différentes, et DMARC est ce qui les relie à l’adresse que les destinataires voient réellement tout en indiquant aux destinataires quoi faire en cas d’échec. Ensemble, ils forment un seul système ; en omettre un laisse une faille que les fournisseurs — et les spammeurs — trouveront.

Quelle est la différence entre SPF et DKIM ?

SPF autorise quels serveurs peuvent envoyer pour votre domaine (une vérification de chemin) et casse lorsque le courrier est transféré. DKIM signe cryptographiquement le message lui-même, prouvant l’origine et l’intégrité, et survit généralement au transfert. DMARC exige qu’au moins l’un d’eux passe et s’aligne avec votre domaine From visible.

Est-il prudent de commencer DMARC à p=reject ?

Non. Commencez à p=none pour surveiller, utilisez les rapports agrégés pour trouver et corriger chaque source d’envoi légitime, puis montez en charge via quarantine jusqu’à reject. Sauter directement à l’application risque de bloquer votre propre courrier légitime.

L’authentification e-mail garantit-elle le placement en boîte de réception ?

Non, mais c’est le prérequis. L’authentification permet aux fournisseurs de faire confiance à vos envois et de les attribuer. Le placement en boîte de réception dépend toujours de la réputation, de l’engagement et de la qualité de la liste — abordés dans notre guide de la délivrabilité e-mail.