Microsoft 365: de Fisher-Price-IT-editie

De vorige twee posts bouwden een mailserver die aan een set regels voldoet, één keer uit vier pakketten en één keer uit een enkele binary. Vrijwel niemand doet dat. Ze betalen Microsoft, wijzen hun domein naar Exchange Online, en laten het de hele klus klaren. De eerlijke vraag is hier dus niet “hoe bouw ik het” maar “als ik al betaald heb voor het platform waarop het grootste deel van het land draait, kan ik het dan aan dezelfde regels laten voldoen?”

Het antwoord, uit Microsofts eigen documentatie en een read-only blik op de DNS van echte tenants, luidt: sommige goed, een aantal helemaal niet, en het platform vertelt je niet welke welke is. Dit is de Fisher-Price-editie van mailbeveiliging. De hoeken zijn afgerond, het scherpe gereedschap is opgeborgen, en een paar van de controls waar je echt naar zou grijpen staan er niet om aan te zetten. Elke bewering is onderbouwd met een Microsoft-pagina gecontroleerd op 22 oktober 2026, en elk DNS-resultaat is reproduceerbaar met dig.

De Scorekaart

Hier staan de huisregels uit de hoofdpost, /nl/email/why-every-mail-setting-has-to-be-right/, afgezet tegen wat Exchange Online een beheerder werkelijk toestaat.

Vijf daarvan zijn een botte nee of een afwezigheid. De vorm ervan is drie kolommen: de dingen die Microsoft beslist en goed doet, het handjevol dat je mag aanzetten, en de dingen die er simpelweg niet zijn om aan te zetten.

Lees verder voor waarom elk op zijn plek staat, want de redenen zijn vernietigender dan de oordelen.

Wat Het Goed Doet, Eerlijk Gezegd

Eerst de lof, want die is verdiend. Op het uitgaande pad is Exchange Online oprecht goed. DANE-validatie staat standaard aan sinds 2022, MTA-STS-validatie is automatisch met “nothing administrators need to do to apply it”,¹ en een Mandatory-DANE-modus per connector kwam begin 2026.² Dat is meer dan de meeste zelfgehoste servers uit de doos voor elkaar krijgen.

Inkomende DANE met DNSSEC werd algemeen beschikbaar op 28 oktober 2024, en de TLSA-records valideren op een tenant die naar de nieuwe host is verhuisd.³⁴ De mogelijkheid bestaat dus. De adder zit in alles eromheen, en dat is de rest van deze post.

Geen Plaintext Inkomend: Er Is Geen Schakelaar

De eerste huisregel is dat de server mail weigert die in platte tekst binnenkomt. Op Exchange Online is er geen manier om dat van elke afzender te eisen. TLS kan worden afgedwongen, maar alleen op een partner-connector, afgebakend tot benoemde domeinen of IP-reeksen, en de parameter “applies only to Partner type connectors”.⁵ Voor alle anderen is de standaard opportunistisch.⁶ Je kunt TLS eisen van je benoemde partners. Je kunt het niet eisen van het internet in het algemeen, en dat is nu juist de verzameling afzenders waar de regel over gaat. Er is geen gedocumenteerde tenant-brede regeling om inkomende TLS te vereisen.

Onbekende Afzenderdomeinen Weigeren: Nergens Gedocumenteerd

De Postfix-build weigert mail waarvan het afzenderdomein niet bestaat, bij MAIL FROM, vóór de body. Ik ging op zoek naar het Exchange Online-equivalent in de anti-spam-, authenticatie- en anti-phishingdocumentatie, en het is er niet. Het dichtst in de buurt komt composite authentication, en Microsoft is er duidelijk over dat “a composite authentication failure doesn’t directly result in a message being blocked”.⁷ Dus ik zeg het voorzichtig: Microsoft documenteert geen enkele regeling die mail van een niet-bestaand afzenderdomein weigert. Of er ongedocumenteerd iets gebeurt in de filtering kan ik van buitenaf niet zien, en jij ook niet, en dat is nu juist het punt.

SPF- En DKIM-Fouten Weigeren: Nee, En Nee

Dit is degene die een beheerder op slag zou moeten stoppen. De huisregel is om een bericht te weigeren dat SPF hard faalt, of waarvan de DKIM-handtekening aanwezig is en niet klopt. Exchange Online doet geen van beide aan de deur.

Voor SPF is er een instelling, begraven in het geavanceerde spamfilter. Hij staat standaard op “Off”, en als hij aan staat weigert hij het bericht niet: hij markeert mail van een niet-vermelde afzender “as high confidence spam”.⁸ Lees dat nog eens. Het sterkste dat Exchange Online doet tegen iemand die een domein vervalst waarvan SPF -all zegt, is het in Junk zetten, en zelfs dat staat uit de doos uit. Voor DKIM is er helemaal niets: geen enkele instelling weigert een bericht puur omdat de handtekening niet klopte. Een mislukte handtekening voedt DMARC en de composite-score, en daar blijft het bij.

In één geval gebeurt afwijzing wél: als het domein van de afzender DMARC p=reject publiceert, honoreert Exchange Online dat standaard en weigert het bij SMTP met 550 5.7.1.⁹ Goed, en standaard aan, maar het hangt volledig af van of de afzender het juiste heeft gedaan. De controls die de andere builds gebruikten voor je eigen inkomende bescherming, weigeren bij SPF-fout en weigeren bij een kapotte handtekening, zijn er niet om aan te zetten.

IPv6: Twee Jaar Later Is De NCSC Er Niet Over Te Bereiken

IPv6 is verplicht in deze serie. Exchange Online ondersteunt het inkomend, per geaccepteerd domein, na een opt-in, en onder voorbehoud dat Microsoft automatisch “a small percentage of our customers” op opt-out zet.¹⁰ Die uitrol werd in oktober 2024 aangekondigd als drie tot zes maanden werk. Dus ik las het AAAA-record op de mailhost van tweeëntwintig Britse organisaties die Microsoft 365 draaien. Negen, twee jaar later, hebben er geen.

De eigen mailbox van het National Cyber Security Centre is niet over IPv6 te bereiken, en die van HMRC, de NHS-maildienst, het Ministry of Defence, de Information Commissioner of Lloyds Bank evenmin.⁴ Of elk door Microsoft op opt-out is gezet of nooit opt-in heeft gedaan, is uit de DNS niet af te leiden. Het resultaat is hetzelfde, en alle tweeëntwintig zitten op de oude mailhost die, zoals we zo gaan zien, niet ondertekend kan worden.

DNSSEC: Niet Gepland Voor De Host Die Je Echt Gebruikt

Hier houden de documentatie en de DNS op het met elkaar eens te zijn, en dit is de scherpste bevinding in de post. Inkomende DANE heeft DNSSEC nodig, en DNSSEC vereist dat de mailhost in een ondertekende zone zit. Elke gewone Exchange Online-tenant heeft zijn MX gericht op een host onder mail.protection.outlook.com. Ik controleerde of die zone ondertekend is, en bewijsbaar is dat niet zo:

$ dig @1.1.1.1 +dnssec DS protection.outlook.com
;; flags: qr rd ra ad; ANSWER: 0
protection.outlook.com. 60 IN NSEC \000.protection.outlook.com. NS RRSIG NSEC

De bovenliggende zone is ondertekend, en hij geeft een geauthenticeerd NSEC-record terug dat bewijst dat er geen DS is voor protection.outlook.com. Dat is een ondertekende verklaring dat de delegatie niet ondertekend is. Dus elke *.mail.protection.outlook.com-MX, oftewel vrijwel elke Microsoft 365-tenant op aarde, zit in een niet-ondertekende zone en kan geen DANE doen.

De nieuwe, ondertekende infrastructuur zit onder een andere naam, mx.microsoft, en ernaartoe verhuizen is een handmatige, opt-in wijziging. Hoeveel hebben dat gedaan? Van de ongeveer vijfendertig Britse domeinen die ik bekeek, zat er niet één op. De tenants die ik op de ondertekende host kon vinden waren allemaal Nederlands. En Microsofts eigen post uit april 2026 zegt dat het plan niet is om de host die iedereen gebruikt te repareren:

Currently, there are no plans to enable DNSSEC on the mail flow domain mail.protection.outlook.com.²

Dus: DNSSEC en DANE zijn beschikbaar op een nieuwe host, als je opt-in doet en migreert, en de host waar elke bestaande tenant werkelijk op zit zal, volgens Microsofts eigen verklaring, niet ondertekend worden. De mogelijkheid is geleverd. De standaard verschoof niet, en gaat dat ook niet doen.

Microsofts eigen twee grootste domeinen laten de splitsing zien, en een ervan is slechter dan de tenants die het de les leest:

outlook.com, de consumentenmaildienst, publiceert DMARC p=none: het vraagt de wereld om zijn mail te controleren en vervolgens niets te doen met een fout, de instelling die de hoofdpost een schouderophalen noemt.⁴ Microsofts bedrijfsdomein doet het beter. Geen van beide hosts is ondertekend.

De Documentatie Spreekt Zichzelf Tegen

Als de eigen documentatie van een leverancier zichzelf tegenspreekt over een beveiligingscontrol, is dat geen muggenzifterij. Het is een klant die twee onverenigbare dingen te horen krijgt over iets dat bepaalt of zijn mail veilig is, en daar let ik op zoals ik dat bij elke leverancier zou doen die betaald wordt om het goed te doen. Drie voorbeelden, allemaal van pagina’s die Microsoft heeft gepubliceerd, allemaal live op 22 oktober 2026.

De SPF-pagina beveelt -all, “hard fail”, aan.¹¹ De Direct Send-post beveelt “a Soft Fail SPF configuration” aan.¹² Beide zijn actueel, en een klant die de ene volgt wordt door de andere terechtgewezen. Bij MTA-STS zegt de inkomende pagina een tenant dat die mx: *.mail.protection.outlook.com moet publiceren, zegt op diezelfde pagina dat “wildcards or ‘*’ must not be used as the MX prefix in all MTA-STS scenarios”,¹ en drukt vervolgens een voorbeeld af dat precies die wildcard gebruikt. Ik vraag Microsoft niet om iets te verzinnen. Ik vraag waarom de pagina die een klant vertelt hoe hij zijn mailstroom moet beschermen, het niet met zichzelf eens kan worden over de ene regel die de bescherming doet.

Dan het Direct Send-gat, oftewel de identiteitsregel, regel zes, die bij de voordeur faalt.

Er is een manier om mail een tenant in te sturen als een van zijn eigen gebruikers zonder enige authenticatie, omdat het “does not require any form of authentication”,¹² en het staat standaard aan. De instelling om het uit te zetten, RejectDirectSend, staat standaard uit, controleert alleen de envelop-afzender en niet de zichtbare From:, en heeft achttien maanden later nog steeds “no fixed date for General Availability”.¹² Een betaald platform leverde een ongeauthenticeerde manier om het eigen domein van een tenant te spoofen, liet die standaard aan staan, en de oplossing is een opt-in schakelaar zonder releasedatum en met een gat in wat hij controleert. Dat is het register dat ik bewaar voor een leverancier die de lijn aanhoudt dat dit moeilijk is. Het is niet moeilijk. Als zodanig doe ik niet alsof dat wel zo is. Het is een standaard die verkeerd is gezet en zo is gelaten.

Kun Je Het Hierop Goed Bouwen? Grotendeels Niet

Hier is dan de eerlijke afrekening, en die is niet dat Microsoft 365 slechte mail is. Het levert betrouwbaar af, de uitgaande beveiliging is oprecht goed, en voor een organisatie zonder mailexpertise is het veiliger dan de server die ze anders verkeerd geconfigureerd zouden hebben. Allemaal waar, en allemaal naast het punt dat deze serie maakt.

Het gaat om controle, en op de controls die het zwaarst wegen voor de dreigingen uit de hoofdpost geeft Exchange Online je die niet. Je kunt geen inkomende TLS vanaf het internet eisen, geen SPF-hard-fail afwijzen, geen vervalste handtekening afwijzen, en geen mail weigeren van een domein dat niet bestaat. De ene onvervalsbare transportbescherming, DANE met DNSSEC, staat uit op de host waar je op zit en is niet gepland om die te bereiken. En het ongeauthenticeerde gat in de voordeur staat standaard open zonder datum om het te sluiten.

Dat is wat de Fisher-Price-editie betekent. Niet dat het voor kinderen is, maar dat het scherpe gereedschap is weggehaald, je de afgeronde krijgt aangereikt, en je te horen krijgt dat het voor je eigen bestwil is. Wat, voor een hoop zaken, ook zo is. Voor een hoop organisaties is het dat oprecht. Voor iedereen die zover is gekomen en begrepen heeft waar het scherpe gereedschap voor was, is het een platform dat namens jou heeft besloten welke van je beveiligingsinstellingen je mag aanraken. Die je het hardst wilde zitten achter het glas.

Je betaalt er hoe dan ook voor. Het minste dat je kunt doen is weten welke van deze regels het stilletjes heeft besloten dat je niet mag aanhouden.