Compauth=fail bei Microsoft 365: zusammengesetzte Authentifizierung verstehen und Reason Codes beheben

Sie prüfen die Header einer Nachricht in Microsoft 365 und stoßen auf compauth=fail reason=001. Die Nachricht stammt von einem bekannten Absender, SPF wirkt korrekt, und dennoch landet sie in der Junk-E-Mail oder in der Quarantäne. Das Feld compauth ist eines der am häufigsten missverstandenen in Exchange Online, weil es keinem Standardprotokoll entspricht: Es ist eine proprietäre Mechanik von Microsoft.

Dieser Leitfaden ist eine vollständige Referenz. Er erklärt, was die zusammengesetzte Authentifizierung ist, wie Microsoft 365 dieses Urteil aus SPF, DKIM, DMARC und internen Signalen berechnet, den wesentlichen Unterschied zwischen impliziter und expliziter Authentifizierung, und liefert dann die vollständige, anhand der offiziellen Microsoft-Dokumentation geprüfte Tabelle der Reason Codes. Schließlich finden Sie einen Diagnose- und Behebungsplan, geordnet nach Code-Familie.

Er richtet sich an Microsoft-365- und Exchange-Online-Administratoren, deren legitime Nachrichten als Spoofing markiert oder in Quarantäne gestellt werden, sowie an Verantwortliche für Zustellbarkeit, die einen Microsoft-Authentifizierungsheader lesen und interpretieren müssen.

Was ist die zusammengesetzte Authentifizierung (compauth) von Microsoft 365?

Die zusammengesetzte Authentifizierung ist ein proprietäres Urteil von Microsoft. Anders als SPF (RFC 7208), DKIM (RFC 6376) und DMARC (RFC 7489) ist compauth durch keine Norm definiert. Es ist eine Bewertungsschicht, die Microsoft 365 über diese drei Protokolle legt, um ein Gesamturteil über die Authentizität eines Absenders zu bilden.

Konkret begnügt sich Exchange Online Protection (EOP) nicht damit, die Ergebnisse von SPF, DKIM und DMARC weiterzureichen. Es aggregiert sie mit zusätzlichen Signalen: der Reputation der sendenden IP-Adresse, dem Verlauf bereits empfangener Nachrichten aus dieser Infrastruktur, dem PTR-Eintrag (Reverse DNS) der IP und Verhaltensmustern aus der Massenanalyse des Microsoft-Datenverkehrs. Das Ergebnis dieser Aggregation wird in das Feld compauth des Headers Authentication-Results geschrieben.

Die Grundeinheit der Bewertung ist die From:-Domain, die der Empfänger sieht, also die Adresse des Headers 5322.From (auch P2-Domain genannt). Genau diese Domain will Microsoft vor Spoofing schützen, und auf sie beziehen sich Ausrichtung und zusammengesetztes Urteil. Diese Präzisierung ist nicht belanglos: Eine Nachricht kann SPF auf der Envelope-Domain (5321.MailFrom) durchaus bestehen und dennoch an der zusammengesetzten Authentifizierung scheitern, weil diese Envelope-Domain nicht mit der angezeigten From:-Domain übereinstimmt. Der Endnutzer sieht niemals den Envelope, sondern nur das From:; logischerweise stützt sich der Spoofing-Schutz daher auf diese Adresse.

Warum hat Microsoft diese zusätzliche Schicht geschaffen, statt sich auf DMARC zu beschränken? Weil die Einführung von DMARC nach wie vor lückenhaft ist. Ein erheblicher Teil der legitimen Domains hat gar keine DMARC-Richtlinie oder veröffentlicht ein p=none, das keinerlei Anweisung zur Durchsetzung gibt. Ohne zusammengesetztes Signal müsste Microsoft diesen Domains entweder blind vertrauen (und Spoofing durchlassen) oder sie systematisch bestrafen (und legitime Post blockieren). Die zusammengesetzte Authentifizierung ist die Antwort auf dieses Dilemma: Sie erlaubt, einen Absender selbst dann zu bewerten, wenn die Standardprotokolle kein klares Urteil liefern, indem sie sich auf bei Microsoft beobachtbare Signale stützt.

Das Feld erscheint in einem Header typischerweise in dieser Form:

Authentication-Results: spf=pass (sender IP is 40.107.0.1)
 smtp.mailfrom=captaindns.com; dkim=pass (signature was verified)
 header.d=captaindns.com; dmarc=pass action=none
 header.from=captaindns.com; compauth=pass reason=100

Die allgemeine Syntax lautet compauth=<ergebnis> reason=<code>. Das Ergebnis nimmt einen von vier Werten an, und der dreistellige Code präzisiert den genauen Grund des Urteils.

compauth=pass / softpass / fail / none: Was bedeutet jeder Wert?

Das zusammengesetzte Ergebnis beschränkt sich nicht auf Erfolg oder Misserfolg. Microsoft unterscheidet vier Zustände, jeder mit einer präzisen Bedeutung.

Der Unterschied zwischen fail und none ist wichtig. fail signalisiert ein aktives Authentifizierungsversagen: Microsoft hat die Nachricht bewertet und ist zu dem Schluss gekommen, dass es die Identität des Absenders nicht garantieren kann. none signalisiert eine fehlende Bewertung, oft wegen eines komplexen Routings oder einer Nachricht, die bereits ein anderes Gateway durchlaufen hat.

Implizite vs. explizite Authentifizierung: der Schlüssel zum Verständnis von compauth

Dies ist die wichtigste Unterscheidung des gesamten Artikels. Microsoft 365 bewertet die Authentifizierung einer Nachricht über zwei Wege, und der Reason Code zeigt an, welcher beschritten wurde.

Die explizite Authentifizierung stützt sich auf die vom Absenderdomain veröffentlichten DNS-Einträge: SPF, DKIM und die DMARC-Richtlinie. Das ist die Standardauthentifizierung. Veröffentlicht die Domain ein striktes DMARC (p=quarantine oder p=reject) und richtet sich die Nachricht korrekt aus, ist das Urteil explizit.

Die implizite Authentifizierung ist eine Microsoft-eigene Erweiterung. Wenn eine Domain kein DMARC veröffentlicht oder eine permissive Richtlinie (p=none, SPF mit ~all oder ?all) verwendet, kann Microsoft sich nicht auf eine erklärte Absicht stützen. Es wendet dann seine eigenen Signale an, um zu entscheiden: IP-Reputation, Versandverlauf, Ausrichtung über PTR, MX der Domain. Dieser Weg erlaubt einer legitimen Nachricht ohne DMARC den Durchgang (zum Beispiel reason 109), birgt aber auch das Risiko eines impliziten Versagens (reason 001 oder 6xx), wenn die Signale unzureichend sind.

Diese Mechanik erklärt zwei Situationen, die Administratoren oft verwirren. Eine Nachricht von einer Domain ohne jede Authentifizierung kann compauth=pass erhalten, wenn ihre IP eine ausgezeichnete Reputation und einen sauberen Verlauf hat (erfolgreiche implizite Authentifizierung). Umgekehrt erhält eine Nachricht von einer Domain mit striktem, aber schlecht ausgerichtetem DMARC ein compauth=fail reason=000 (gescheiterte explizite Authentifizierung), selbst wenn die sendende IP ansonsten gut beleumundet ist.

Der explizite Weg hat stets Vorrang. Veröffentlicht die Domain ein verwertbares DMARC, wendet Microsoft dessen Richtlinie an, bevor es auf die impliziten Signale zurückgreift. Deshalb ist die Veröffentlichung eines korrekt ausgerichteten DMARC der stärkste Steuerungshebel, über den ein Absender bei seinem zusammengesetzten Urteil verfügt.

Wo finden Sie compauth=fail in Ihren Headern?

Das zusammengesetzte Urteil lesen Sie im Header Authentication-Results, doch die vollständige Analyse erfordert den Abgleich mehrerer Microsoft-Header.

Der Header Authentication-Results fasst die Urteile von SPF, DKIM, DMARC und compauth zusammen. Das ist der Ausgangspunkt. Um aber die tatsächliche Auswirkung eines compauth=fail zu verstehen, muss man auch den Header X-Forefront-Antispam-Report lesen, der die Entscheidungsfelder von EOP enthält.

Im X-Forefront-Antispam-Report sind mehrere Felder nützlich:

Hier ein kommentiertes Beispiel eines echten Headers, bei dem die zusammengesetzte Authentifizierung scheitert:

Authentication-Results: spf=none (sender IP is 203.0.113.20)
 smtp.mailfrom=marketing.captaindns.com; dkim=none (message not signed)
 header.d=none; dmarc=none action=none header.from=captaindns.com;
 compauth=fail reason=001
X-Forefront-Antispam-Report: CIP:203.0.113.20; CTRY:US;
 CAT:SPOOF; SFV:SPM; SCL:5; SFTY:9.19

Hier veröffentlicht die Domain weder ein verwertbares SPF noch DKIM noch DMARC: Die explizite Authentifizierung ist unmöglich und die implizite scheitert (reason=001). EOP stuft die Nachricht als CAT:SPOOF mit einem SCL:5 und einem Indikator SFTY:9.19 ein, was sie der Junk-E-Mail zuführt. Es ist die Verschränkung von compauth=fail und diesen Entscheidungsfeldern, die das tatsächliche Schicksal der Nachricht bestimmt.

Man muss allerdings wissen, wo man diese Header findet. In Outlook im Web öffnen Sie die Nachricht, dann das Optionsmenü und "Nachrichtendetails anzeigen", um die Rohquelle zu kopieren. Im Outlook-Desktopclient öffnen Sie die Nachricht in einem eigenen Fenster, dann Datei und Eigenschaften: Das Feld "Internetkopfzeilen" enthält alles. Auf Administratorseite ermöglicht die Nachrichtenablaufverfolgung (Message Trace) des Exchange-Admin-Centers, das EOP-Urteil einer zugestellten Nachricht abzurufen, ohne überhaupt auf das Postfach des Empfängers zuzugreifen. Für eine Diagnose im großen Maßstab gleichen die aggregierten DMARC-Berichte (RUA) die scheiternden Versandquellen ab und ergänzen die Analyse einzelner Header sinnvoll.

Um diese Header fehlerfrei zu extrahieren und zu lesen, kopieren Sie die vollständige Quelle der Nachricht und führen sie durch einen spezialisierten Analysator. Das Thema des Lesens von Headern wird in unserem Leitfaden E-Mail-Header lesen ausführlich behandelt.

Die vollständige Tabelle der compauth-Reason-Codes

Hier folgt die zentrale Referenz dieses Artikels. Die Tabelle unten ist anhand der offiziellen Microsoft-Dokumentation geprüft (Seite "Anti-spam message headers" auf Microsoft Learn, Stand 8. Oktober 2025). Jede Zeile nennt den Code, das zugehörige zusammengesetzte Ergebnis, die genaue Bedeutung laut Microsoft, die typische Ursache und die Behebung.

Genauigkeitshinweis: die Codes 604, 605 und 703

Manche Drittanbieter-Tools (darunter kommerzielle DMARC-Analysatoren) nennen die Codes 604, 605 und 703 als eigenständige compauth-Reason-Codes. Diese Codes erscheinen nicht in der aktuellen offiziellen Microsoft-Dokumentation. In der Familie 6xx dokumentiert Microsoft nur den Code 601. In der Familie 7xx deckt die Dokumentation den Bereich 701-704 ab, ohne 703 mit einer eigenen Bedeutung herauszustellen. Weder ein 604 noch ein 605 ist definiert.

Wir erfinden ihnen daher keine Bedeutung. Sollten Sie einem dieser Codes begegnen, behandeln Sie ihn nach seiner Familie: Ein 6xx ist ein implizites Versagen (wie ein 601 zu beheben), ein 7xx ein impliziter Erfolg. Stützen Sie keine Diagnose auf eine unbelegte Definition.

Versagenscodes: 000, 001, 002, 010 und 6xx/601

Das sind die Codes, die einen Administrator dazu bringen, diesen Artikel zu lesen. Sie verteilen sich auf zwei Logiken.

Die Codes 000 und 010 betreffen das explizite Versagen: Die Domain veröffentlicht ein striktes DMARC, doch die Nachricht richtet sich nicht aus. Das 010 ist der Sonderfall, bei dem die scheiternde Domain eine akzeptierte Domain Ihrer eigenen Organisation ist. Das 000 betrifft hingegen jede externe Domain mit striktem, schlecht ausgerichtetem DMARC.

Die Codes 001, 6xx und 601 betreffen das implizite Versagen: Microsoft konnte sich nicht auf eine erklärte Richtlinie stützen, und seine internen Signale haben nicht ausgereicht. Das 601 ist der Unterfall der akzeptierten Domain der Organisation. Das 002 schließlich ist ein Sonderfall: Es spiegelt keinen technischen Mangel wider, sondern eine Administratorentscheidung (ein manueller Sperreintrag).

Erfolgscodes (1xx, 7xx) und softpass (2xx)

Die Familie 1xx umfasst die Erfolge, ob explizit (100, 101, 102) oder trotz einer Schwäche toleriert (108, 109, 111, 112). Das 130 verdient besondere Aufmerksamkeit: Es zeigt an, dass ein vertrauenswürdiger ARC-Sealer eine Nachricht retten konnte, die bei DMARC wegen einer Weiterleitung gescheitert wäre.

Die Familie 7xx umfasst die impliziten Erfolge auf Basis von Reputation und Verlauf. Die Familie 2xx (softpass) signalisiert einen schwachen Erfolg: Die Ausrichtung beruht auf dünnen Signalen wie dem PTR oder dem Subnetz. Ein softpass ist kein Versagen, sollte aber besser durch Veröffentlichung einer expliziten Authentifizierung verstärkt werden.

none-/bypass-Codes (3xx, 4xx, 9xx, 905) und NDR (501/502)

Die Familien 3xx, 4xx und 9xx entsprechen Nachrichten, die nicht bewertet wurden oder die zusammengesetzte Authentifizierung umgangen haben. Das 905 ist am aufschlussreichsten: Es signalisiert ein komplexes Routing (Durchlauf über einen On-Premises-Server oder einen Drittdienst vor Microsoft 365), das die normale Anwendung von DMARC verhindert. Die Antwort auf ein 905 ist in der Regel die Einrichtung von ARC oder eines authentifizierten Relays.

Die Codes 501 und 502 betreffen legitime NDR (Unzustellbarkeitsberichte): Microsoft wendet auf sie kein DMARC an, da sie auf einen zuvor hergestellten Kontakt antworten.

Diagnose und Behebung nach Code-Familie

Die Tabelle gibt den Überblick. Dieser Abschnitt vertieft die häufigsten Fälle und das konkrete Vorgehen.

reason=000: ein striktes DMARC, durch die Ausrichtung gebrochen

Das reason=000 bedeutet, dass die Absenderdomain ein DMARC mit p=quarantine oder p=reject veröffentlicht, die Nachricht aber die DMARC-Ausrichtung nicht erfüllt. Die DMARC-Ausrichtung verlangt, dass SPF oder DKIM erfolgreich ist und dass die geprüfte Domain mit der From:-Domain übereinstimmt. Zu beachten: Seit Mitte August 2023, wenn der Empfänger seinen MX direkt auf Microsoft 365 richtet, begnügt sich ein reason=000 gegenüber einem p=reject nicht mehr damit, die Nachricht abzuwerten, es kann zu einer Abweisung auf Gateway-Ebene führen (NDR 550 5.7.509). Bei der Behebung geht es also nicht mehr nur um den Posteingang gegen Junk, sondern um die Zustellung überhaupt.

Die häufigste Ursache ist die E-Mail-Weiterleitung. Wird eine Nachricht weitergeleitet, ändert sich die sendende IP (die IP des Weiterleitungsservers ersetzt die ursprüngliche IP), was die SPF-Ausrichtung bricht. Ist DKIM nicht vorhanden oder wird der Körper während der Übertragung verändert, scheitert auch DKIM, und DMARC scheitert somit vollständig.

Die zweite Ursache ist der Versand von einer nicht autorisierten Quelle: ein E-Mail-Dienstleister, der weder im SPF deklariert noch für die DKIM-Signatur mit Ihrer Domain konfiguriert wurde.

Die Behebung hängt vom Fall ab. Bei einer legitimen Versandquelle autorisieren Sie sie: Fügen Sie ihren include:-Mechanismus dem SPF hinzu und konfigurieren Sie die auf Ihre Domain ausgerichtete DKIM-Signatur. Bei der Weiterleitung ist ARC die einzige robuste Antwort: Der Weiterleitungsserver muss eine ARC-Signatur anbringen, und der Empfänger Microsoft 365 muss diesen Sealer als vertrauenswürdig anerkennen (was dann ein reason=130 erzeugt).

Nehmen wir ein konkretes Beispiel einer Weiterleitung, die ein reason=000 erzeugt. Eine Nachricht geht von compta@captaindns.com aus, ordnungsgemäß mit DKIM signiert mit d=captaindns.com und von einer durch das SPF der Domain autorisierten IP versandt. Am Ursprung ist alles ausgerichtet. Der Empfänger hat eine automatische Weiterleitung an ein bei Microsoft 365 gehostetes Postfach eingerichtet. Der Weiterleitungsserver leitet die Nachricht von seiner eigenen IP aus weiter, die nicht im SPF von captaindns.com steht: SPF scheitert auf Microsoft-Seite. Hat der Weiterleitungsserver zusätzlich einen Hinweis "weitergeleitete Nachricht" zum Körper hinzugefügt, stimmt der DKIM-Hash nicht mehr und DKIM scheitert ebenfalls. Das From: ist compta@captaindns.com mit einem strikten DMARC geblieben: DMARC scheitert also vollständig, und Microsoft schreibt compauth=fail reason=000. Die Nachricht ist jedoch vollkommen legitim. Nur ARC, das die ursprünglichen Authentifizierungsergebnisse über die gesamte Kette hinweg bewahrt, erlaubt es, diesen Fall zu retten, ohne die Richtlinie der absendenden Domain zu lockern.

reason=001: fehlende oder zu schwache Authentifizierung

Das reason=001 ist das implizite Versagen schlechthin. Die Domain liefert Microsoft nichts, um zu entscheiden: kein verwertbares DMARC, SPF mit ~all oder ?all, kein ausgerichtetes DKIM. Microsoft versucht eine implizite Authentifizierung, doch die Signale (IP-Reputation, Verlauf) reichen nicht für einen positiven Schluss aus.

Die Behebung ist struktureller Natur. Veröffentlichen Sie die drei Säulen der E-Mail-Authentifizierung. Ein korrektes SPF, das alle Ihre Versandquellen deklariert, auf Ihre Domain ausgerichtete DKIM-Signaturen und einen DMARC-Eintrag. Beginnen Sie DMARC mit einem korrekt ausgerichteten p=none, um zu beobachten, ohne zu blockieren, und verschärfen Sie dann auf p=quarantine, sobald Ihre Quellen beherrscht sind. Entwickeln Sie auf SPF-Seite den abschließenden Mechanismus von ~all zu -all, sobald Sie der Vollständigkeit Ihrer Quellen sicher sind.

Eine wichtige Nuance: Eine Domain mit p=none oder ein SPF mit ~all ist nicht "kaputt", sondern nur permissiv. Microsoft deutet diese Permissivität als fehlende klare Absicht und schaltet auf die implizite Authentifizierung um. Das reason=001 ist also nicht die Strafe für einen Syntaxfehler, sondern die Feststellung, dass die Domain Microsoft nichts gibt, um auf dem Standardweg positiv zu schließen. Genau deshalb lässt das Verschärfen der Richtlinien den Code verschwinden: Sie verlagern die Bewertung vom impliziten Weg (unsicher) auf den expliziten Weg (deterministisch).

reason=010 und reason=601: das innerbetriebliche Spoofing

Diese beiden Codes teilen ein Merkmal: Die Absenderdomain ist eine akzeptierte Domain Ihrer eigenen Microsoft-365-Organisation. Anders gesagt: Eine Nachricht gibt vor, von Ihrer Domain zu stammen, doch Microsoft kann nicht bestätigen, dass sie tatsächlich von einer autorisierten Quelle versandt wurde. Das 010 entspricht dem expliziten Teil (striktes DMARC scheitert), das 601 dem impliziten Teil.

Das ist ein in der Praxis äußerst häufiges Szenario: Ein Netzwerkdrucker, eine Geschäftsanwendung, ein CRM, ein Abrechnungstool oder ein Marketing-Dienstleister versendet E-Mails "im Namen" Ihrer Domain, ohne in Ihrem SPF deklariert oder für DKIM konfiguriert worden zu sein. Microsoft deutet das als potenzielles internes Spoofing. Dieser Mechanismus hängt mit dem "via"-Hinweis zusammen, den Microsoft 365 mitunter anzeigt; wir behandeln ihn ausführlich in unserem Artikel über innerbetriebliches Spoofing und den Microsoft-Hinweis.

Die Behebung besteht darin, die legitime Quelle ausdrücklich zu autorisieren. Drei Optionen, in der Reihenfolge der Präferenz: die Quelle Ihrem SPF-Eintrag hinzufügen und sie für die DKIM-Signatur mit Ihrer Domain konfigurieren; ihre Sendungen über ein authentifiziertes SMTP-Relay Ihres Mandanten leiten; als letztes Mittel einen Eintrag in der Tenant Allow/Block List erstellen. Vermeiden Sie es, sich dauerhaft auf die Zulassungsliste zu stützen: Das ist ein Übergangsfix, keine Authentifizierung.

reason=002: eine manuelle Sperre durch die Mandantenrichtlinie

Das reason=002 spiegelt keinen technischen Mangel wider. Es signalisiert, dass ein Administrator dieses Absender-/Domain-Paar ausdrücklich gesperrt hat, in der Regel über die Tenant Allow/Block List oder eine Anti-Spoofing-Regel. Ist der Absender legitim, ist die Behebung einfach: den Sperreintrag entfernen. Prüfen Sie vorher, warum die Sperre gesetzt wurde, um keine aus gutem Grund geschlossene Tür wieder zu öffnen.

reason=130: ein ARC-Sealer hat das DMARC-Versagen legitim ersetzt

Das reason=130 ist ein Erfolg, kein Problem. Es zeigt an, dass eine Nachricht bei DMARC gescheitert wäre (typischerweise wegen einer Weiterleitung), ein vertrauenswürdiger ARC-Sealer aber die ursprünglichen Authentifizierungsergebnisse bewahrt hat, was Microsoft akzeptiert hat. Das ist genau das gewünschte Verhalten für eine legitime Weiterleitung. Sehen Sie diesen Code, funktioniert Ihre ARC-Kette. Die Funktionsweise von ARC wird in unserem Leitfaden Was ist ARC (Authenticated Received Chain) ausführlich beschrieben.

Bedeutet compauth=fail, dass meine E-Mail blockiert ist?

Nein, im Regelfall, aber mit einem wichtigen Vorbehalt seit 2023. Die Microsoft-Dokumentation bleibt im Grundsatz eindeutig: Ein compauth=fail löst für sich allein weder eine Abweisung noch eine automatische Quarantäne aus. Das zusammengesetzte Urteil ist ein Faktor unter mehreren in der ganzheitlichen Bewertung von EOP. Das gilt insbesondere für ein implizites Versagen (reason=001) und für Domains ohne striktes DMARC: Die Nachricht wird dann ganzheitlich bewertet und landet oft in der Junk-E-Mail, nicht abgewiesen.

Der Vorbehalt betrifft das explizite Versagen gegenüber einer strikten DMARC-Richtlinie. Seit Mitte August 2023 setzt Exchange Online Protection die vom Absenderdomain veröffentlichte DMARC-Richtlinie standardmäßig durch, wenn die Empfängerdomain ihren MX direkt auf Microsoft 365 richtet. Ein DMARC-Versagen gegen p=reject führt dann zu einer Abweisung auf Gateway-Ebene (mit einem Unzustellbarkeitsbericht, NDR), und p=quarantine zu einer Quarantäne, statt des früheren Verhaltens, das alles als Junk einstufte. Diese Änderung stammt aus der Anti-Phishing-Einstellung "DMARC-Richtlinie durchsetzen, wenn eine Nachricht als Spoofing erkannt wird", standardmäßig aktiv, mit konfigurierbaren, getrennten Aktionen für p=quarantine und p=reject. Konkret kann ein als reason=000 typisiertes explizites Versagen gegen ein p=reject nun am Gateway abgewiesen werden, nicht mehr nur als Junk eingestuft. Der zurückgegebene NDR hat die Form: 550 5.7.509: Access denied, sending domain ... does not pass DMARC verification and has a DMARC policy of reject.

Ein Vorbehalt im Vorbehalt: Diese standardmäßige Abweisung greift, wenn der MX des Empfängers direkt auf Microsoft 365 zeigt. Zeigt der MX auf ein vor Microsoft 365 platziertes Drittanbieter-Gateway, setzt EOP die DMARC-Richtlinie nur durch, wenn die "erweiterte Filterung für Connectors" (Enhanced Filtering for Connectors) aktiviert ist, denn es muss die tatsächliche sendende IP hinter dem Relay ermitteln können.

Nachdem das zusammengesetzte Urteil festgestellt ist, kombiniert EOP diese Information mit anderen Signalen, um über das Schicksal der Nachricht zu entscheiden: dem SCL (Spam Confidence Level), der Kategorie CAT, dem Sicherheitsindikator SFTY, der IP-Reputation, dem Inhalt der Nachricht sowie den im Mandanten konfigurierten Anti-Spam- und Anti-Phishing-Richtlinien. Eine Nachricht kann durchaus compauth=fail erhalten und trotzdem im Posteingang ankommen, wenn die anderen Signale beruhigend sind.

Umgekehrt wird die Nachricht abgewertet, wenn sich compauth=fail mit einer ungünstigen Kategorie verbindet. Ein CAT:SPOOF, begleitet von einem SFTY:9.x, lenkt die Nachricht in die Junk-E-Mail oder die Quarantäne, oft mit einem Spoofing-Warnbanner. Es ist also der Gesamtkontext, nicht das compauth allein, der über die Zustellung entscheidet.

Konkret existieren mehrere Entscheidungspfade nebeneinander. Ein compauth=fail reason=001 von einer IP mit guter Reputation, ohne verdächtigen Inhalt, kann mit einem schlichten niedrigen SCL im Posteingang landen. Dasselbe reason=001 von einer neuen oder wenig beleumundeten IP, mit typisierten Links oder Anhängen, erbt ein hohes SCL und eine Kategorie SPM oder PHSH und geht in die Junk-E-Mail. Schließlich löst ein compauth=fail mit CAT:SPOOF und SFTY:9.19 (Domain-Spoofing) den Anti-Spoofing-Schutz aus und kann direkt zur Quarantäne führen. Derselbe Wert compauth=fail erzeugt also drei verschiedene Ausgänge je nach der ihn umgebenden Signalumgebung.

Diese Logik hat eine praktische Konsequenz. Ein compauth=fail zu beheben heißt nicht nur, eine Markierung verschwinden zu lassen: Es geht darum, das von Microsoft wahrgenommene Gesamtrisiko zu senken. Das Ausrichten von SPF, DKIM und DMARC hebt das zusammengesetzte Urteil in Richtung pass, verbessert aber auch die Reputation Ihrer Infrastruktur auf Dauer, was auf die Gesamtheit der Signale wirkt. Landen Ihre Nachrichten trotz korrekter Authentifizierung in der Junk-E-Mail, behandelt unser Leitfaden Warum Ihre E-Mails im Spam landen die übrigen Hebel der Zustellbarkeit.

Empfohlener Aktionsplan zur Behebung eines compauth=fail

Hier das Vorgehen, von der Diagnose bis zur Überprüfung, anwendbar unabhängig vom Reason Code.

Für die Schritte SPF und DKIM beschleunigen zwei Tools die Diagnose: Der SPF-Prüfer bestätigt die Ausrichtung und zählt die DNS-Abfragen, und der DKIM-Prüfer validiert die Veröffentlichung und Syntax Ihres Schlüssels. Die detaillierten Ursachen eines Signaturversagens behandelt unser Leitfaden DKIM fail: Ursachen und Behebung, und die SPF-Fehler SPF permerror: Diagnose und Behebung sowie SPF: zu viele DNS-Abfragen.

Die neuen Anforderungen von Microsoft für Versender mit hohem Volumen

Das compauth von Exchange Online Protection betrifft die von Microsoft-365-Organisationen empfangene Post. Parallel dazu hat Microsoft die Latte für die eingehende Post in seinen Verbraucher-Postfächern bei Outlook höher gelegt. Diese beiden Mechanismen sind verschieden, laufen aber auf dieselbe Anforderung hinaus: seine Post authentifizieren.

Seit dem 5. Mai 2025 muss jeder Versender von mehr als 5.000 Nachrichten pro Tag an Verbraucher-Postfächer @outlook.com, @hotmail.com und @live.com die drei Säulen SPF, DKIM und DMARC veröffentlichen, mit einer DMARC-Richtlinie von mindestens p=none, ausgerichtet auf SPF oder DKIM. Diese Schwelle übernimmt die bereits von Gmail und Yahoo im Februar 2024 auferlegte Logik.

Laut Microsoft werden nicht konforme Nachrichten zunächst in die Junk-E-Mail geleitet und dann, nach einer anfänglichen Filterphase, abgewiesen (nicht zugestellt). Die zugehörige Abweisung hat die Form: 550 5.7.515 Access denied, sending domain [Domain] does not meet the required authentication level.

Ein wesentlicher Punkt zur Vermeidung jeder Verwechslung mit dem Rest dieses Artikels: Diese Anforderungen zielen auf die Verbraucher-Postfächer Outlook, Hotmail und Live und beruhen auf einem anderen Mechanismus als dem compauth von Exchange Online Protection auf der Microsoft-365-Unternehmensseite. Schon die SMTP-Codes unterscheiden sich: 5.7.515 signalisiert ein Authentifizierungsdefizit auf der Verbraucherseite mit hohem Volumen, während 5.7.509 einer von EOP durchgesetzten DMARC-Abweisung auf der Unternehmensseite entspricht (siehe oben). Verwechseln Sie die beiden nicht.

Die gute Nachricht ist, dass die Herstellung der Konformität auch das Grundproblem löst, das dieser Leitfaden behandelt. Ausgerichtetes SPF, DKIM und DMARC zu veröffentlichen, um diese Hürde zu nehmen, beseitigt schon konstruktionsbedingt die Ursachen eines reason=001 (implizites Versagen): Die Microsoft-Bewertung wechselt dann vom impliziten Weg (unsicher) zum expliziten Weg (deterministisch). Die Linie ist klar: Microsoft setzt DMARC 2023 auf EOP-Seite standardmäßig durch, schreibt dann 2025 den großen Outlook-Versendern die Authentifizierung vor, im Gefolge von Gmail und Yahoo. Die E-Mail-Authentifizierung ist nicht mehr optional.

📖 Glossar

• Authentication-Results: Header (RFC 7001/8601), den der empfangende Server hinzufügt und der die Urteile von SPF, DKIM, DMARC und, bei Microsoft, compauth festhält.
• Zusammengesetzte Authentifizierung (compauth): proprietäres Urteil von Microsoft 365, das SPF, DKIM, DMARC und interne Signale aggregiert.
• Explizite Authentifizierung: Bewertung auf Basis der veröffentlichten DNS-Einträge (SPF, DKIM, DMARC-Richtlinie).
• Implizite Authentifizierung: Bewertung auf Basis der internen Signale von Microsoft (Reputation, Verlauf, PTR) in Ermangelung einer verwertbaren Richtlinie.
• Ausrichtung: Übereinstimmung zwischen der durch SPF (5321.MailFrom) oder DKIM geprüften Domain und der sichtbaren From:-Domain (5322.From).
• Reason Code: dreistelliger Code, der den Grund des zusammengesetzten Urteils präzisiert.
• ARC-Sealer: Dienst, der eine ARC-Signatur (RFC 8617) anbringt, die die Authentifizierungsergebnisse während einer Weiterleitung bewahrt.
• SCL / SFTY / CAT: Entscheidungsfelder von Exchange Online Protection (Spam-Level, Sicherheitsindikator, Urteilskategorie).

Quellen

• Microsoft Learn: Anti-spam message headers in EOP (Doku Stand 8. Oktober 2025)
• Microsoft Learn: Email authentication in Microsoft 365
• Microsoft Learn: Use DMARC to validate email
• Microsoft Tech Community: Announcing new DMARC policy handling defaults for enhanced email security (2023)
• Microsoft Tech Community: Strengthening Email Ecosystem: Outlook's new requirements for high-volume senders (2025)
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 8617: The Authenticated Received Chain (ARC) Protocol