SPF, DKIM et DMARC : sécuriser sa messagerie professionnelle

Afficher une adresse comme direction@votreentreprise.fr ne prouve pas que le message a été envoyé par votre entreprise. Sans authentification, un tiers peut tenter d’usurper le domaine et les services destinataires disposent de moins de signaux pour distinguer vos e-mails légitimes. SPF, DKIM et DMARC répondent ensemble à ce problème, mais une configuration copiée au hasard peut aussi bloquer vos propres outils.

Ce guide explique le rôle de chaque mécanisme, la méthode de déploiement et les contrôles à réaliser lorsqu’un site, une messagerie, un CRM et une newsletter envoient avec le même domaine.

Commencez par inventorier tous les expéditeurs

Avant de modifier le DNS, listez tout ce qui envoie des e-mails en utilisant votre domaine :

• les boîtes des collaborateurs ;
• le formulaire du site et les notifications WordPress ;
• le logiciel de facturation ou de devis ;
• le CRM et les automatisations ;
• la plateforme de newsletter ;
• les outils de support, réservation ou signature ;
• les scanners, copieurs ou applications anciennes.

Pour chaque source, notez le domaine visible dans le champ « De », le serveur réellement utilisé et la documentation fournie. Cette cartographie est la partie la plus importante : une politique parfaite qui oublie le logiciel de facturation fera échouer ses messages.

SPF autorise les sources d’envoi

SPF est un enregistrement TXT publié dans le DNS. Il indique quels serveurs peuvent envoyer pour le domaine technique utilisé lors du transport. Le serveur destinataire compare l’adresse IP de l’expéditeur à cette politique.

Selon la documentation Google Workspace sur SPF, il faut identifier toutes les sources légitimes, maintenir l’enregistrement à jour et retirer les services inutilisés. Un domaine ne doit publier qu’une seule politique SPF ; plusieurs enregistrements concurrents produisent une erreur.

SPF possède aussi une limite de recherches DNS. Empiler les instructions « include » de nombreux fournisseurs peut dépasser cette limite, même si la ligne semble correcte. Ne fusionnez donc pas des valeurs sans analyser ce qu’elles appellent.

Enfin, SPF ne vérifie pas directement l’adresse visible par l’utilisateur. Il porte sur le domaine de l’enveloppe technique. C’est l’une des raisons pour lesquelles SPF seul ne suffit pas à lutter contre l’usurpation.

DKIM signe le contenu du message

DKIM ajoute une signature cryptographique aux en-têtes de chaque e-mail. Le fournisseur d’envoi conserve une clé privée ; la clé publique correspondante est publiée dans le DNS sous un sélecteur. Le destinataire peut ainsi vérifier que certaines parties du message n’ont pas été modifiées depuis la signature.

Chaque service peut utiliser son propre sélecteur DKIM. Cette organisation facilite la rotation des clés et la coexistence de plusieurs expéditeurs. Une migration ne devrait pas supprimer l’ancien sélecteur avant que tous les messages en transit et tous les outils aient basculé.

DKIM résiste généralement mieux au transfert qu’un contrôle SPF, car l’adresse IP change lors d’un renvoi. Certaines modifications du contenu ou des en-têtes peuvent toutefois casser la signature. Google recommande d’utiliser SPF et DKIM ensemble, notamment lorsque des messages sont transférés.

DMARC vérifie l’alignement et donne une consigne

DMARC s’appuie sur SPF et DKIM, puis vérifie l’alignement : le domaine authentifié correspond-il au domaine visible dans l’adresse « De » ? Un message passe DMARC si au moins l’un des deux mécanismes passe et reste correctement aligné.

La documentation Microsoft sur l’authentification des e-mails explique pourquoi les trois mécanismes doivent fonctionner ensemble. SPF ou DKIM peuvent chacun authentifier un domaine différent de celui affiché ; DMARC relie le contrôle à l’identité présentée au destinataire.

La politique DMARC indique ensuite ce que le destinataire devrait faire lorsqu’un message échoue :

• p=none : observer sans demander de blocage ;
• p=quarantine : orienter les échecs vers les indésirables ;
• p=reject : demander le rejet des messages non conformes.

DMARC peut également fournir des rapports agrégés. Ils montrent quels serveurs envoient pour le domaine et quels mécanismes passent ou échouent. Ces rapports demandent une lecture régulière ou un outil capable de les synthétiser.

Déployez progressivement pour ne pas bloquer l’activité

Passer directement à p=reject sans inventaire est dangereux. Un outil oublié peut produire des devis, confirmations ou alertes légitimes qui seront refusés. Google recommande de configurer SPF et DKIM avant DMARC, de commencer en observation, puis d’augmenter progressivement l’application après analyse des rapports.

1. Cartographier. Recensez chaque source, domaine d’enveloppe, signature DKIM et volume.
2. Corriger SPF. Construisez une politique unique couvrant les sources nécessaires sans dépasser les limites.
3. Activer DKIM. Générez les clés chez chaque fournisseur et vérifiez les signatures dans les messages reçus.
4. Publier DMARC en observation. Utilisez une adresse dédiée pour recevoir les rapports.
5. Analyser. Identifiez les expéditeurs inconnus, les défauts d’alignement et les outils légitimes oubliés.
6. Renforcer par étapes. Testez une quarantaine partielle, augmentez le pourcentage, puis envisagez le rejet lorsque le flux est maîtrisé.

Le site WordPress est souvent l’expéditeur oublié

Par défaut, un serveur web peut tenter d’envoyer directement des e-mails avec une adresse du domaine. Ces messages sont parfois mal authentifiés ou bloqués par l’hébergeur. Utiliser un service SMTP ou une API d’envoi adaptée permet d’identifier clairement la source et d’appliquer SPF ou DKIM.

Ne placez pas l’adresse du visiteur dans le champ « De » d’un formulaire. Le site n’est pas autorisé à envoyer au nom de gmail.com ou du domaine du prospect. Utilisez une adresse de votre propre domaine comme expéditeur et placez l’adresse saisie dans « Répondre à ». Cette différence simple évite de nombreux échecs DMARC.

Testez les formulaires après chaque changement de messagerie ou de DNS. Vérifiez la réception, la réponse, les en-têtes d’authentification et le comportement sur plusieurs fournisseurs.

Les erreurs les plus courantes

• publier deux enregistrements SPF au lieu d’une seule politique consolidée ;
• oublier un CRM, un copieur ou le site dans l’inventaire ;
• dépasser la limite de recherches DNS de SPF ;
• publier une clé DKIM sans activer la signature chez le fournisseur ;
• confondre réussite SPF et alignement DMARC ;
• appliquer p=reject avant d’avoir lu les rapports ;
• supprimer les anciennes entrées pendant une migration encore en cours ;
• croire qu’une authentification correcte garantit la boîte principale.

La délivrabilité dépend aussi de la réputation du domaine et de l’adresse IP, du volume, des plaintes, du contenu et du respect du choix des destinataires. Les règles actuelles de Gmail pour les expéditeurs imposent au minimum SPF ou DKIM à tous les expéditeurs vers Gmail, et SPF, DKIM ainsi que DMARC aux expéditeurs en volume. Elles demandent aussi TLS, un DNS cohérent et un faible taux de plaintes.

Comment vérifier un message réel

Envoyez un e-mail depuis chaque source vers plusieurs boîtes de test. Dans Gmail, Outlook ou un autre client, affichez les en-têtes complets et cherchez la ligne Authentication-Results. Elle indique généralement les résultats SPF, DKIM et DMARC, ainsi que les domaines évalués.

Un simple outil de vérification DNS confirme que les enregistrements sont publiés, mais il ne prouve pas que le fournisseur signe réellement ou que l’alignement fonctionne. Le test doit partir du flux réel : formulaire, CRM, boîte utilisateur et newsletter.

Authentifier sans figer l’écosystème

Une bonne configuration permet d’ajouter ou de retirer un outil sans reconstruire la politique dans l’urgence. Conservez un inventaire, documentez chaque entrée DNS et prévoyez la rotation des clés. Lorsqu’un service est résilié, retirez ses autorisations après avoir confirmé qu’il n’envoie plus.

Alliance Web peut auditer la zone, coordonner les fournisseurs et sécuriser les flux dans le cadre de son service de gestion de domaine et de messagerie professionnelle. Pour reprendre l’ensemble des accès, commencez par le guide nom de domaine et DNS.