La délivrabilité email en 2026 — les standards, le warm-up, le feedback loop.

§1 · Définition

Ce qu'est réellement la délivrabilité email.

La délivrabilité est le taux auquel vos messages envoyés atteignent la boîte de réception principale du destinataire — distinct de la livraison (le message a été accepté par le serveur de messagerie destinataire) et de l'envoi (vous l'avez confié au pipeline d'expédition). Un message peut être envoyé avec succès, livré au serveur destinataire, et finir dans les spams — c'est un succès de livraison et un échec de délivrabilité. Les chiffres qui comptent — open rate, click rate, conversion — dépendent de la délivrabilité, pas de la livraison.

Les mailbox providers — Gmail, Outlook, Yahoo, Apple iCloud Mail, Proton, les grands fournisseurs régionaux — exécutent chacun un pipeline de scoring multi-étapes sur tout message entrant. Les étapes sont à peu près les mêmes d'un fournisseur à l'autre, avec des pondérations différentes :

1. Contrôles à la connexion. rDNS, sanity HELO/EHLO, support TLS, présence de l'IP sur des RBL (Spamhaus, SpamCop, etc.).
2. Contrôles d'authentification. Pass/fail SPF (RFC 7208), validation de signature DKIM (RFC 6376), alignement DMARC (RFC 7489). Les trois doivent passer proprement pour bénéficier du scoring le plus clément en aval.
3. Scoring de contenu. Densité de mots-clés spam, réputation des liens, ratio image/texte, cohérence entre le From-name et le From-address.
4. Lookup de réputation. L'historique interne du fournisseur sur votre IP d'envoi et votre From-domain — bounce rate historique, complaint rate, engagement sur les envois précédents.
5. Signal d'engagement. Le destinataire (ou des destinataires de sa cohorte) a-t-il ouvert ou cliqué des messages similaires de votre part auparavant ? L'engagement récent est le signal positif unique le plus fort.
6. Disposition. Boîte de réception, onglet Promotions (Gmail), spams, ou rejet. La disposition est réinjectée dans la réputation.

Les cinq sections ci-dessous traitent des étapes 2 (authentification) et 4 (réputation). L'étape 1 est surtout l'affaire du relai d'envoi ; les étapes 3 et 5 sont des décisions de contenu et d'audience qui sortent du périmètre d'un guide de délivrabilité. L'étape 6 est le résultat. Pour un expéditeur commercial typique, bien faire les étapes 2 et 4 vous fait passer de 60–80 % d'inboxing à plus de 95 %.

Ce guide s'adresse aux opérateurs auto-hébergés parce que ce sont eux qui règlent les molettes. En SaaS, la plateforme abstrait l'essentiel ; en auto-hébergé, vous êtes propriétaire de l'enregistrement SPF, de la paire de clés DKIM, de la politique DMARC, du calendrier de warm-up d'IP. La bonne nouvelle : les standards sont publics et stables. La mauvaise : il n'y a pas de raccourci.

§2 · SPF

SPF — Sender Policy Framework.

SPF (RFC 7208) est une liste publique d'adresses IP autorisées à envoyer des emails au nom de votre domaine. Vous la publiez sous forme d'un unique enregistrement TXT sur votre domaine d'envoi. Quand un mailbox provider reçoit un message prétendant provenir de @yourcompany.com, il consulte l'enregistrement SPF sur yourcompany.com et demande : ce message provient-il d'une des IP listées ? Si oui, SPF passe. Sinon, SPF échoue.

La syntaxe

v=spf1 include:amazonses.com ~all

Se lit ainsi : « SPF version 1, autoriser tout ce qu'Amazon SES autorise, soft-fail tout le reste. » Le ~all en fin de chaîne est la clause catch-all. ~all = soft-fail (marquer suspect mais accepter), -all = hard-fail (rejeter), ?all = neutre (pas d'avis). Utilisez ~all jusqu'à ce que DMARC soit en bonne santé, puis durcissez en -all.

Plusieurs expéditeurs (par ex. Google Workspace pour le sortant + SES pour le marketing + Mailgun pour le transactionnel) se chaînent avec plusieurs mécanismes include: :

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

La limite des 10 lookups DNS. La RFC 7208 §4.6.4 plafonne la résolution SPF à 10 lookups DNS au total. Chaque include: en compte un. Échec courant : chaîner 5 vendeurs ou plus et dépasser la limite, après quoi SPF résout en permerror et est traité comme fail. Auditez avec dig TXT yourcompany.com + un SPF flattener si vous êtes proche de la limite.

SPF dans AcelleMail

Le modèle SendingDomain de AcelleMail expose getSpf() dans app/Model/SendingDomain.php:154, qui lit le paramètre global spf_record et restitue la valeur de l'enregistrement TXT. La méthode verifySpf(string $ipOrHostname) ligne 363 enveloppe la bibliothèque Mika56\SPFCheck — elle interroge le DNS en direct au runtime et asserte RESULT_PASS. La surface de vérification dans l'admin UI s'affiche en vert quand l'enregistrement est présent et autorise l'IP d'envoi, en rouge sinon.

Astuce pratique : SPF n'authentifie que l'envelope sender (le MAIL FROM au niveau SMTP), pas le From-header visible. C'est précisément cette distinction que l'alignement DMARC corrige — voir §4.

§3 · DKIM

DKIM — DomainKeys Identified Mail.

DKIM (RFC 6376) attache une signature cryptographique à chaque message sortant. Le serveur destinataire récupère votre clé publique depuis un enregistrement TXT du DNS, vérifie la signature contre certains headers et le corps du message, et accepte le message comme authentique si le calcul tombe juste. SPF dit « cette IP est autorisée à envoyer pour nous » ; DKIM dit « ce corps de message et ce From-header n'ont pas été altérés depuis qu'on les a signés ».

Le mécanisme

1. Vous générez une paire de clés RSA (1024 bits minimum, 2048 bits recommandé pour les nouveaux setups).
2. La clé publique entre dans le DNS sous forme d'enregistrement TXT à {selector}._domainkey.{yourdomain}. Le sélecteur est une chaîne arbitraire (par ex. k1, mail, 20251208) que vous choisissez pour permettre une rotation de clés sans casser les messages en vol.
3. La clé privée reste sur votre serveur d'envoi. Le MTA (ou le relai d'envoi) signe chaque message sortant avec, en ajoutant un header DKIM-Signature.
4. Le serveur destinataire lit les valeurs d= (domaine) et s= (sélecteur) du header de signature, va chercher {s}._domainkey.{d}, récupère la clé publique et vérifie.

DKIM dans AcelleMail

SendingDomain::generateDkimKeys() dans app/Model/SendingDomain.php:221 génère une paire de clés RSA 1024 bits via les bindings OpenSSL de PHP, stocke la moitié privée sur dkim_private et la moitié publique sur dkim_public. Le sélecteur est lu depuis dkim_selector sur le modèle, avec un fallback sur le paramètre global dkim_selector. La valeur de l'enregistrement DNS est restituée via $this->getDomain()->getDkimDnsRecord() (ligne 270) et présentée à l'opérateur avec un bouton de copie à côté de « la valeur à publier ».

Le pattern de génération de clé (extrait de generateDkimKeys()) :

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

Vérification : $this->getDomain()->verifyDkim() interroge le DNS à {selector}._domainkey.{domain} et compare la clé publique publiée à la valeur stockée localement. La méthode verify() complète sur le modèle orchestre les contrôles identité + DKIM + SPF + DMARC en un seul appel (ligne 300).

DKIM géré par le fournisseur

Si vous envoyez via Amazon SES, SendGrid, Mailgun ou tout autre fournisseur qui signe de son côté, vous publiez le sélecteur et la clé publique du fournisseur au lieu de générer les vôtres. La capacité driver-level SignsDkimOnServer de AcelleMail (voir app/SendingServers/Capabilities/SignsDkimOnServer.php) marque les drivers qui gèrent DKIM à distance ; l'UI affiche alors les enregistrements CNAME du fournisseur à publier plutôt que de générer une paire de clés locale. SES utilise trois CNAME qui délèguent _domainkey à amazonses.com — vous les positionnez une seule fois et SES fait tourner la clé sous-jacente pour vous.

§4 · DMARC

DMARC — alignement, politique et reporting.

DMARC (RFC 7489) se pose au-dessus de SPF et DKIM. Il fait trois choses que SPF et DKIM ne font pas individuellement :

1. Alignement. Exige que le domaine d'enveloppe validé par SPF ou le domaine signataire DKIM corresponde au domaine du From-header visible. Sans alignement, SPF et DKIM peuvent passer pour un domaine différent de celui que voit le destinataire — la faille qu'exploite le phishing.
2. Politique. Indique aux serveurs destinataires quoi faire en cas d'échec d'alignement : none (ne rien faire, juste reporter), quarantine (livrer en spams), reject (refuser le message au niveau SMTP).
3. Reporting. Rapports agrégés (RUA — rapports XML quotidiens de tous les envois depuis votre domaine) et rapports forensiques (RUF — rapports individuels par échec) envoyés aux adresses que vous spécifiez. Les rapports vous donnent une visibilité sur qui envoie du courrier en prétendant être vous.

La syntaxe

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

Se lit ainsi : « DMARC version 1, mettre en quarantaine les messages qui échouent à l'alignement, envoyer les rapports agrégés à dmarc@yourcompany.com, appliquer la politique à 100 % des messages en échec, exiger un alignement strict pour SPF et DKIM. »

Le déploiement standard

1. Jour 0 : publier p=none avec rua= pointant sur une boîte surveillée. Recevoir les rapports pendant 7 à 14 jours. Phase d'observation pure — aucun message n'est rejeté.
2. Jour 14 : dépouiller les rapports. Identifier les expéditeurs légitimes (votre propre SES, les IP d'envoi de votre CRM, les fournisseurs transactionnels) et les amener tous en alignement SPF + DKIM.
3. Jour 30 : durcir en p=quarantine; pct=10. Le courrier non aligné part en spams pour 10 % des destinataires. Surveiller les rapports pendant deux semaines.
4. Jour 45 : monter à pct=50, puis pct=100 sur 2 à 4 semaines.
5. Jour 60–90 : durcir en p=reject. Désormais le courrier non aligné bounce au niveau SMTP — les phishers qui se servent de votre domaine se prennent des rejets durs.

Ne sautez pas le déploiement. Passer directement d'aucun DMARC à p=reject est la cause la plus fréquente de désastres de délivrabilité auto-infligés : un expéditeur transactionnel oublié (votre CRM, votre outil de support, votre système de facturation) se met à hard-bounce à la seconde où p=reject se propage.

Les exigences des mailbox providers

Depuis février 2024, Gmail et Yahoo exigent DMARC pour tout expéditeur dépassant 5 000 messages par jour vers leurs domaines, plus SPF ou DKIM aligné, plus le List-Unsubscribe en un clic (RFC 8058). Microsoft 365 s'est aligné sur le même standard au moment de la rédaction. La barre de l'« envoi commercial » a définitivement bougé — DMARC n'est plus optionnel pour une liste supérieure à ~1 000 contacts. Installez-le tôt, même si votre liste est encore petite.

§5 · BIMI

BIMI — le bonus logo de marque.

BIMI (Brand Indicators for Message Identification) affiche le logo de votre marque à côté de vos messages dans la boîte de réception du destinataire. Gmail, Yahoo, Apple Mail et Fastmail le supportent depuis 2025. C'est une fonctionnalité connexe à la délivrabilité — pas de l'authentification au sens strict — mais elle requiert DMARC en p=quarantine ou p=reject comme prérequis, ce qui justifie sa présence dans ce guide.

Étapes de mise en place (une fois DMARC en quarantine ou plus strict) :

1. Créer une version SVG de votre logo en suivant la spec BIMI SVG Tiny PS — carré, pas de texte hors du repère, tracés simples.
2. Héberger le SVG sur une URL HTTPS publiquement accessible.
3. Obtenir éventuellement un Verified Mark Certificate (VMC) auprès d'une CA — exigé par Gmail pour afficher le badge avec une coche bleue, ~1 500 $/an. Les Common Mark Certificates (CMC) sont une alternative moins chère pour les marques non déposées.
4. Publier l'enregistrement BIMI : default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

L'impact de BIMI sur la délivrabilité est indirect mais mesurable : les logos de marque en boîte de réception font progresser les open rates de 5 à 20 % dans les études de cas publiées (données du pilote Yahoo Mail, rapport BIMI de Mailchimp). C'est aussi un puissant levier — vous ne pouvez pas activer BIMI sans avoir d'abord durci DMARC, donc les équipes s'en servent comme carotte pour une opération de mise au propre de l'authentification.

§6 · Réputation

Réputation — ce que les mailbox providers notent réellement.

L'authentification est binaire — un enregistrement résout et s'aligne, ou pas. La réputation est continue : un score de 0 à 100 maintenu par chaque mailbox provider, sur votre IP d'envoi et votre From-domain indépendamment. Les deux scores se combinent dans la décision de routage (boîte de réception vs Promotions vs spams vs rejet).

Les signaux

Où consulter votre score de réputation

• Google Postmaster Tools (postmaster.google.com) — réputation IP et domaine vue de Gmail, plus conformité à l'authentification, taux de chiffrement, spam rate. Gratuit.
• Microsoft SNDS (postmaster.live.com/snds/) — données au niveau IP d'Outlook.com, classification de réputation expéditeur. Gratuit, inscription requise.
• Yahoo Sender Hub — plus récent, inscription via la page Yahoo Postmaster. Statistiques agrégées par domaine.
• Dashboards des fournisseurs — l'Amazon SES Reputation Dashboard expose les bounce + complaint rates avec leurs seuils. SparkPost, Mailgun, SendGrid ont tous l'équivalent.

Consultez-en au moins un par semaine. Les indicateurs avancés (tendance du spam rate, chute de la réputation IP) apparaissent plusieurs jours avant les effets en aval (open rate qui décroche) — le temps de remarquer qu'une campagne sous-performe, le problème de réputation a déjà deux semaines.

§7 · Warm-up d'IP

Warm-up d'IP — le calendrier sur 6 semaines.

Une IP d'envoi fraîche démarre à zéro de réputation. Les mailbox providers throttlent les gros volumes des nouvelles IP par conception — c'est la défense principale contre les snowshoe spammers qui montent des instances cloud pour blaster. Le warm-up est la pratique consistant à augmenter graduellement le volume d'envoi sur 4 à 6 semaines en restant à l'intérieur des limites de throttling par jour et par heure, pour construire la réputation organiquement.

Vous ne le faites qu'une fois par IP. La plupart des équipes ne le font jamais parce que les IP partagées d'Amazon SES, SendGrid et Mailgun arrivent déjà chauffées. Les cas où le warm-up compte : IP dédiée sur SES (typiquement > 1 M d'envois/mois pour la justifier), MTA Postal auto-hébergé sur une instance cloud neuve, migration d'un ESP vers un autre avec changement de domaine.

Le calendrier

Calendrier basé sur les recommandations publiées de warm-up de SparkPost / Postmark / SES, consolidées dans un tableau unique semaine par semaine. Rampez plus lentement si vous voyez le complaint rate monter ; rampez plus vite uniquement si vous avez le feu vert réputation confirmé par le fournisseur à chaque étape.

Suivi du warm-up dans AcelleMail

Le modèle SendingServer de AcelleMail intègre l'état de warm-up en first-class. warmup_enabled, warmup_strategy_id et warmup_started_at figurent sur la table sending_servers ; isWarmupEnabled() dans app/Model/SendingServer.php:333 filtre les décisions au moment de l'envoi. La table compagne SendingServerWarmupLog enregistre chaque envoi pendant la fenêtre de warm-up avec date, statut et un payload meta sérialisé — voir app/Model/SendingServerWarmupLog.php.

Le pattern : attribuez une WarmupStrategy (une ligne qui définit la courbe de volume jour par jour) à un sending server, basculez warmup_enabled = true, fixez warmup_started_at = now(). La SendingServerWarmupUsage du pipeline d'envoi suit le compteur du jour et refuse de dispatcher au-delà du plafond quotidien de la stratégie. Quand le plafond du jour N de la stratégie dépasse votre volume quotidien plein, le serveur sort de période et le mode warm-up se désactive automatiquement.

Les classes DynamicRateTracker et InMemoryRateTracker (app/Library/) gèrent le rate limiting par minute / par heure au niveau SMTP — même en dehors du warm-up, AcelleMail fait respecter les plafonds publiés du relai pour qu'un pic dans la queue ne déclenche pas le throttling côté fournisseur.

§8 · Bounces + plaintes

Bounces, plaintes et le feedback loop.

Hard bounces vs soft bounces

Un hard bounce est un échec permanent — typiquement un code SMTP 5xx : l'adresse n'existe pas, le domaine ne résout pas, la boîte du destinataire est désactivée définitivement. Le modèle BounceLog de AcelleMail définit les constantes HARD et SOFT dans app/Model/BounceLog.php:33 ; un hard bounce supprime immédiatement l'adresse. Un soft bounce est transitoire — un code 4xx : boîte pleine, serveur temporairement indisponible, message trop volumineux. Les soft bounces sont rejoués selon un calendrier de backoff ; les adresses qui soft-bouncent à répétition sur plusieurs envois finissent par être déclassées en hard.

La carte de classification des notifications de bounce AWS SES (la source que la documentation BounceLog.php:32 de AcelleMail cite) : les types de bounce incluent Permanent (hard) avec les sous-types General / NoEmail / Suppressed / OnAccountSuppressionList ; Transient (soft) avec les sous-types General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected ; plus Undetermined (à traiter comme soft, à réessayer).

Les plaintes

Une plainte survient quand un destinataire clique « signaler comme spam » dans son client mail. Les plaintes arrivent via les Feedback Loops (FBL) — un canal de notification par fournisseur où les ISP vous transmettent les messages signalés. Le FeedbackLoopHandler de AcelleMail dans app/Model/FeedbackLoopHandler.php traite les messages FBL entrants en IMAP/POP et parse les headers Abuse Reporting Format (ARF, RFC 5965) pour extraire le message ID d'origine et le type de feedback.

Les types de feedback ARF que AcelleMail gère (selon FeedbackLoopHandler::FEEDBACK_TYPES ligne 35) :

• abuse — le destinataire a explicitement marqué comme spam. Supprimer immédiatement.
• fraud — le destinataire a marqué comme phishing. Supprimer + remonter à la revue sécurité.
• virus — l'antivirus du destinataire a signalé un payload. Supprimer + auditer le contenu.
• other — plainte générique. Supprimer.
• not-spam — signalement explicite « ce n'est pas du spam » (rare). Exclu de la suppression — voir EXCLUDED_FEEDBACK_TYPES.

Principaux mailbox providers participant aux FBL : AOL, Yahoo, Microsoft (via JMRP), Comcast, BlueTie. Gmail n'exploite pas de FBL public — ils livrent les retours « marqué comme spam » via le dashboard Postmaster Tools et via les rapports DMARC agrégés.

Règles de suppression

1. Hard bounce → supprimer définitivement. Ne jamais réessayer ; l'adresse est morte.
2. Plainte → supprimer définitivement. Le destinataire a demandé activement d'arrêter. Renvoyer est illégal dans la plupart des juridictions et détruit la réputation.
3. Soft bounce ×3 sur 30 jours → déclasser en hard, supprimer. Les soft bounces persistants traduisent une boîte pleine ou des problèmes de connectivité durables — à traiter comme morts.
4. Désabonnement → supprimer pour le marketing, pas pour le transactionnel. Les reçus de commande et les réinitialisations de mot de passe continuent ; les campagnes s'arrêtent.
5. Spam-trap hit → escalader en investigation. Retirez l'intégralité de la source d'acquisition de cet abonné. La liste a probablement été contaminée par des adresses achetées ou scrapées.

§9 · Hygiène de liste

Hygiène de liste — la discipline qui maintient la réputation au plus haut.

L'authentification est une mise en place one-shot. La réputation est une discipline opérationnelle. Les sept habitudes qui font bouger l'aiguille :

1. Double opt-in pour toutes les inscriptions marketing. Un clic de confirmation avant que l'adresse ne rejoigne la liste active. Élimine les fautes de frappe, les adresses de rôle (info@, sales@) et les adresses moissonnées. Ajoute 10 à 20 % de friction à l'inscription ; soustrait 50 à 80 % du risque de bounce/plainte.
2. Désabonnement en un clic (RFC 8058). Header List-Unsubscribe pointant sur une URL en un clic. Obligatoire chez Gmail et Yahoo pour les expéditeurs > 5 K/jour vers leurs domaines depuis février 2024. Rendez le désabonnement plus facile que la plainte — les destinataires qui auraient cliqué « spam » cliqueront « se désabonner » à la place.
3. Reconquête avant suppression. Les abonnés qui n'ont pas ouvert depuis 90 jours reçoivent une campagne « on veut rester pertinents ». Ouverture → garder. Pas d'ouverture → basculer en queue sunset. Pas d'ouverture après 180 jours → supprimer.
4. Auto-suppression des bounces. Traitez le webhook bounce en quelques minutes ; retirez de la liste d'envoi active avant la campagne suivante. Les handlers BounceLog::record() de AcelleMail et les webhooks bounce de type vbrandsync font cela automatiquement.
5. Ne jamais importer de listes achetées. Jamais. Les listes achetées sont semées de spam traps. Un seul trap touché et votre domaine est sur Spamhaus pour 30 jours et plus. Le calcul ne tombe jamais juste — les listes achetées sont un puits de réputation permanent.
6. Segmenter par engagement. Envoyez aux 50 % engagés deux fois plus souvent, aux 50 % froids deux fois moins. Cela fait monter l'open rate global, fait baisser le complaint rate, et donne aux mailbox providers un signal « cet expéditeur est pertinent » très fort.
7. Plafonner la cadence d'automatisation. Une welcome series + abandon de panier + post-achat + anniversaire + reconquête peut produire 8 messages en une seule semaine. Plafonnez le total des messages d'automatisation à un par 48 heures par destinataire, avec des exceptions dures pour le transactionnel (reçus, réinitialisations de mot de passe).

§10 · Outillage AcelleMail

L'outillage de délivrabilité de AcelleMail — ce que la source embarque.

Tiré directement de l'arbre source sous app/Model/ et app/Library/. Chaque entrée est un vrai modèle, interface de capacité ou classe de bibliothèque — pas du marketing.

§11 · Dépannage

Problèmes de délivrabilité courants et correctifs.

§12 · FAQ

FAQ délivrabilité email.

Tête de cluster

Où aller ensuite.

Domaines authentifiés. Bounces suivis. Réputation calibre boîte de réception.

AcelleMail embarque la vérification SPF/DKIM/DMARC, le traitement des feedback loops ARF, la machine à états du warm-up d'IP et le rate limiting par serveur, en standard. Chaque affirmation de ce guide se rattache à une classe de app/Model/ ou app/Library/ de AcelleMail dans l'arbre source.