AAL  -  Sept 2020  -  5 mn de lecture

Délivrabilité B2B : gestion des MX hétérogènes

S'il est toujours question de remise d'emails en boite de réception, les problématiques de délivrabilité B2B et B2C (B2C = Webmails US Gmail/Outlook/Yahoo + ISP locaux) différent par de très nombreux aspects techniques.

D’abord de part les infrastructures de messagerie et des solutions antispam mises en œuvre (Reputation-Based vs. Content-Based), mais également par la population des noms de domaines représentés.

 

En effet, les noms de domaines B2C se chiffrent en centaines (avec leurs alias associés, par exemple outlook.com=live.com=msn.com=hotmail.com), les noms de domaines B2B en millions.

 

Ensuite, les solutions antispam B2C sont principalement basées sur des filtres de réputation avec Feedback Loop (ex : Return Path), tandis que les messageries B2B reposent sur une grande variété de solutions tierces, chacune avec leurs spécificités : filtres de contenu heuristiques, blacklistes publiques, Grey-Listing, Challenge-Response, Bot cliqueurs.

 

Les problématiques de délivrabilité B2B et B2C se rejoignent pourtant avec l’avènement des deux principales solutions d’hébergement de messagerie dans le Cloud, que sont Office365 et G Suite, qui représentent à elles-seules plus de 50% des domaines B2B hébergés, dont une majorité de TPE/PME (sur un échantillon d’1M de domaines FR).

 

Ci-dessous un tableau comparatif, non exhaustif, des caractéristiques des MX B2C et B2B :

Rafale.IO - B2C vs B2B MX .JPG

Cependant, les enjeux de la délivrabilité B2B restent cruciaux en particulier dans le contexte des solutions de marketing automation, dont la pertinence des ciblages et l’efficacité des scénarios de routage peuvent être réduits à néant, simplement parce que les emails n’arrivent pas en boite de réception.

 

La difficulté tient avant tout dans la disparité des solutions d’hébergement de messagerie et des technologies antispams qui y sont déployées, qui nécessitent chacune le réglage de multiples paramètres spécifiques de délivrabilité, parmi lesquels, qualification des message SMTP et bounces back, définition des quotas d’envoi de warmup, nominaux et restreints.

 

Le recensement des principales solutions d’hébergement de messagerie B2B (plusieurs dizaines d’acteurs par pays) utilisant chacune leur propre dictionnaire, pour différencier les adresses en Hard Bounce des blocages temporaires par exemple, et sensibles aux paramètres techniques d’envois, tels que :

  • le nombre de threads simultanés par [ IP , MX ]

  • le nombre de messages par session SMTP

  • les volumes de messages acceptés par heure, par jour, par IP et par domaine de sender

peut représenter des mois/homme de mise au point ainsi qu’une veille continue car ces paramètres évoluent au quotidien.

Groupes de domaines et alias

De la même façon qu’en B2C, où plusieurs domaines sont associés à un groupe de MX uniques (par exemple, yahoo.com, rocketmail.com et ymail.com ont les mêmes enregistrements DNS de type MX, en l’occurrence « mta*.am0.yahoodns.net », ces hôtes ayant eux même des enregistrements de type A pointant vers des plages d’adresses IP communes, 67.195.*.*, 98.136.*.*, …), il en est de même dans le B2B, avec les hébergeurs.

 

Par exemple, les messageries de michelin.com, danone.com ou encore schneider-electric.com partagent les mêmes enregistrements DNS MX, en l’occurrence « cluster*.eu.messagelabs.com », correspondant au service d’hébergement sécurisé dans le Cloud de Broadcom, tandis qu’axa.com, lesechos.fr, pfizer.com, pointent vers « mx*-*.gslb.pphosted.com », service d’hébergement de l’éditeur Proofpoint.

 

Savoir donc à quel système de messagerie on s’adresse avant même d’initier une session SMTP est essentiel, ce afin de respecter leurs paramètres et quotas d’envoi, mais également d’interpréter ensuite correctement leurs messages de retour.

 

En d’autres termes, si les domaines A et B ont les mêmes enregistrements MX, qui pointent vers un groupe de domaine Z qui n’accepte qu’une seule connexion à la fois d’une même IP, si les domaines A et B ne sont pas référencés en tant qu’alias, l’envoi simultanné d’emails @A et @B conduira au refus par le domaine Z d’une des deux connexions. Au contraire, s’ils sont bien référencés dans le système comme alias du groupe Z, avec comme paramètre d’envoi un seul thread instantanné, les deux emails seront transmis l’un après l’autre.

Les MTA professionnels ayant des capacités d’envoi de l’ordre de 1000 emails par seconde, il est impossible de lancer une résolution DNS MX pour chaque email avant prise de job, juste pour déterminer leur éligibilité à l’expédition immédiate.

Pour cette raison, une base d’alias doit être constituée préalablement et maintenue au fil de l’eau.

 

Cependant, dans un contexte B2B, il ne s’agit que d’une présomption d’alias.

 

En effet, le taux de changement d’hébergeur de domaines B2B (sur l’échantillon) est supérieur à 1% par mois, alors qu’il est quasi nul en B2C (hors migrations et fusions, par exemple lorsqu’ aol.com est passé sur les MX de yahoo.com en février 2018).

 

Par ailleurs, même la validité des enregistrements DNS en cache ne garantit pas qu’au final l’email sera délivré sur le MX du groupe dans lequel le domaine de destination est référencé en tant qu’alias.

MX hétérogènes

 

En effet, nombre de domaines disposent de solutions d’hébergement hétérogènes en cascade, par exemple camaieu.com, dont la résolution MX donne :

 

camaieu.com MX pref = 10, mail exchanger = in.hes.trendmicro.eu

camaieu.com MX pref = 20, mail exchanger = mailhost2.camaieu.com

camaieu.com MX pref = 30, mail exchanger = camaieu-com.mail.protection.outlook.com

et la résolution IP donne :

 

in.hes.trendmicro.eu                    Addresses: 52.58.62.238 52.58.62.239

mailhost2.camaieu.com                   Addresses: 92.175.139.23

camaieu-com.mail.protection.outlook.com Addresses: 104.47.8.36 104.47.9.36

 

Dans la pratique, selon la priorité définie par les « MX preference », si in.hes.trendmicro.eu ne peut être contacté, quelle qu’en soit la raison, panne, maintenance ou indisponibilité, c’est mailhost2.camaieu.com qui sera essayé, puis camaieu-com.mail.protection.outlook.com en dernier recours. Trois infrastructures, trois systèmes de messagerie, trois groupes de solutions antispam, tous totalement différents.

 

Dans cette situation, lors de la prise de job, le système aura respecté les paramètres et quotas d’envoi du MX primaire en présumant du succès du contact de son hôte (in.hes.trenmicro.eu en l’occurrence), mais aura dialogué au final avec un tout autre système de messagerie distant, camaieu-com.mail.protection.outlook.com par exemple, avec 3 conséquences :

  • l’absence de vérification des paramètres d’envoi sur le groupe de domaines @outlook, avec donc des risques de dépassement de quotas et donc de blocages

  • des erreurs potentielles d’interprétation de messages de retours SMTP, avec des adresses emails actives qualifiées illégitimement en Hard Bounce par exemple

  • des statistiques de routage erronées, indiquant des emails délivrés sur le groupe de domaines @trendmicro au lieu d’@outlook
     

Pour cette raison, un algorithme de délivrabilité B2B précis doit prendre en charge le possible échec de la présomption de l’hôte du groupe de domaine sur lequel l’email sera délivré, et effectuer le cas échéant les redressements adéquats en temps réel.

 

Ci-dessous, à titre d’exemple, un extrait de l’algorithme implémenté dans Rafale :

Rafale.IO - Heterogeneous MX handling.JP

Le turnover de l’hébergement des messageries B2B nécessite la mise à jour en temps réel des bases d’alias. Cependant, pour les raisons évoquées ci-dessus, une éventuelle mise à jour automatique ne doit s’effectuer que sur le MX primaire du domaine considéré. Dans l’exemple cité, il serait en effet impropre de rattacher camaieu.com au groupe de domaines @outlook au lieu de @trendmicro, seulement sur la base d’une erreur temporaire sur les MX principaux.

L’algorithme ci-dessus a la vertu de non seulement mettre à jour automatiquement les alias des domaines déjà référencés, mais aussi de rattacher dynamiquement les domaines inconnus aux groupes existants, par analyse du pattern des adresses de leurs hôtes ainsi que directement par leurs adresses IP correspondantes.

NB : les traitements en pointillés sur le schéma, qui gèrent les stratégies de contact des MX, feront l’objet d’un article ultérieur.

Impacts opérationnels

C’est pourquoi, en toute rigueur, les statistiques de routage ne doivent pas seulement être ventilées par groupe de domaines présumés, mais par groupe de domaines réellement contactés.

 

Statistiques avant routage :

Statistiques après routage, lorsque les deux premiers MX n'ont pu être contactés :

Par ailleurs, le chainage des messages au sein d’une même session SMTP doit être réalisé avec beaucoup de précautions : autant envoyer à la suite des emails à des adresses hotmail.com, live.com, outlook.com ne pose pas de problème particulier, autant sur des domaines B2B, seul un chainage sur des adresses email du même domaine n’est pas sans risque : en effet, rien de garantit que deux domaines alias d’un même groupe aient les mêmes MX secondaires, comme le montre l’exemple ci-dessous :

Dans ce contexte, en dehors des conséquences déjà évoquées (non respect des quotas d’envoi des groupes de domaine, erreurs de qualification de messages de retour SMTP, adresses emails actives qualifiées par erreur en Hard Bounces, statistiques d’envoi erronées), le plus grave est sans doute que cet envoi peut être perçu par le système distant comme une tentative d’exploitation de relai ouvert, ce qui peut conduire au référencement des IPs et domaines d’émission dans des blacklistes publiques (SMTP Open Relay Scanner), desquelles il peut être difficile de sortir…

Entre les contraintes techniques liées au respect des quotas d’envoi post prise de job lors de fallback MX, et la nécessité de mises à jour en temps réel des bases d’alias, le routage sur des domaines B2B demande un soin très particulier, dont la négligence peut impacter significativement la performance des envois, voire nuire à la réputation globale de l’émetteur.