Microsoft zet eigen antispam-model uit na vertraagde externe mail

Microsoft schakelt een eigen antispam-model uit dat vrijdag e-mail van en naar externe domeinen in Exchange Online vertraagde, een storing die het bedrijf in zijn beheercentrum bijhoudt onder incident EX1467029.

Voor een Nederlandse organisatie op Microsoft 365 is dit het type storing dat je pas merkt als een klant belt. Intern bleef alles werken: mail tussen collega's, Teams, de agenda. Wat haperde was precies het verkeer met de buitenwereld, dus offertes, orders, bevestigingen en facturen. Microsoft tekent daarbij aan dat de dienst berichten periodiek opnieuw probeert af te leveren, maar dat een afzender die na 24 tot 72 uur alsnog een foutmelding terugkrijgt de mail met de hand opnieuw moet sturen. Dat venster loopt bij dit incident door tot in het weekend.

Wat Microsoft in het beheercentrum meldde

De eerste melding stond er vrijdag om 08.19 uur Nederlandse tijd: Microsoft onderzocht klachten over vertraagde ontvangst van mail van externe domeinen, waarbij gebruikers met tussenpozen de foutmelding "Server busy" kregen over meerdere postvakken tegelijk. Een halfuur later stond de titel al ruimer, want ook uitgaande mail bleek geraakt.

Om 09.03 uur noemde het bedrijf voor het eerst zijn eigen spamfilter als factor. Om 09.59 uur werd dat concreet: de handhaving van een specifiek antispam-model draagt bij aan de impact voor een deel van het mailverkeer, schrijft Microsoft in de registratie die beheerders in het beheercentrum zien. Als eerste noodmaatregel zette het bedrijf de geraakte IP-adressen op een toegestane lijst, terwijl het parallel werkte aan het uitzetten van het model zelf.

Om 10.26 uur was dat uitzetten onderweg en zag Microsoft in de telemetrie minder matches en minder afgeknepen verkeer. Om 11.02 uur meldden de eerste organisaties dat hun wachtrijen weer doorliepen, en om 11.28 uur stelde Microsoft vast dat nieuwe mail weer normaal wordt verwerkt. De opgelopen wachtrijen hield het bedrijf daarna in de gaten voor een laatste validatie, en het incident stond nog open zonder eindtijd. Een tijdlijn voor volledig herstel gaf Microsoft niet, en het merkte de uitval aan als incident, het label voor serviceproblemen met merkbare gebruikersimpact.

Het spamfilter kneep legitieme post af

De oorzaak maakt dit incident anders dan de uitval van vorige week. Er ging geen inlog stuk en geen datacenter plat. Een filtermodel dat verkeer moet beoordelen begon legitieme post als verdacht te behandelen en af te knijpen, waarna afzenders tegen een dichte deur aan liepen. Beheerders in Duitsland en elders in Europa zagen mail van externe providers hun tenant niet bereiken en stranden op de SMTP-code 451 4.7.500, de melding waarmee Exchange Online aangeeft dat het de verbinding tijdelijk terugschroeft.

Dat is een stil soort falen. Een postvak dat niet opent, ziet iedereen binnen een minuut. Een offerte die twintig minuten in een wachtrij hangt of pas na drie dagen als onbestelbaar terugkomt, ziet niemand, tot de klant zelf vraagt waar het bleef. Voor beheerders is de praktische les navenant nuchter: CyberSecurityNews raadt aan niet massaal berichten opnieuw te versturen, omdat dat de wachtrijen verder belast, en te letten op vertraagde e-mails met eenmalige inlogcodes, want ook die lopen over dezelfde route.

Op Microsofts publieke statuspagina stond ondertussen geen productbrede verstoring. Het incident leefde alleen in het beheercentrum van de eigen tenant. Wie zijn storingsbeeld op de publieke pagina baseert, had vrijdagochtend niets gezien.

Drie incidentcodes in vijf dagen

EX1467029 is de derde code die Microsoft sinds maandag 31 augustus in het beheercentrum opende. De eerste twee horen bij één doorlopende uitval: vertraagde en mislukte e-mail plus authenticatiefouten voor tienduizenden gebruikers onder EX1464935, die daarna uitwaaierde naar de hele suite en waarbij zoeken in Teams, SharePoint en OneDrive een tweede werkdag onbetrouwbaar bleef door een probleem in een centrale authenticatieconfiguratie. Die uitval werd pas woensdag 3 september afgerond. Daarnaast loopt in hetzelfde beheercentrum sinds 28 augustus nog een lichtere melding over Teams-clients op Windows die tot twee minuten nodig hebben om te openen.

De drie storingen delen geen oorzaak. De eerste zat in de inlog, de tweede in de zoekinfrastructuur die daarop leunde, deze in het spamfilter. Dat is precies wat ze samen betekenisvol maakt: het zijn drie verschillende hendels die Microsoft binnen zijn eigen dienst omzet, en geen van drieën is vanuit jouw tenant te zien, te testen of terug te draaien.

De reflex om dan maar weer een eigen mailserver neer te zetten is begrijpelijk en meestal verkeerd. Zelf hosten verlengt juist je patchcyclus en je detectietijd, waardoor een eigen mailserver een aantrekkelijker doelwit voor statelijke spionage is dan Microsoft 365. Wat deze storing wel scherp stelt, is iets kleiners en concreters: uitgaande zakelijke post is bij de meeste bedrijven een enkelvoudige route zonder alarm. Er is geen tweede kanaal en geen meting die roept als een bericht blijft hangen. Zolang dat zo is, is de eerste die het merkt niet de beheerder, maar de klant die geen offerte kreeg.