Microsoft 365: Die Fisher-Price-IT-Edition

Die letzten beiden Beiträge haben einen Mailserver gebaut, der eine Reihe von Regeln einhält, einmal aus vier Paketen und einmal aus einer einzigen Binary. Fast niemand macht das. Man bezahlt Microsoft, richtet seine Domain auf Exchange Online aus und lässt es den ganzen Rest erledigen. Die faire Frage ist hier also nicht „wie baue ich es“, sondern „wenn ich die Plattform, auf der das halbe Land läuft, ohnehin schon bezahlt habe, kann ich sie dazu bringen, dieselben Regeln einzuhalten?“

Die Antwort, aus Microsofts eigener Dokumentation und einem Read-only-Blick auf das DNS echter Mandanten, lautet: einige davon gut, mehrere gar nicht, und die Plattform sagt dir nicht, welche welche ist. Das ist die Fisher-Price-Edition der Mail-Sicherheit. Die Ecken sind abgerundet, das scharfe Werkzeug ist weggeräumt, und ein paar der Kontrollen, nach denen du tatsächlich greifen würdest, sind gar nicht zum Einschalten da. Jede Behauptung ist mit einer Microsoft-Seite belegt, geprüft am 22. Oktober 2026, und jedes DNS-Ergebnis ist mit dig reproduzierbar.

Die Wertung

Hier sind die Hausregeln aus dem Leitbeitrag, /de/email/why-every-mail-setting-has-to-be-right/, gegen das, was Exchange Online einem Administrator tatsächlich erlaubt.

Fünf davon sind ein glattes Nein oder eine Fehlstelle. Die Form davon sind drei Spalten: die Dinge, die Microsoft entscheidet und richtig macht, die Handvoll, die du einschalten darfst, und die, die schlicht nicht da sind, um sie umzulegen.

Lies weiter, warum jede dort steht, wo sie steht, denn die Gründe sind vernichtender als die Urteile.

Was es gut macht, klar gesagt

Erst das Lob, denn es ist verdient. Auf dem ausgehenden Pfad ist Exchange Online wirklich gut. DANE-Validierung ist seit 2022 standardmäßig an, MTA-STS-Validierung läuft automatisch, mit „nothing administrators need to do to apply it“,¹ und ein Mandatory-DANE-Modus pro Connector kam Anfang 2026.² Das ist mehr, als die meisten selbst gehosteten Server ab Werk hinbekommen.

DANE eingehend mit DNSSEC wurde am 28. Oktober 2024 allgemein verfügbar, und die TLSA-Einträge validieren bei einem Mandanten, der auf den neuen Host umgezogen ist.³⁴ Die Fähigkeit existiert also. Der Haken ist alles drumherum, und das ist der Rest dieses Beitrags.

Kein Klartext eingehend: Es gibt keinen Schalter

Die erste Hausregel lautet, dass der Server Mail verweigert, die im Klartext ankommt. Auf Exchange Online gibt es keine Möglichkeit, das von jedem Absender zu verlangen. TLS lässt sich fordern, aber nur auf einem Partner-Connector, begrenzt auf benannte Domains oder IP-Bereiche, und der Parameter „applies only to Partner type connectors“.⁵ Für alle anderen ist der Standard opportunistisch.⁶ Von deinen benannten Partnern kannst du TLS verlangen. Vom Internet als Ganzem kannst du es nicht verlangen, und genau um diese Menge an Absendern geht es in der Regel. Es ist keine mandantenweite Kontrolle dokumentiert, die eingehendes TLS erzwingt.

Unbekannte Absenderdomains verwerfen: Nirgends dokumentiert

Der Postfix-Aufbau verweigert Mail, deren Absenderdomain nicht existiert, bei MAIL FROM, vor dem Nachrichtentext. Ich habe das Exchange-Online-Äquivalent in der Dokumentation zu Anti-Spam, Authentifizierung und Anti-Phishing gesucht, und es gibt keines. Das Nächste ist composite authentication, und Microsoft sagt ausdrücklich, dass „a composite authentication failure doesn’t directly result in a message being blocked“.⁷ Also sage ich es vorsichtig: Microsoft dokumentiert keine Kontrolle, die Mail von einer nicht existierenden Absenderdomain verwirft. Ob im Filtern etwas Undokumentiertes passiert, kann ich von außen nicht sehen, und du auch nicht, was ziemlich genau der Punkt ist.

SPF- und DKIM-Fehler ablehnen: Nein, und nein

Das ist die eine, die einen Administrator abrupt innehalten lassen sollte. Die Hausregel lautet, eine Nachricht abzulehnen, die SPF hart durchfällt, oder deren DKIM-Signatur vorhanden ist und nicht verifiziert. Exchange Online tut an der Tür weder das eine noch das andere.

Für SPF gibt es eine Einstellung, vergraben im erweiterten Spam-Filter. Sie ist standardmäßig „Off“, und wenn sie an ist, lehnt sie die Nachricht nicht ab: Sie markiert Mail von einem nicht gelisteten Absender „as high confidence spam“.⁸ Lies das zweimal. Das Stärkste, was Exchange Online gegen jemanden tut, der eine Domain fälscht, deren SPF -all sagt, ist, sie in den Junk-Ordner zu legen, und selbst das ist ab Werk aus. Für DKIM gibt es gar nichts: Keine Einstellung lehnt eine Nachricht allein deshalb ab, weil ihre Signatur nicht verifiziert hat. Eine fehlgeschlagene Signatur fließt in DMARC und die composite-Bewertung ein, und damit hat es sich.

Ablehnung passiert in einem Fall: Wenn die Domain des Absenders DMARC p=reject veröffentlicht, respektiert Exchange Online das standardmäßig und verweigert zur SMTP-Zeit mit 550 5.7.1.⁹ Gut, und standardmäßig an, aber es hängt ganz davon ab, dass der Absender das Richtige getan hat. Die Kontrollen, die die anderen Aufbauten für deinen eigenen eingehenden Schutz genutzt haben, bei SPF-Fehler ablehnen und bei kaputter Signatur ablehnen, sind nicht zum Einschalten da.

IPv6: Zwei Jahre später ist das NCSC darüber nicht erreichbar

IPv6 ist in dieser Reihe Pflicht. Exchange Online unterstützt es eingehend, pro akzeptierter Domain, nach einem Opt-in, und vorbehaltlich dessen, dass Microsoft automatisch „a small percentage of our customers“ wieder abmeldet.¹⁰ Dieser Rollout wurde im Oktober 2024 mit drei bis sechs Monaten angekündigt. Also habe ich den AAAA-Eintrag auf dem Mail-Host von zweiundzwanzig britischen Organisationen gelesen, die Microsoft 365 nutzen. Neun haben zwei Jahre später keinen.

Das Postfach des National Cyber Security Centre selbst ist über IPv6 nicht erreichbar, ebenso wenig HMRC, der NHS-Maildienst, das Verteidigungsministerium, der Information Commissioner oder Lloyds Bank.⁴ Ob jedes von Microsoft abgemeldet wurde oder nie angemeldet war, lässt sich aus dem DNS nicht sagen. Das Ergebnis ist dasselbe, und alle zweiundzwanzig liegen auf dem alten Mail-Host, der, wie wir gleich sehen, nicht signiert werden kann.

DNSSEC: Nicht geplant für den Host, den du tatsächlich nutzt

Hier hören Dokumentation und DNS auf, sich einig zu sein, und es ist der schärfste Befund im Beitrag. DANE eingehend braucht DNSSEC, und DNSSEC braucht den Mail-Host in einer signierten Zone. Jeder gewöhnliche Exchange-Online-Mandant hat seinen MX auf einen Host unter mail.protection.outlook.com gerichtet. Ich habe geprüft, ob diese Zone signiert ist, und sie ist es nachweislich nicht:

$ 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

Die übergeordnete Zone ist signiert, und sie liefert einen authentifizierten NSEC-Eintrag, der beweist, dass es kein DS für protection.outlook.com gibt. Das ist eine signierte Aussage, dass die Delegierung unsigniert ist. Jeder *.mail.protection.outlook.com-MX also, das heißt fast jeder Microsoft-365-Mandant der Welt, liegt in einer unsignierten Zone und kann kein DANE.

Die neue, signierte Infrastruktur liegt unter einem anderen Namen, mx.microsoft, und der Umzug dorthin ist eine manuelle Opt-in-Änderung. Wie viele haben ihn gemacht? Von rund fünfunddreißig britischen Domains, die ich stichprobenartig geprüft habe, war keine einzige darauf. Die Mandanten, die ich auf dem signierten Host finden konnte, waren allesamt niederländisch. Und Microsofts eigener Beitrag vom April 2026 sagt, der Plan ist nicht, den Host zu reparieren, den alle nutzen:

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

Also: DNSSEC und DANE sind auf einem neuen Host verfügbar, wenn du dich anmeldest und migrierst, und der Host, auf dem jeder bestehende Mandant tatsächlich liegt, wird nach Microsofts eigener Aussage nicht signiert. Die Fähigkeit ist ausgeliefert. Der Standard hat sich nicht bewegt, und wird es auch nicht.

Microsofts eigene zwei größte Domains zeigen die Spaltung, und eine davon ist schlechter als die Mandanten, die sie belehrt:

outlook.com, der Maildienst für Endverbraucher, veröffentlicht DMARC p=none: Es bittet die Welt, seine Mail zu prüfen, und dann bei einem Fehler nichts zu tun, was die Einstellung ist, die der Leitbeitrag ein Schulterzucken nennt.⁴ Microsofts Unternehmensdomain macht es besser. Keiner der beiden Hosts ist signiert.

Die Dokumentation widerspricht sich selbst

Wenn die eigene Dokumentation eines Anbieters sich bei einer Sicherheitskontrolle widerspricht, ist das keine Kleinigkeit. Es ist ein Kunde, dem zwei unvereinbare Dinge über etwas gesagt werden, das entscheidet, ob seine Mail sicher ist, und darauf achte ich so, wie ich es bei jedem Lieferanten täte, der dafür bezahlt wird, es richtig zu machen. Drei Beispiele, alle von Seiten, die Microsoft veröffentlicht hat, alle live am 22. Oktober 2026.

Die SPF-Seite empfiehlt -all, „hard fail“.¹¹ Der Direct-Send-Beitrag empfiehlt „a Soft Fail SPF configuration“.¹² Beide sind aktuell, und ein Kunde, der dem einen folgt, wird vom anderen gerügt. Bei MTA-STS weist die Seite für eingehende Mail einen Mandanten an, mx: *.mail.protection.outlook.com zu veröffentlichen, sagt auf derselben Seite, dass „wildcards or ‘*’ must not be used as the MX prefix in all MTA-STS scenarios“,¹ und druckt dann ein Beispiel, das genau diesen Wildcard verwendet. Ich verlange nicht, dass Microsoft etwas erfindet. Ich frage, warum die Seite, die einem Kunden erklärt, wie er seinen Mailfluss schützt, sich über die eine Zeile, die den Schutz leistet, nicht mit sich selbst einig werden kann.

Dann das Direct-Send-Loch, das ist die Identitätsregel, Regel sechs, die an der Vordertür versagt.

Es gibt eine Möglichkeit, Mail als einer der eigenen Nutzer in einen Mandanten zu senden, ganz ohne Authentifizierung, weil es „does not require any form of authentication“,¹² und es ist standardmäßig an. Die Einstellung, um es abzuschalten, RejectDirectSend, ist standardmäßig aus, prüft nur den Envelope-Absender und nicht das sichtbare From:, und hat achtzehn Monate später immer noch „no fixed date for General Availability“.¹² Eine bezahlte Plattform hat einen unauthentifizierten Weg ausgeliefert, um die eigene Domain eines Mandanten zu fälschen, hat ihn standardmäßig angelassen, und der Fix ist ein Opt-in-Schalter ohne Veröffentlichungsdatum und mit einer Lücke in dem, was er prüft. Das ist der Ton, den ich mir für einen Lieferanten vorbehalte, der die Haltung einnimmt, das sei schwer. Es ist nicht schwer. Und so werde ich nicht so tun, als wäre es das. Es ist ein Standard, der falsch gesetzt und liegen gelassen wurde.

Kannst du es damit richtig bauen? Größtenteils nicht

Hier also die ehrliche Abrechnung, und sie lautet nicht, dass Microsoft 365 schlechte Mail ist. Es stellt zuverlässig zu, seine ausgehende Sicherheit ist wirklich gut, und für eine Organisation ohne Mail-Expertise ist es sicherer als der Server, den sie sonst falsch konfiguriert hätte. Alles wahr, und alles neben dem Punkt, den diese Reihe macht.

Es geht um Kontrolle, und bei den Kontrollen, die für die Bedrohungen aus dem Leitbeitrag am wichtigsten sind, gibt Exchange Online sie dir nicht. Du kannst eingehendes TLS aus dem Internet nicht erzwingen, einen SPF-Hard-Fail nicht ablehnen, eine gefälschte Signatur nicht ablehnen und Mail von einer nicht existierenden Domain nicht verwerfen. Der eine unfälschbare Transportschutz, DANE mit DNSSEC, ist auf dem Host, auf dem du bist, aus, und es ist nicht geplant, ihn dorthin zu bringen. Und das unauthentifizierte Loch in der Vordertür ist standardmäßig offen, ohne Datum, es zu schließen.

Das ist es, was die Fisher-Price-Edition bedeutet. Nicht, dass sie für Kinder ist, sondern dass das scharfe Werkzeug weggenommen wurde, man dir das abgerundete in die Hand drückt und dir sagt, es sei zu deinem Besten. Was es für viele Läden auch ist. Für viele Organisationen ist es das wirklich. Für jeden, der so weit gelesen und verstanden hat, wofür das scharfe Werkzeug da war, ist es eine Plattform, die an deiner Stelle entschieden hat, welche deiner Sicherheitseinstellungen du anfassen darfst. Die, die du dir am meisten gewünscht hast, liegen hinter Glas.

Du bezahlst so oder so dafür. Das Mindeste, was du tun kannst, ist zu wissen, welche dieser Regeln sie klammheimlich entschieden hat, dich nicht einhalten zu lassen.