Ghost-Sender ist ein neu dokumentierter Fehler in der Art, wie Microsoft Exchange Online eingehende E-Mails annimmt. Er erlaubt einem Angreifer, eine gefälschte E-Mail zuzustellen, die aussieht, als käme sie von einer Kollegin, einem Kollegen oder einer vertrauenswürdigen Marke, obwohl die Nachricht jede Authentifizierungsprüfung nicht besteht, die gefälschte Post abfangen soll. Sicherheitsforscher von InfoGuard veröffentlichten die Technik am 9. Juni 2026, und Microsoft hat sie als bekannte architektonische Einschränkung eingestuft und nicht als Fehler, den das Unternehmen beheben will.
Der Fehler betrifft Organisationen, die eingehende E-Mails über einen Spam-Filter eines Drittanbieters leiten, bevor sie Microsoft 365 erreichen. Dieser Aufbau ist verbreitet, besonders bei Unternehmen, deren IT von einer Agentur oder einem Dienstleister betreut wird. Die DMARC-Durchsetzung ist die übliche Verteidigung gegen Spoofing, und sie stoppt diesen Angriff nicht, weil die gefälschte Post über einen Weg eintritt, auf dem das DMARC-Urteil nie angewendet wird. Die folgenden Abschnitte erklären, wie die Technik funktioniert, warum Authentifizierung allein sie nicht stoppen kann und welche Microsoft-365-Einstellungen die Lücke schließen.
Ghost-Sender ist eine Technik, um gefälschte E-Mails in Microsoft-365-Postfächer zuzustellen. Die Nachricht gibt vor, von einer vertrauenswürdigen Kollegin, einem Kollegen oder einer bekannten Marke zu stammen. Die Authentifizierungsprüfungen erkennen diese Behauptung als falsch, und Exchange Online stellt die Nachricht trotzdem zu.
Forscher von InfoGuard legten die Technik am 9. Juni 2026 öffentlich offen. In ihren Tests erreichte eine Nachricht, die vorgab, von noreply@microsoft.com zu stammen, das Postfach mit einem negativen Ergebnis bei jeder Prüfung: SPF schlug fehl, DKIM fehlte und DMARC schlug fehl. Solche Ergebnisse bedeuten normalerweise, dass die Nachricht abgewiesen wird oder im Spam-Ordner landet. Diese wurde zugestellt.
Die Technik benötigt keine gestohlenen Passwörter und keine Änderungen am DNS der Zieldomäne. Sie missbraucht die Art, wie Exchange Online eingehende E-Mails weiterleitet, sodass sie selbst gegen eine Domäne funktioniert, deren SPF-, DKIM- und DMARC-Einträge alle korrekt konfiguriert sind.
Viele Organisationen richten die Mail-Einträge ihrer Domäne nicht direkt auf Microsoft aus. Sie schalten ein Sicherheits-Gateway eines Drittanbieters davor: einen Spam- und Malware-Filter von einem Anbieter wie Proofpoint, Mimecast oder Barracuda. Ihr MX-Eintrag (der DNS-Eintrag, der der Welt mitteilt, wohin E-Mails zuzustellen sind) verweist auf diesen Filter, nicht auf Microsoft. Die Post soll in eine Richtung fließen: vom Internet zum Filter, vom Filter zu Microsoft, von Microsoft ins Postfach.
Das Problem ist, dass die eigene Zustelladresse von Microsoft die ganze Zeit erreichbar bleibt. Jede Microsoft-365-Organisation (in Microsofts Terminologie ein „Tenant“) hat eine direkte Zustelladresse in der Form yourdomain.mail.protection.outlook.com, und diese nimmt Post von jedem im Internet an. Ein Angreifer, der an diese Adresse sendet, erreicht Exchange Online direkt und umgeht den externen Filter vollständig. Der Filter sieht die Nachricht nie, also greift keine seiner Regeln gegen Spoofing oder Phishing.
Weil die Nachricht über Microsofts eigene Infrastruktur eintrifft, behandelt Exchange Online sie mit mehr Vertrauen als eine Nachricht aus dem offenen Internet. Dieses fehlgeleitete Vertrauen ist der Kern des Fehlers.
SPF, DKIM und DMARC sind Prüfungen, die ein empfangender Mailserver durchführt, um zu entscheiden, ob eine Nachricht wirklich von der Domäne in ihrer From-Adresse stammt. Sie sind die zentrale Verteidigung gegen Domänen-Spoofing und fangen den allergrößten Teil davon ab.
Ghost-Sender überwindet diese Prüfungen nicht. Er umgeht die Stelle in der Zustellung, an der ihr Ergebnis angewendet wird. Die gefälschte Nachricht besteht alle drei tatsächlich nicht, genau wie der Test von InfoGuard zeigte. Doch die Post wurde bereits an Microsofts direkter Zustelladresse angenommen, und Exchange Online wendet auf Post, die es als intern behandelt, nicht dieselbe DMARC-Durchsetzung an. Das Authentifizierungsurteil lautet „fail“, und die Nachricht wird trotzdem zugestellt.
Nichts davon bedeutet, dass DMARC optional ist. DMARC ist weiterhin die Kontrolle, die alltägliches Spoofing stoppt: gefälschte Lieferantenrechnungen, falsche Zahlungsaufforderungen der Geschäftsführung und Phishing über nachgeahmte Domänen, das Ihren Exchange-Endpunkt nie erreicht. Ghost-Sender ist eine eng begrenzte architektonische Ausnahme und ändert nichts daran, warum Sie DMARC darunter brauchen.
Auf diese Weise gefälschte Nachrichten landen auf einer Infrastruktur, auf der saubere Authentifizierung ohnehin schwer aufrechtzuerhalten ist. Laut DMARCeyes Branchenbericht für das 1. Quartal 2026 wies Post, die Microsofts Infrastruktur zugeordnet wurde, eine Konformität von 90,0 % auf, wobei SPF bei 26,6 % der Nachrichten und DKIM bei 19,6 % fehlschlug. Ein erheblicher Teil der legitimen, über Microsoft versendeten Post authentifiziert sich bereits nicht sauber. Wie der Bericht für das 1. Quartal anmerkt, ist eine niedrige Konformität bei einem großen Anbieter fast immer ein Konfigurationsproblem auf der Absenderseite und kein Fehler der Plattform selbst. Die üblichen Ursachen sind Kunden, die nicht die richtigen DKIM-Schlüssel in ihr DNS eingetragen haben oder deren Versand über ihren SPF-Eintrag hinausgewachsen ist.
Der Punkt ist nicht, dass Microsofts Post schwach wäre. Der Punkt ist, dass der Mail-Fluss in Microsoft 365 kompliziert korrekt zu konfigurieren ist, und Ghost-Sender nutzt eine bestimmte Lücke darin aus, wie das eingehende Routing verdrahtet ist.
Den vollständigen Bericht können Sie hier herunterladen:
InfoGuard meldete das Problem am 21. April 2026 an Microsoft. Microsoft setzte am folgenden Tag eine interne Gegenmaßnahme ein und nahm sie am 27. April wieder zurück. Am 29. Mai 2026 stufte Microsoft Ghost-Sender als bekannte architektonische Einschränkung ein und nicht als Produktschwachstelle, und zu diesem Datum gab es keine Lösung auf Plattformebene.
In der Praxis bedeutet das, dass die Verantwortung, die Lücke zu schließen, bei jeder Organisation liegt und nicht bei einem Patch, der automatisch kommt. Microsoft verschärft die zugehörigen Standardeinstellungen, und bei neuen Tenants ist Direct Send (die Funktion, auf der der Angriff beruht) nun standardmäßig abgelehnt, nach einer Änderung, die Microsoft Anfang 2026 auszurollen begann. Bestehende Tenants behalten ihre aktuelle Konfiguration, bis eine Administratorin oder ein Administrator sie ändert.
Wenn Sie Microsoft 365 mit einem externen Filter betreiben, können Sie nicht auf eine Lösung warten. Sie müssen die Konfiguration selbst prüfen und anpassen.
Sie sind potenziell betroffen, wenn zwei Dinge zutreffen: Ihre Organisation nutzt Microsoft 365 (oder Exchange im Hybridmodus), und der MX-Eintrag Ihrer Domäne verweist auf einen Filter eines Drittanbieters statt direkt auf Microsoft. Das betrifft einen großen Teil der betreuten Tenants, denn ein dediziertes Sicherheits-Gateway vor Microsoft zu schalten, ist ein verbreitetes Design.
Das Scanning von InfoGuard ergab, dass über 20 % der Exchange-Online-Domänen, die im Rahmen von Bug-Bounty-Programmen getestet wurden, verwundbar erschienen und dass weniger als die Hälfte der Umgebungen mit externem MX-Eintrag überhaupt eine Gegenmaßnahme im Einsatz hatte.
Um einen Tenant zu prüfen, gehen Sie drei Fragen durch:
*.mail.protection.outlook.com verweist, wird die Post über einen Drittanbieter geleitet, und der direkte Microsoft-Endpunkt bleibt weiterhin angreifbar.Zwei Konfigurationen blockieren Ghost-Sender zuverlässig, und Microsofts eigene Steuerung von Direct Send fügt eine dritte Ebene hinzu.
X-MS-Exchange-Organization-AuthAs: Internal aus einer genehmigten Quelle trägt oder nicht aus Ihren genehmigten IP-Bereichen stammt. Einfach gesagt fängt das Post ab, die vorgibt, intern zu sein, aber nicht über einen vertrauenswürdigen Weg eingetroffen ist.RejectDirectSend) entfernt genau den Weg, den Ghost-Sender missbraucht. Stellen Sie zuvor sicher, dass Ihre legitimen Drucker, Scanner und Fachanwendungen einen authentifizierten Connector verwenden.Das ist kein DMARC-Problem, sondern ein Microsoft-365-Konfigurationsproblem mit einer Microsoft-365-Lösung. Was DMARC-Monitoring hinzufügt, ist Sichtbarkeit. Wenn eine gefälschte Nachricht SPF, DKIM und DMARC nicht besteht, protokolliert Microsoft diesen Fehlschlag dennoch und nimmt ihn in Ihre DMARC-Aggregatberichte auf. Ein Werkzeug, das diese Berichte für Sie liest, zeigt gefälschte, bei der Authentifizierung fehlgeschlagene Post, die im Namen Ihrer Domäne von Quellen versendet wird, die Sie nicht kennen. Genau das ist das Signal, dass eine Technik wie Ghost-Sender gegen Sie eingesetzt wird. Der kostenlose Tarif von DMARCeye deckt eine Domäne ab und verwandelt diese Rohdaten aus den Berichten in eine verständliche Übersicht darüber, wer in Ihrem Namen sendet und was fehlschlägt.
Wenn Sie sofort sehen möchten, was Ihre Domäne aktuell veröffentlicht, beginnen Sie mit ihrem aktuellen DMARC-Eintrag:
E-Mail-Sicherheit funktioniert in Ebenen, und keine einzelne Ebene deckt alles ab. DMARC ist der wesentliche Kern: Es authentifiziert die Domäne in Ihrer From-Adresse und stoppt die breite Kategorie des Spoofings, die den Großteil des E-Mail-Betrugs ausmacht. Dieser Fehler schwächt es nicht. Was der Fehler offenlegt, ist eine andere Ebene: das Vertrauen, das Microsoft 365 in seinen eigenen internen Mail-Fluss setzt. DMARC war nie dafür gedacht, diese Ebene zu steuern, und nur Ihre Microsoft-365-Konfiguration kann sie absichern.
Für Agenturen und IT-Dienstleister lautet die Botschaft an einen Kunden beides zugleich: Behalten Sie Ihre DMARC-Durchsetzung bei, weil sie den Großteil des Spoofings stoppt, und schließen Sie die Lücke in Exchange Online, weil DMARC sie nicht erreichen kann.
Diese zweiteilige Antwort ist die Arbeit, die aus unserer Sicht am meisten zählt. DMARCeye existiert, um Menschen klare Sichtbarkeit darüber zu geben, wer im Namen ihrer Domäne sendet, und um Spoofing zu erklären, das reale Risiko, das es mit sich bringt, sowie die Lösungen, die funktionieren, einschließlich derer, die wie diese über DMARC selbst hinausgehen.