Introduction : pourquoi vos emails n’arrivent pas à destination

Imaginez cette situation : vous venez de lancer votre nouvelle offre de formation en ligne, votre newsletter part à 2 000 contacts, et trois jours plus tard vous constatez que le taux d’ouverture ne dépasse pas 4 %. Vous pensez à un problème d’objet, à l’heure d’envoi, peut-être à la segmentation. Mais la vérité, plus brutale, est ailleurs : vos emails n’atteignent jamais la boîte principale. Ils atterrissent en spam — ou pire, ils sont silencieusement rejetés avant même d’entrer dans la boîte du destinataire, sans aucun message d’erreur de votre côté.

Ce scénario n’est pas hypothétique. Des études de Return Path, Validity et Litmus convergent pour estimer qu’entre 15 % et 35 % des emails légitimes n’atteignent jamais la boîte principale des destinataires à l’échelle mondiale. Pour les expéditeurs qui n’ont pas configuré les protocoles d’authentification — ce qui est la norme dans la grande majorité des PME et associations francophones d’Afrique de l’Ouest — la proportion dépasse facilement 30 %. Une campagne de prospection, une confirmation de commande, une facture mensuelle : autant de communications commerciales et transactionnelles perdues, avec des conséquences directes sur le chiffre d’affaires et la relation client.

La situation a pris un tournant décisif en février 2024. Google et Yahoo ont simultanément rendu obligatoires, pour tous les expéditeurs en masse (à partir de 5 000 messages par jour vers Gmail), l’authentification SPF, la signature DKIM, et une politique DMARC au minimum en mode p=none. Ce qui était une bonne pratique recommandée depuis des années est devenu une exigence technique ferme, sous peine de rejet systématique. Les deux géants représentant à eux seuls plus de 50 % des boîtes aux lettres actives dans le monde, ignorer cette réalité revient à couper la moitié de ses communications email.

Ce pilier couvre l’ensemble des six protocoles qui définissent l’état de l’art de la deliverability email professionnelle en 2026 : SPF pour l’autorisation des serveurs d’envoi, DKIM pour la signature cryptographique des messages, DMARC pour aligner les deux et définir une politique de traitement, MTA-STS pour chiffrer le transport, BIMI pour afficher votre logo dans les clients de messagerie conformes, et ARC pour préserver la chaîne d’authentification lors des transferts et redirections. Chacun de ces six mécanismes fait l’objet d’une RFC publiée par l’IETF — c’est-à-dire d’un standard ouvert, vérifiable, interopérable. Ce n’est pas du marketing de prestataire : c’est l’infrastructure qui fait qu’un email est considéré comme légitime ou comme suspect.

Des tutoriels pas-à-pas du cluster couvrent chaque protocole en détail — liens dans la section dédiée. Ce pilier vous donne la vue d’ensemble conceptuelle, l’architecture de conformité, et les points d’attention spécifiques au contexte ouest-africain.

Pourquoi maîtriser la deliverability email en 2026

La deliverability email n’est pas un sujet réservé aux équipes marketing des grandes entreprises. C’est une problématique d’infrastructure qui concerne chaque organisation qui utilise l’email comme canal de communication professionnel — ce qui, en pratique, signifie toutes les organisations sans exception. Pourtant, dans l’écosystème des PME et des startups francophones, elle reste largement sous-estimée, traitée en pompier après la première crise plutôt qu’anticipée lors de la configuration initiale du domaine.

Le contexte de 2026 rend l’enjeu encore plus pressant. Le volume d’emails envoyés par jour dans le monde dépasse les 350 milliards selon les chiffres Statista, dont une part considérable est du spam ou du phishing. Face à cette inflation, les grands fournisseurs de messagerie — Google, Microsoft, Yahoo, Apple — ont durci leurs algorithmes de filtrage. Ces algorithmes s’appuient désormais de manière quasi-systématique sur les signaux d’authentification pour décider du sort d’un message entrant. Un email parfaitement rédigé, envoyé depuis un domaine légitime mais non authentifié, sera traité avec la même méfiance qu’un email de phishing.

Le phishing est précisément la raison pour laquelle ces protocoles ont été développés. L’usurpation de domaine — envoyer un email qui prétend venir de votre domaine sans y être autorisé — est triviale en l’absence de mécanismes d’authentification. N’importe qui peut envoyer un email avec From: contact@votre-entreprise.com sans avoir accès à votre serveur. SPF, DKIM et DMARC ont précisément pour rôle de rendre cette usurpation détectable et de permettre aux serveurs destinataires de la rejeter. En déployant ces protocoles, vous ne faites pas que améliorer votre deliverability : vous protégez votre réputation de domaine et vos clients contre les tentatives de fraude menées en votre nom.

Du côté des indicateurs business, la corrélation entre authentification correcte et performance email est documentée. Des analyses sectorielles montrent que les domaines avec SPF+DKIM+DMARC correctement configurés enregistrent des taux de placement en boîte principale significativement supérieurs — de l’ordre de 15 à 25 points de pourcentage — par rapport aux domaines sans authentification. Pour une PME dont l’email est le canal principal de relation client, facturation ou support, cet écart se traduit directement en qualité de service et en revenus.

Enfin, la dimension réglementaire commence à se faire sentir. Les régulateurs de protection des données — dont la CDP au Sénégal et la CGPDCP en Côte d’Ivoire sous tutelle de l’ARTCI — intègrent progressivement dans leurs recommandations les bonnes pratiques de sécurisation des communications électroniques. Si le RGPD européen a montré la voie sur le plan mondial, les régulateurs africains développent leurs propres cadres qui convergent vers les mêmes exigences de traçabilité et de sécurisation. Documenter votre infrastructure d’authentification email sera de plus en plus utile lors d’audits ou de certifications.

Les 6 piliers de l’authentification email expliqués

SPF — Sender Policy Framework : autoriser vos serveurs d’envoi

Le SPF, défini dans la RFC 7208 publiée par l’IETF en avril 2014, est le protocole fondateur de l’authentification email. Son principe est d’une simplicité élégante : le propriétaire d’un domaine publie dans ses enregistrements DNS une liste des serveurs autorisés à envoyer des emails en son nom. Lorsqu’un serveur destinataire reçoit un email prétendu venir de @votre-domaine.com, il interroge le DNS de ce domaine pour vérifier si l’adresse IP de l’expéditeur figure dans cette liste. Si oui, le SPF passe. Si non, le serveur destinataire peut choisir de marquer l’email comme suspect ou de le rejeter, selon sa configuration.

Concrètement, un enregistrement SPF est un enregistrement DNS de type TXT associé à votre domaine. Sa syntaxe suit une grammaire définie par la RFC 7208. Un exemple typique pour une PME utilisant Google Workspace et un SMTP de notification tiers ressemblerait à ceci :

v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.10 ~all

Dans cette syntaxe, v=spf1 identifie la version du protocole. Les mécanismes include: délèguent la vérification à l’enregistrement SPF du service tiers concerné (Google, Amazon SES). Le mécanisme ip4: autorise explicitement une adresse IP. Le qualificateur final ~all — le tilde signifiant « softfail » — indique que tout serveur non listé devrait être traité avec méfiance mais pas rejeté automatiquement. Le qualificateur -all (tiret, « hardfail ») est plus strict et indique un rejet ferme.

La limite critique du SPF est qu’il ne s’applique qu’à l’adresse technique de l’expéditeur, le Mail From ou envelope sender, pas à l’adresse visible par l’utilisateur final dans le champ From: du message. Cette distinction entre l’enveloppe SMTP et l’en-tête du message est la raison pour laquelle SPF seul est insuffisant — et pourquoi DMARC existe pour combler ce manque. Un autre point d’attention : les enregistrements SPF sont limités à 10 consultations DNS récursives. Au-delà, le mécanisme échoue avec un permerror. Les PME qui utilisent de nombreux services tiers (CRM, ERP, plateforme d’emailing, outil de notification) doivent gérer cette limite avec soin.

DKIM — DomainKeys Identified Mail : signer cryptographiquement vos messages

Le DKIM, normalisé dans la RFC 6376 (2011, mis à jour par les RFC 8301 et RFC 8463), ajoute une couche de vérification que SPF ne peut offrir : il prouve que le contenu du message n’a pas été altéré en transit et qu’il a bien été signé par un serveur autorisé du domaine expéditeur. Le mécanisme repose sur la cryptographie asymétrique à clé publique/privée.

Le principe de fonctionnement est le suivant. Le serveur d’envoi génère une paire de clés asymétriques. La clé privée est stockée de manière sécurisée sur le serveur d’envoi. La clé publique est publiée dans le DNS du domaine, sous un enregistrement TXT à l’adresse sélecteur._domainkey.votre-domaine.com. Lors de l’envoi, le serveur calcule une signature cryptographique couvrant des en-têtes choisis du message (typiquement From, To, Subject, Date) et le corps du message, et insère cette signature dans l’en-tête DKIM-Signature du message. Lors de la réception, le serveur destinataire récupère la clé publique depuis le DNS, recalcule la signature, et vérifie qu’elle correspond. Si le message a été modifié en chemin — ne serait-ce qu’un espace ajouté dans le corps — la signature ne correspondra plus.

Le « sélecteur » DKIM est un identifiant arbitraire qui permet d’utiliser plusieurs clés pour un même domaine — par exemple une clé par service d’envoi, ou une clé par période (rotation régulière recommandée tous les 12 mois minimum). Les RFC 8301 et 8463 précisent que les clés RSA doivent être d’au moins 2048 bits, et que les clés Ed25519 sont désormais supportées par les implémentations modernes pour une sécurité équivalente avec une taille de clé plus compacte.

Un point crucial : DKIM signe l’en-tête From: visible par l’utilisateur, contrairement à SPF. C’est cet alignement entre la signature DKIM et l’adresse From: qui permet à DMARC de fonctionner de manière robuste. Sans DKIM, DMARC ne peut s’appuyer que sur SPF pour son alignement — or, comme expliqué ci-dessus, SPF porte sur l’enveloppe et non sur le From: visible.

DMARC — Domain-based Message Authentication, Reporting & Conformance : aligner et agir

Le DMARC, défini dans la RFC 7489 publiée en mars 2015 (une révision DMARCbis est en cours de finalisation à l’IETF depuis 2024), est le chef d’orchestre qui donne toute leur puissance à SPF et DKIM. Seul, chacun de ces deux protocoles présente des lacunes. Ensemble, coordonnés par DMARC, ils forment un système d’authentification cohérent qui protège l’adresse From: visible par l’utilisateur final — c’est-à-dire l’adresse qui compte vraiment pour lutter contre le phishing.

DMARC fonctionne selon deux concepts clés : l’alignement et la politique. L’alignement signifie que le domaine du From: visible doit correspondre au domaine vérifié soit par SPF (alignement SPF : le domaine Mail From doit correspondre), soit par DKIM (alignement DKIM : le domaine dans la signature d= doit correspondre). L’alignement peut être strict (aspf=s, adkim=s) — correspondance exacte — ou relaxé (aspf=r, adkim=r) — sous-domaine accepté. La politique (p=) indique au serveur destinataire comment traiter les messages qui échouent à l’alignement DMARC : none (surveiller, ne rien faire), quarantine (envoyer en spam), ou reject (refuser le message).

Un enregistrement DMARC typique pour un domaine en phase de déploiement progressif ressemblerait à ceci :

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@votre-domaine.com; ruf=mailto:dmarc-forensics@votre-domaine.com; sp=quarantine; adkim=r; aspf=r

Dans cet exemple, p=quarantine envoie les emails non conformes en spam, pct=25 applique cette politique à seulement 25 % des messages non conformes pour une montée en charge progressive, et rua/ruf configurent les adresses de réception des rapports agrégés et forensiques. Ces rapports sont envoyés automatiquement par les serveurs destinataires conformes (Gmail, Outlook, Yahoo) — c’est une mine d’information pour comprendre qui envoie des emails en votre nom. La progression recommandée est : p=none pendant 4 à 8 semaines pour analyser les rapports, puis p=quarantine avec pct=10, puis montée progressive jusqu’à p=reject; pct=100.

MTA-STS — Mail Transfer Agent Strict Transport Security : chiffrer le transport

Là où SPF, DKIM et DMARC s’occupent de l’authentification de l’expéditeur, MTA-STS (RFC 8461, septembre 2018) s’attaque à un problème différent : la sécurité du transport lui-même. Le protocole SMTP prend en charge le chiffrement TLS via STARTTLS depuis les années 2000, mais de manière opportuniste — c’est-à-dire que si le chiffrement échoue ou est dégradé par un attaquant, le message est quand même livré en clair. C’est la fameuse attaque par rétrogradation (downgrade attack) ou l’interception par Man-in-the-Middle. MTA-STS résout ce problème en permettant à un domaine de publier une politique qui dit explicitement : « mes serveurs de réception DOIVENT supporter TLS valide — si ce n’est pas le cas, ne livre pas le message ».

MTA-STS fonctionne via deux éléments : un enregistrement DNS TXT (_mta-sts.votre-domaine.com) qui signale l’existence d’une politique, et un fichier de politique hébergé sur un serveur HTTPS accessible à l’URL https://mta-sts.votre-domaine.com/.well-known/mta-sts.txt. Ce fichier HTTPS doit lui-même être servi avec un certificat TLS valide — c’est la garantie d’intégrité du mécanisme. Le fichier de politique précise la liste des serveurs MX autorisés et le mode (enforce pour le rejet strict, testing pour la phase de test, none pour désactiver).

En complément de MTA-STS, le protocole SMTP TLS Reporting (RFC 8460) permet d’envoyer des rapports sur les échecs de connexion TLS, de manière analogue aux rapports DMARC agrégés. L’adoption de MTA-STS reste plus faible que celle de SPF/DKIM/DMARC car il nécessite l’hébergement d’un fichier HTTPS sur un sous-domaine dédié, mais Gmail le supporte en émission depuis 2019 et son déploiement en réception améliore significativement la posture de sécurité.

BIMI — Brand Indicators for Message Identification : votre logo dans la boîte de réception

BIMI est le protocole le plus récent et le plus visible de cette liste — littéralement. Développé par le groupe de travail AuthIndicators Working Group (regroupant Google, Yahoo, Verizon, Fastmail et d’autres), BIMI permet aux expéditeurs qui ont déployé DMARC en mode reject ou quarantine de faire afficher leur logo directement dans la boîte de réception des clients de messagerie compatibles, à la place de l’initiale générique. Gmail, Yahoo Mail et Apple Mail supportent BIMI.

Le mécanisme repose sur un enregistrement DNS TXT à l’adresse default._bimi.votre-domaine.com qui pointe vers une image SVG de votre logo (format SVG Tiny P/S obligatoire, hébergé en HTTPS) et, pour les clients qui l’exigent comme Gmail, un VMC (Verified Mark Certificate) — un certificat X.509 qui atteste que votre organisation est bien propriétaire de la marque associée au logo. Les VMC sont émis par des autorités de certification autorisées comme DigiCert et Entrust (et Comodo depuis 2024). Un VMC représente un investissement annuel non négligeable (typiquement 1 000 à 1 500 dollars), ce qui fait de BIMI une fonctionnalité orientée vers les entreprises établies plutôt que les startups. Il existe cependant un niveau d’entrée sans VMC (Common Mark Certificate, CMC) supporté par certains clients.

L’intérêt business de BIMI dépasse l’esthétique. Des études (Twilio SendGrid, 2023) montrent que les emails affichant le logo BIMI enregistrent des taux d’ouverture supérieurs de 10 % en moyenne, simplement parce que l’identité visuelle de l’expéditeur renforce la confiance avant même que le destinataire n’ouvre le message. Le logo devient un signal de confiance dans la boîte de réception.

ARC — Authenticated Received Chain : préserver l’authentification lors des transferts

ARC, défini dans la RFC 8617 publiée en juillet 2019, répond à un problème technique qui devient critique dans les workflows modernes : que se passe-t-il avec DMARC lorsqu’un email est transféré ou passe par un intermédiaire — une liste de diffusion, un service de réexpédition, un outil de CRM qui reroute les messages ? Lorsqu’un serveur intermédiaire modifie un message (en ajoutant un pied de page, en réencapsulant le corps), la signature DKIM originale peut être invalidée. Et si le serveur intermédiaire envoie depuis sa propre adresse IP, SPF peut échouer. Résultat : un email parfaitement légitime échoue à DMARC et peut être rejeté par le serveur final — c’est le comportement normal et attendu de DMARC, mais il pénalise ici des flux légitimes.

ARC résout ce problème en permettant à chaque serveur intermédiaire de tamponner l’état de l’authentification du message au moment où il le reçoit, avant de le transmettre. Le serveur final peut alors reconstituer la chaîne d’authentification complète — d’où le terme « Authenticated Received Chain ». Si le serveur intermédiaire est connu et de confiance (par exemple Google Groups, qui implémente ARC), le serveur final peut prendre une décision éclairée même si les vérifications SPF/DKIM directes échouent. ARC n’est pas une décision automatique — c’est une information supplémentaire que le serveur final peut prendre en compte ou non selon sa politique. Gmail, par exemple, utilise ARC depuis 2017 pour améliorer la gestion des listes de diffusion.

Architecture de conformité Gmail et Yahoo 2024+

En octobre 2023, Google et Yahoo ont annoncé conjointement un durcissement de leurs exigences pour les expéditeurs en masse, entré en vigueur en février 2024. Ces exigences ne sont pas des recommandations : les envois qui ne les respectent pas sont activement rejetés ou envoyés en spam. Comprendre leur architecture permet de s’y conformer de manière systématique plutôt que de corriger à tâtons.

Les exigences se déclinent selon le volume d’envoi. Pour tous les expéditeurs, sans exception de volume : authentification SPF ou DKIM (l’un ou l’autre est suffisant, mais les deux sont fortement recommandés), connexion SMTP entrant en TLS valide, taux de spam inférieur à 0,30 % (mesuré via Google Postmaster Tools pour Gmail), et en-têtes de message valides conformes aux RFC 5321 et 5322. Pour les expéditeurs en masse — définis comme envoyant plus de 5 000 messages par jour vers des adresses Gmail — les exigences sont plus strictes : SPF ET DKIM tous les deux (pas seulement l’un ou l’autre), politique DMARC publiée au minimum en p=none, alignement DMARC effectif, et en-têtes List-Unsubscribe avec List-Unsubscribe-Post pour le désabonnement en un clic.

L’architecture technique recommandée pour une conformité complète se décompose ainsi. Première couche : le DNS du domaine d’envoi doit porter un enregistrement SPF valide listant tous les serveurs autorisés, un enregistrement DKIM avec une clé d’au moins 2048 bits pour chaque service d’envoi (une clé différente par sélecteur), et un enregistrement DMARC en progression vers p=reject. Deuxième couche : le serveur d’envoi (ou votre relais SMTP tiers) doit signer tous les messages sortants en DKIM et s’assurer que le domaine signataire (d=) correspond au domaine du From: visible. Troisième couche : un système de monitoring des rapports DMARC doit être en place — analyser les rapports agrégés (rua) au moins hebdomadairement pour détecter les sources d’envoi non autorisées ou les problèmes de configuration. Quatrième couche (optionnelle mais fortement recommandée) : MTA-STS pour sécuriser le transport en réception, BIMI avec VMC pour la visibilité dans la boîte de réception.

Une dimension souvent négligée est la réputation de l’adresse IP d’envoi. DMARC et DKIM peuvent être parfaits : si votre adresse IP d’envoi figure sur des listes noires (Spamhaus, SORBS, Barracuda), vos emails seront quand même rejetés. La réputation IP se construit sur la durée et se dégrade rapidement si des pratiques d’envoi inadéquates sont adoptées — listes non nettoyées, taux de rebond élevé, taux de plaintes spam élevé. Google Postmaster Tools (https://postmaster.google.com) est l’outil officiel gratuit pour surveiller la réputation IP et de domaine auprès de Gmail.

Outils de diagnostic et de monitoring

La configuration des protocoles d’authentification email ne se fait pas en aveugle. Il existe un ensemble d’outils en ligne et de services dédiés qui permettent de vérifier, analyser et monitorer l’ensemble de la chaîne, de la configuration DNS aux rapports DMARC en passant par la réputation IP. Voici les principaux outils que tout administrateur sérieux devrait connaître.

MXToolbox (https://mxtoolbox.com) est le couteau suisse de l’administration email. Son interface propose des vérifications SPF, DKIM, DMARC, MTA-STS et BIMI depuis une interface web sans installation. La fonctionnalité Email Health teste l’intégralité des enregistrements DNS liés à un domaine en un seul clic et produit un rapport structuré avec les erreurs et avertissements. MXToolbox propose également une vérification des listes noires (Blacklist Check) sur plus de 100 listes simultanément, une fonctionnalité précieuse pour diagnostiquer un problème de réputation IP. La version gratuite couvre la majorité des besoins de diagnostic ; les abonnements payants ajoutent le monitoring en temps réel avec alertes.

MailHardener (https://www.mailhardener.com) est une plateforme spécialisée dans l’analyse DMARC. Elle ingère les rapports agrégés envoyés par les serveurs destinataires conformes, les analyse et présente une vue claire de quels serveurs envoient des emails au nom de votre domaine, avec quel résultat d’authentification. MailHardener propose également des vérifications BIMI et MTA-STS et génère des alertes lorsqu’une nouvelle source d’envoi inconnue apparaît dans vos rapports — signe potentiel d’une tentative d’usurpation. Un niveau gratuit est disponible pour les petits volumes.

dmarcian (https://dmarcian.com) est l’un des outils DMARC les plus complets du marché, fondé par les co-auteurs de la RFC 7489. La plateforme offre la visualisation des rapports DMARC en temps réel, un assistant de déploiement guidé pour progresser de p=none vers p=reject, et des tableaux de bord qui agrègent les données de centaines de serveurs destinataires. C’est l’outil de référence pour les équipes qui gèrent de nombreux domaines ou des volumes d’envoi importants. Moins accessible financièrement pour les TPE (à partir de 20 $/mois), mais incontournable pour les organisations qui envoient plusieurs centaines de milliers d’emails par mois.

Google Postmaster Tools (https://postmaster.google.com) est gratuit et officiel. Il fournit des données directement issues de Gmail : réputation du domaine, réputation IP, taux d’erreurs d’authentification, taux de spam signalé par les utilisateurs Gmail, et score de chiffrement TLS. C’est la source la plus fiable pour comprendre comment Gmail perçoit vos envois. La vérification du domaine se fait via un enregistrement DNS TXT, ce qui est rapide. À coupler avec le tableau de bord SMTP de Yahoo (https://senders.yahooinc.com) pour couvrir les deux principaux destinataires.

Pour les tests ponctuels, mail-tester.com reste une référence simple : vous envoyez un email de test à une adresse générée, et vous obtenez un score sur 10 avec le détail des problèmes détectés. DKIM Validator de dmarcian et les vérificateurs en ligne de MXToolbox permettent de tester une signature DKIM sur un message réel. Pour MTA-STS spécifiquement, mta-sts.io offre un outil de validation de la politique publiée.

Tutoriels du cluster

Ce pilier donne la vue conceptuelle et l’architecture globale. Chaque protocole fait l’objet d’un tutoriel pas-à-pas dédié dans le cluster cluster-email-deliverability. Les tutoriels suivants sont disponibles ou planifiés :

• Configurer SPF, DKIM et DMARC sur Postfix avec Ubuntu 22.04 — installation d’OpenDKIM, génération de clés 2048 bits, configuration des enregistrements DNS, vérification complète.
• Déployer MTA-STS et SMTP TLS Reporting pour sécuriser votre transport email — mise en place du fichier de politique HTTPS, enregistrement DNS, monitoring avec TLS-RPT.
• Analyser et exploiter les rapports DMARC avec dmarcian et MailHardener — déchiffrer les XML des rapports agrégés, identifier les sources non autorisées, piloter la progression vers p=reject.
• Utiliser Brevo ou Postmark comme SMTP relay depuis un VPS Hetzner — configuration Postfix en mode relay, authentification SASL, gestion des logs, tests end-to-end depuis l’Afrique de l’Ouest.

Ces quatre satellites couvrent l’ensemble des besoins pratiques de déploiement pour une PME qui part de zéro. La progression recommandée est : commencer par le tutoriel SPF/DKIM/DMARC, puis le tutoriel SMTP relay si vous utilisez un VPS, puis le tutoriel d’analyse des rapports pour affiner votre configuration, et enfin MTA-STS pour compléter la sécurisation du transport.

Adaptation au contexte ouest-africain

La deliverability email présente des défis et des opportunités spécifiques pour les organisations basées en Afrique de l’Ouest qui méritent une analyse détaillée. Les solutions génériques conçues pour les entreprises européennes ou nord-américaines doivent être adaptées à la réalité locale : infrastructure réseau, coûts, cadre réglementaire, et comportements des utilisateurs.

La première question que se pose tout responsable technique est celle du serveur d’envoi : faut-il héberger son propre serveur SMTP ou passer par un relais tiers ? La réponse dépend du volume et des ressources disponibles, mais dans la grande majorité des cas pour les PME et startups west-africaines, le recours à un relais SMTP tiers est fortement recommandé. La raison principale est la réputation IP. Envoyer depuis une adresse IP fraîchement provisionnée — que ce soit sur un VPS Hetzner à Nuremberg, OVHcloud à Strasbourg, ou un hébergeur local — nécessite un processus de « warm-up » progressif qui prend plusieurs semaines et requiert une expertise pointue. Une erreur dans ce processus peut faire blacklister votre IP en quelques heures, avec des conséquences durables sur votre deliverability.

Pour les organisations basées en Afrique de l’Ouest qui souhaitent héberger leur infrastructure sur des VPS à coût maîtrisé, la combinaison recommandée est d’utiliser un VPS Hetzner (ARM ou x86, à partir de 3,79 €/mois) pour l’infrastructure applicative et les serveurs de réception, et de router les envois sortants via un relais SMTP spécialisé. Brevo (ex-Sendinblue), dont les équipes commerciales et le support sont partiellement francophones et qui accepte les paiements par carte Visa/Mastercard internationaux, est une option accessible avec un tier gratuit jusqu’à 300 emails par jour. Postmark offre un niveau de deliverability parmi les plus élevés du marché pour les emails transactionnels (confirmations de commande, notifications, alertes), avec une réputation IP soigneusement maintenue. Amazon SES reste la solution la plus économique à grande échelle (0,10 $ pour 1 000 emails) mais requiert une configuration plus technique et un processus de validation de l’identité de l’expéditeur.

La question de la réputation IP est encore plus critique depuis l’Afrique de l’Ouest. Historiquement, les plages d’adresses IP de certains pays de la région ont mauvaise réputation sur les listes noires en raison d’un passé de spam et de cybercriminalité. Cette réalité s’améliore progressivement avec le développement des infrastructures locales, mais elle impose aux organisations locales d’être encore plus rigoureuses que leurs homologues européens : listes d’envoi parfaitement entretenues, désabonnements traités en moins de 48 heures, taux de plaintes spam soigneusement surveillés. L’utilisation d’un relais tiers à IP pré-réchauffée contourne ce problème pour les envois sortants.

La gestion des listes d’opt-in mérite une attention particulière. Les pratiques d’envoi varient fortement dans la région, avec une culture parfois permissive envers les listes achetées ou partagées entre partenaires. Ces pratiques sont non seulement contre-productives (taux de plaintes élevés, spam traps, désabonnements massifs) mais potentiellement non conformes aux cadres réglementaires en développement. Au Sénégal, la Commission de Protection des Données personnelles (CDP), créée par la loi 2008-12, exige le consentement explicite pour la collecte et l’utilisation des données personnelles, y compris les adresses email. En Côte d’Ivoire, l’ARTCI (Autorité de Régulation des Télécommunications/TIC) et l’APDP (Autorité de Protection des Données à caractère Personnel) exercent une surveillance croissante sur les pratiques de traitement des données. Le double opt-in — confirmation par email du consentement à l’inscription — est non seulement la meilleure pratique en termes de deliverability, mais aussi la garantie la plus solide de conformité réglementaire.

Sur le plan de la bande passante et de la connectivité, les organisations qui gèrent leur propre serveur de réception SMTP (MX) sur un hébergement local doivent être conscientes des limitations. La qualité des connexions peut varier, et des configurations de timeout plus tolérantes peuvent être nécessaires. Pour les organisations disposant d’un site WordPress ou d’une application web hébergée localement, le recours à un plugin ou une bibliothèque qui utilise un SMTP tiers pour les emails de notification (plutôt que la fonction mail() PHP native qui envoie depuis l’IP du serveur web) est une priorité absolue.

Enfin, il est important de mentionner que certains noms de domaine enregistrés sous des TLD africains (**.sn** pour le Sénégal, **.ci** pour la Côte d’Ivoire, **.ml** pour le Mali, etc.) peuvent rencontrer des difficultés de réputation historiques. Le choix d’utiliser un domaine en **.com** ou en **.org** pour les communications professionnelles sensibles, avec les DNS correctement configurés chez un registrar fiable, peut être justifié dans certains contextes à fort enjeu de délivrabilité.

Erreurs fréquentes à éviter

FAQ — Questions fréquentes

Pour aller plus loin

Maîtriser la deliverability email est un investissement technique à faible coût mais à fort retour sur investissement. Une fois la configuration initiale en place et les rapports DMARC correctement analysés, la maintenance est minimale — une rotation de clés DKIM annuelle, une surveillance mensuelle des listes noires, et une progression progressive de la politique DMARC vers p=reject.

Pour approfondir chaque protocole individuellement, les sources primaires de référence sont :

• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8617 — The Authenticated Received Chain (ARC) Protocol
• Google — Bulk sender guidelines (exigences 2024)
• Yahoo — Sender Best Practices
• BIMI Group — AuthIndicators Working Group

La prochaine étape pratique recommandée est de commencer par le tutoriel de configuration SPF, DKIM et DMARC sur votre serveur ou votre hébergeur. Si vous n’avez pas encore accès à un outil d’analyse de rapports DMARC, créez un compte gratuit sur MailHardener ou dmarcian avant d’activer votre politique DMARC — les rapports commencent à arriver dans les 24 heures suivant la publication de l’enregistrement DNS.

Pour les organisations qui souhaitent un accompagnement structuré dans leur déploiement email ou une formation technique de leurs équipes, ITSkillsCenter propose des formations pratiques sur l’administration système et la sécurisation des infrastructures email, adaptées au contexte des entreprises francophones d’Afrique de l’Ouest.