Le jour où Microsoft a bloqué tout notre sous-réseau

Vous avez fait tout ce qu'on attend d'un expéditeur sérieux. Votre domaine indique quels serveurs ont le droit d'envoyer des courriers en son nom. Chaque message est signé. Votre serveur se présente sous une identité cohérente avec celle publiée dans le DNS.

En clair : on sait qui vous êtes, et on peut le vérifier.

Et malgré cela, vos messages n'arrivent pas chez Outlook.

Pas dans les indésirables. Pas avec quelques minutes de retard. Ils sont refusés avant même d'être acceptés.

C'est ce qui nous est arrivé les 7 et 8 août 2026 sur l'infrastructure d'envoi de Spore. À chaque tentative vers une adresse Microsoft, le même code revenait : S3140.

Ce que l'authentification garantit — et ce qu'elle ne garantit pas

Dès qu'on commence à envoyer un peu sérieusement du courrier électronique, trois sigles reviennent partout : SPF, DKIM et DMARC.

Autant les poser clairement.

• —SPF indique, dans le DNS du domaine, quels serveurs sont autorisés à envoyer des messages en son nom.
• —DKIM ajoute une signature cryptographique à chaque message. Le serveur qui le reçoit peut vérifier cette signature grâce à une clé publique publiée dans le DNS.
• —DMARC définit la politique à appliquer lorsque les contrôles précédents échouent ou ne correspondent pas au domaine attendu.

Ces mécanismes permettent de répondre à une question essentielle : l'expéditeur est-il bien celui qu'il prétend être ?

Mais ils ne répondent pas à une autre question, tout aussi importante : est-ce que son courrier mérite d'être accepté ?

Un spammeur peut parfaitement avoir un SPF propre, une signature DKIM valide et une politique DMARC correcte.

L'authentification ne prouve pas qu'un message est souhaité. Elle prouve seulement que son origine peut être vérifiée.

L'authentification est un préalable, pas un laissez-passer. Elle permet de vous identifier, donc de vous tenir responsable.

C'est ensuite que commence le vrai travail des filtres.

Google, Yahoo ou Microsoft cherchent à savoir s'ils peuvent faire confiance à ce que vous envoyez. Pour cela, ils observent l'adresse IP d'origine, son ancienneté, le volume de messages envoyé, les plaintes reçues, les erreurs de livraison et parfois la réputation de toute la plage réseau à laquelle elle appartient.

Le problème du voisinage

Notre adresse IP n'avait pas forcément fait quoi que ce soit de répréhensible.

Le problème venait de son voisinage.

Une adresse IP n'est jamais vraiment isolée. Elle appartient à une plage détenue par un hébergeur et utilisée par de nombreux autres clients.

Quand un opérateur estime qu'une partie de cette plage a été trop souvent utilisée pour envoyer du courrier indésirable, il peut décider de se méfier de l'ensemble.

Vous pouvez donc avoir une adresse parfaitement propre et subir malgré tout les conséquences de ce qu'ont fait les autres.

La logique se comprend.

Si les filtres ne sanctionnaient qu'une adresse précise, il suffirait à un expéditeur malveillant d'en changer. Chez la plupart des hébergeurs, cela prend quelques minutes.

Bloquer une plage entière rend ce jeu plus coûteux.

Mais cette méthode a un effet secondaire évident : elle pénalise aussi les expéditeurs honnêtes qui ont simplement eu le malheur de s'installer au mauvais endroit.

Ils n'ont rien fait de particulier, n'ont pratiquement aucun moyen de connaître la réputation de leur voisinage avant d'utiliser l'adresse, et découvrent le problème une fois le service en production.

Trois opérateurs, trois manières de juger

On met souvent Google, Yahoo et Microsoft dans le même panier. En pratique, leurs méthodes diffèrent beaucoup.

	Google	Yahoo	Microsoft
Signal particulièrement surveillé	Réputation générale et comportement des destinataires	Plaintes et réputation	Réputation de l'adresse IP et du réseau
Quand quelque chose va mal	Le message peut finir en spam	Limitation ou refus	Refus explicite avec un code
Outils proposés	Postmaster Tools	Boucle de rétroaction	SNDS et JMRP
Comment réagir	Corriger et attendre	Contacter le support	Demander une levée de blocage

Google est souvent le plus difficile à comprendre.

Le serveur peut accepter votre message sans erreur, puis le ranger dans les indésirables. Dans vos journaux, tout semble donc s'être bien passé.

Le message a été livré, techniquement.

Il n'a simplement presque aucune chance d'être lu.

Microsoft est plus brutal, mais aussi plus clair. Lorsque le message est refusé, le refus apparaît immédiatement dans les journaux, accompagné d'un code.

Au moins, vous savez qu'il y a un problème.

Le laissez-passer A38

Une fois le blocage compris, encore faut-il savoir à qui parler.

Et là, le problème technique devient un problème administratif.

Les moteurs de recherche renvoient très vite vers un portail Microsoft destiné aux problèmes de délivrabilité. Seulement, celui que l'on trouve le plus facilement concerne surtout les boîtes professionnelles.

Notre problème touchait les adresses grand public : Outlook.com et Hotmail.

Ce n'est pas le même service. Ce n'est pas le même formulaire.

Et rien ne vous l'explique vraiment.

Vous remplissez le mauvais formulaire, vous envoyez votre demande, et il ne se passe rien.

Personne ne vous répond pour vous dire que vous vous êtes trompé de porte.

Il faut comprendre qu'un autre guichet existe, puis réussir à le trouver.

Nous avons finalement déposé la demande auprès du support chargé de la délivrabilité des boîtes grand public, avec les adresses IP concernées, nos journaux d'envoi et les éléments de configuration.

Demande envoyée le 9 août. Réponse le lendemain :

Mitigated. These IP(s) have been unblocked but may be subject to low daily email limits until they have established a good reputation.

Autrement dit : les adresses ont été débloquées, mais Microsoft continuera à limiter leur volume tant qu'elles n'auront pas suffisamment d'historique.

La levée du blocage ne remet donc pas les compteurs à zéro.

Il faut ensuite envoyer progressivement, proprement, sans incident, jusqu'à ce que l'adresse inspire davantage confiance.

Et la décision ne se propage pas forcément immédiatement à toute l'infrastructure Microsoft. Pendant plusieurs heures, voire davantage, certains serveurs peuvent encore refuser les messages.

Ce que trois jours de blocage coûtent vraiment

Entre le premier refus et la levée du blocage, trois jours se sont écoulés.

Le plus frustrant, c'est que nous n'avons pratiquement rien eu à corriger.

La configuration était correcte depuis le début. SPF, DKIM, DMARC, reverse DNS : tout était conforme. Vérifier tout cela a pris environ une heure.

Le reste du temps a été consacré à comprendre le problème et à trouver la bonne personne.

Il a fallu :

• —comprendre qu'un code de rejet inconnu ne désignait pas une erreur de configuration, mais un problème de réputation ;
• —éliminer les différentes pistes DNS une par une ;
• —comprendre que le premier formulaire trouvé n'était pas le bon ;
• —retrouver le service qui s'occupe réellement des boîtes Outlook.com et Hotmail ;
• —réunir les adresses IP, les journaux horodatés et les messages d’erreur bruts ;
• —attendre la réponse, puis attendre encore que le déblocage se propage.

Aucune fonctionnalité n'est sortie de ces heures de travail.

Rien n'a été amélioré pour les utilisateurs.

Nous avons simplement consacré trois jours à rétablir quelque chose qui aurait dû fonctionner dès le départ.

C'est exactement le genre de travail qu'on ne veut pas voir surgir au milieu du développement d'un produit.

Ce que nous avons changé depuis

À ce moment-là, une seule adresse IP portait l'essentiel de notre trafic.

Quand elle a été bloquée chez Microsoft, tous les messages destinés à Microsoft sont donc tombés avec elle, alors même que 84 autres messages continuaient à être distribués normalement chez les autres opérateurs.

Un problème sur une seule adresse pouvait avoir des conséquences pour tous nos clients.

Nous avons changé cela.

Les messages sont désormais répartis selon leur nature. Le courrier strictement transactionnel ne partage plus la même adresse que les envois plus volumineux. Un nouveau compte n'est pas immédiatement mélangé au trafic déjà établi.

Le but est simple : éviter qu'un incident local se transforme en panne générale.

Nous avons également branché la remontée automatique des accusés de livraison et des rejets.

Lorsqu'un serveur distant refuse un message, l'information revient maintenant directement dans notre système.

Elle ne termine plus dans une boîte électronique que personne ne pense à consulter.

Et surtout, nous avons appris quelque chose qu'aucune documentation technique ne vous donne vraiment : comment fonctionne la partie administrative de ces grands opérateurs.

Nous savons maintenant où frapper, quoi envoyer et quels éléments préparer.

La prochaine fois, le diagnostic ne prendra pas trois jours.

C'est aussi cela, le service que nous proposons.

Nous exploitons nous-mêmes l'infrastructure d'envoi : les serveurs, les adresses IP, les signatures, les journaux.

Et avec cette infrastructure viennent les problèmes de réputation, les demandes de déblocage et les échanges avec les opérateurs.

Nous les prenons en charge.

La réputation d'un serveur ne se construit d'ailleurs pas uniquement au moment où un problème apparaît. Elle s'entretient à chaque message envoyé.

Cela passe par des domaines vérifiés, des signatures correctes, le retrait automatique des adresses qui n'existent plus, l'analyse des rejets et la conservation d'un historique précis de chaque tentative.

Nos serveurs sont en France. Vos domaines restent les vôtres. Et nous facturons les messages envoyés, pas le nombre de contacts stockés dans une base.

Un expéditeur qui démarre seul rencontre aussi un autre problème : il n'a presque aucun historique.

Avec quelques dizaines de messages par jour, une nouvelle adresse reste longtemps difficile à évaluer pour les filtres. Il faut du trafic régulier et un comportement stable pour construire progressivement une bonne réputation.

C'est là que l'histoire se retourne.

Un client de Spore n'arrive pas sur une adresse qui vient d'être créée le matin même.

Il profite d'une infrastructure déjà en activité, entretenue au quotidien et surveillée.

Chaque message correctement délivré contribue à entretenir cette réputation commune.

Vous, pendant ce temps, vous envoyez votre message.

Une requête.

Et il part.