Pourquoi un taux d’activation mesuré à 24% peut-il, une fois la délivrabilité vérifiée, remonter à 34% sans qu’aucune ligne de code produit n’ait changé ? La réponse tient à un maillon que les dashboards d’activation ignorent structurellement : ils comptent les signups sans jamais vérifier si l’email correspondant a été livré. Une adresse saisie avec une faute de frappe au moment de l’inscription, un domaine expéditeur trop jeune pour avoir une IP reputation établie ou un message filtré en spam produisent exactement le même symptôme côté produit : un utilisateur qui n’active jamais son compte. Apple Mail Privacy Protection a déjà rendu le taux d’ouverture inutilisable comme signal d’engagement. La délivrabilité de la séquence d’onboarding, elle, reste un angle mort tant que personne ne va la vérifier à la source.
Un domaine neuf n’a pas d’historique, l’onboarding en hérite le premier
Un produit qui lance sa séquence d’onboarding le jour de son ouverture publique envoie parfois plusieurs milliers de messages en une semaine depuis un domaine qui n’a jamais rien envoyé. Les fournisseurs de messagerie lisent ce pattern comme un signal de risque, indépendamment de la croissance qu’il traduit côté produit. Les guides de délivrabilité recommandent généralement un démarrage progressif étalé sur 4 à 8 semaines. Le compte le plus jeune reçoit ses emails les plus critiques par le canal le moins fiable ; un domaine établi dilue ce risque, un domaine neuf l’assume seul.
Les adresses saisies au signup sont les moins vérifiées de toute la base
Un formulaire d’inscription qui accepte « @gmial.com » sans broncher alimente une base de contacts avec une adresse qui n’existera jamais. Ce type de faute de frappe se comporte exactement comme une adresse abandonnée après la fermeture d’un compte : le message rebondit dès le premier essai, avant même l’ouverture du welcome email. Une adresse générique comme info@, contact@ ou admin@ pose un problème différent : elle passe la vérification syntaxique et MX sans difficulté. Elle atterrit ensuite dans une boîte partagée que la personne réellement inscrite ne consulte presque jamais, ce qui plombe l’engagement de toute la séquence d’onboarding sans provoquer le moindre bounce.
Validity distingue les spam traps recyclés, d’anciennes adresses réactivées par les fournisseurs pour repérer les listes mal entretenues, des pièges dits pristine, jamais associés à un utilisateur réel (Validity, 2024). Une base de signup ne devrait en théorie contenir aucun piège pristine, faute de collecte externe. Le risque vient d’ailleurs : les fautes de frappe (gmial, hotmial, yaho) et les adresses jetables souscrites le temps d’un essai gratuit.
Un calcul publié par Bounceproof en juillet 2026 chiffre l’écart. Si 20% des inscriptions utilisent une adresse invalide ou jetable et que 15% des adresses valides restantes atterrissent en spam, l’audience réellement activable tombe à 65% des signups déclarés. Mesurer le taux d’activation sur 100% des inscriptions revient alors à sous-évaluer la performance réelle de 35%. À l’inverse, un double opt-in réduit le volume de signups de 5 à 15% mais fait remonter le taux d’activation mesuré de 15 à 30 points, la liste résultante ne contenant que des boîtes confirmées. Une adresse invalide non filtrée en amont pèse donc directement sur un chiffre que personne ne relie jamais à la délivrabilité.
Trois fournisseurs, trois seuils, une même sanction
Google et Yahoo ont aligné leurs exigences d’expéditeurs en masse en février 2024 : authentification SPF/DKIM/DMARC obligatoire au-delà de 5 000 emails quotidiens, désabonnement en un clic et complaint rate maintenu sous 0,3%. Microsoft applique une logique voisine via son indice SNDS, sans jamais avoir publié le même texte commun.
Les expéditeurs de plus de 5 000 messages quotidiens vers des adresses Gmail ou Yahoo doivent s’authentifier via SPF/DKIM/DMARC, proposer un désabonnement en un clic et maintenir un taux de plainte sous 0,3%, sans distinction entre trafic marketing et trafic transactionnel comme une séquence d’onboarding.
| Fournisseur | Seuil de complaint rate | Sanction en cas de dépassement |
|---|---|---|
| Google (Gmail) | 0,3% toléré, 0,1% recommandé pour rester en zone de confort | Filtrage renforcé, blocage temporaire au-delà de 5 000 emails/jour sans authentification conforme |
| Yahoo/AOL | 0,3%, aligné sur Google depuis février 2024 | Routage automatique vers le dossier bulk, puis rejet SMTP en cas de récidive |
| Microsoft (indice SNDS) | Jaune dès 0,3%, rouge au-delà de 0,5% | Dégradation de l’IP reputation tier, filtrage progressif sur Outlook et Hotmail |
Ces seuils s’appliquent à l’ensemble du trafic sortant d’un domaine, séquence d’onboarding comprise. Un pic d’inscriptions viral le jour d’un lancement Product Hunt peut faire grimper le complaint rate d’un domaine entier bien avant l’envoi de la première newsletter.
Ce que les dashboards d’activation ne peuvent pas voir
Un product manager regarde une cohorte d’activation à J7 et conclut que l’onboarding email « ne convertit pas ». Personne dans la réunion n’a consulté Google Postmaster Tools ni le taux de hard bounce spécifique à cette séquence.
Apple Mail Privacy Protection précharge les pixels de tracking dès la réception du message, ce qui rend le taux d’ouverture inutilisable pour distinguer un email lu d’un email jamais arrivé. La mise à jour Gmail de décembre 2025 a aussi fait chuter les scores seedlist de plusieurs expéditeurs sans notification préalable. La lecture des métriques d’engagement classiques est restée brouillée pendant plusieurs semaines pour les équipes concernées. Les guides de Google et de Microsoft détaillent les seuils à respecter sur l’ensemble d’un flux d’envoi. Aucun des deux n’isole la séquence d’onboarding du reste du volume, alors que c’est là que l’histoire diverge le plus vite d’un domaine à l’autre : un domaine neuf construit toute sa réputation à partir de ce segment, un domaine établi la dilue dedans. En pratique, ce sous-ensemble reste invisible dans des dashboards produit qui mesurent l’activation sans jamais remonter à la livraison qui la précède.
Isoler l’onboarding pour mesurer sans bruit
Faire porter la séquence d’onboarding par un sous-domaine dédié permet de lire un bounce rate et un complaint rate propres à ce segment, sans que le volume d’une newsletter ne vienne les diluer. Cette isolation a un coût technique : chaque sous-domaine porte ses propres enregistrements SPF et DKIM ; une politique DMARC à p=reject appliquée au domaine racine sans alignement correct sur le sous-domaine casse la délivrabilité du jour au lendemain, ARC sealing compris. Le PTR record de l’adresse IP dédiée à l’onboarding mérite la même attention que le SPF ou le DKIM : une résolution DNS inversée absente ou mal alignée sur le nom d’hôte déclaré par le MTA déclenche un rejet immédiat chez une partie des serveurs Microsoft, indépendamment de tout autre critère de réputation.
Les rapports agrégés DMARC, analysés avec un outil comme parsedmarc, permettent ensuite de vérifier le policy_evaluated propre à ce sous-domaine plutôt que celui, plus favorable, du domaine marketing établi. Un écart brutal entre les deux jeux de rapports signale un défaut d’alignement qui resterait invisible si les flux onboarding et marketing étaient mélangés dans un seul tableau de bord. Ce niveau de granularité coûte un peu de temps de configuration au départ ; il évite ensuite des semaines de diagnostic à l’aveugle quand le taux d’activation décroche sans raison apparente.
Les vagues de credential stuffing qui créent des comptes en masse via des adresses jetables produisent le même bruit qu’une liste achetée : elles gonflent artificiellement le dénominateur du taux d’activation et exposent le domaine à des adresses spam trap fraîchement recyclées.
Une Suppression List alimentée en continu par les hard bounces et les plaintes de ce segment évite d’y renvoyer indéfiniment. Cette isolation ne règle pas tout, surtout : au-delà du contrôle syntaxique et MX, une adresse peut rester parfaitement valide et pourtant appartenir à quelqu’un qui ne consultera jamais sa boîte, l’engagement réel restant hors de portée d’une vérification de délivrabilité seule.
Vérifier avant d’envoyer coûte moins cher que délister après
Une IP listée sur le SBL Spamhaus après un pic d’onboarding mal maîtrisé déclenche un formulaire de délistage dont le traitement est annoncé à 72 heures, sans garantie que le domaine associé n’ait pas déjà perdu sa place dans les algorithmes de tri prioritaire des boîtes de réception chez les gros fournisseurs entre-temps. Le mécanisme se vérifie avant l’envoi, bien avant le premier rejet en production : un échantillon de la base de signup passé au crible via une vérification syntaxique et MX, complétée par un contrôle au niveau boîte, détecte la majorité des adresses invalides et jetables avant qu’elles n’entrent dans la séquence.
La seule façon de savoir si une séquence d’onboarding donnée souffre d’un problème d’acheminement ou d’un problème de produit, c’est de vérifier l’échantillon des signups des sept derniers jours avant d’accuser l’UX ou le copywriting. Le warm-up d’un domaine et l’hygiène de la liste au signup relèvent du même diagnostic technique, même si l’habitude consiste à les traiter comme deux chantiers séparés. Les exigences publiées par Google pour les expéditeurs en masse s’appliquent dès le premier email envoyé et non uniquement à la campagne marketing qui arrivera six mois plus tard.
Le message rejeté ne revient jamais deux fois.
