AAL  -  Avril 2021  -  10 mn de lecture

Délivrabilité B2B : radiographie MX

Selon l’Arcep, il y a à ce jour plus de 3,7 millions de noms de domaines déposés en .FR (en augmentation de 14% sur 2020 – sur près de 370 millions au niveau mondial, toutes extensions TLD confondues), chacun disposant d’au moins une adresse email, fournie par le service de messagerie standard du Registrar.


Or, la gestion technique de la délivrabilité requiert deux capacités essentielles : 1/ Le contrôle de la vitesse et des quotas d’envoi par domaine de destination, par exemple dans un contexte de warm-up de réputation d’IP 2/ La qualification précise des messages de bounce des serveurs SMTP distants, typiquement pour distinguer un NPAI d’un blocage.


Autant le premier point reste techniquement accessible dans un contexte B2C, à l’échelle des quelques dizaines de webmails US et FAI locaux (Outlook/Gmail/Yahoo, Orange/SFR/Free/Laposte), autant maintenir un contexte complet d’envoi par domaine B2B semble irréaliste au regard du nombre de domaines en jeu.


Cependant, un grand nombre de domaines B2B hébergent très peu d’adresses email, aussi, la question de l’utilité du contrôle de flux dans ce contexte peut se poser… sous réserve qu’ils ne soient pas hébergés sur une même plateforme mutualisée.


La qualification précise des messages de bounce reste relativement générique, puisqu’elle ne dépend essentiellement que du type serveur de messagerie contacté : webmail/FAI, serveur Microsoft Exchange, PostFix, Exim, Sendmail, ou encore appliance de sécurité comme Barracuda, Ironport ou Sophos.


Naturellement, il n’y a pas autant de serveurs de messagerie qu’il y a de domaines, au contraire puisque la grande majorité des services de messagerie sont fournis en Saas, qu’il s’agisse de Microsoft (avec Office365), Google (avec GSuite), ou encore la messagerie standard des Registrars (OVH/Gandi/1and1).


L’enjeu consiste donc à déterminer les principaux services et solutions de messagerie et d’identifier les domaines qui y sont hébergés, afin de n’avoir qu’à définir un seul profil de routage par hébergeur plutôt que par domaine individuel.


Dans un contexte B2C, les groupes de domaines sont bien connus et référencés, par exemple, outlook.com, live.com, hotmail.com, msn.com, etc sont hébergés sur Office365, de la même façon qu’orange.fr et wanadoo.fr sont hébergés chez l’opérateur Orange.


Pour le B2B en revanche, le nombre d’hébergeurs, de serveurs de messagerie et de solutions de sécurité est beaucoup plus important. De plus, le churn significatif des domaines nécessite une mise à jour en continu, qu’il s’agisse du rattachement de domaines à des groupes connus ou de l’identification de nouveaux hébergeurs/solutions, ce qui représente une tâche d’administration lourde et pour un résultat bien souvent hasardeux.

 

Pour répondre à cette problématique, Rafale intègre un module spécifique, appelé MxMonitor (ou MxM), dont la mission est double : 

  1. Qualifier, avant routage, le type de serveur de messagerie associé au domaine de destination.

  2. Suivre en continu sa disponibilité technique et les évolutions de sa configuration.
     

MxM - Data Sources.jpg

Les capacités d’identification permettent d’ajuster optimalement les paramètres de délivrabilité avant expédition (contrôle du flux d’envoi, interprétation des bounces…), tandis que le monitoring peut s’assimiler aux fonctions d’un cache DNS couplé à un downdetector.

A ces fins, MxM dispose de deux modes opératoires :

  • L’un passif, dans lequel il va interroger régulièrement des sources de données externes susceptibles de lui fournir des informations techniques sur le domaine, tels que le WHOIS, le DNS ou encore les NICs.

  • L’autre semi-actif, où il va établir une session SMTP avec le serveur de messagerie distant, sans pour autant lui transmettre d’email.

L’ensemble des informations collectées va permettre de constituer une empreinte spécifique et qualifier ainsi le système de messagerie du domaine avec un bon niveau de fiabilité, et subsidiairement, de lui associer un score de réputation permettant d’ajuster le cas échéant la stratégie de routage en conséquence.

A titre d’illustration, voici les statistiques issues de la base connaissance MxM de la plateforme de routage Rafale « devops » (Saas mutualisé), gérant exclusivement des NewsLetters de sites web B2B, comptant aussi bien des emails de professions libérales que de grandes entreprises.

I. Périmètre

Le système maintient, sous forme d’un index MD5, le nombre d’adresses email uniques par domaine, ce afin de déterminer la représentation relative du domaine au sein du trafic global.

A fin mars 2021, la plateforme comptabilisait 6,8 millions d’adresses email uniques, réparties sur 680000 domaines. A noter que près de la moitié des emails sont des adresses de webmail/FAI, encore beaucoup utilisées par les professions libérales, TPEs, petits commerces, pour un solde net de 3,5 millions emails avec des domaines purement B2B.

Le nombre de domaines en .FR est de 267k, représentant 7% de l’ensemble de domaines B2B français, ce qui n’est pas forcément représentatif du marché.

La distribution des adresses email par domaine est d’une extrême granularité, puisque 90% des domaines ont moins de 10 adresses email, tandis que 0,1% des domaines en ont plus de 100 (voir diagramme de Pareto), avec des extrêmes supérieurs à 10000.

Enfin, 275 extensions TLD sont représentées, le .COM restant majoritaire, juste devant le .FR.

MxM - B2B Database FR.jpg

II. WHOIS

Chaque extension TLD est gérée par un organisme spécifique, avec quelques exceptions, comme Verizon qui gère aussi bien les .COM que les .NET et les .TV, ou encore Afilias avec les .INFO et .PRO.

L’adresse de chaque serveur WHOIS peut être retrouvée avec une résolution DNS de type CNAME sur XXX.whois-servers.net, ou XXX est l’extension recherchée. Par exemple, fr.whois-servers.net pointe vers whois.nic.fr, géré par l’Afnic, qui délivre leur licence aux 400 Registrars français.

OVH se démarque largement, qu’il s’agisse des .FR ou des autres TLD, même si les services US sont beaucoup plus présents sur le .COM. NB : plusieurs pays européens ont protégé leur service WHOIS par un Capcha, tels que la Suisse, l’Allemagne, l’Italie, l’Espagne, la Roumanie, la Pologne… ce qui compromet leur interrogation automatisée, raison de leur absence des statistiques.

En dehors de l’identité du Registrar par lequel a été souscrit le nom de domaine, le service WHOIS fournit également la date de création du domaine, utile pour mesurer son ancienneté et de fait sa notoriété, ainsi que sa date d’expiration, information à recouper à d’éventuels messages de hardbounce post-routage.

MxM - Registrars.jpg

III. DNS

III.1 MX Records

La résolution DNS des enregistrements MX des 680k domaines fait ressortir 256k hôtes uniques, parmi lesquels certains sont surreprésentés :

  • Les Registrars OVH, Gandi et 1and1, qui fournissent en standard un service de messagerie avec la souscription du nom de domaine, et qui hébergent 30% des noms de domaines et 11% des adresses email.

  • Les deux leaders mondiaux, Microsoft avec Office365 et Google, avec GSuite, qui concentrent respectivement 13% des domaines / 21% des adresses email, et 8% des domaines / 7% des adresses email.

A noter qu’Office365 impose d’utiliser un nom d’hôte MX spécifique par domaine, constitué du nom de domaine dont les ‘.’ sont remplacés par des ‘-‘, suffixé par ‘protection.outlook.com’, tandis que sur GSuite, tous les domaines ont exactement les mêmes enregistrements MX que ceux de gmail.com (aspx….). Les MX spécifiques Office 365 renvoient vers les mêmes plages d’adresses IP qu’outlook.com…. ce qui gonfle artificiellement le nombre de MX, le vrai chiffre se situant plutôt autour des 170k MX uniques.

Une analyse un peu plus détaillée, prenant en compte d’autres indicateurs (cf. infra), permet d’identifier d’une part 150 hébergeurs, qui concentrent à eux seuls près de 80% des domaines, représentant 70% du total des adresses email, et d’autre part, une cinquantaine de solutions OnPremise d’importance, hébergeant seulement quelques centaines de domaines, mais plus de 9% du total des emails.

C’est typiquement le cas des banques, avec par exemple la BNP (80 domaines / 8200 emails), la SocGen (20 domaines / 6300 emails), ou encore le Credit Agricole (140 domaines / 13000 emails), mais aussi les grands comptes, tels que SaintGobain (75 domaines / 9800 emails), Renault (35 domaines / 8400 emails), ou EDF (15 domaines / 7800 emails).

L’inégalité de la répartition entre les hébergeurs à faible nombre de domaines mais grand nombre d’adresses email et les hébergeurs à nombreux domaines mais faible nombre d’adresses email s’explique par la typologie des titulaires des domaines, les TPEs s’accommodant des services de messagerie mutualisée fournis par leur Registrar, les grandes entreprises s’orientant plutôt vers des solutions sécurisées internalisées ou externalisées.

Au cumul, la définition de 200 profils de routage permet de couvrir avec précision la délivrabilité sur 80% des domaines et 80% des adresses email.

Une partie des 20% restants va pouvoir être qualifiée par analyse des autres sources.
 

MxM - Distribution.jpg
MxM - DNS Records.JPG

III.2 Zone DNS

En dehors des MX, le DNS peut fournir également de nombreux autres enregistrements, tels que DNSKEY, RRSIG, NSEC3PARAM, SPF, DMARC ou encore MTA-STS/SMTP-TLS, qui témoignent du niveau de protection et sécurité du domaine.

C’est ainsi qu’on peut constater que DNSSEC n’est implémenté que pour 9% des domaines, et que seuls 5% sont protégés de requêtes de type ‘ANY’ (RFC8482).

Quant aux enregistrements MTA-STS et SMTP-TLS, ils ne sont déclarés que par 200 domaines, principalement les webmails US et quelques grands comptes… et dont 4 comportent au moins une erreur d’implémentation.

On remarquera également le relativement faible niveau d’adoption d’IPv6, avec 11,5% d’enregistrement AAAA.

III.3 SPF

SPF est en revanche implémenté dans 64% des zones DNS, même si ce chiffre est un peu en trompe l’oeil : en effet, les zones par défaut d’OVH, de Gandi et d’Infomaniak, sur lesquels sont hébergés au cumul 177k domaines, incluent respectivement les enregistrements standards « v=spf1 include:mx.ovh.com ~all », « v=spf1 include:_mailcust.gandi.net ?all » et « v=spf1 include:spf.infomaniak.ch ?all ».

En définitive, le taux d’adoption « proactif » avoisine plutôt les 47%, dont un tiers seulement est configuré en FAIL.

Les enregistrements SPF révèlent aussi indirectement les services SaaS utilisées en corrélation avec le domaine, qu’il s’agisse de plateformes d’email marketing ou de solutions de sécurité.

Cas particuliers :

  • 7500 domaines publient encore un enregistrement de type SPF obsolète (valeur 99), parmi lesquels encore 1500 n’ont pas migré vers le standard 2016 en type TXT « v=spf1… »

  • Moins de 600 domaines utilisent les derniers raffinements de la syntaxe SPF, avec l’utilisation des mot clefs « exists:%{i} » et « include:%{i} »

MxM - TXT Records.jpg

III.4 DMARC

Le standard DMARC est significativement moins déployé que le SPF, avec seulement 5,8% de taux de renseignement.

 

Les stratégies paramétrées sont tout aussi timides que le déploiement, avec 75% des actions fixées à ‘none’, 12% à ‘reject’ et 13% à ‘quarantine’, et dans ce dernier cas, lorsqu’un pourcentage est précisé (« pct= »), 99% des valeurs sont à 100%.

 

Seulement 33k de paramètres « rua » et 21k de « ruf » sont déclarés, en d’autres termes, 43% des domaines qui implémentent DMARC ne reçoivent pas les rapports d’analyse agrégés et 64% ne reçoivent pas les rapports d’investigation.

 

A noter un nombre significatifs d’erreurs de syntaxe présents dans de nombreux enregistrements, de la simple coquille (« p=rejet » au lieu de « p=reject ») au non respect des délimiteurs de syntaxe ‘ ; ’ entre les champs (confondu avec espace ‘  ‘ ou encore ‘ : ’).

IV. SMTP

Les 256k hôtes MX uniques se résolvent en 95k adresses IP uniques. La connexion SMTP à ces IPs permet de remonter les fonctionnalités supportées par le serveur de messagerie distant, et le cas échéant, d’effectuer un STARTTLS afin d’en vérifier les paramètres SSL.

 

Plus de 20% Certificats ne matchent pas avec leur nom d’hôte MX, et 11% sont autosignés. La majorité des Certificats expirés sont issus de Let’s Encrypt, dont la version gratuite produit des Certificats d’une durée de validité de 90 jours.

 

En principe, les certificats serveurs doivent matcher avec le nom d’hôte contacté (contenu dans l’enregistrement MX du DNS), en rappelant qu’il revient au client de décider ou non de la poursuite de la connexion en cas de mismatch du Certificat attendu (champ CN), et en sachant que, pour des raisons de sécurité, l’usage des wildcards est de plus en plus déconseillé.

 

Le seul cas ou le serveur peut être amené à refuser la connexion si elle n’est pas sécurisée est via l’implémentation des protocoles MTA-STS/SMTP-TLS en mode « enforce », et qui concerne 130 des 200 serveurs identifiés qui supportent ce standard. C’est pourquoi autant plus de 90% des serveurs de messagerie supportent le chiffrement, autant la généralisation des transmissions d’email authentifiées n’est pas pour demain.

 

Par ailleurs l’empreinte constituée par le support éventuel des 50 extensions SMTP définies par la RFC 1869, ainsi que l’analyse du banner permet de déterminer le type de serveur de messagerie avec une fiabilité acceptable dans 70% des cas.

MxM - SMTP Extensions.jpg

V. NIC

Un organisme central (et mondial), l’IANA (Internet Assigned Numbers Authority), attribue des blocs racines /8 (16 millions d’IP) à 5 RIRs (Regional Internet Registry) continentaux :

  • RIPE NCC (Réseaux IP Européens - Network Coordination Centre) : Europe + Moyen-Orient

  • APNIC (Asia Pacific Network Information Center, créé en 1993) : Asie + Pacifique

  • ARIN (American Registry for Internet Numbers, créé en 1997) : Amérique du Nord

  • LACNIC (Latin America and Caribbean Network Information Center, créé en 1999) : Amérique Latine + Caraïbes

  • AfriNIC (African Network Information Center, créé en 2005) : Afrique

 

Les RIRs ont pour fonction d’attribuer à leur tour les blocs reçus en sous-bloc aux LIRs (Local Internet Registries), typiquement des FAIs. Nb : cette délégation peut, selon les RIRs, s’effectuer via l’intermédiaire d’un NIR (National Internet Registry).

 

Enfin, les LIRs peuvent attribuer des sous-blocs d’une taille maximale /24 (256 adresses) à leurs clients finaux, cas d’espèce de la location de plages d’IP dédiées chez OVH.

 

Chaque RIR dispose de sa propre interface de query, et de ses formats et structures de données en réponse, il est tout de même possible de normaliser les titulaires des blocs d’IP, leur pays d’origine, et la taille des plages.

 

Cela permet par exemple d’identifier que Barracuda, TrendMicro et Sophos hébergent une partie de leurs services sur EC2, tandis que MailinBlack utilise des IPs Microsoft.

 

De la même façon, on peut observer qu’OVH existe ET en tant que Registrar et à ce titre, fournisseur d’une solution de messagerie standard, ET en tant qu’hébergeur, loueur de serveurs dédiés sur lesquels peuvent être installés n’importe quel serveur de messagerie OnPremise (PostFix, Sendmail, Exim,), ET enfin, en tant que Service Provider avec sa solution de fourniture d’un Microsoft Exchange en mode Saas « Hosted Exchange », les trois volets de l’activité étant répartis sur des réseaux spécifiques.

 

Subsidiairement, cela permet également l’identification de plages d’adresses IP sur lesquelles il peut être préjudiciable de router (ex : 103.224.2XX.XXX/24).

MxM - B2B Servers.JPG

En conclusion, MxM permet un haut niveau d’automatisation de la gestion de la délivrabilité B2B, une fois bien sûr les 200 principaux hébergeurs référencés, et moins de 30 profils de serveurs de messagerie OnPremise suffisent à couvrir 90% des messages de bounce connus à ce jour.

 

De plus, les fonctions de monitoring permettent de maintenir le référentiel de domaines à jour en continu, même en l’absence de routage de campagnes, ce qui offre une vision temps réel de l’état des principales infrastructures de messagerie du marché (et permet par exemple l’identification rapide d’une panne de Cloud ou de DataCenter…).

 

Comme indiqué en introduction, l’échantillon des données depuis lequel sont tirées ces statistiques n’est pas forcément représentatif du marché dans sa globalité, aussi, un même traitement sur une toute autre base pourrait donner des résultats sensiblement différents.