Délivrabilité des emails pour les petites annonces pour adultes : pourquoi le code de vérification n'arrive jamais

La panne pour laquelle personne ne reçoit d'alerte

Un nouvel utilisateur s'inscrit, saisit une adresse email et attend le code à six chiffres qui lui permet de terminer la vérification d'âge. Il n'arrive pas dans la minute où il le devrait. Peut-être atterrit-il dans le dossier spam dix minutes plus tard, bien après que l'utilisateur a abandonné et fermé l'onglet. Peut-être le serveur de messagerie destinataire le rejette-t-il directement au moment de l'envoi, avec un message de rebond qui défile dans un journal que personne ne surveille. Dans un cas comme dans l'autre, rien dans l'expérience ne dit à l'opérateur que quelque chose s'est mal passé. Le tunnel d'inscription affiche simplement un visiteur de plus qui a saisi une adresse email et n'est jamais revenu, indiscernable de quelqu'un qui a simplement changé d'avis.

Cette ambiguïté est le vrai problème, plus que n'importe quelle cause technique précise. La plupart des sites vérifient si un email a été envoyé, une coche verte sur un tableau de bord, pas s'il a réellement été placé devant un être humain. Ce sont deux événements distincts, et l'écart entre les deux est exactement l'endroit où un problème de délivrabilité se cache pendant des mois. Un opérateur qui n'a jamais eu de panne d'hébergement ni de gel de prestataire de paiement peut malgré tout perdre une part réelle de nouvelles inscriptions à cause d'un problème de messagerie qu'il n'a aucun moyen de remarquer, parce qu'il n'y a ni incident, ni ticket d'assistance, ni tableau de bord qui passe au rouge.

C'est un type de risque fournisseur différent de celui qui ferme un compte d'hébergement avec un avis citant une clause que personne n'a relue depuis la signature. Un hébergeur suspendu est bruyant : le site s'éteint, et l'opérateur l'apprend en quelques minutes parce que les clients le signalent et que le tableau de bord aussi. Un problème de délivrabilité est silencieux par construction. Le compte d'envoi reste ouvert, la facture mensuelle continue d'arriver, et le seul symptôme visible est un tunnel d'inscription qui perd des gens à la toute dernière étape pour des raisons qui, du côté de l'opérateur, ressemblent à un abandon ordinaire plutôt qu'à une panne technique réparable.

La cause sous-jacente reste néanmoins le même type de friction de catégorie qui apparaît avec les hébergeurs, les banques et les prestataires de paiement. Les fournisseurs de boîtes de réception et les services d'envoi d'emails notent cette catégorie comme plus risquée que la plupart, certains explicitement et nommément, et un nouveau domaine sans historique d'envoi démarre chaque message avec un désavantage qui n'a rien à voir avec ce que le message dit réellement.

Pourquoi cette catégorie est filtrée plus durement que la plupart

Les filtres antispam et les fournisseurs de services d'emails ne traitent pas tous les secteurs de la même façon, et il vaut mieux lire les différences avant de s'inscrire qu'après qu'un compte a été signalé. La politique publiée par SendGrid sur les contenus interdits liste, comme points distincts, « pornographie ou contenu sexuellement explicite » et, séparément, « services d'escorte, recherche d'épouses ou de conjoints par correspondance, agences matrimoniales internationales et services similaires ». Cette seconde catégorie ne concerne pas ce que contient l'email. Elle nomme l'activité elle-même comme motif d'exclusion, ce qui signifie qu'un code de vérification en texte brut envoyé par un annuaire d'escortes peut se retrouver hors politique uniquement à cause de la catégorie, quelle que soit la sobriété du message.

La politique d'utilisation acceptable de Mailgun trace la limite ailleurs, tout à fait différemment. Sa section sur les contenus interdits se limite au matériel qui constitue ou promeut l'exploitation d'enfants, la zoophilie ou des actes non consentis, sans clause distincte nommant les activités pour adultes ou les services d'escorte comme catégorie. C'est une restriction nettement plus étroite que celle de SendGrid, visant ce qui est illégal plutôt que le secteur qui envoie. Deux grands fournisseurs généralistes, accessibles via le même type de formulaire d'inscription, tracent la limite à des endroits vraiment différents, et un opérateur qui en choisit un sans lire au-delà de la page tarifaire n'a aucun moyen de savoir de quel côté de cette limite se trouve son compte avant qu'une revue ne le signale.

C'est le même angle mort de vérification préalable qui prend au dépourvu les opérateurs face à une clause de résiliation d'hébergement ou de CDN qu'ils n'ont jamais lue, un niveau plus bas dans la pile. La question à se poser avant de choisir un fournisseur d'emails n'est pas de savoir s'il autorise techniquement l'envoi de courrier pour ce type d'activité en général. C'est de savoir si la politique écrite du fournisseur nomme spécifiquement la catégorie d'activité, par écrit, avant que le premier code de vérification ne parte, pas après qu'une revue anti-abus l'ait découvert.

Un nouveau domaine d'envoi aggrave cela par-dessus tout ce que le fournisseur autorise. Les filtres pèsent lourdement l'historique et le rythme de volume d'un domaine, et un domaine apparu récemment qui se met immédiatement à envoyer des codes automatiques en volume ressemble, pour un filtre sans autre signal, au schéma d'un compte créé dans un but étroit puis abandonné une fois signalé. Ce n'est pas un jugement sur l'activité ; c'est une correspondance de motif que déclenche n'importe quel domaine tout neuf, petites annonces pour adultes ou non, et qui ne s'estompe qu'avec le temps et un comportement d'envoi constant.

Le socle technique que tout fournisseur de boîtes de réception impose désormais

Même un fournisseur dont la politique accueille le compte sans réserve ne peut pas, à lui seul, faire atterrir un email dans la boîte de réception. Depuis le 1er février 2024, Google exige de tout expéditeur envoyant du courrier vers des adresses Gmail, quel que soit le volume, de respecter un socle documenté : au minimum, SPF ou DKIM correctement configurés sur le domaine d'envoi. SPF liste quels serveurs sont autorisés à envoyer au nom du domaine ; DKIM signe chaque message afin que le serveur destinataire puisse confirmer qu'il n'a pas été altéré en transit. Les expéditeurs atteignant 5 000 messages par jour vers des adresses Gmail spécifiquement font face à une barre plus haute : SPF et DKIM ensemble, plus DMARC publié sur le domaine, au minimum en mode surveillance. Un site de petites annonces qui envoie des codes de vérification d'âge, des réinitialisations de mot de passe et des reçus de paiement à une échelle réelle franchit rapidement ce seuil de 5 000 messages, puisque chacun d'eux compte pour le total.

Les propres directives publiées par Google fixent un chiffre précis au-dessus de l'authentification : les expéditeurs de toute taille doivent maintenir le taux de plaintes rapporté via Postmaster Tools de Google sous 0,30 pour cent, et les mêmes directives recommandent de rester sous 0,10 pour cent comme marge de sécurité réelle, plutôt que de traiter 0,30 pour cent comme un objectif confortable à approcher. La non-conformité se traduit par deux pannes distinctes et documentées séparément, plutôt que par une pénalité vague. Le courrier qui échoue à SPF, DKIM ou DMARC peut être marqué comme spam ou rejeté directement avec l'erreur SMTP 5.7.26. Les expéditeurs qui dépassent le quota d'envoi autorisé par Google se heurtent à un mur distinct, une erreur de limitation 4.7.28. Aucun des deux n'annonce « ce secteur n'est pas le bienvenu ici ». Les deux ressemblent, depuis le tableau de bord d'un développeur, à une panne technique ordinaire, et c'est précisément pour cela qu'ils tendent à être remarqués des semaines plus tard plutôt que corrigés le jour où ils commencent.

Yahoo, dont l'infrastructure dessert aussi les adresses AOL, publie indépendamment le même type d'exigence : SPF et DKIM ensemble, une politique DMARC d'au moins p=none qui doit passer la vérification, et le même plafond de 0,30 pour cent sur le taux de plaintes, en vigueur selon le même calendrier depuis février 2024. Un opérateur qui résout cela pour Gmail et suppose que Yahoo et AOL suivront a généralement raison sur la mécanique, puisque les deux fournisseurs ont convergé vers des chiffres presque identiques, mais les deux systèmes continuent de mesurer et d'appliquer les règles séparément, donc un domaine en règle avec l'un n'est pas automatiquement en règle avec l'autre.

Une exigence de cet ensemble est écrite volontairement de façon étroite. Le désabonnement en un clic, via l'en-tête List-Unsubscribe, s'applique spécifiquement aux messages marketing et aux messages souscrits, selon les propres termes de Google. Un code de vérification ou un reçu de paiement n'est ni l'un ni l'autre, donc ce n'est pas ce que vise cette ligne en particulier. Les exigences d'authentification et de réputation au-dessus, SPF, DKIM, DMARC et le plafond de plaintes, ne sont pas limitées de cette façon : elles s'appliquent à tout message qu'un domaine envoie, transactionnel compris.

L'erreur qui entraîne aussi le courrier important vers le bas

La façon la plus courante dont un opérateur abîme ses propres emails de vérification est d'envoyer du courrier marketing depuis le même domaine que celui qui envoie les codes de vérification et les reçus de paiement. La réputation est suivie surtout au niveau du domaine et du sous-domaine d'envoi, ce qui explique pourquoi séparer les flux aide, mais l'isolation entre sous-domaines n'est pas absolue : un pic de plaintes sur un sous-domaine peut encore se répercuter sur le domaine parent, en particulier si les deux flux partagent la même identité de signature DKIM en coulisses. Un email promotionnel annonçant une nouveauté ou une offre saisonnière, envoyé à une liste devenue obsolète, produit exactement le genre de pic de plaintes capable de faire chuter la réputation d'un domaine partagé, et une partie de ces dégâts atteint le code de vérification qu'un utilisateur tout juste inscrit attend en ce moment même, un message qui n'a rien à voir avec l'envoi marketing à l'origine du problème.

C'est aussi là que la discipline opérationnelle construite autour de la vérification d'âge s'entremêle avec un problème de délivrabilité purement technique, d'une façon facile à manquer. Un parcours de vérification qui dépend d'un code arrivant dans une boîte de réception n'est fiable qu'à hauteur de la réputation du domaine d'envoi le jour où ce code part, et la réputation est une ressource partagée entre tous les types de messages utilisant une infrastructure liée, à moins que l'opérateur ne les tienne délibérément séparés.

La solution est structurelle, pas un réglage à basculer après qu'un pic de plaintes s'est déjà produit. Envoyez le courrier transactionnel, codes de vérification, confirmations de paiement, réinitialisations de mot de passe, depuis un sous-domaine dédié qui ne sert à rien d'autre, par exemple mail.exemple.com plutôt que le domaine nu ou un sous-domaine marketing partagé, et signez-le avec sa propre clé DKIM plutôt qu'une clé réutilisée sur tous les flux. Envoyez le contenu marketing ou les newsletters depuis un sous-domaine entièrement séparé, comme news.exemple.com, avec ses propres enregistrements d'authentification et sa propre réputation, capable d'absorber une mauvaise semaine de plaintes sans entraîner avec elle le courrier qui doit absolument arriver. Les deux flux peuvent transiter par le même compte chez le fournisseur, mais ils doivent paraître, et être signés, comme des expéditeurs nettement distincts aux yeux du serveur de messagerie destinataire.

Ce qu'il faut vraiment vérifier cette semaine

Commencez par sortir la politique d'utilisation acceptable de tout service qui envoie actuellement le courrier transactionnel du site, et trouvez, par écrit, si elle nomme spécifiquement la catégorie d'activité, de la même façon que la vérification précédente sur les contrats d'hébergement et de CDN a fonctionné pour les fournisseurs d'infrastructure. Un fournisseur dont la politique exclut déjà la catégorie par son nom n'est pas un fournisseur sur lequel bâtir un parcours de vérification, aussi fiable ait-il été jusqu'ici, parce qu'une revue de compte peut mettre fin à cette fiabilité sans aucun avertissement.

Vérifiez que SPF, DKIM et DMARC sont réellement publiés et validés sur le domaine qui envoie en ce moment les emails de vérification et de reçu, plutôt que de le supposer parce que quelqu'un les a configurés une fois, il y a des années. Un enregistrement DNS qui était correct au moment où il a été écrit peut devenir obsolète après une migration de fournisseur, et un domaine sans authentification démarre chaque message avec une réelle chance de rejet selon les règles que Google et Yahoo appliquent depuis février 2024, quel que soit le contenu du message.

Séparez le courrier transactionnel et le courrier marketing sur des sous-domaines distincts avec des clés de signature distinctes s'ils ne le sont pas déjà, et traitez cela comme un travail d'infrastructure plutôt que comme une décision de l'équipe marketing, puisqu'une erreur ici coûte un contrôle d'identité raté, pas une vente manquée.

Surveillez le taux de plaintes réel via les rapports du fournisseur lui-même ou via Postmaster Tools de Google selon un calendrier fixe, et traitez toute approche des 0,10 pour cent comme le point à investiguer, pas les 0,30 pour cent, puisque 0,30 pour cent est plus proche du point où le courrier commence à être rejeté que du point où un problème commence. Et envoyez de temps en temps une véritable inscription test vers une adresse Gmail personnelle et une adresse Yahoo personnelle, et chronométrez combien de temps met le code à arriver et où il atterrit, parce qu'un tableau de bord signalant un envoi réussi signale ce qui est sorti du serveur, pas ce qu'un utilisateur a réellement vu.