Emailing professionnel en 2026 : le guide complet de la délivrabilité

Un programme d'e-mail professionnel n'est pas un bouton « envoyer ». C'est une chaîne qui commence par la collecte loyale d'une adresse, traverse une infrastructure SMTP authentifiée, reçoit les décisions de Gmail, Outlook, Yahoo ou du serveur d'une entreprise, puis revient sous forme de rebonds, plaintes, clics et conversions.

La règle la plus utile est aussi la plus simple : un message techniquement livré n'est pas nécessairement arrivé en boîte de réception, et un message ouvert n'a pas nécessairement été lu par une personne.

Ce guide est la porte d'entrée du dossier Synapx consacré à l'e-mailing. Chaque partie présente le système complet puis renvoie vers le billet spécialisé, afin de ne pas répéter artificiellement les mêmes explications.

La carte du dossier

Question	Billet de référence
D'où viennent les boîtes mail, SMTP, POP, IMAP et Exchange ?	Histoire, protocoles et architecture d'une boîte mail
Comment acquérir, segmenter et nettoyer les destinataires ?	Construire une liste d'e-mails de qualité
Pourquoi une campagne bascule-t-elle dans le spam ?	Réputation, volume, pièges à spam et rebonds
Peut-on encore croire le taux d'ouverture ?	Pixels de tracking, Apple MPP et ouvertures simulées
Comment tester le message et son infrastructure ?	Les outils de test avant envoi
Que signifie une inscription sur une DNSBL ?	Les listes de blocage e-mail expliquées
Comment fonctionnent SPF, DKIM et DMARC ?	Sécurité de l'e-mail et authentification du domaine
Quelles règles appliquer en France et dans l'Union européenne ?	Emailing, RGPD et règles de la CNIL
Quels indicateurs piloter après l'envoi ?	Mesurer une campagne sans se limiter aux ouvertures
Faut-il exploiter son propre système d'envoi ?	Construire une plateforme d'e-mailing

Le trajet réel d'une campagne

flowchart LR
    A["Collecte<br>et preuve"] --> B["Segmentation<br>et suppression"]
    B --> C["Création HTML<br>et texte"]
    C --> D["Soumission SMTP<br>ou API"]
    D --> E["MTA, file,<br>DKIM et TLS"]
    E --> F["Serveur<br>destinataire"]
    F --> G{"Décision"}
    G -->|accepté| H["Inbox, onglet,<br>spam ou quarantaine"]
    G -->|temporaire| I["4xx : nouvelle<br>tentative"]
    G -->|définitif| J["5xx : rebond<br>et suppression"]
    H --> K["Clic, conversion,<br>plainte, retrait"]
    I --> E
    J --> L["Boucle de retour<br>et diagnostic"]
    K --> L
    L --> B

Chaque flèche peut casser. Une base achetée crée des plaintes avant même que l'HTML soit évalué. Une signature DKIM valide ne répare pas un lien trompeur. Un excellent taux de clic ne compense pas des rebonds ignorés. La délivrabilité est un système de rétroaction, pas une note décorative obtenue une fois.

SMTP transporte ; la boîte mail stocke

SMTP organise la remise du courrier. Une application peut soumettre un message à un service d'envoi par SMTP authentifié ou par API ; le prestataire le place ensuite dans une file et contacte en SMTP les serveurs MX des domaines destinataires. Les réponses commençant par 2 annoncent un succès de l'étape SMTP, celles en 4 un échec temporaire et celles en 5 un échec définitif.

Cette acceptation ne dit pas où le message sera rangé. Le système destinataire peut encore le placer dans la boîte principale, une catégorie promotionnelle, le courrier indésirable ou une quarantaine d'entreprise. C'est pourquoi le taux de livraison et le placement en boîte ne sont pas synonymes.

Pour comprendre les rôles du MTA, du serveur IMAP et du client, le point de départ reste le dossier boîte mail, SMTP, POP, IMAP et Exchange.

Les mises en œuvre sont documentées séparément dans installer et configurer Postfix pour le transport SMTP et déployer Dovecot pour l'accès IMAP/POP3 aux boîtes. Une plateforme de campagne n'a pas besoin d'exposer Dovecot si elle ne fournit aucune boîte utilisateur.

La réputation n'est pas un enregistrement DNS

Les opérateurs observent une identité d'envoi dans la durée : domaine visible, domaine DKIM, domaine de retour, adresses IP, liens, cadence, historique des plaintes et réaction de leurs propres utilisateurs. Il n'existe donc pas un « score universel » que l'expéditeur pourrait lire et optimiser mécaniquement.

Deux réputations se croisent :

• la réputation du domaine, qui suit plus facilement la marque quand elle change de prestataire ;
• la réputation de l'adresse IP, partagée avec d'autres clients ou dédiée à un seul programme.

Une IP dédiée n'est pas automatiquement meilleure. À faible volume, une bonne infrastructure partagée peut offrir un historique plus stable. À fort volume, l'IP dédiée donne le contrôle mais aussi l'entière responsabilité. Une rotation d'IP destinée à fuir une mauvaise réputation n'est pas une stratégie de délivrabilité : elle rend l'identité encore moins stable.

SPF, DKIM et DMARC : le socle d'identité

Ces trois mécanismes ont des fonctions distinctes :

Contrôle	Question posée	Limite principale
SPF	Cette adresse IP est-elle autorisée à utiliser le domaine d'enveloppe ?	Les transferts peuvent le casser ; il ne valide pas seul le From: visible
DKIM	Une partie du message porte-t-elle une signature vérifiable d'un domaine ?	Une réécriture peut casser la signature ; un signataire autorisé peut envoyer un mauvais message
DMARC	SPF ou DKIM réussit-il avec un domaine aligné sur le From: visible ?	Un succès authentifie le domaine, pas l'intention ni la qualité du contenu

La spécification DMARC de référence est désormais la RFC 9989 publiée en mai 2026. Le détail, les exemples DNS et le passage prudent de p=none à p=reject sont traités dans le guide SPF, DKIM et DMARC.

Pour les transferts et listes de diffusion, ARC permet à des intermédiaires d'enregistrer cryptographiquement les résultats d'authentification qu'ils ont observés. ARC ne force pas le destinataire à accepter le message et ne « répare » pas magiquement DMARC ; il fournit une chaîne d'éléments que le destinataire peut choisir d'évaluer.

Les exigences des grandes messageries sont un plancher

Google et Yahoo demandent notamment aux expéditeurs en volume une authentification SPF et DKIM, une politique DMARC au minimum publiée, un DNS direct et inverse cohérent, un transport TLS et un mécanisme de désabonnement simple. Microsoft impose depuis 2025 SPF, DKIM et DMARC aux domaines envoyant plus de 5 000 messages par jour vers Outlook.com, avec rejet possible des flux non conformes.

Pour les messages marketing et promotionnels concernés, le désabonnement en un clic repose sur les en-têtes normalisés par la RFC 8058 :

List-Unsubscribe: <https://news.example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Le lien HTTPS doit accepter un POST sans demander de connexion, et les en-têtes doivent être couverts par une signature DKIM. Cette commande native ne remplace pas le lien de désabonnement visible dans le corps. Elle le complète.

Les seuils publiés par les opérateurs ne sont pas des objectifs à frôler. Gmail indique un taux de spam à maintenir sous 0,1 % et à ne jamais laisser atteindre 0,3 %; Yahoo demande de rester sous 0,3 %. Une campagne légale peut dépasser ces valeurs si les destinataires ne la reconnaissent pas ou ne la souhaitent plus.

TLS, MTA-STS et protection du transport

TLS chiffre généralement la liaison entre deux serveurs SMTP, mais le mode historique avec STARTTLS peut rester opportuniste. MTA-STS permet à un domaine destinataire d'annoncer par DNS et HTTPS qu'il exige TLS vers ses MX. DANE associe le service SMTP à des enregistrements TLSA protégés par DNSSEC.

Ces mécanismes protègent le trajet entre serveurs ; ils ne chiffrent pas nécessairement le message de bout en bout et ne rendent pas son contenu fiable. Le fonctionnement de la chaîne DNSSEC, des KSK et ZSK est détaillé séparément dans le guide DNSSEC.

BIMI : un logo après l'authentification, pas avant

BIMI est une spécification de l'industrie, pas une RFC qui obligerait tous les clients mail. Le domaine publie une assertion DNS qui pointe vers son logo et, suivant le fournisseur, vers un certificat de marque. Gmail demande notamment une politique DMARC appliquée et un VMC ou CMC reconnu ; l'affichage final dépend encore de ses contrôles anti-abus.

Exemple de forme d'enregistrement :

default._bimi.example.com. IN TXT "v=BIMI1; l=https://assets.example.com/logo.svg; a=https://assets.example.com/certificat.pem"

BIMI peut améliorer la reconnaissance visuelle d'un expéditeur compatible. Il ne donne aucune priorité SMTP, ne remplace ni DMARC ni le consentement et ne garantit pas l'affichage du logo.

Une liste de 500 personnes peut valoir plus que 500 000 adresses

Une petite liste composée de personnes qui ont demandé un contenu précis produit des signaux interprétables : clics, réponses, ventes, retraits et préférences. Une base massive achetée mélange adresses anciennes, personnes non informées, rôles génériques et pièges à spam. Elle augmente les rebonds et les plaintes tout en rendant les statistiques inutiles.

La qualité se construit au formulaire : information claire, finalité déterminée, preuve de la collecte, validation syntaxique, double opt-in lorsque pertinent et segmentation dès l'origine. Elle se maintient ensuite avec une liste de suppression qui empêche tout réimport accidentel d'une adresse retirée. Voir la méthode complète de construction d'une liste.

Tester avant d'envoyer, observer après

Un test unique ne représente pas la décision de tous les destinataires. La recette utile combine plusieurs familles de contrôles :

1. Identité : SPF, DKIM, DMARC, alignement, PTR et nom EHLO.
2. Transport : TLS, réponse SMTP, latence et comportement de la file.
3. Message : structure MIME, version texte, liens, images, poids et en-têtes de liste.
4. Rendu : Outlook, Gmail, Apple Mail, mobile, mode sombre et images bloquées.
5. Accessibilité : ordre de lecture, contraste, texte alternatif et boutons compréhensibles.
6. Placement : boîtes témoins chez plusieurs opérateurs, avec prudence sur la représentativité.
7. Retour : rebonds, plaintes, retraits, clics et conversions reliés à un identifiant stable.

Le comparatif fonctionnel de Mail-Tester, GlockApps, Litmus, Email on Acid/Mailgun Inspect et MXToolbox se trouve dans les outils de test avant envoi.

Mesurer ce que l'entreprise cherche réellement

Le taux d'ouverture est devenu un signal bruité : Apple Mail Privacy Protection peut précharger les images, des passerelles de sécurité peuvent les demander, et d'autres clients bloquent les contenus distants. Le clic lui-même peut être visité par un robot de sécurité.

Il faut construire une hiérarchie :

• objectif métier : vente, prise de rendez-vous, activation ou rétention ;
• conversion attribuée avec une règle explicite ;
• clic humain probable et visite qualifiée ;
• plaintes, désabonnements et rebonds ;
• ouverture comme tendance secondaire, si son usage est juridiquement permis.

Les formules, les biais et un tableau de bord reproductible sont détaillés dans le guide des KPI e-mail. Les implications techniques et juridiques du pixel sont traitées dans le dossier sur le tracking d'ouverture.

La check-list opérationnelle avant chaque campagne

• [ ] La source, la date, la finalité et la preuve d'inscription sont connues pour chaque segment.
• [ ] Les oppositions, plaintes et rebonds définitifs sont dans une suppression globale impossible à contourner.
• [ ] Le domaine visible, le MAIL FROM et la signature DKIM sont inventoriés et DMARC est aligné.
• [ ] Le PTR, le nom EHLO, TLS et les limites de débit ont été vérifiés sur le flux réel.
• [ ] L'adresse expéditrice, l'objet et la raison de la sollicitation sont immédiatement reconnaissables.
• [ ] Un lien de désabonnement visible et, pour le marketing en volume, le mécanisme RFC 8058 fonctionnent réellement.
• [ ] Le message dispose d'une version texte et a été testé avec images bloquées, sur mobile et dans Outlook.
• [ ] Les liens, domaines de tracking et pages d'arrivée utilisent une identité cohérente et HTTPS.
• [ ] Une alerte existe pour les pics de 4xx, 5xx, plaintes et taux de rebonds.
• [ ] La réussite est définie par une conversion ou un résultat métier, pas seulement par une ouverture.

Diagnostiquer dans le bon ordre

Symptôme	Première preuve à examiner	Mauvais réflexe
Rejet immédiat	Code SMTP complet, IP, domaine, heure et identifiant de file	Changer l'objet du message
Beaucoup de 4xx	Domaine destinataire, cadence, connexions et historique de réputation	Multiplier brutalement les connexions
Accepté mais placé en spam	Plaintes, engagement, authenticité, stabilité et boîtes témoins	Chercher un mot « interdit » unique
Hausse soudaine des ouvertures	Part Apple MPP, robots, proxys et changement de tracking	Conclure à un succès commercial
DKIM passe, DMARC échoue	Domaine d=, domaine visible et alignement	Ajouter un second enregistrement SPF
Présence sur une DNSBL	Liste exacte, critère, journaux sortants et impact réel	Payer ou demander le retrait avant de corriger la cause

L'e-mailing durable tient finalement en trois contrats : le destinataire sait pourquoi il reçoit le message, le domaine prouve qui l'a autorisé, et l'expéditeur réagit aux signaux négatifs avant que les opérateurs ne le fassent à sa place.