AAL - Sept 2020 - 5 mn de lecture
B2B deliverability: heterogeneous MX handling
While it is still a question of delivering emails to the inbox, the rules and issues of B2B and B2C deliverability (B2C = webmails US Gmail / Outlook / Yahoo + local ISP) differ in many technical aspects.
First of all, by the messaging infrastructures and anti-spam solutions implemented (Reputation-Based vs. Content-Based), but also by the population of domain names represented.
Indeed, B2C domain names number in the hundreds (with their associated aliases, for example outlook.com = live.com = msn.com = hotmail.com), B2B domain names in millions.
Next, B2C antispam solutions are mainly based on reputation filters with Feedback Loop (ex: Return Path), while B2B messaging systems are based on a wide variety of third-party solutions, each with their specificities: heuristic content filters, public blacklists, Gray-Listing, Challenge-Response, Bot clickers.
However, B2B and B2C deliverability issues come together with the advent of the two main cloud email hosting solutions, Office365 and G Suite, which alone represent more than 50% of hosted B2B domains, including a majority of SMBs (out of a sample of 1M of FR domains).
Below is a non-exhaustive comparative table of the characteristics of B2C and B2B MX:
However, the challenges of B2B deliverability remain crucial, particularly in the context of marketing automation solutions, where the relevance of targeting and the efficiency of routing scenarios can be reduced to nothing, simply because emails never reach the inbox.
The difficulty lies above all in the disparity of e-mail hosting solutions and anti-spam technologies deployed there, which each require the adjustment of multiple specific deliverability parameters, among which, SMTP and bounces back messages qualification, definition of quotas for sending warmup, nominal and restricted.
The inventory of the main B2B messaging hosting solutions (several dozen players per country) each using their own dictionary, to differentiate Hard Bounce addresses from blacklisting messages for example, and sensitive to technical sending parameters, such as :
the number of simultaneous threads per [IP, MX]
the number of messages per SMTP session
the volumes of messages accepted per hour, per day, per IP and per sender domain
can represent months / man of development as well as a continuous watch because these parameters change on a daily basis.
Domain groups and aliases
In the same way as in B2C, where several domains are associated with a group of unique MXs (for example, yahoo.com, rocketmail.com and ymail.com have the same DNS records of type MX, in this case "mta * .am0.yahoodns.net ”, these hosts themselves having type A records pointing to common IP address ranges, 67.195. *. *, 98.136. *. *,…), most of the B2B domains are hosted by third party solutions.
For example, the michelin.com, danone.com or schneider-electric.com messaging services share the same DNS MX records, in this case “cluster * .eu.messagelabs.com”, corresponding to the secure hosting service in Broadcom's Cloud, while axa.com, lesechos.fr, pfizer.com, point to “mx * - *. gslb.pphosted.com”, hosting service from the publisher Proofpoint.
Knowing which messaging system you are talking to before even initiating an SMTP session is essential, in order to fulfil their parameters and sending quotas, but also to correctly interpret and understand their SMTP return messages.
In other words, if domains A and B have the same MX records, which point to a domain group Z that accepts only one connection at a time from the same IP, if domains A and B are not referenced as aliases, sending @A and @B emails simultaneously will lead to the refusal by domain Z of one of the two connections. On the contrary, if they are correctly referenced in the system as an alias of group Z, with a single instantaneous thread as sending parameter, the two emails will be transmitted one after the other.
While professional MTAs have sending capacities about 1000 emails per second, it is impossible to initiate a DNS MX resolution for each email before taking a job, just to determine their eligibility for immediate sending.
For this reason, an alias database must be set up beforehand and kept up-to-date.
However, in a B2B context, this is only a presumption of aliases.
Indeed, the rate of change of B2B domain host (on the sample) is greater than 1% per month, while it is almost zero in B2C (excluding migrations and mergers, for example when aol.com is spent on the MX of yahoo.com in February 2018).
Moreover, even the validity of cached DNS records does not guarantee that the email will ultimately be delivered to the MX of the group in which the destination domain is referenced as an alias.
Indeed, many domains have heterogeneous cascading hosting solutions, for example camaieu.com, whose MX resolution gives:
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
and the IP resolution gives:
in.hes.trendmicro.eu Addresses: 22.214.171.124 126.96.36.199
mailhost2.camaieu.com Addresses: 188.8.131.52
camaieu-com.mail.protection.outlook.com Addresses: 184.108.40.206 220.127.116.11
In practice, depending on the priority defined by the "MX preference", if in.hes.trendmicro.eu cannot be contacted, for whatever reason, failure, maintenance or unavailability, it is mailhost2.camaieu.com which will be tried, then camaieu-com.mail.protection.outlook.com as a last resort. Three infrastructures, three messaging systems, three groups of anti-spam solutions, all totally different.
In this situation, when taking the job, the system will have fulfilled the parameters and sending quotas of the primary MX, assuming the success of the contact of its host (in.hes.trenmicro.eu in this case), but will have in the end dialogued with a completely different remote messaging system, camaieu-com.mail.protection.outlook.com for example, with 3 consequences:
the absence of compliance with the sending parameters on the @outlook domain group, with therefore the risk of exceeding quotas and therefore blocking
potential errors in the interpretation of SMTP return messages, with active email addresses illegitimately qualified as Hard Bounce for example
erroneous routing statistics, indicating emails delivered to the @trendmicro domain group instead of @outlook
For this reason, a precise B2B deliverability algorithm must take care of the possible failure of the presumption of the domain group host to which the email will be delivered, and make the appropriate real-time adjustments if necessary.
Below, by way of example, an extract of the algorithm implemented in Rafale:
The turnover in B2B messaging hosting requires real-time updating of alias databases. However, for the reasons mentioned above, any automatic update should only be carried out on the primary MX of the domain in question. In the example cited, it would indeed be improper to attach camaieu.com to the @outlook domain group instead of @trendmicro, only on the basis of a temporary error on the primary MXs.
The above algorithm has the virtue of not only automatically updating the aliases of domains already referenced, but also of dynamically attaching unknown domains to existing groups, by analyzing the pattern of the addresses of their hosts as well as directly by their corresponding IPs addresses.
NB: the dotted treatments on the diagram, which manage the MX contact strategies, will be the subject of a later article.
Therefore, strictly speaking, the routing statistics should not only be broken down by group of presumed domains, but by group of domains actually contacted.
Statistics before routing:
Statistics after routing, when the first two MXs could not be contacted:
In addition, the chaining of messages within the same SMTP session must be carried out with great care: sending emails to hotmail.com, live.com, outlook.com addresses is not a problem, but on B2B domains, only a chaining on email addresses of the same domain is not without risk: indeed, nothing guarantees that two alias domains of the same group have the same secondary MXs, as shown in the example below:
In this context, apart from the consequences already mentioned (non-compliance with the sending quotas of domain groups, errors in qualifying SMTP return messages, active email addresses mistakenly qualified as Hard Bounces, incorrect sending statistics), the more serious is undoubtedly that this sending can be perceived by the remote system as an attempt to exploit an open relay, which can lead to the listing of IPs and sending domains in public blacklists (SMTP Open Relay Scanner), of which it can be difficult to get out ...
Between the technical constraints linked to fulfil the post job-taking sending quotas during MX fallback, and the need for real-time updates of the alias databases, routing on B2B domains requires very particular care, whose negligence can significantly impact the mailings performance, and even damage the sender's global reputation.