Pourquoi des emails professionnels finissent en spam

Les services de messagerie (Gmail, Outlook, Yahoo, etc.) filtrent de plus en plus strictement les emails pour limiter le phishing (usurpation d’identité) et les arnaques. Un domaine d’entreprise mal configuré peut être perçu comme « suspect », même si le contenu du message est sérieux.

Les causes fréquentes sont :

• absence d’authentification du domaine (pas de SPF/DKIM/DMARC, ou configuration incomplète) ;
• envoi depuis plusieurs outils (Gmail, Outlook, site web, CRM, outil emailing) sans alignement technique ;
• mauvaise réputation d’envoi (taux de rebond élevé, plaintes, listes non qualifiées) ;
• problèmes d’infrastructure (serveur d’envoi mal identifié, IP partagée douteuse, DNS mal tenu).

SPF, DKIM et DMARC ne « garantissent » pas l’arrivée en boîte de réception, mais ils constituent la base attendue pour qu’un domaine soit jugé fiable.

SPF, DKIM, DMARC : définitions simples

Ces trois mécanismes s’appuient sur le DNS (l’annuaire public de configuration d’un nom de domaine) pour aider les messageries à vérifier l’origine d’un email.

SPF : qui a le droit d’envoyer pour le domaine

SPF (Sender Policy Framework) est une règle publiée dans le DNS qui liste les serveurs autorisés à envoyer des emails au nom du domaine.

• Exemple : autoriser Microsoft 365, Google Workspace et le serveur d’envoi d’un site web.
• Objectif : réduire l’usurpation d’adresse (quelqu’un qui envoie “depuis” votre domaine sans autorisation).

À retenir : SPF vérifie l’adresse IP / serveur qui envoie.

DKIM : une signature cryptographique dans chaque email

DKIM (DomainKeys Identified Mail) ajoute une signature à l’email. La messagerie du destinataire vérifie cette signature grâce à une clé publique publiée dans le DNS.

• Objectif : prouver que le message n’a pas été modifié en route et qu’il est bien lié au domaine.
• Particulièrement utile quand des emails transitent via des services tiers.

À retenir : DKIM vérifie l’intégrité et l’authenticité via une signature.

DMARC : la politique à appliquer si SPF/DKIM échouent

DMARC (Domain-based Message Authentication, Reporting & Conformance) indique aux messageries :

• quoi faire si un email échoue aux contrôles (laisser passer, mettre en spam, rejeter) ;
• où envoyer des rapports permettant de voir qui envoie des emails au nom du domaine (légitime ou non).

DMARC s’appuie aussi sur une notion importante : l’alignement. En clair, le domaine visible par le destinataire (le “From:”) doit correspondre au domaine authentifié par SPF et/ou DKIM.

À retenir : DMARC fixe une règle et fournit de la visibilité.

Comment ces trois standards travaillent ensemble

Le scénario le plus courant :

• SPF confirme que le serveur qui envoie est autorisé ;
• DKIM confirme que l’email est signé correctement ;
• DMARC vérifie l’alignement et dit quoi faire en cas d’échec.

Un domaine peut fonctionner avec SPF seul, mais la combinaison SPF + DKIM + DMARC est devenue la référence pour limiter l’usurpation et améliorer la délivrabilité.

Erreurs fréquentes qui déclenchent le spam

Plusieurs enregistrements SPF

SPF doit en général être publié dans un seul enregistrement. Quand plusieurs enregistrements SPF existent, certains serveurs considèrent la configuration comme invalide.

SPF trop permissif

Un SPF qui autorise « trop large » peut réduire la confiance. À l’inverse, un SPF trop strict peut casser des envois légitimes (site web, outil emailing, facturation, etc.).

DKIM non activé sur l’outil d’envoi

Publier une clé DKIM dans le DNS ne suffit pas : il faut aussi que l’outil (Google Workspace, Microsoft 365, solution emailing, serveur SMTP) signe réellement les messages.

DMARC absent ou “p=none” conservé trop longtemps

DMARC en p=none sert souvent à observer sans bloquer. Si ce mode reste en place durablement, la protection contre l’usurpation est limitée.

Envois depuis des adresses gratuites pour le business

Utiliser une adresse gratuite (ex. @gmail.com) pour des échanges professionnels n’empêche pas de communiquer, mais réduit la cohérence de marque et complique la gouvernance (départs d’employés, accès, archives). Un domaine professionnel avec SPF/DKIM/DMARC correctement configurés est plus robuste.

Checklist anti-spam : sécuriser et améliorer la délivrabilité

Cette checklist vise les cas courants : PME, ONG, associations et projets en croissance, souvent avec une équipe réduite et plusieurs outils (site WordPress, formulaires, WhatsApp en support, campagnes ponctuelles).

Préparer l’inventaire des sources d’envoi

• Liste des outils qui envoient des emails : Google Workspace / Microsoft 365, serveur SMTP, site web (formulaire de contact), CRM, outil emailing (newsletter), facturation, support.
• Liste des adresses utilisées : contact@, info@, direction@, rh@, etc.
• Volume approximatif : faible (quelques dizaines/jour) ou plus élevé (campagnes).

Vérifier les bases du domaine

• Domaine maîtrisé : accès au registrar (gestion du nom de domaine) et au DNS.
• SSL sur le site (https) : pas directement lié à SPF/DKIM/DMARC, mais renforce la confiance globale et évite des alertes côté navigateur.
• Emails professionnels hébergés sur une solution stable (boîtes, redirections, sauvegardes si nécessaire).

Mettre en place SPF correctement

• Un seul enregistrement SPF pour le domaine principal.
• Autoriser uniquement les services réellement utilisés (messagerie + outils d’envoi).
• Éviter les configurations “fourre-tout” qui ouvrent trop large.

Activer DKIM sur chaque service d’envoi

• Activer la signature DKIM dans l’outil (Workspace, 365, plateforme emailing, etc.).
• Publier la clé DKIM dans le DNS selon les recommandations du fournisseur.
• Garder une traçabilité : quel sélecteur DKIM est utilisé par quel service.

Déployer DMARC de façon progressive

• Démarrer en observation (politique de type “surveillance”) pour collecter des rapports et identifier les envois inconnus.
• Corriger les sources qui échouent (souvent un site web, un ancien outil, ou un prestataire).
• Renforcer ensuite la politique (mise en spam puis rejet) quand l’écosystème d’envoi est maîtrisé.
• Activer les rapports DMARC vers une adresse dédiée (ou un service de lecture de rapports) pour suivre l’évolution.

Soigner les emails “transactionnels” du site web

• Formulaires WordPress : privilégier un envoi via SMTP authentifié ou un service transactionnel reconnu plutôt que l’envoi “local” du serveur, souvent moins fiable.
• Adresse d’expéditeur cohérente : éviter les “From” incohérents (ex. no-reply@ avec réponse attendue).
• Limiter les pièces jointes lourdes : dans un contexte mobile et data coûteuse, elles augmentent les risques de blocage et dégradent l’expérience.

Contrôler les signaux de réputation

• Listes propres : éviter les bases achetées, privilégier le consentement.
• Réduire les rebonds : supprimer les adresses invalides.
• Contenu lisible : objet clair, identité de l’expéditeur, signature, coordonnées.
• Rythme d’envoi raisonnable : surtout lors des premières campagnes depuis un nouveau domaine.

Repères utiles pour décider en contexte Afrique de l’Ouest

Dans de nombreux pays ouest-africains, la consultation des emails se fait majoritairement sur mobile, via Gmail ou Outlook. Les filtres anti-spam y sont stricts, et les utilisateurs se fient beaucoup aux signaux de confiance (nom de domaine, cohérence de l’expéditeur, absence d’alertes).

Bonnes pratiques adaptées :

• fiabiliser l’envoi (SPF/DKIM/DMARC + SMTP propre) avant de lancer une campagne ou une refonte ;
• prévoir une adresse dédiée pour les rapports DMARC (ex. dmarc@domaine) ;
• documenter les outils autorisés à envoyer pour éviter les régressions lors d’un changement de prestataire ;
• aligner site web et emails : même domaine, mêmes coordonnées, même identité visuelle.

Sources de référence

• Google Workspace Admin Help – SPF
• Google Workspace Admin Help – DKIM
• Google Workspace Admin Help – DMARC
• DMARC.org – ressources et explications
• Microsoft Learn – documentation sécurité et messagerie