Google publie un seuil : cinq mille messages par jour. Microsoft publie le même. Yahoo, interrogé sur le sien, répond ceci :
« A « bulk » sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold. »
Un volume significatif. Nous ne préciserons pas de seuil.
La tentation est de lire cette phrase comme une négligence, ou comme le signe d’une documentation moins soignée que celle du concurrent. C’est l’inverse : c’est la phrase la plus réfléchie de tout le corpus.
Un seuil publié est un seuil optimisable
Quand Google annonce 5 000 messages sur 24 heures, il donne aux expéditeurs honnêtes une règle claire. Il donne aussi, au même instant, une cible à ceux qui veulent rester juste en dessous.
Google a d’ailleurs fermé la porte la plus évidente : les envois d’un domaine et de ses sous-domaines s’additionnent, et le statut d’expéditeur groupé, une fois acquis, n’expire jamais. Deux verrous ajoutés parce que le chiffre était public.
Yahoo n’a pas eu à poser ces verrous. On ne contourne pas un seuil qu’on ignore.
Le coût de ce choix est réel, et il pèse entièrement sur vous : chez Yahoo, vous ne pouvez pas vous déclarer conforme. Vous ne pouvez qu’être toléré, et le découvrir après coup.
Ce que Yahoo publie, en revanche, est très précis
Le silence ne porte que sur le volume. Sur le reste, la documentation Yahoo est plus explicite que celle de Microsoft.
Le taux de plainte doit rester sous 0,3 %, exactement comme chez Google. Cette convergence entre deux concurrents est le fait le plus solide du dossier.
Tous les expéditeurs doivent mettre en place SPF et DKIM. Les expéditeurs groupés doivent en plus publier une politique DMARC valide, avec au minimum p=none. Yahoo recommande fortement d’aller au delà, en p=quarantine ou p=reject, sans l’exiger.
La clé DKIM doit faire au moins 1024 bits, 2048 étant recommandé. C’est la reprise exacte de ce que dit la norme depuis 2018, et un rappel utile : beaucoup de clés en production sont plus courtes.
Les enregistrements DNS inverses doivent être valides, significatifs et non génériques. Un PTR de la forme ip-91-121-33-12.provider.net satisfait la vérification technique et échoue au test du mot « significatif ».
Le désabonnement doit être honoré sous deux jours, et la méthode POST du désabonnement en un clic est « hautement recommandée ».
Enfin, la boucle de retour sur les plaintes ne fonctionne qu’avec des messages signés en DKIM, et elle est fondée sur le domaine. Sans DKIM, vous n’apprendrez jamais qui s’est plaint chez Yahoo.
Le silence sur TLS
Google écrit noir sur blanc qu’il exige TLS pour les connexions SMTP des expéditeurs groupés. Sur les pages de Yahoo consacrées aux bonnes pratiques, à la foire aux questions et aux codes d’erreur SMTP, nous n’avons trouvé aucune exigence équivalente.
Nous nous gardons d’en conclure que Yahoo accepte le texte clair. L’absence d’une phrase dans une documentation ne prouve pas l’absence de la règle : elle prouve l’absence de la phrase. C’est une distinction que ce métier oublie souvent, et elle vaut aussi pour les chiffres que tout le monde répète sans les avoir lus.
La transparence n’est pas une vertu, c’est une stratégie
Mettez les trois opérateurs côte à côte et vous obtenez trois doctrines.
Google publie beaucoup, ce qui lui permet d’exiger beaucoup : on ne peut reprocher un rejet à qui a écrit ses conditions.
Microsoft publie un seuil et une exigence d’authentification, sans taux de plainte ni norme de désabonnement, et a transformé son rejet annoncé en classement en indésirables six jours avant l’échéance.
Yahoo publie ses exigences techniques et garde pour lui la seule variable que l’expéditeur pourrait ajuster.
Aucune de ces trois postures n’est plus légitime que les autres. Ce sont des infrastructures privées qui écrivent leurs propres conditions d’accès, et qui les révisent quand elles le jugent utile.
Ce que vous faites demain matin
Cessez de raisonner en conformité et raisonnez en marges.
La conformité suppose un référentiel stable et public. Vous n’en avez pas : vous avez trois référentiels, dont un partiellement secret et un révisable sans préavis.
Ce qui tient dans les trois cas est court : une authentification complète et alignée, un taux de plainte tenu très en dessous du plafond, une liste dont chaque adresse a une origine et existe réellement, et une sortie qui fonctionne du premier coup.
Le reste est de l’ajustement à un seuil, et l’ajustement à un seuil échoue le jour où le seuil bouge. Ce jour arrive toujours.
Sources
- Yahoo Sender Hub. Frequently Asked Questions
- Yahoo Sender Hub. Best Practices
- Yahoo Sender Hub. Complaint Feedback Loop
- Yahoo Sender Hub. SMTP Error Codes
- Google Workspace Admin Help. Consignes pour les expéditeurs d’e-mails
- Kitterman, S. (2018). Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM), RFC 8301
LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.