Voici le post-mortem d’un incident de délivrabilité vers Microsoft qui s’est produit chez nous à l’été 2024.
À partir du 9 juillet 2024, nous constatons que des spams sont envoyés avec des expéditeurs en @evolix.net vers Microsoft. On s’en rend compte car on reçoit des bounces mais aussi quelques réponses/plaintes d’utilisateurs sur une adresse qui existait bien (la plupart des adresses en @evolix.net utilisées n’existait pas).
Exemple d’un spam envoyé depuis une IP thaïlandaise :
Date: Thu, 11 Jul 2024 12:28:20 +0000
From: Service Plus Affiliate <xxx@evolix.net>
To: xxx@outlook.com
CC: xxx@outlook.com
Subject: Quick Savings Alert: 50% OFF Home Warranty Sale!
Return-Path: xxx@evolix.net
Message-ID: <Exf6vWO9DBgkI4iTvmHxvEhaLe@phvpthsdmaszxsx.evolix.net>
Ces spams sont envoyés par des adresses IPs complètement extérieures à nous, on n’y prête pas tellement attention dans un premier temps.
Les spams se poursuivent sur le même modèle mais en utilisant des expéditeurs en @XXX.evolix.net où l’enregistrement DNS XXX.evolix.net n’existe même pas.
À partir du 17 juillet, plusieurs serveurs remontent des problèmes de délivrabilité vers Microsoft en passant en jaune/rouge dans SNDS.
À partir du 19 juillet, des clients nous remontent des problèmes de délivrabilité vers Microsoft : les emails envoyés passent systématiquement dans la boîte Spam voire disparaissent.
Nous relayons les emails impactés par notre service « Zedmel », ce qui corrige une partie des problèmes.
Mais de plus en plus de clients nous remontent ce même problème.
Le 31 juillet 2024, après pas mal d’analyses, on se rend compte que le problème se produit quand on a « evolix.net » visible dans l’email envoyé : HELO, reverse DNS, etc.
Les emails sont bien acceptés par les serveurs SMTP de Microsoft, mais ils obtiennent une « note tueuse » maximale : X-MS-Exchange-Organization-SCL: 9
Ces emails sont alors mis en Spam ou en Quarantaine (suivant la politique des administrateurs Office365) c’est-à-dire invisibles pour le destinataire.
En effet, quand un serveur dédié n’a pas personnalisé son reverse DNS ou sa configuration Postfix, nous mettons par défaut un enregistrement en XXX.evolix.net
Les serveurs avec des domaines personnalisés ne sont pas impactés.
On se lance donc dans la personnalisation des domaines des serveurs impactés.
Mais en parallèle, les vagues de spams se poursuivent avec @evolix.net ou @XXX.evolix.net
Le 5 août 2024, nous décidons de changer nos enregistrements SPF et DMARC pour « evolix.net«
pour « forcer » Microsoft à rejeter ces spams et faire cesser le problème à sa source.
Comme nous avons des centaines serveurs avec des adresses IPs de nombreux fournisseurs, et comme nous avons quelques process qui envoient des emails en @evolix.net nous avions mis un SPF qui autorise le monde entier :evolix.net. IN TXT "v=spf1 include:spf.protection.evolix.net +all"
C’est une grosse erreur : SPF est un mécanisme d’autorisation, il ne faut jamaisautoriser le monde entier… au pire il vaut mieux ne pas mettre de SPF.
On passe donc notre SPF ainsi :evolix.net. IN TXT "v=spf1 ptr include:spf.protection.evolix.net ~all"
(le champ « ptr » est déconseillé mais c’est notre seul moyen d’autoriser nos centaines de serveurs éparpillés partout, d’autres gros acteurs comme OVH l’utilisent aussi).
On passe aussi à une politique DMARC plus stricte pour avoir des rejets :"v=DMARC1;p=reject;sp=reject"
Le 12 août 2024, après avoir finalement fixé les quelques process susceptibles d’envoyer
en @evolix.net vers l’extérieur on passe même le SPF en -all pour être sûr que
Microsoft coupe bien le robinet des spams :evolix.net. IN TXT "v=spf1 ptr include:spf.protection.evolix.net -all"
Les vagues de spams se sont en fait arrêtées depuis quelques jours déjà.
Le 13 août, on prend contact avec l’équipe Postmaster de Microsoft pour expliquer tout ça et leur demander jusqu’à quand le blocage de « evolix.net » va durer.
On est habitué à avoir des réponses de leur part, mais dans ce cas nos demandes restent lettre morte.
On les relance à peu près toutes les semaines sans succès.
Pour mémoire, voici les « support request » toujours sans réponse à ce jour :
- Microsoft Support Request 7048679NNN : ouvert le 13 août, 7 relances (dernière le 23 septembre)
- Microsoft Support Request 7050730NNN : ouvert le 6 septembre, 2 relances (dernière le 23 septembre)
En parallèle, durant le mois d’août on s’assure que le problème est bien contourné partout.
Mais on aimerait tout de même que ce blocage chez Microsoft soit réglé.
Dans le merveilleux monde de la réputation des IPs et domaines au niveau SMTP, en général les blocages ne durent pas plus que 30 jours.
Vu que Microsoft ne nous répond pas, nous prenons notre mal en patience et espérons que le blocage disparaîtra début septembre au pire.
Le 6 septembre 2024, le problème est toujours présent et Microsoft ne nous répond toujours pas malgré nos relances.
Nous décidons de créer un compte Office365 (gratuit le 1er mois puis 15 EUR par mois) afin de contacter Microsoft en tant que « client ». Nous ouvrons donc le ticket 2409061410002NNN auprès du support niveau 1.
On obtient rapidement une réponse par email et même par téléphone, mais malheureusement cela reste du support de base. Même si l’interlocuteur maîtrise pas trop mal SPF/DKIM/DMARC il nous aiguille sur des fausses pistes.
Le 18 septembre 2024, on ouvre un nouveau ticket 2409181420002NNN auprès du support niveau 1.
On obtient également rapidement des réponses par email et par téléphone, mais cela reste basique.
On insiste en demandant que le problème soit escaladé. On nous demande de produire des rapports
à l’aide d’outils Microsoft assez fastidieux mais on ne lâche pas l’affaire.
On répond/relance le 19 septembre, le 23 septembre, le 25 septembre, le 30 septembre,
le 1er octobre, le 4 octobre, le 8 octobre, le 11 octobre…
On nous redemande de recréer des rapports déjà fournis, on nous demande poliment de patienter.
Le 15 octobre 2024 vers 16h, on reçoit un appel téléphonique de Microsoft :
« j’ai escaladé au support niveau 2, puis niveau 3, et ils me disent qu’ils ont enlevé le blocage, ça sera effectif dans 24h maximum »
Le 16 octobre au matin, le problème est toujours présent.
Mais à midi, on refait à nouveau un test avec Message-ID contenant « evolix.net » et effectivement : l’email aterrit en INBOX avec une « note tueuse » minimale : X-MS-Exchange-Organization-SCL: 1
On essaye évidemment d’en savoir plus : qu’est-ce qui a causé cela, mais on a toujours que le support niveau 1 en interlocuteur, et l’on comprend vite que l’on n’aura pas davantage d’informations.
Conclusion
Une grande partie des messageries est monopolisée par des gros acteurs qu’il est très difficile de contacter. Il faut éviter à tout prix d’avoir une raison de les contacter, donc il faut mettre des politiques SPF et DMARC strictes pour tous les domaines et sous-domaines que vous gérez. Si un domaine ou sous-domaine n’envoie pas d’email, il faut l’indiquer via SPF (« v=spf1 -all ») et annoncer une politique DMARC stricte (« v=DMARC1;p=reject;sp=reject »). Si vous avez des utilisateurs non aguéris ou des applis web publiques, il faut envisager de rate-limiter vos envois par exemple avec Postwd. Si vraiment besoin de les contacter pour un problème complexe, ouvrez un compte payant et contactez les en tant que client.
Les leçons qu’on en tire :
- il ne faut jamais utiliser +all dans un enregistrement SPF, au pire il est préférable de ne pas avoir de SPF…
- il faut mieux être radical avec des -all en SPF et reject en DMARC afin de détecter au niveau SMTP les problèmes et non pas avoir des emails mis en Spam ou pire « en quarantaine » (invisible pour l’utilisateur final)
- tout enregistrement DNS existant doit aussi avoir du SPF/DMARC, notamment pour indiquer qu’il n’est pas utilisé pour des emails
- analyser les entêtes de gros fournisseurs pour comprendre leurs vérifications antispams
- en dernier recours, il faut pouvoir changer les domaines / adresses IP utilisés pour l’envoi
- si un problème de réputation est toujours présent après 30 jours, c’est qu’il y a eu une opération manuelle
- propager la bonne parole pour « run your own mail server » afin de limiter ces monopoles malsains sur la messagerie
