ARC & SEG für Microsoft 365 — Trusted ARC Sealers und Defender
Microsoft 365 bringt ARC bereits mit: Exchange Online validiert eingehende ARC-Ketten und signiert weitergeleitete Nachrichten im Microsoft-Ökosystem automatisch. Die Konfigurationsaufgabe ist, externen Weiterleitungsdiensten über die Trusted-ARC-Sealers-Liste zu vertrauen. Als integriertes Secure Email Gateway dient Microsoft Defender for Office 365 in Plan 1 und Plan 2 — aufbauend auf Exchange Online Protection. Diese Anleitung zeigt ARC-Konfiguration, SEG-Schicht und Verifikation.
ARC und SEG für Microsoft 365 und Exchange Online
Microsoft 365 ist bei ARC eine der wenigen Plattformen mit nativer Unterstützung: Exchange Online validiert eingehende ARC-Ketten und versiegelt weitergeleitete Nachrichten innerhalb des Microsoft-Ökosystems seit 2019 automatisch. Der einzige aktive Konfigurationsschritt betrifft externe Weiterleitungsdienste — über die Trusted-ARC-Sealers-Liste, die seit Juni 2022 pro Tenant einstellbar ist. Ein vertrauenswürdiger ARC-Sealer kann eine DMARC-Fehlschlagung überschreiben.
Als Secure Email Gateway braucht Microsoft 365 keine Drittlösung: Exchange Online Protection (EOP) ist in allen Cloud-Postfächern enthalten und liefert Anti-Spam, Anti-Malware und Connection-Filtering. Microsoft Defender for Office 365 Plan 1 ergänzt Safe Links, Safe Attachments (Sandboxing) und KI-gestützten Anti-Phishing-Schutz; Plan 2 fügt Threat Explorer, Automated Investigation and Response (AIR) und Angriffssimulationstraining hinzu. Die Microsoft-Dokumentation (learn.microsoft.com, Abruf 2026-05-21) beschreibt die ARC-Konfiguration im Detail.
Hardening-Pfad: MX → SPF → DKIM → DMARC → DMARC-Enforcement → MTA-STS → DNS-Sicherheit → ARC & SEG (dieser Guide). Bedrohungs-Cluster: Defender for Office 365 ist die zentrale Abwehr gegen Phishing und Business Email Compromise.
Microsofts ARC-Implementierung ist produktiv und funktioniert — gleichzeitig sollten Sie wissen, dass ARC (RFC 8617) den IETF-Status Experimental trägt und das Working-Group-Dokument draft-ietf-dmarc-arc-to-historic (Stand 22. April 2026) eine Reklassifizierung als Historic empfiehlt. Nachfolger ist DKIM2. Für Microsoft-365-Kunden heißt das: Die Trusted-ARC-Sealers-Konfiguration weiter pflegen — sie wirkt heute real für Forwarding-Szenarien — aber keine darüber hinausgehenden ARC-Investitionen planen.
ARC-Status und MX-Pattern von Microsoft 365 prüfen
Bevor Sie ARC-Sealer konfigurieren, prüfen Sie den Ist-Zustand: das MX-Pattern für die Stack-Detection, die DMARC-Policy als Voraussetzung der gesamten Authentifizierungskette und das ARC-Ergebnis im Header einer weitergeleiteten Test-Mail.
# Microsoft-365-MX-Pattern prüfen (Stack-Detection)
dig MX ihre-domain.de +short
# Erwartet: 0 ihrtenant.mail.protection.outlook.com.
# DMARC-Policy der eigenen Domain (Voraussetzung der gesamten Kette)
dig TXT _dmarc.ihre-domain.de +short
# Erwartet: v=DMARC1; p=quarantine; ... oder v=DMARC1; p=reject; ...
# ARC-Ergebnis im Header einer eingehenden, weitergeleiteten Mail
# (Outlook: Datei -> Eigenschaften -> Internetkopfzeilen)
# Erwartet u. a.:
# Authentication-Results: ...; arc=pass (i=1 ...)
# X-Forefront-Antispam-Report: ...; compauth=pass reason=130
# reason=130 = DMARC hätte versagt, aber ein vertrauenswürdiger
# ARC-Sealer hat die Original-Authentifizierung bestätigt.Exchange Online schreibt das ARC-Ergebnis in den X-Forefront-Antispam-Report-Header. compauth=pass reason=130 bedeutet: Die reguläre DMARC-Prüfung wäre fehlgeschlagen, aber ein als vertrauenswürdig konfigurierter ARC-Sealer hat die ursprünglichen Authentifizierungsergebnisse bestätigt — die E-Mail wird trotzdem zugestellt. Erscheint dieser Wert nicht, obwohl Sie Forwarding nutzen, fehlt der entsprechende Sealer in der Trusted-ARC-Sealers-Liste.
Trusted ARC Sealers im Microsoft Defender Portal konfigurieren
Trusted ARC Sealers legen fest, welchen weiterleitenden Diensten Exchange Online bei der ARC-Auswertung vertraut. Die Konfiguration erfolgt im Microsoft Defender Portal oder per Exchange Online PowerShell. Tragen Sie ausschließlich Domains ein, von denen Sie tatsächlich regelmäßig weitergeleitete E-Mails erhalten — etwa Google Groups oder konkrete Mailinglisten-Server.
# Trusted ARC Sealers per Exchange Online PowerShell setzen
# WICHTIG: nur Sealer hinzufügen, von denen real weitergeleitete
# Mail eingeht - sonst wird der DMARC-Schutz untergraben.
Set-ArcConfig -Identity Default -ArcTrustedSealers "google.com","mx.beispiel-liste.org"
# Aktuelle ARC-Konfiguration anzeigen
Get-ArcConfig | Format-List
# GUI-Weg im Microsoft Defender Portal:
# security.microsoft.com
# -> E-Mail & Zusammenarbeit -> Richtlinien & Regeln
# -> Bedrohungsrichtlinien -> E-Mail-Authentifizierungseinstellungen
# -> Tab ARC -> Vertrauenswürdige ARC-Absiegler hinzufügenJeder Eintrag in der Trusted-ARC-Sealers-Liste ist ein Stück abgegebenes Vertrauen: Exchange Online akzeptiert von diesem Sealer ARC-Ketten, die DMARC sonst verwerfen würde. Fügen Sie deshalb nur Sealer hinzu, deren ARC-Implementierung Sie als seriös einschätzen und von denen real Mail eingeht. Eine pauschale Aufnahme vieler Domains untergräbt den DMARC-Schutz Ihrer Empfänger-Domain. Die Konfiguration ist tenant-weit und ergänzt — sie ersetzt nicht — die DMARC-Auswertung.
Die offizielle Microsoft-Dokumentation (learn.microsoft.com/en-us/defender-office-365/email-authentication-arc-configure, Abruf 23. Mai 2026) gibt einen exemplarischen Konfigurations-Befehl mit zwei Sealer-Domains: Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.com". Praktisch typische Sealer-Domains in DACH-Setups sind der Mailinglisten-Hoster Ihrer Organisation (z. B. lists.beispiel-verein.de), Google Groups (google.com als Sealer-Domain), oder ein vertrauenswürdiger Forwarder wie GMX/WEB.DE im Fall von Adress-Umleitungen. Wichtige Mechanik: Der Domain-Wert muss exakt dem d=-Wert in den ARC-Seal- und ARC-Message-Signature-Headern entsprechen. Sie finden den Wert über den Microsoft Message Header Analyzer oder in Outlook unter Datei → Eigenschaften → Internetkopfzeilen. Replace-Verhalten beachten: Set-ArcConfig überschreibt die gesamte Liste, fügt nicht hinzu — vor einem Add die aktuelle Liste mit Get-ArcConfig auslesen, neue Domain ergänzen, dann mit allen Domains zusammen erneut setzen.
SEG-Schicht — Microsoft Defender for Office 365 aktivieren
Microsoft 365 bietet das Secure Email Gateway integriert. Exchange Online Protection (EOP) ist in jedem Cloud-Postfach aktiv. Microsoft Defender for Office 365 Plan 1 (enthalten in Business Premium, als Add-on zu E3) bringt Safe Links und Safe Attachments; Plan 2 (in E5) ergänzt Post-Breach-Funktionen. Aktivieren Sie die Schutzschicht über die voreingestellten Sicherheitsrichtlinien.
Im Defender-Portal unter E-Mail & Zusammenarbeit → Richtlinien & Regeln → Bedrohungsrichtlinien finden Sie die voreingestellten Sicherheitsrichtlinien. Standard Protection passt für die meisten Postfächer; Strict Protection empfiehlt sich für Geschäftsführung, Finanzabteilung und andere hochwertige Ziele. Ein zusätzliches dediziertes SEG lohnt sich für M365-Kunden nur bei regulatorischen Vorgaben für ein eigenständiges Gateway, in Multi-Cloud-Umgebungen oder bei branchenspezifischen KRITIS-Anforderungen.
Verifikation per Authentication-Results-Header und Defender-Dashboard
Die ARC-Konfiguration prüfen Sie an einer real weitergeleiteten E-Mail: Senden Sie eine Nachricht über eine Mailingliste an ein Microsoft-365-Postfach und kontrollieren Sie die Internetkopfzeilen. Die SEG-Wirkung zeigt das Defender-Portal — bei Plan 2 detailliert im Bedrohungs-Explorer.
# 1. Test-Mail über eine Mailingliste / Weiterleitung an ein
# Microsoft-365-Postfach senden.
# 2. Internetkopfzeilen der empfangenen E-Mail öffnen.
# 3. Prüfen:
# Authentication-Results: ...; arc=pass ...
# X-Forefront-Antispam-Report: ...; compauth=pass reason=130
# SEG-Wirkung: Defender-Portal -> Bedrohungs-Explorer (Plan 2)
# zeigt blockierte Phishing-/Malware-Mails pro Tag.
# Plan 1: E-Mail-Entitätsseite zeigt Safe-Links-/Safe-Attachments-Verdikte.
# Wolf-Agents Email Security Check: erkennt das
# *.mail.protection.outlook.com-MX-Pattern automatisch und
# prüft ARC-Detection plus SEG-Status der Domain.
Ergänzend prüfen Sie mit dem Wolf-Agents Email Security Check — dieser erkennt Microsoft-365-Domains automatisch über das MX-Suffix *.mail.protection.outlook.com, bewertet die ARC-Detection und gleicht die MX-Records gegen die SEG-Provider-Datenbank ab. Das Monitoring überwacht die E-Mail-Sicherheit alle 6 Stunden.
Häufige Fehler bei ARC & SEG für Microsoft 365
Trusted ARC Sealers pauschal mit vielen Domains gefüllt
Problem: Um Forwarding-Probleme schnell zu lösen, werden zahlreiche Domains als ARC-Sealer hinzugefügt. Ursache: Jeder Sealer darf DMARC-Fehlschlagungen überschreiben — eine lange Liste öffnet ein Einfallstor für Spoofing über fremde ARC-Ketten. Lösung: Nur konkret benötigte, vertrauenswürdige Sealer eintragen und die Liste regelmäßig prüfen.
ARC-Einstellungen im Microsoft-365-Admin-Center gesucht
Problem: Die ARC-Konfiguration wird im Microsoft 365 Admin Center (admin.microsoft.com) gesucht. Ursache: ARC ist eine Sicherheitsfunktion und gehört ins Microsoft Defender Portal. Lösung: Unter security.microsoft.com → E-Mail-Authentifizierungseinstellungen → Tab ARC konfigurieren, alternativ per Set-ArcConfig.
„Wir haben Defender — wir brauchen kein DMARC“
Problem: Das integrierte SEG wird als Ersatz für SPF/DKIM/DMARC betrachtet. Ursache: Verwechslung der Schutzrichtungen — DMARC verhindert Missbrauch der eigenen Domain durch Dritte, ein SEG schützt die eigenen Postfächer vor eingehenden Bedrohungen. Lösung: Beide Schichten parallel betreiben — DMARC mit Enforcement-Policy plus Defender.
Externes SEG vor M365 ohne Enhanced Filtering
Problem: Ein drittes SEG ist vorgeschaltet, danach erkennt Exchange Online SPF und ARC nicht mehr korrekt. Ursache: Exchange Online wertet die IP des vorgeschalteten SEG aus statt der Original-Absender-IP. Lösung: Das Enhanced Filtering for Connectors (Skip Listing) für den eingehenden Connector des SEG aktivieren, damit Microsoft die Original-Header auswertet.
Compliance: NIS2 lit. a + lit. d, BSI APP.5.3.A4, DSGVO mit Microsoft 365
Microsoft Defender for Office 365 als integriertes SEG zahlt direkt auf NIS2 Art. 21 Abs. 2 lit. a ein („Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme“) und setzt die BSI-IT-Grundschutz-Basis-Anforderung APP.5.3.A4 um (Spam- und Schadsoftware-Prüfung auf dem E-Mail-Server). Die ARC-Validierung sichert die Authentifizierungskette über Weiterleitungen und Drittanbieter ab und unterstützt damit lit. d (Sicherheit der Lieferkette). Microsoft 365 ist DSGVO-konform mit der EU Data Boundary, deren Rollout 2024 abgeschlossen wurde.
Microsoft-365-ARC-SEG-Compliance-Stack: NIS2 lit. a (SEG als Defense-in-Depth-Schicht) + NIS2 lit. d (ARC sichert die Forwarding-Lieferkette) + BSI IT-Grundschutz APP.5.3.A4 (Spam-/Schadsoftware-Prüfung) + DSGVO Art. 32 (Schutz personenbezogener Daten) + Microsoft EU Data Boundary 2024. Wolf-Agents-USP: Der Email Security Check erkennt Microsoft-365-Domains automatisch über das Pattern *.mail.protection.outlook.com, bewertet ARC-Detection und SEG-Status im 165-Punkte-Scanner (ARC und SEG als je 5 Bonuspunkte) und weist transparent aus, dass API-basierte ICES-Lösungen für MX-basierte Erkennung unsichtbar bleiben. Cross-Verweis: Phishing und Business Email Compromise.
ARC- und SEG-Anleitung für weitere Provider:
Wie steht Ihre Domain bei ARC & SEG · Microsoft 365?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.