How to anticipate, detect and solve email deliverability problems?

I might have, titled this article: "For a holistic approach to email deliverability!" (like natural medicine)... but I didn't have the courage 😉 So I didn't.

The email deliverability is often misunderstood, most of the time, deliverability problems are solved in the form of small corrective actions... which often lead to even more complex incidents to solve. Deliverability is therefore to be taken in its entirety. Any problem solving, even the smallest one, must lead to structural corrective actions and not conjunctural ones.

In an ideal world, there would be no need for deliverability monitoring. If all email senders followed good practices, there would be no practices, there would be no need. Unfortunately, there are not only quality senders, and spam filters must absolutely protect themselves from some of some of them.

So even senders with good practices, who respect their recipients, can be caught for some details on which they look too much like spammers.

With the principle of reputation in deliverabilityISPs and Webmails try to detect whether a message is desired by the user, or whether it is irritating for the recipient. To do so, they analyze a multitude of signals that will change this reputation, either positively or negatively. It is on these signals that it is necessary to work so that they are systematically good.

In the following lines, we will not only put ourselves in the position of the advertiser, but also in the more complete position of the sending infrastructure, whether it be that of an advertiser or of a of the sending infrastructure, whether it be that of an advertiser (who has internalized his (which would have internalized its routing or which manages multiple internal customers) or a marketing platform that needs to maintain its global reputation and satisfy/help its customers in their deliverability.

Anticiper et limiter les risques d’incidents de délivrabilité

The best way to solve an incident is not to have one! And to make this possible, you will have to set up mechanisms to deliverability monitoring (and blocking) systems that are more severe than the spam filters and reputation engines of ISPs and webmails. The idea is to eradicate all practices and signals that would resemble those of a spammer.

Detecting declines in engagement

Engagement is one of the most used signs by American webmails to detect if a campaign is wanted or not by its recipients. If your open rates or click rates are declining (on all your mailings or on a particular category) you should ask yourself questions and rectify the situation. This is true from a deliverability point of view, but obviously also from a marketing point of view.

Understanding when you are close to critical thresholds

In addition to engagement, there are other overall statistics that should be observed. This is primarily the case for the spam complaint rate (see our article on feedback loops), but also the hard bounce rate. Depending on the deliverability monitoring tools you may also want to check the volumes of spamtraps affected.

It is also interesting to follow the reputation figures delivered by the different email box providers (SignalSpam, SNDS from Microsoft), Gmail Postmaster Tools, ...).

Remove any spam-like practices

Some tools allow you to test your messages and give you feedback on any blocking points "BEFORE" the message is sent. If email content is less important to spam filters than it used to be (well, actually, thedeliverability content analysis has radically evolved, but that's another story). These practices can be introduced by a modification to your email template, an error in the selected sending profile, etc. Historically, this point was treated with a "spam" score, often based on the venerable "SpamAssassin".

Limit technical misconfigurations

Normally, a deliverability infrastructure should be stable and not change "by itself". However, technology, like people, is sometimes capricious. An IP that disappears, a tracking that jumps, a SPF registration that moves, a badly signed email, ... all these elements must be analyzed regularly so that there are no surprises at the time of sending.

Be able to preventively block problematic email flows problematic

This last point is mainly in the hands of the person or company in charge of the person or company in charge of the deliverability infrastructure. deliverability infrastructure. If any of the items listed above become problematic, there should "ALWAYS" be an automatic blocking mechanism after a certain threshold. This blocking mechanism will prevent further degradation of the signals in the eyes of ISPs and Webmails. Furthermore, the blocking should be as fine-grained as possible possible in order to stop only the type of campaign and the sending profile(s) at risk. of sending at risk.

Détecter les incidents de délivrabilité

If, despite your desire to limit the risk of delivery incidents upstream of deliverability incidents, you have still gone to the wall, it is crucial to check what type of to check what type of deliverability incident you are facing. confronted with. This will help you later on to identify the origin of the problem and to solve it.

We can define 4 types of deliverability incidents.

Poor categorization of emails

This is probably the "lightest" of the problems deliverability problems. If Gmail had already opened the ball many years ago with its "Promotions", "Notifications" tabs, ... All the players have followed and we now find categorization everywhere. Obviously, when a transactional email ends up in the Gmail's promo box, this can cause some problems. It is therefore important to to detect categorization problems, either with dedicated tools or with the feedback from the or with customer service feedback.

Spamming of emails

This is probably the most common deliverability incident. most common delivery issue. While your emails seem to be correct, they arrive in a spam box. It is important to remember that an email delivered in spam is "delivered"! It will not generate any error message such as type error message, this is not information that will be directly present in your statistical reports. There are many reasons for this, but they are often related to your reputation level. The easiest way to detect spamming is to check the opening rates destination, if a destination (Outlook.com for example) goes from 22% example) goes from 22% of opening to 10% of opening while the other destinations remain stable, it is probably that your emails are in spam at Outlook.com.

The other technique consists in using seedlists via dedicated solutions. These solutions provide you with several hundred addresses on most of the messaging systems on the market. You integrate these email addresses in your routing tool, and at regular intervals you shoot campaigns to these addresses. The inbox monitoring platform will automatically read all the addresses to check if the emails have arrived in Inbox... or not. You will then have access to a statistical report allowing you to check what percentage of emails are delivered to spam or inboxes for each destination.

Be able to detect blockages at entry

An "inbound" block is a block that occurs at the SMTP server level. The message is blocked and will return (in theory) an SMTP error message (block bounce). (in theory) an SMTP error message (block bounce). You should therefore see a "massive" increase in bounces for a "of bounces for one or more destinations. The other (complementary) solution is to use a seedlist and Inbox Monitoring, in which case these emails will be marked as "bounced". In this case, these emails will be marked as "missing".

This is a much more serious level of blocking than spamming and will likely require even more remedial action.

Detecting blacklisting

Fourth stage of the deliverability incident. Your IPs or domains may be listed by blacklistsThis is often because you have hit a number of spamtraps. Here, there is only one way of quick detection, it is to pass your IPs and your domains in a verification tool of all the blacklists of the market. Be careful, some blacklists are very important and will have a major impact on your deliverability while others are almost not used. So set up an automatic alert system.

Détecter les origines des problèmes de délivrabilité

In the event of a proven deliverability incident, you must you must act quickly to block the problematic email flow on your side, but also carry out an investigation to identify the source(s) of of the incidents. These two actions... it's a bit of a chicken and egg situation. You must urgently stop the problematic email flow... and urgently do the investigative work to see what those flows are and why they are problematic.

Punctual blocking

In case of punctual blocking (from one day to overnight, without warning, some emails are blocked or delivered as spam). In this case, your survey will work from one to the other. You will probably detect a drop in performance on a particular day in your performance on a particular day in your dashboards, keep digging to find the name of the to find the name of the campaign, keep digging to find the problematic message the problematic message and or target, and the problematic destination. problematic destination.

Based on this, you can probably see what type of problem you are exposed to and what triggered the incident. the incident.

Multi-blocking and structural concerns

In this case, you are regularly exposed to performance drops, back and forth between the inbox and the spam box, waves of block bounces spam box, waves of block bounces, ... Here the investigation will have to dig into the history of the data management methods, check if there have been changes in the configuration configuration or infrastructure and to check the deployment of automated campaigns/scenarios. scenarios.

The investment to restore the situation will probably be more complex.

Améliorer les pratiques délivrabilité

Depending on the origin of the deliverability concern (see the investigation), it will obviously be necessary to take a "structural" corrective action. "structural" corrective action. The objective should never be to re-deliver the emails as quickly as possible, but to correct the emails as quickly as possible, but to correct once and for all the the origin of the incident through a configuration change or a change of practice. By providing temporary solutions, we expose ourselves to new deliverability blockages that will probably be increasingly difficult to resolve. to resolve.

Several types of good practices can be distinguished practices:

• Deliverability Infrastructure: IP usage, domain usage, authentication, DMARC, ...
• Data Quality: Methods of address recruitment, inactive persons managementcleaning of bounces, ...
• Email content: Brand identification elements, image hosting and link tracking domains, code quality, ...
• Targeting and marketing pressure: targeting and personalization strategy, sending frequencies, staggered sending, ...
• Recipient Engagement: performance optimization strategy (test plan), message ergonomics, ...

Avoir les bonnes informations à communiquer aux ISPs/Blacklists sur votre incident de délivrabilité

It is sometimes necessary to contact ISPs and blacklists to request a blacklists in order to ask for an unblocking of the situation (or at least for information). However, if your problem is at the level of reputation, it may be better to wait for your corrective actions to take effect. to take effect.

If you feel the need to get in touch with them you will have to communicate the information you have previously collected:

• How did you detect the problem?
• What was the source of the problem (you are always the culprit, not the ISP or the spam filter)!
• What you have put in place structurally to ensure that this never happens again!
• Ask for the release

Bonus : Comment documenter un incident de délivrabilité pour votre consultant ?

Quand un incident de délivrabilité survient, le réflexe est souvent d’alerter son consultant… mais sans toujours fournir les bons éléments pour qu’il puisse agir rapidement et efficacement.

Résultat ? Des échanges flous, des délais d’investigation prolongés, et un risque accru que l’incident s’aggrave avant d’être traité.

Pour gagner du temps, il suffit d’avoir un doc clef en main qui permettra de réunir tous les éléments dont vous disposez sur le problème de délivrabilité afin de le communiquer à votre consultant délivrabilité..

Here are the 6 dimensions clés à documenter :

1. Comment l’incident a-t-il été détecté ?

Commencez par identifier les signaux d’alerte :

• Baisse anormale des taux d’ouverture
• Augmentation soudaine des bounces
• Retours d’utilisateurs ou du support client
• Taux de plaintes inhabituellement élevé

Chaque symptôme est une pièce du puzzle. Plus ils sont précis, plus l’analyse gagne en efficacité.

2. Quelle est la nature du problème ?

Distinguez la forme exacte que prend l’incident :

• Les emails tombent en spam ?
• Les envois sont bloqués (hard bounces massifs) ?
• L’infrastructure (IP, domaine) a été ajoutée à une blocklist publique ?

Comprendre le type d’impact oriente immédiatement les premiers gestes à poser.

3. Quand les conséquences ont-elles commencé ?

Là encore, la précision est clé :

• À quel moment exact (date / heure) les indicateurs ont-ils changé ?
• Quelles campagnes ou flux ont été affectés ?
• Peut-on faire un lien avec une modification récente ou une action spécifique ?

Le croisement temporel est souvent révélateur de l’origine de l’incident.

4. Quels changements ont précédé l’incident ?

Listez tout changement survenu dans les heures ou jours qui précèdent :

• Import massif de nouveaux contacts ?
• Modification des règles de segmentation ?
• Mise en production de nouveaux scénarios automatisés ?
• Changements techniques : nouvel expéditeur, nouvelle IP, domaine de tracking ?
• Campagne atypique ou ciblage inhabituel ?

Chaque changement est une hypothèse à tester.

5. Quel est le périmètre technique touché ?

Spécifiez précisément les éléments concernés :

• Quel(s) domaine(s) d’envoi ?
• Quelle(s) IP(s) ?
• Quelles typologies de campagnes (newsletter, trigger, marketing automation…) ?
• Quelles marques ou entités ?
• Quels FAI/webmails posent problème (Gmail, Outlook, Orange, etc.) ?

C’est ce qui permettra de prioriser l’analyse et d’orienter les tests.

6. Quelles actions ont déjà été entreprises ?

Enfin, précisez ce qui a été tenté pour limiter l’impact :

• Arrêt temporaire de certaines campagnes ?
• Contact avec les abuse desks des FAI concernés ?
• Réduction des volumes ?
• Nettoyage des segments peu engagés ?
• Ajout de filtres ou de règles dans vos outils d’envoi ?

Un incident de délivrabilité bien documenté, c’est un diagnostic plus rapide, une remédiation plus efficace… et moins de stress pour tout le monde.

Conclusion

As is often the case in life... prevention is better than cure. But even with all the good will in the world, it is sometimes difficult to succeed. It is therefore necessary to be prepared, to acquire the right reflexes, the right tools and to be well surrounded!

Psssst : Discover the replay of our live on the 10 questions we've all asked ourselves about deliverability.