Vos e-mails professionnels arrivent en spam ? L’impact d’une mauvaise configuration SPF, DKIM et DMARC

Un devis, une facture ou un lien de réinitialisation parfaitement légitime peut finir dans les courriers indésirables si le domaine expéditeur est mal authentifié. Les services de messagerie évaluent de nombreux signaux, mais SPF, DKIM et DMARC constituent la base permettant de vérifier l’identité d’un expéditeur.
L’enjeu est particulièrement concret pour les entreprises marocaines qui communiquent avec des clients au Maroc, en Europe et ailleurs. Une même organisation peut envoyer des messages depuis Microsoft 365 ou Google Workspace, mais aussi depuis son CRM, son site web, son outil de support et son logiciel de facturation. Chaque service doit être correctement déclaré.
Le rôle respectif de SPF, DKIM et DMARC

Ces mécanismes sont complémentaires. Ils ne vérifient pas exactement la même chose et l’activation de l’un ne corrige pas l’absence des deux autres.
SPF autorise les serveurs d’envoi
SPF est un enregistrement TXT publié dans le DNS. Il indique les infrastructures autorisées à envoyer des e-mails pour un domaine. Le serveur destinataire compare l’adresse IP qui se connecte avec la politique SPF liée à l’expéditeur d’enveloppe.
Les problèmes fréquents comprennent l’oubli d’un nouveau prestataire, la publication de plusieurs enregistrements SPF, l’accumulation de directives « include » ou le maintien de services qui ne sont plus utilisés. Le transfert automatique peut également provoquer un échec, car l’adresse IP du serveur intermédiaire n’est pas forcément autorisée.
DKIM appose une signature vérifiable
DKIM ajoute une signature cryptographique aux messages sortants. Le destinataire récupère la clé publique correspondante dans le DNS et vérifie que les éléments signés n’ont pas été modifiés en cours de route.
Une erreur de sélecteur, une clé publique incomplète, une signature non activée chez le fournisseur ou la modification du message par un relais peuvent invalider le contrôle. Les anciens sélecteurs doivent aussi être inventoriés et retirés lorsqu’ils ne servent plus.
DMARC contrôle l’alignement du domaine
DMARC relie les résultats SPF et DKIM au domaine affiché dans le champ visible « From ». Pour réussir DMARC, le message doit obtenir un résultat valide avec SPF ou DKIM, et le domaine ayant réussi doit être aligné avec celui que voit le destinataire.
La politique DMARC peut demander l’observation, la mise en quarantaine ou le rejet des messages suspects. Ses rapports agrégés permettent également de repérer les plateformes qui utilisent le domaine.
Pourquoi une mauvaise configuration nuit à la délivrabilité

L’authentification n’est pas l’unique critère de classement. La réputation, les plaintes, la qualité des listes, le contenu et les variations de volume comptent également. Toutefois, un échec SPF, DKIM ou DMARC supprime un signal de confiance essentiel et facilite l’usurpation du domaine.
- Service absent du SPF : le CRM, le site ou l’outil d’envoi utilise une infrastructure non déclarée.
- Plusieurs politiques SPF : des enregistrements concurrents sont publiés au lieu d’une politique unique et valide.
- DKIM valide mais non aligné : le prestataire signe avec son propre domaine, sans correspondance avec le domaine visible.
- Politique DMARC trop stricte trop tôt : le rejet est activé avant d’avoir identifié tous les flux légitimes.
- DNS obsolète : une migration laisse des fournisseurs et des sélecteurs inutilisés.
- Sous-domaines oubliés : les messages marketing ou transactionnels partent sans politique cohérente.
Ces erreurs peuvent entraîner un placement en spam, une délivrabilité variable selon le fournisseur ou un rejet direct. Une politique stricte mal préparée peut même bloquer les messages légitimes de l’entreprise.
Comment établir un diagnostic fiable
1. Recenser tous les expéditeurs
Inventoriez les boîtes des collaborateurs, formulaires web, boutiques en ligne, CRM, newsletters, outils de support, logiciels comptables et applications internes. Vérifiez aussi les services rattachés à votre hébergement web, car le site utilise souvent un circuit d’envoi distinct de la messagerie principale.
2. Examiner les en-têtes complets
Envoyez des messages de test vers plusieurs fournisseurs de messagerie, puis consultez leurs en-têtes complets. Contrôlez les résultats SPF, DKIM et DMARC, le domaine de signature DKIM, l’expéditeur d’enveloppe et le domaine visible. Un simple résultat « pass » ne suffit pas si les domaines ne sont pas alignés.
3. Vérifier les réponses DNS publiques
Contrôlez ce que les serveurs destinataires peuvent réellement interroger, pas uniquement ce qu’affiche l’interface de gestion. Il doit exister une politique SPF cohérente, des sélecteurs DKIM accessibles et un enregistrement DMARC syntaxiquement valide. Tenez compte du cache DNS après chaque modification.
4. Exploiter les rapports DMARC
Les rapports agrégés regroupent les adresses IP d’envoi et les résultats d’authentification. Ils aident à distinguer les services autorisés des sources inconnues. Ces données doivent être conservées et partagées avec précaution, car elles décrivent une partie de l’infrastructure.
5. Ne pas confondre authentification et réputation
Si les domaines sont alignés mais que les messages restent en spam, examinez la réputation du domaine et des IP, les hausses soudaines de volume, les plaintes, les destinataires inactifs, la réputation des liens et la pertinence du contenu. Une identité vérifiée ne transforme pas un message indésirable en message attendu.
Corriger les réglages sans perturber les envois
Commencez par une phase d’observation. Consolidez les autorisations SPF et ne retirez un ancien fournisseur qu’après avoir vérifié qu’aucun flux ne l’utilise. SPF impose une limite de recherches DNS : les inclusions inutiles et les chaînes complexes sont donc à éviter.
Activez DKIM sur chaque plateforme compatible, de préférence avec un domaine qui vous appartient et qui s’aligne avec l’adresse visible. Documentez les sélecteurs, les responsables et les rotations de clés. Lors d’un renouvellement, validez la nouvelle clé avant de supprimer l’ancienne.
Pour DMARC, observez d’abord les rapports et corrigez les sources légitimes en échec. Renforcez ensuite la politique par étapes contrôlées. Les sous-domaines et les prestataires internationaux doivent faire partie du périmètre dès le départ.
Cette démarche complète une véritable stratégie de cybersécurité. L’authentification multifacteur, la gestion des accès, l’audit des boîtes et la réponse aux incidents restent indispensables : SPF, DKIM et DMARC ne bloquent pas l’envoi depuis un compte réellement compromis.
Les bonnes pratiques à maintenir dans la durée
- Désigner un responsable des paramètres DNS et de l’authentification e-mail.
- Contrôler tout nouveau prestataire avant son premier envoi.
- Surveiller les rapports DMARC et les erreurs de livraison.
- Séparer les flux avec des sous-domaines clairement administrés lorsque cela est pertinent.
- Retirer les anciens fournisseurs des enregistrements et des applications.
- Tester les messages transactionnels après une migration ou une modification DNS.
- Entretenir des listes fondées sur le consentement et traiter rapidement les désabonnements.
Pour une entreprise présente au Maroc et à l’international, les tests doivent couvrir les fournisseurs réellement utilisés par ses clients. Le comportement de livraison peut varier selon le réseau destinataire, la région et la nature du message.
Conclusion : gérer l’authentification comme une infrastructure
SPF, DKIM et DMARC ne sont pas des réglages à effectuer une seule fois. Ils doivent évoluer à chaque changement d’hébergeur, de plateforme marketing, d’application ou de fournisseur de messagerie. Une méthode fiable consiste à recenser les flux, contrôler l’alignement, observer les rapports et renforcer progressivement la politique.
Si vos messages légitimes sont rejetés ou classés en spam, évitez de modifier plusieurs enregistrements au hasard. Sauvegardez la configuration, collectez les en-têtes, identifiez les sources autorisées et testez chaque correction. Pour auditer votre chaîne d’envoi et préparer un plan d’action, vous pouvez contacter l’équipe developer.ma.


French