SPF, DKIM et DMARC : comprendre l’authentification de ses e-mails

E-mail et CRM · 7 min de lecture

SPF, DKIM et DMARC sont complémentaires : SPF vérifie si un serveur est autorisé à envoyer pour un domaine, DKIM permet de vérifier une signature du message, et DMARC relie ces contrôles au domaine visible de l’expéditeur. Pour une petite entreprise, la priorité est d’inventorier tous les outils qui envoient des e-mails, puis de vérifier leur authentification avant de durcir les règles.

À retenir

• La messagerie professionnelle et l’outil marketing doivent être contrôlés séparément.
• Un contrôle SPF ou DKIM réussi ne suffit pas toujours à valider DMARC.
• Une politique DMARC d’observation ne demande pas le rejet des messages.
• L’authentification ne garantit pas l’arrivée dans la boîte principale.

Commencer par les services qui envoient réellement

Recensez la messagerie des collaborateurs, la newsletter, les confirmations de commande, la facturation et les notifications du site. Pour chaque service, notez le domaine visible dans le champ « De », son responsable et les instructions d’authentification du fournisseur. Un outil ancien peut continuer à envoyer même s’il n’apparaît plus dans vos campagnes habituelles.

Repérez ensuite qui gère la zone DNS, c’est-à-dire les enregistrements techniques de votre domaine. Cette personne n’est pas nécessairement celle qui administre votre site. Demandez une copie des enregistrements existants avant tout changement, ainsi qu’une procédure de retour arrière. N’envoyez pas de mots de passe par e-mail pour préparer cet inventaire.

Comprendre SPF, DKIM et DMARC sans les confondre

SPF : autoriser les serveurs d’envoi

SPF s’appuie sur un enregistrement DNS qui indique les serveurs autorisés à envoyer pour le domaine contrôlé. Dans le cas courant, ce domaine est celui de l’expéditeur de l’enveloppe technique, associé au Return-Path, pas nécessairement celui affiché dans « De ». La documentation SPF de Google décrit les autorisations ; sa documentation DMARC explique cette distinction entre domaines.

Pour un même nom de domaine contrôlé, il faut un seul enregistrement SPF regroupant les autorisations nécessaires, pas un enregistrement concurrent par fournisseur. Ne fusionnez pas des valeurs au hasard : les services peuvent utiliser des domaines d’enveloppe différents. Faites vérifier la syntaxe et les dépendances par la personne responsable. Ajouter de nombreux fournisseurs peut aussi rencontrer la limite des consultations DNS autorisées par SPF ; faites contrôler les inclusions imbriquées, pas seulement la longueur du texte.

DKIM : vérifier la signature du message

Le service expéditeur signe le message avec une clé privée. Le serveur destinataire vérifie cette signature avec une clé publique accessible dans le DNS. Cela permet de contrôler les parties signées du message et le domaine signataire. DKIM ne chiffre pas le contenu et ne prouve pas que la demande contenue dans l’e-mail est honnête.

La documentation DKIM de Google détaille les clés et la vérification. Plusieurs fournisseurs peuvent utiliser des sélecteurs différents, qui identifient leurs clés. Suivez les noms et valeurs fournis par chaque outil. La publication DNS ne suffit pas toujours : l’activation de la signature côté expéditeur doit également être vérifiée.

DMARC : contrôler l’alignement et définir une politique

DMARC utilise le domaine visible dans « De ». Pour réussir, il faut au moins un contrôle réussi et aligné : SPF avec son domaine d’enveloppe, ou DKIM avec son domaine signataire. L’alignement peut être strict, avec des domaines identiques, ou souple, avec le même domaine organisationnel, par exemple votre domaine et un sous-domaine, selon les réglages. La documentation officielle DMARC expose ces conditions et les politiques disponibles.

• p=none ne demande pas de traitement particulier au titre de DMARC ; il sert notamment à observer avec des rapports configurés.
• p=quarantine demande de traiter les échecs comme suspects, par exemple en courrier indésirable.
• p=reject demande de rejeter les messages en échec.

Le serveur destinataire conserve ses propres règles de filtrage. « None » ne signifie donc pas que tous les messages arriveront en boîte de réception.

Exemple illustratif : un domaine et plusieurs outils

Cet exemple est fictif et ne fournit pas de configuration à copier. Une boutique utilise une messagerie professionnelle, un outil de newsletter et un service de confirmations de commande. Tous affichent son domaine dans « De ».

Les e-mails de la messagerie réussissent DMARC grâce à une signature DKIM alignée. La newsletter réussit SPF, mais uniquement pour le domaine technique du fournisseur ; sa signature DKIM utilise aussi ce domaine tiers. Sans alignement avec le domaine visible, elle échoue à DMARC. Un résultat « SPF réussi » ne résout donc pas tout.

La boutique demande au fournisseur une authentification adaptée à son domaine et vérifie un nouvel envoi réel. Elle contrôle également les confirmations de commande avant de renforcer sa politique. Ces observations sont hypothétiques : elles illustrent les vérifications à faire, pas un diagnostic sur votre installation.

Déployer progressivement et vérifier les résultats

Configurez les mécanismes nécessaires en suivant les instructions de chaque service. Google recommande de commencer DMARC avec p=none, puis d’ajuster la politique après observation de l’authentification. Configurez une adresse de rapports réellement suivie et désignez la personne chargée de les interpréter. Publier un enregistrement sans examiner les échecs laisse les problèmes invisibles.

Envoyez ensuite un message réel depuis chaque service vers une boîte externe de test. Examinez les résultats du serveur destinataire dans les en-têtes, notamment Authentication-Results, ainsi que les domaines utilisés. La documentation DKIM explique cette vérification. Un statut vert dans l’outil expéditeur ou la simple présence d’un enregistrement DNS ne démontre pas que tous vos flux fonctionnent.

Checklist à transmettre au responsable technique

1. Inventorier les services actifs et leurs domaines d’envoi.
2. Identifier le gestionnaire DNS et sauvegarder la configuration existante.
3. Vérifier SPF pour chaque domaine d’enveloppe concerné.
4. Contrôler les sélecteurs DKIM et l’activation des signatures.
5. Vérifier l’alignement DMARC sur des messages réels.
6. Prévoir la réception et l’analyse des rapports.
7. Tester les messages marketing et les notifications essentielles.
8. Corriger les flux légitimes avant toute politique plus restrictive.

Limites et erreurs fréquentes

Passer directement à p=reject sans inventaire peut bloquer des e-mails légitimes. Copier les enregistrements d’une autre entreprise, remplacer un SPF sans vérifier les services actifs ou publier une clé DKIM au mauvais nom sont d’autres erreurs à éviter.

Ces mécanismes ne remplacent ni le consentement à la prospection, ni la qualité des listes, ni la sécurité des comptes. Ils ne garantissent pas la délivrabilité et ne rendent pas un message sûr à eux seuls. Ce guide explique les décisions ; les valeurs DNS doivent être adaptées par une personne compétente.

Questions fréquentes

Le prestataire e-mail peut-il tout configurer ?

Il peut fournir les instructions et gérer la signature de ses propres envois. La coordination avec le gestionnaire DNS et les autres services reste nécessaire. Demandez des preuves sur chaque flux concerné.

DMARC avec p=none suffit-il à protéger le domaine ?

C’est une étape d’observation, pas une demande de blocage des échecs. Utilisez les rapports pour identifier les services légitimes à corriger, puis décidez d’une politique adaptée.

Pourquoi un e-mail authentifié arrive-t-il encore en spam ?

L’authentification n’est qu’un élément du contrôle. Le destinataire applique aussi ses propres filtres. Examinez les retours et la qualité des envois sans promettre qu’une correction DNS supprimera tout classement en indésirable.

Votre prochaine étape

Rassemblez un message récent de chaque service et la liste de leurs responsables. Demandez un contrôle des résultats SPF, DKIM et DMARC et de l’alignement avant d’autoriser une modification. Vous obtiendrez ainsi un diagnostic vérifiable plutôt qu’un simple « tout est configuré ».

Sources et ressources

• Google : à propos des enregistrements SPF, serveurs autorisés et unicité de l’enregistrement.
• Google : configurer DKIM, clés, signatures et vérification.
• Google : configurer DMARC, alignement, politiques et observation progressive.
• RFC 6376 : DKIM, signature sans chiffrement.
• Google : consignes aux expéditeurs, authentification et filtrage antispam.