Microsoft 365

Einfache Kurzanleitung zum Einrichten von MS 365 mit SecuMail.
SecuMail Filter – SecuMail Encryption

Empfangsweg

Sendeweg

API-Sync

Tests und Tools


Allgemeines zur MS-365 Integration

Voraussetzungen | PowerShell | Hinweise


Voraussetzungen & Rechte


Portal oder PowerShell?

Alle Schritte in diesen Anleitungen lassen sich sowohl über die Microsoft Admin-Portale (Exchange Admin Center, Entra ID Portal, Security Portal) als auch per PowerShell ausführen.

Wir dokumentieren primär den Portal-Weg, weil:

  • Portal-Anleitungen sind für die meisten Administratoren zugänglicher und intuitiver
  • Suchbegriffe und Konzepte ändern sich seltener als exakte Menüpfade oder PowerShell-Syntax
  • Einstellungen lassen sich im Portal visuell prüfen

PowerShell-Befehle sind als optionale Alternative angegeben. Sie eignen sich besonders für:

  • Automatisierung und Skripte
  • Schnelle Prüfung bestehender Konfiguration (Get-Befehle)
  • Dokumentation und Reproduzierbarkeit

Wichtig: Da Microsoft die Portal-Oberfläche regelmässig ändert, verwenden wir Suchbegriffe statt exakter Klickpfade. Nutzen Sie die Suchfunktion im jeweiligen Admin-Portal, um die beschriebenen Einstellungen zu finden.

Diese Voraussetzungen gelten für alle FAQ-Cases. Bitte stellen Sie sicher, dass diese erfüllt sind, bevor Sie mit der Konfiguration beginnen.

Benötigte Rechte im MS365-Tenant

  • Exchange Administrator (oder höher) für Connector- und Transport-Rule-Konfiguration (Cases 1a, 1b, 2a, 2b, 2c, 7)
  • Security Administrator für ARC-Konfiguration (Case 2c)
  • Global Administrator oder Application Administrator für App-Registrierungen und Admin Consent (Cases 3a, 3b)

Admin-Portale (Übersicht)

Für die Konfiguration werden folgende Portale verwendet:

Exchange Admin Center (EAC): URL: https://admin.exchange.microsoft.com Suche nach: "Exchange admin center" im Microsoft 365 Admin Center Verwendet für: Connectors, Transport Rules, Message Trace

Microsoft 365 Defender / Security Portal: URL: https://security.microsoft.com Suche nach: "Security" im Microsoft 365 Admin Center Verwendet für: ARC-Konfiguration, Antispam-Policies

Entra ID Portal (ehemals Azure AD): URL: https://entra.microsoft.com Suche nach: "Entra" oder "Azure Active Directory" Verwendet für: App-Registrierungen (Cases 3a, 3b)

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-allgemein-voraussetzungen-rechte.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.



PowerShell einrichten (optional)


PowerShell-Module installieren

Falls Sie PowerShell verwenden möchten:

Für Connector- und Transport-Rule-Konfiguration: Exchange Online Management Modul (V3+)

Für Graph-API-Cases (3a, 3b) zusätzlich: Microsoft Graph PowerShell SDK

Prüfung installierter Module:

Verbindung herstellen: Exchange Online

Hinweis: Bei aktivierter MFA (Multi-Faktor-Authentifizierung) öffnet sich ein Browser-Fenster zur interaktiven Anmeldung. Der Parameter -UserPrincipalName ist optional, beschleunigt aber die Anmeldung.

Verbindung herstellen: Microsoft Graph (nur Cases 3a, 3b)

Hinweis: Der Scope wird je nach Bedarf angepasst. Für reine Leseoperationen genügt "Group.Read.All".

Verbindung trennen

Nach Abschluss der Konfiguration die Verbindungen trennen:

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-allgemein-powershell.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.



Allgemeine Hinweise & Haftungsausschluss


Allgemeine Hinweise

  • Die Konfiguration kann vollständig im Portal durchgeführt werden. PowerShell ist optional.
  • Für die Portal-Konfiguration benötigen Sie einen aktuellen Browser (Edge, Chrome, Firefox).
  • Falls Sie PowerShell verwenden: Führen Sie PowerShell als Administrator aus.
  • Die PowerShell-Module erfordern PowerShell 5.1 (Windows) oder PowerShell 7+ (Windows, macOS, Linux).
  • Bei Problemen mit der Modulinstallation: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
  • Änderungen an Connectors und Transport Rules werden in der Regel innerhalb weniger Minuten aktiv. In seltenen Fällen kann es bis zu einer Stunde dauern.

Hinweis zu den PowerShell-Befehlen: Die Befehle in diesen Anleitungen dienen als Referenz. Sie wurden nicht in allen Tenant-Konfigurationen getestet. Insbesondere bei Tenants mit Custom-Policies oder speziellen Sicherheitsrichtlinien können Abweichungen auftreten. Die Get-Befehle zur Prüfung sind in der Regel unbedenklich. Bei Set- und New-Befehlen empfehlen wir dringend, diese zuerst in einer Testumgebung auszuführen.

Haftungsausschluss

Diese Anleitungen werden ohne Gewähr bereitgestellt. Die Umsetzung erfolgt auf eigene Verantwortung. SecuMail übernimmt keine Haftung für Schäden, Fehlkonfigurationen oder Ausfälle, die durch die Anwendung dieser Anleitungen entstehen. Die Angaben können Fehler enthalten oder durch Änderungen seitens Microsoft veraltet sein. Prüfen Sie kritische Einstellungen vor der Umsetzung in einer Testumgebung oder im Einzelfall mit dem Microsoft-Support.

Die PowerShell-Befehle wurden nicht in allen Umgebungen getestet. Prüfen Sie kritische Befehle vor der Ausführung in einer Testumgebung. Insbesondere Set- und New-Cmdlets sollten Sie vor dem produktiven Einsatz in einer Testumgebung validieren.

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-allgemein-hinweise.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.






MS365 Konfiguration - Empfangsweg

Für E-Mails, die Ihre Organisation aus dem Internet empfängt.


Empfangsweg - IP-Whitelist


Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: EMPFOHLEN

Ziel

Die IP-Adressen der SecuMail-Server in MS365 als vertrauenswürdige Quelle hinterlegen (Inbound Connector). Damit erkennt MS365, dass Mails über SecuMail vorgeprüft ankommen.

Warum

  • Der MS365-eigene Spamfilter (EOP) greift weniger aggressiv ein, wenn die Quelle bekannt und gewhitelistet ist.
  • MS365 drosselt Verbindungen von unbekannten IPs. Whitelisting reduziert Throttling und verbessert die Zustellgeschwindigkeit.

Voraussetzungen

Schritt 1: Inbound Connector anlegen EMPFOHLEN

Der Connector vom Typ "Partner" nimmt Mails von den angegebenen SecuMail-IPs entgegen und erzwingt TLS.

Im Exchange Admin Center (EAC): Suche nach: "Connectors" oder navigieren zu Mail flow > Connectors

  • "Connector hinzufügen" (Add a connector)
  • Verbindung von: "Partnerorganisation" (Partner organization)
  • Verbindung zu: "Office 365"
  • Name: "SecuMail Inbound"
  • Authentifizierung: "Absender-IP-Adresse" auswählen
  • IP-Adressen: 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27
  • TLS erzwingen: Aktivieren (Häkchen setzen)
  • Enhanced Filtering konfigurieren (siehe Abschnitt unten) Ergebnis: Ein Inbound Connector der Mails von SecuMail-IPs akzeptiert

Enhanced Filtering im Connector aktivieren: Im erstellten Connector unter den erweiterten Einstellungen: Suche nach: "Enhanced Filtering" oder "Erweiterte Filterung"

  • "Skip these IP addresses" / "Diese IP-Adressen überspringen": Dieselben IP-Adressen eintragen: 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27
  • "Skip last IP" NICHT aktivieren (deaktiviert lassen) Ergebnis: EOP erkennt die echte Quell-IP hinter SecuMail

Hinweis: Die SenderIPAddresses und EFSkipIPs müssen identisch sein. Die oben eingesetzten Werte stammen aus der aktuellen Konfiguration.

Der Connector macht drei Dinge gleichzeitig:

  • IP-Whitelist (SenderIPAddresses)
  • TLS erzwingen (RequireTls)
  • Enhanced Filtering (EFSkipIPs) — damit EOP die echte Quell-IP erkennt statt nur die SecuMail-IP
  • ConnectorType: Partner
  • SenderIPAddresses: Die hinterlegten SecuMail-IP-Bereiche
  • RequireTls: True
  • EFSkipIPs: Die hinterlegten SecuMail-IP-Bereiche
  • EFSkipLastIP: False
  • Enabled: True

Ändern bestehender Konfiguration:

Wenn der Connector bereits existiert und IP-Bereiche aktualisiert werden müssen (SenderIPAddresses und EFSkipIPs immer gemeinsam aktualisieren):

Im Exchange Admin Center (EAC): Suche nach: "Connectors" oder navigieren zu Mail flow > Connectors

  • Connector "SecuMail Inbound" öffnen
  • IP-Adressen aktualisieren
  • Enhanced Filtering IP-Adressen ebenfalls aktualisieren

Schritt 2: Enhanced Filtering — Hintergrund EMPFOHLEN

Warum Enhanced Filtering (EFSkipIPs) wichtig ist: Ohne Enhanced Filtering sieht der MS365-Spamfilter (EOP) bei jeder eingehenden Mail nur die SecuMail-IP als Quelle. Das hat folgende Nachteile:

  • Spam-/Phishing-Erkennung leidet, weil IP-Reputation nicht korrekt ausgewertet werden kann
  • DKIM- und SPF-Validierung durch EOP basiert auf falscher Quell-IP
  • Alle Mails erscheinen als von derselben Quelle stammend

Enhanced Filtering lässt EOP hinter das Gateway schauen und die tatsächliche Absender-IP auswerten. Die Konfiguration erfolgt direkt im Connector (siehe Schritt 1, Enhanced Filtering Abschnitt).

Test: Nach Empfang einer externen Mail im Message Header prüfen:

  • X-MS-Exchange-SkipListedInternetSender: Muss die echte Quell-IP anzeigen (nicht die SecuMail-IP)
  • X-MS-Exchange-ExternalOriginalInternetSender: Muss die echte Quell-IP anzeigen

Schritt 3: TLS für den Empfangsweg prüfen EMPFOHLEN

Der Inbound Connector wurde in Schritt 1 bereits mit TLS-Erzwingung angelegt.

Falls das nachträglich geändert werden muss:

Im Exchange Admin Center (EAC): Suche nach: "Connectors" oder navigieren zu Mail flow > Connectors

  • Connector "SecuMail Inbound" öffnen
  • TLS-Einstellung prüfen: "TLS erzwingen" muss aktiviert sein
  • RequireTls: True

Hinweis für S/MIME-Produkte (Encryption, Filter+Encryption): TLS auf dem Empfangsweg ist bei S/MIME STARK EMPFOHLEN, da verschlüsselte Mails im Transport geschützt sein müssen.

Schritt 4: DNS-Einträge prüfen ZWINGEND

Ohne korrekte DNS-Konfiguration funktioniert der Mailflow nicht.

MX-Record ZWINGEND Der MX-Record der Kundendomain muss auf die SecuMail-Mailserver zeigen: mx-a.secumail.de (Prio 10) / mx-b.secumail.de (Prio 10) Damit werden eingehende Mails über SecuMail geroutet.

SPF-Record ZWINGEND Der SPF-Record der Kundendomain muss die SecuMail-Server als berechtigte Absender enthalten. Ohne korrekten SPF werden ausgehende Mails als Spam oder Spoofing eingestuft. Anleitung: https://www.secumail.de/f-a-q/#1489262272575-af5fa3ea-c5da

SecuMail-Netzwerke ZWINGEND für Connector-Konfiguration] Die aktuellen IP-Bereiche der SecuMail-Server: 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27 Referenz: https://www.secumail.de/f-a-q/#1509011751766-d54bf2b1-bc78

Wichtig: Ändern Sie den MX-Record erst, wenn alle anderen Konfigurationsschritte (Connectors, Transport Rules) abgeschlossen sind. Sonst werden Mails an SecuMail geroutet, aber MS365 ist noch nicht bereit sie zu empfangen.

Hinweise

Angaben ohne Gewähr — Umsetzung auf eigene Verantwortung.

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-empfangsweg-ip-whitelist.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.



Empfangsweg - Exklusiver Empfang


Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: OPTIONAL (Zusatz zu IP-Whitelist) Voraussetzung: Inbound Connector aus Empfangsweg: IP-Whitelist muss bereits eingerichtet sein.

Ziel

MS365-Tenant so konfigurieren, dass ausschliesslich Mails von den SecuMail-Netzwerken angenommen werden. Alle anderen eingehenden Verbindungen werden abgelehnt.

Warum

  • Ohne diese Einschränkung können Angreifer den MX-Record umgehen und Mails direkt an MS365 zustellen, ohne dass SecuMail diese prüfen kann.
  • Maximaler Schutz: Jede eingehende Mail hat den SecuMail-Filter durchlaufen.

Voraussetzungen

Schritt 1: Transport Rule anlegen OPTIONAL

Eine Transport Rule die alle eingehenden Mails ablehnt, die NICHT von den SecuMail-IPs stammen.

Im Exchange Admin Center (EAC): Suche nach: "Rules" oder navigieren zu Mail flow > Rules

  • "Regel hinzufügen" (Add a rule) > "Neue Regel erstellen" (Create a new rule)
  • Name: "Nur SecuMail-Empfang erlauben"
  • Priorität: 0 (höchste Priorität)
  • Bedingung: "Der Absender befindet sich..." (The sender is located...) > "Ausserhalb der Organisation" (Outside the organization)
  • Ausnahme: "Die IP-Adresse des Absenders befindet sich in einem dieser Bereiche..." (The sender IP address is in any of these ranges...) > 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27
  • Aktion: "Nachricht ablehnen und Erklärung angeben" (Reject the message and include an explanation) > Text: "Direktzustellung nicht erlaubt. Bitte über MX-Record senden." > Erweiterter Statuscode: 5.7.1
  • Regel aktivieren Ergebnis: Alle externen Mails werden abgelehnt, ausser sie kommen von SecuMail-IPs

Die Logik der Regel:

  • Betrifft: Alle Mails von extern (Absender ausserhalb der Organisation)
  • Ausnahme: Mails von SecuMail-IPs
  • Aktion: Ablehnung mit Fehlermeldung

Diese Regel lehnt alle externen Mails ab, AUSSER sie kommen von den SecuMail-IPs.

  • State: Enabled
  • Priority: 0
  • FromScope: NotInOrganization
  • ExceptIfSenderIpRanges: Die SecuMail-IP-Bereiche

Funktionstest

  1. Testmail von einem externen Server (nicht über SecuMail) senden. -> Muss abgelehnt werden mit "5.7.1 Direktzustellung nicht erlaubt"
  2. Testmail regulär über MX (via SecuMail) senden. -> Muss zugestellt werden.

Hinweise

  • Diese Regel hat höchste Priorität (Priority 0), damit sie vor anderen Transport Rules greift.
  • Interne Mails (innerhalb des Tenants) sind nicht betroffen (Absender ausserhalb der Organisation als Bedingung).
  • Bei Änderungen der SecuMail-Netze muss auch diese Regel aktualisiert werden.

Angaben ohne Gewähr — Umsetzung auf eigene Verantwortung.

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-empfangsweg-exklusiver-empfang.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.






MS365 Konfiguration - Sendeweg

Für E-Mails, die Ihre Organisation ins Internet versendet.


Sendeweg - Relay Filter


Produkte:

  • Filter

Priorität: ZWINGEND

Ziel

Ausgehende Mails des MS365-Tenants über relay.secumail.de:25 routen, damit SecuMail den Ausgangsfilter anwenden kann.

Wichtig

Interne Mails (innerhalb der eigenen Domain, Weiterleitungen an interne Postfächer) dürfen NICHT über das Relay gehen. Die Transport Rule muss so konfiguriert sein, dass nur Mails an externe Empfänger geroutet werden.

Voraussetzungen

Schritt 1: Outbound Connector anlegen ZWINGEND

Im Exchange Admin Center (EAC): Suche nach: "Connectors" oder navigieren zu Mail flow > Connectors

  • "Connector hinzufügen" (Add a connector)
  • Verbindung von: "Office 365"
  • Verbindung zu: "Partnerorganisation" (Partner organization)
  • Name: "SecuMail Filter Outbound"
  • Routing: "Mails über diese Smarthosts weiterleiten" (Route email through these smart hosts) > relay.secumail.de
  • TLS: "Immer TLS verwenden" (Always use TLS) aktivieren > Stufe: "Nur verschlüsseln" (Encryption only)
  • Einschränkung: Connector nur verwenden wenn eine Transport Rule darauf verweist (Transport Rule Scoped)
  • Connector aktivieren Ergebnis: Ein Outbound Connector der Mails an relay.secumail.de routet
  • ConnectorType: Partner
  • SmartHosts: {relay.secumail.de}
  • TlsSettings: EncryptionOnly
  • UseMXRecord: False
  • IsTransportRuleScoped: True
  • Enabled: True

Schritt 2: Transport Rule für ausgehende Mails ZWINGEND

Die Rule routet nur Mails an externe Empfänger über den Connector. Interne Mails bleiben im Tenant.

Im Exchange Admin Center (EAC): Suche nach: "Rules" oder navigieren zu Mail flow > Rules

  • "Regel hinzufügen" (Add a rule) > "Neue Regel erstellen" (Create a new rule)
  • Name: "Route ausgehend über SecuMail Filter"
  • Bedingung 1: "Der Absender befindet sich..." (The sender is located...) > "Innerhalb der Organisation" (Inside the organization)
  • Bedingung 2: "Der Empfänger befindet sich..." (The recipient is located...) > "Ausserhalb der Organisation" (Outside the organization)
  • Aktion: "Nachricht umleiten an den folgenden Connector" (Redirect the message to the following connector) > "SecuMail Filter Outbound" auswählen
  • Regel aktivieren Ergebnis: Ausgehende externe Mails werden über SecuMail geroutet, interne Mails bleiben unberührt

Erklärung der Bedingungen:

  • Absender innerhalb der Organisation: Nur Mails von internen Absendern
  • Empfänger ausserhalb der Organisation: Nur Mails an externe Empfänger
  • Kombination stellt sicher: Interne Mails werden nicht geroutet
  • State: Enabled
  • FromScope: InOrganization
  • SentToScope: NotInOrganization
  • RouteMessageOutboundConnector: SecuMail Filter Outbound

Schritt 3: TLS für den Sendeweg EMPFOHLEN

Der Outbound Connector wurde in Schritt 1 mit TLS-Stufe "Nur verschlüsseln" (EncryptionOnly) angelegt — TLS erzwungen, Zertifikat nicht geprüft.

Für höhere Sicherheit kann auf DomainValidation umgestellt werden — dabei wird zusätzlich das Zertifikat des Ziels gegen den angegebenen Domainnamen geprüft.

Im Exchange Admin Center (EAC): Suche nach: "Connectors" oder navigieren zu Mail flow > Connectors

  • Connector "SecuMail Filter Outbound" öffnen
  • TLS-Einstellungen ändern: > "Immer TLS verwenden" (Always use TLS) > Stufe auf "Domainvalidierung" (Domain validation) ändern > TLS-Domain: *.secumail.de Ergebnis: TLS mit Zertifikatsprüfung gegen *.secumail.de

TLS-Stufen:

  • EncryptionOnly: TLS wird erzwungen, Zertifikat nicht geprüft (Standard, betriebssicher)
  • CertificateValidation: TLS erzwungen UND Zertifikat wird auf Gültigkeit geprüft (ohne Domainabgleich)
  • DomainValidation: TLS erzwungen UND Zertifikat wird gegen TlsDomain geprüft (höchste Sicherheit)

Hinweis: Der Parameter -TlsDomain wird NUR bei DomainValidation ausgewertet. Bei CertificateValidation oder EncryptionOnly hat er keine Wirkung.

Falls nach Umstellung Zustellprobleme auftreten, auf EncryptionOnly zurückstellen. Prüfen Sie mit SecuMail, welcher TlsDomain-Wert korrekt ist.

Schritt 4: DNS - SPF-Record prüfen ZWINGEND

Der SPF-Record der Kundendomain muss die SecuMail-Server als berechtigte Absender enthalten. Ohne korrekten SPF werden ausgehende Mails vom Empfänger als Spam oder Spoofing eingestuft.

Anleitung: https://www.secumail.de/f-a-q/#1489262272575-af5fa3ea-c5da

(Eintrag mit "v=spf1" suchen — SecuMail muss enthalten sein)

Wichtig: DNS-Änderungen können je nach TTL-Wert bis zu 48 Stunden dauern, bis sie weltweit propagiert sind.

Funktionstest

  1. Eine Mail an eine externe Adresse senden. -> Im Message Trace prüfen, ob die Mail über den Connector "SecuMail Filter Outbound" geroutet wurde.
  2. Eine Mail an einen internen Empfänger senden. -> Muss direkt zugestellt werden (nicht über Connector).

Hinweise

  • Port 25 wird verwendet (relay.secumail.de:25).
  • Bei Problemen mit der Zustellung prüfen Sie den Message Trace im Exchange Admin Center (Suche nach: "Message trace" oder navigieren zu Mail flow > Message trace).
  • Für Encryption-Produkte siehe stattdessen: Sendeweg: Relay Encryption

Angaben ohne Gewähr — Umsetzung auf eigene Verantwortung.

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-sendeweg-relay-filter.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.



Sendeweg - Relay Encryption


Produkte:

  • Encryption
  • Filter+Encryption

Priorität: ZWINGEND

Ziel

Ausgehende Mails des MS365-Tenants über enc.secumail.de:25 routen, damit SecuMail die S/MIME-Verschlüsselung und -Signatur anwenden kann.

Wichtig

Interne Mails (innerhalb der eigenen Domain, Weiterleitungen an interne Postfächer) dürfen NICHT über das Relay gehen. Die Transport Rule muss so konfiguriert sein, dass nur Mails an externe Empfänger geroutet werden.

Voraussetzungen

Schritt 1: Outbound Connector anlegen ZWINGEND

Im Exchange Admin Center (EAC): Suche nach: "Connectors" oder navigieren zu Mail flow > Connectors

  • "Connector hinzufügen" (Add a connector)
  • Verbindung von: "Office 365"
  • Verbindung zu: "Partnerorganisation" (Partner organization)
  • Name: "SecuMail Encryption Outbound"
  • Routing: "Mails über diese Smarthosts weiterleiten" (Route email through these smart hosts) > enc.secumail.de
  • TLS: "Immer TLS verwenden" (Always use TLS) aktivieren > Stufe: "Nur verschlüsseln" (Encryption only)
  • Einschränkung: Connector nur verwenden wenn eine Transport Rule darauf verweist (Transport Rule Scoped)
  • Connector aktivieren Ergebnis: Ein Outbound Connector der Mails an enc.secumail.de routet
  • ConnectorType: Partner
  • SmartHosts: {enc.secumail.de}
  • TlsSettings: EncryptionOnly
  • UseMXRecord: False
  • IsTransportRuleScoped: True
  • Enabled: True

Schritt 2: Transport Rule für ausgehende Mails ZWINGEND

Die Rule routet nur Mails an externe Empfänger über den Connector. Interne Mails bleiben im Tenant.

Im Exchange Admin Center (EAC): Suche nach: "Rules" oder navigieren zu Mail flow > Rules

  • "Regel hinzufügen" (Add a rule) > "Neue Regel erstellen" (Create a new rule)
  • Name: "Route ausgehend über SecuMail Encryption"
  • Bedingung 1: "Der Absender befindet sich..." (The sender is located...) > "Innerhalb der Organisation" (Inside the organization)
  • Bedingung 2: "Der Empfänger befindet sich..." (The recipient is located...) > "Ausserhalb der Organisation" (Outside the organization)
  • Aktion: "Nachricht umleiten an den folgenden Connector" (Redirect the message to the following connector) > "SecuMail Encryption Outbound" auswählen
  • Regel aktivieren Ergebnis: Ausgehende externe Mails werden über SecuMail Encryption geroutet, interne Mails bleiben unberührt

Erklärung der Bedingungen:

  • Absender innerhalb der Organisation: Nur Mails von internen Absendern
  • Empfänger ausserhalb der Organisation: Nur Mails an externe Empfänger
  • Kombination stellt sicher: Interne Mails werden nicht geroutet
  • State: Enabled
  • FromScope: InOrganization
  • SentToScope: NotInOrganization
  • RouteMessageOutboundConnector: SecuMail Encryption Outbound

Schritt 3: TLS für den Sendeweg STARK EMPFOHLEN

Bei S/MIME-Produkten ist TLS auf dem Sendeweg STARK EMPFOHLEN. Die zu verschlüsselnden Mails verlassen den Tenant im Klartext Richtung SecuMail — ohne TLS wären sie auf dem Transportweg ungeschützt.

Der Outbound Connector wurde in Schritt 1 mit TLS-Stufe "Nur verschlüsseln" (EncryptionOnly) angelegt — TLS erzwungen, Zertifikat nicht geprüft.

Für höhere Sicherheit kann auf DomainValidation umgestellt werden — dabei wird zusätzlich das Zertifikat des Ziels gegen den angegebenen Domainnamen geprüft.

Im Exchange Admin Center (EAC): Suche nach: "Connectors" oder navigieren zu Mail flow > Connectors

  • Connector "SecuMail Encryption Outbound" öffnen
  • TLS-Einstellungen ändern: > "Immer TLS verwenden" (Always use TLS) > Stufe auf "Domainvalidierung" (Domain validation) ändern > TLS-Domain: *.secumail.de Ergebnis: TLS mit Zertifikatsprüfung gegen *.secumail.de

TLS-Stufen:

  • EncryptionOnly: TLS wird erzwungen, Zertifikat nicht geprüft (Standard, betriebssicher)
  • CertificateValidation: TLS erzwungen UND Zertifikat wird auf Gültigkeit geprüft (ohne Domainabgleich)
  • DomainValidation: TLS erzwungen UND Zertifikat wird gegen TlsDomain geprüft (höchste Sicherheit)

Hinweis: Der Parameter -TlsDomain wird NUR bei DomainValidation ausgewertet. Bei CertificateValidation oder EncryptionOnly hat er keine Wirkung.

Falls nach Umstellung Zustellprobleme auftreten, auf EncryptionOnly zurückstellen. Prüfen Sie mit SecuMail, welcher TlsDomain-Wert korrekt ist.

Schritt 4: DNS - SPF-Record prüfen ZWINGEND

Der SPF-Record der Kundendomain muss die SecuMail-Server als berechtigte Absender enthalten. Ohne korrekten SPF werden ausgehende Mails vom Empfänger als Spam oder Spoofing eingestuft.

Anleitung: https://www.secumail.de/f-a-q/#1489262272575-af5fa3ea-c5da

(Eintrag mit "v=spf1" suchen — SecuMail muss enthalten sein)

Wichtig: DNS-Änderungen können je nach TTL-Wert bis zu 48 Stunden dauern, bis sie weltweit propagiert sind.

Funktionstest

  1. Eine Mail an eine externe Adresse senden. -> Im Message Trace prüfen, ob die Mail über den Connector "SecuMail Encryption Outbound" geroutet wurde.
  2. Eine Mail an einen internen Empfänger senden. -> Muss direkt zugestellt werden (nicht über Connector).

Hinweise

  • Port 25 wird verwendet (enc.secumail.de:25).
  • Wenn der Kunde die Rücklieferung verschlüsselter Mails über MS365 wählt, muss zusätzlich ARC konfiguriert werden: Sendeweg: Rücklieferung + ARC
  • Für Filter-only-Produkte siehe stattdessen: Sendeweg: Relay Filter

Angaben ohne Gewähr — Umsetzung auf eigene Verantwortung.

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-sendeweg-relay-encryption.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.



Sendeweg - Rücklieferung via MS365 + ARC Seal


Produkte:

  • Encryption
  • Filter+Encryption

NUR wenn der Kunde die Rücklieferung über MS365 wählt. Priorität: ZWINGEND (wenn Rückweg über MS365 gewählt)

Ziel

Verschlüsselte Mails, die SecuMail bearbeitet hat, zurück an MS365 zur finalen Auslieferung senden. MS365 muss so konfiguriert werden, dass es diese Mails akzeptiert, obwohl der Absender die eigene Domain des Kunden ist.

Problem

Wenn SecuMail eine verschlüsselte Mail an MS365 zurückliefert, sieht MS365 folgendes:

  • Absender: user@kundendomain.de (die eigene Domain des Kunden)
  • Quelle: SecuMail-Server (nicht der eigene Tenant)

MS365 lehnt diese Mail ab, weil SPF fehlschlägt: Die eigene Domain kommt von einem externen Server. Das ist ein Schutzmechanismus gegen Spoofing, der hier aber unerwünscht ist.

Lösung: ARC (Authenticated Received Chain)

SecuMail signiert jede zurückgelieferte Mail mit einem ARC Seal. Der ARC-Schlüssel liegt unter: arc._domainkey.secumail.de Die signierende Domain ist: secumail.de

Der Kunde muss zwei Dinge konfigurieren:

  1. secumail.de als vertrauenswürdigen ARC Sealer hinterlegen
  2. SPF Hard Fail in der Antispam-Policy deaktivieren

Ohne Schritt 2 ignoriert MS365 den ARC Seal und lehnt die Mail trotzdem ab.

Voraussetzungen

  • Allgemeine Voraussetzungen: siehe Allgemeine Voraussetzungen
  • Zugang zum Microsoft 365 Defender / Security Portal für ARC-Konfiguration

Schritt 1: Trusted ARC Sealer hinterlegen ZWINGEND

Im Security Portal (Microsoft 365 Defender): Suche nach: "Email authentication settings" oder "E-Mail-Authentifizierungseinstellungen" Alternativ navigieren zu: Richtlinien > Bedrohungsrichtlinien > E-Mail-Authentifizierungseinstellungen > ARC (englisch: Policies > Threat policies > Email authentication settings > ARC)

  • "Vertrauenswürdigen ARC-Sealer hinzufügen" (Add trusted ARC sealer)
  • Domain eingeben: secumail.de
  • Speichern Ergebnis: secumail.de wird als vertrauenswürdiger ARC Sealer akzeptiert. Mails mit gültigem ARC Seal von secumail.de werden trotz SPF-Fehler zugestellt.

Falls bereits andere Trusted Sealers existieren, diese beibehalten und secumail.de zusätzlich eintragen.

Falls bereits andere Trusted Sealers existieren, diese mit angeben:

  • ArcTrustedSealers: {secumail.de} (ggf. zusammen mit anderen)

Schritt 2: SPF Hard Fail prüfen (ggf. deaktivieren) ZWINGEND

Wenn die Antispam-Policy so eingestellt ist, dass SPF Hard Fail als Spam markiert wird (MarkAsSpamSpfRecordHardFail = On), ignoriert MS365 den ARC Seal. In diesem Fall muss die Einstellung deaktiviert werden.

Hinweis: Der Microsoft-Default ist bereits "Off". Die Prüfung ist trotzdem zwingend, da Custom-Policies oder Preset-Security- Policies den Wert geändert haben könnten.

Im Security Portal (Microsoft 365 Defender): Suche nach: "Anti-spam policies" oder "Antispamrichtlinien" Alternativ navigieren zu: Richtlinien > Bedrohungsrichtlinien > Antispamrichtlinien (englisch: Policies > Threat policies > Anti-spam policies)

  • Standardrichtlinie (Default) öffnen
  • Suche nach der Einstellung "SPF-Eintrag: Schwerer Fehler" (SPF record: hard fail) oder "MarkAsSpamSpfRecordHardFail"
  • Wert muss "Aus" (Off) sein
  • Falls "Ein" (On): Auf "Aus" (Off) umstellen
  • Dasselbe für alle Custom-Policies prüfen Ergebnis: SPF Hard Fail wird nicht mehr als Spam markiert, ARC Seal wird korrekt ausgewertet

Zuerst prüfen — alle Policies anzeigen:

Falls bei irgendeiner Policy der Wert "On" ist, deaktivieren:

Für Custom-Policies analog:

  • MarkAsSpamSpfRecordHardFail: Off (bei allen relevanten Policies)

Prüfung der Gesamtkonfiguration

  1. ARC-Konfiguration prüfen: Im Security Portal unter Email authentication settings > ARC prüfen, ob secumail.de als Trusted ARC Sealer gelistet ist.
  1. Antispam-Policy prüfen: Im Security Portal unter Anti-spam policies die Default-Policy und alle Custom-Policies auf SPF Hard Fail prüfen.
  1. ARC Public Key im DNS verifizieren (externer Check): Der TXT-Record arc._domainkey.secumail.de muss auflösbar sein. nslookup -type=TXT arc._domainkey.secumail.de

Funktionstest

  1. Eine verschlüsselte Mail über SecuMail senden, die über MS365 zurückgeliefert wird.
  2. Im Message Header der empfangenen Mail prüfen: - ARC-Seal Header muss vorhanden sein (d=secumail.de) - Authentication-Results muss "arc=pass" enthalten
  3. Die Mail darf nicht als Spam markiert oder abgelehnt werden.

Hinweise

  • Der ARC Public Key (arc._domainkey.secumail.de) wird von SecuMail gepflegt und ist bereits im DNS hinterlegt.
  • Ändern Sie die SPF-Hard-Fail-Einstellung nur, wenn Sie die Rücklieferung über MS365 nutzen. Bei direkter Auslieferung durch SecuMail ist diese Änderung nicht nötig.
  • Die Deaktivierung von SPF Hard Fail ist sicherheitstechnisch vertretbar, da SecuMail als vorgelagerter Filter bereits SPF prüft und nur legitime Mails weiterleitet.

Angaben ohne Gewähr — Umsetzung auf eigene Verantwortung.

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-sendeweg-ruecklieferung-arc.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.






MS365 Konfiguration - API-Sync

Adress- und Benutzersynchronisation via Microsoft Graph API.


Graph API - Filter-Adress-Sync


Produkte:

  • Filter
  • Filter+Encryption

Priorität: OPTIONAL

Ziel

E-Mail-Adressen und Benutzernamen aus dem MS365-Tenant via Microsoft Graph API an SecuMail synchronisieren. SecuMail benötigt diese Daten, um den Mailfilter korrekt auf die Empfängeradressen des Kunden anzuwenden.

Optionale Gruppeneinschränkung

Standardmässig werden alle lizenzierten Benutzer synchronisiert. Optional kann eine Entra ID Security Group angelegt werden, um nur bestimmte Benutzer zu synchronisieren. Gruppenname (Empfehlung): SecuMail-Filter-Users

Welche Daten werden synchronisiert

  • E-Mail-Adressen (mail, proxyAddresses)
  • Anzeigename (displayName)
  • Benutzerprinzipalname (userPrincipalName)
  • Kontotyp (userType) - wird intern für Lizenzierung genutzt
  • Kontostatus (accountEnabled)
  • Zugewiesene Lizenzen (assignedLicenses)

Die letzten drei Felder kommen automatisch mit und werden intern von SecuMail zur Lizenzberechnung verwendet.

Benötigte Graph API Berechtigungen

  • User.Read.All (Application) - Benutzer und deren Adressen lesen
  • Group.Read.All oder GroupMember.Read.All (Application) - nur bei Gruppeneinschränkung, um Gruppenmitglieder abzufragen

Voraussetzungen

  • Allgemeine Voraussetzungen: siehe Allgemeine Voraussetzungen
  • Zugang zum Entra ID Portal (ehemals Azure Active Directory) Suche nach: "App registrations" / "App-Registrierungen"
  • Globaler Administrator oder Application Administrator für Admin Consent

Schritt 1: App Registration in Entra ID anlegen ZWINGEND

Im Entra ID Portal: Suche nach: "App registrations" oder "App-Registrierungen"

  • "Neue Registrierung" (New registration)
  • Name: "SecuMail Filter Sync" (oder ähnlich)
  • Unterstützte Kontotypen: "Nur Konten in diesem Organisationsverzeichnis" (Accounts in this organizational directory only) — Single Tenant
  • Umleitungs-URI (Redirect URI): nicht erforderlich (App nutzt Client Credentials)
  • "Registrieren" klicken Ergebnis: App wird angelegt

Nach dem Anlegen notieren (auf der Übersichtsseite der App):

  • Anwendungs-ID (Client ID)
  • Verzeichnis-ID (Tenant ID)

Schritt 2: Client Secret erstellen ZWINGEND

Im Entra ID Portal in der erstellten App-Registrierung: Suche nach: "Certificates & secrets" oder "Zertifikate und Geheimnisse"

  • Tab "Geheime Clientschlüssel" (Client secrets)
  • "Neuer geheimer Clientschlüssel" (New client secret)
  • Beschreibung: z.B. "SecuMail Sync"
  • Ablaufdatum: nach Unternehmensrichtlinie (Empfehlung: 12-24 Monate)
  • "Hinzufügen" klicken
  • Secret-Wert sofort notieren (wird nur einmal angezeigt!) Ergebnis: Client Secret erstellt

Schritt 3: API-Berechtigungen hinzufügen ZWINGEND

Im Entra ID Portal in der erstellten App-Registrierung: Suche nach: "API permissions" oder "API-Berechtigungen"

  • "Berechtigung hinzufügen" (Add a permission)
  • "Microsoft Graph" auswählen
  • "Anwendungsberechtigungen" (Application permissions) auswählen
  • Hinzufügen: > User.Read.All > Group.Read.All (oder GroupMember.Read.All bei Gruppeneinschränkung)
  • "Administratorzustimmung erteilen für [Tenant]" (Grant admin consent for [Tenant]) klicken (erfordert Global Administrator) Ergebnis: Berechtigungen erteilt

Prüfung im Portal: Status muss "Erteilt für [Tenant]" (Granted for [Tenant]) anzeigen.

Schritt 4 (optional): Security Group anlegen OPTIONAL

Wenn nur bestimmte Benutzer synchronisiert werden sollen:

Im Entra ID Portal: Suche nach: "Groups" oder "Gruppen"

  • "Neue Gruppe" (New group)
  • Gruppentyp: "Sicherheit" (Security)
  • Gruppenname: "SecuMail-Filter-Users"
  • Beschreibung: "Benutzer die über SecuMail Filter synchronisiert werden"
  • E-Mail-aktiviert: Nein
  • Mitglieder hinzufügen: Gewünschte Benutzer auswählen
  • "Erstellen" klicken Ergebnis: Security Group mit den gewünschten Mitgliedern

Mitglieder hinzufügen:

Schritt 5: Zugangsdaten an SecuMail übermitteln ZWINGEND

Folgende Daten müssen SecuMail mitgeteilt werden:

  • Tenant ID
  • Application (Client) ID
  • Client Secret
  • Gruppenname (falls Gruppeneinschränkung gewählt)

Sicherheitshinweis: Diese Daten per sicherem Kanal übermitteln (z.B. verschlüsselte Mail, Kundenportal), nicht per unverschlüsselter E-Mail.

Prüfung

Nach Einrichtung durch SecuMail kann die Synchronisation wie folgt geprüft werden:

  1. Im Entra ID Portal: Suche nach: "App registrations" oder "App-Registrierungen" > "SecuMail Filter Sync" öffnen > Suche nach: "Sign-in logs" oder "Anmeldeprotokolle" Prüfen, ob regelmässige Anmeldungen stattfinden.
  2. Berechtigungen prüfen: In der App unter "API permissions" / "API-Berechtigungen": Alle Berechtigungen müssen Status "Erteilt" (Granted) haben.

Hinweise

  • Das Client Secret hat ein Ablaufdatum. Vor Ablauf muss ein neues Secret erstellt und an SecuMail übermittelt werden.
  • Bei Änderungen an der Benutzerstruktur (neue Domains, Umbenennungen) wird die nächste Synchronisation diese automatisch erfassen.
  • Für S/MIME-Encryption-Sync siehe: Graph API: S/MIME-Sync Bei Filter+Encryption werden beide Apps benötigt.

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-graph-api-filter-sync.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.



Graph API - S/MIME-User-Sync


Produkte:

  • Encryption
  • Filter+Encryption

Priorität: OPTIONAL

Ziel

E-Mail-Adressen und Benutzernamen aus dem MS365-Tenant via Microsoft Graph API an SecuMail synchronisieren. SecuMail benötigt diese Daten, um S/MIME-Zertifikate für die richtigen Benutzer auszustellen und die Verschlüsselung korrekt anzuwenden.

Optionale Gruppeneinschränkung

Standardmässig werden alle lizenzierten Benutzer synchronisiert. Optional kann eine Entra ID Security Group angelegt werden, um nur bestimmte Benutzer für S/MIME zu aktivieren. Gruppenname (Empfehlung): SecuMail-Encryption-SMIME-Users

Welche Daten werden synchronisiert

  • E-Mail-Adressen (mail, proxyAddresses)
  • Anzeigename (displayName)
  • Benutzerprinzipalname (userPrincipalName)
  • Kontotyp (userType) - wird intern für Lizenzierung genutzt
  • Kontostatus (accountEnabled)
  • Zugewiesene Lizenzen (assignedLicenses)

Die letzten drei Felder kommen automatisch mit und werden intern von SecuMail zur Lizenzberechnung verwendet.

Benötigte Graph API Berechtigungen

  • User.Read.All (Application) - Benutzer und deren Adressen lesen
  • Group.Read.All oder GroupMember.Read.All (Application) - nur bei Gruppeneinschränkung, um Gruppenmitglieder abzufragen

Voraussetzungen

  • Allgemeine Voraussetzungen: siehe Allgemeine Voraussetzungen
  • Zugang zum Entra ID Portal (ehemals Azure Active Directory) Suche nach: "App registrations" / "App-Registrierungen"
  • Globaler Administrator oder Application Administrator für Admin Consent

Schritt 1: App Registration in Entra ID anlegen ZWINGEND

Im Entra ID Portal: Suche nach: "App registrations" oder "App-Registrierungen"

  • "Neue Registrierung" (New registration)
  • Name: "SecuMail S/MIME Sync" (oder ähnlich)
  • Unterstützte Kontotypen: "Nur Konten in diesem Organisationsverzeichnis" (Accounts in this organizational directory only) — Single Tenant
  • Umleitungs-URI (Redirect URI): nicht erforderlich (App nutzt Client Credentials)
  • "Registrieren" klicken Ergebnis: App wird angelegt

Nach dem Anlegen notieren (auf der Übersichtsseite der App):

  • Anwendungs-ID (Client ID)
  • Verzeichnis-ID (Tenant ID)

Hinweis: Bei Filter+Encryption wird eine separate App für den S/MIME-Sync empfohlen. Die Filter-Sync-App (Graph API: Filter-Sync) bleibt davon unberührt.

Schritt 2: Client Secret erstellen ZWINGEND

Im Entra ID Portal in der erstellten App-Registrierung: Suche nach: "Certificates & secrets" oder "Zertifikate und Geheimnisse"

  • Tab "Geheime Clientschlüssel" (Client secrets)
  • "Neuer geheimer Clientschlüssel" (New client secret)
  • Beschreibung: z.B. "SecuMail S/MIME Sync"
  • Ablaufdatum: nach Unternehmensrichtlinie (Empfehlung: 12-24 Monate)
  • "Hinzufügen" klicken
  • Secret-Wert sofort notieren (wird nur einmal angezeigt!) Ergebnis: Client Secret erstellt

Schritt 3: API-Berechtigungen hinzufügen ZWINGEND

Im Entra ID Portal in der erstellten App-Registrierung: Suche nach: "API permissions" oder "API-Berechtigungen"

  • "Berechtigung hinzufügen" (Add a permission)
  • "Microsoft Graph" auswählen
  • "Anwendungsberechtigungen" (Application permissions) auswählen
  • Hinzufügen: > User.Read.All > Group.Read.All (oder GroupMember.Read.All bei Gruppeneinschränkung)
  • "Administratorzustimmung erteilen für [Tenant]" (Grant admin consent for [Tenant]) klicken (erfordert Global Administrator) Ergebnis: Berechtigungen erteilt

Prüfung im Portal: Status muss "Erteilt für [Tenant]" (Granted for [Tenant]) anzeigen.

Schritt 4 (optional): Security Group anlegen OPTIONAL

Wenn nur bestimmte Benutzer S/MIME-Zertifikate erhalten sollen:

Im Entra ID Portal: Suche nach: "Groups" oder "Gruppen"

  • "Neue Gruppe" (New group)
  • Gruppentyp: "Sicherheit" (Security)
  • Gruppenname: "SecuMail-Encryption-SMIME-Users"
  • Beschreibung: "Benutzer die über SecuMail S/MIME-Zertifikate erhalten"
  • E-Mail-aktiviert: Nein
  • Mitglieder hinzufügen: Gewünschte Benutzer auswählen
  • "Erstellen" klicken Ergebnis: Security Group mit den gewünschten Mitgliedern

Mitglieder hinzufügen:

Schritt 5: Zugangsdaten an SecuMail übermitteln ZWINGEND

Folgende Daten müssen SecuMail mitgeteilt werden:

  • Tenant ID
  • Application (Client) ID
  • Client Secret
  • Gruppenname (falls Gruppeneinschränkung gewählt)

Sicherheitshinweis: Diese Daten per sicherem Kanal übermitteln (z.B. verschlüsselte Mail, Kundenportal), nicht per unverschlüsselter E-Mail.

Prüfung

Nach Einrichtung durch SecuMail kann die Synchronisation wie folgt geprüft werden:

  1. Im Entra ID Portal: Suche nach: "App registrations" oder "App-Registrierungen" > "SecuMail S/MIME Sync" öffnen > Suche nach: "Sign-in logs" oder "Anmeldeprotokolle" Prüfen, ob regelmässige Anmeldungen stattfinden.
  2. Berechtigungen prüfen: In der App unter "API permissions" / "API-Berechtigungen": Alle Berechtigungen müssen Status "Erteilt" (Granted) haben.

Hinweise

  • Das Client Secret hat ein Ablaufdatum. Vor Ablauf muss ein neues Secret erstellt und an SecuMail übermittelt werden.
  • Bei Filter+Encryption werden zwei separate Apps benötigt: eine für Filter-Sync und eine für S/MIME-Sync.
  • Für Filter-Sync siehe: Graph API: Filter-Sync

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-graph-api-smime-sync.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.






MS365 Konfiguration - Funktionstest

Prüfen, ob der Mailflow über SecuMail korrekt funktioniert.


Funktionstest


Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: EMPFOHLEN

Ziel

Nach Abschluss der Konfiguration prüfen, ob der Mailflow über SecuMail korrekt funktioniert. Diese Checkliste deckt beide Richtungen (Empfang und Versand) ab.

Voraussetzungen

  • Allgemeine Voraussetzungen: siehe Allgemeine Voraussetzungen
  • Alle relevanten Konfigurationsschritte sind abgeschlossen (Connectors, Transport Rules, DNS, etc.)
  • Ein externes Testpostfach (z.B. Gmail, anderer Provider)

Checkliste: Konfiguration prüfen

Die Konfiguration kann sowohl im Portal als auch per PowerShell geprüft werden. Für eine schnelle Übersicht empfehlen wir die PowerShell Get-Befehle.

  1. Inbound Connector prüfen: Im Exchange Admin Center: Suche nach "Connectors" oder navigieren zu Mail flow > Connectors > Connector "SecuMail Inbound" öffnen und Einstellungen prüfen
  1. Outbound Connector prüfen: Im Exchange Admin Center: Suche nach "Connectors" oder navigieren zu Mail flow > Connectors > Connector "SecuMail Filter Outbound" bzw. "SecuMail Encryption Outbound" öffnen und Einstellungen prüfen
  1. Transport Rules prüfen: Im Exchange Admin Center: Suche nach "Rules" oder navigieren zu Mail flow > Rules > Alle SecuMail-bezogenen Regeln prüfen
  1. ARC-Konfiguration prüfen (nur bei Rücklieferung, Cases B/C): Im Security Portal: Suche nach "Email authentication settings" oder navigieren zu Richtlinien > Bedrohungsrichtlinien > E-Mail-Authentifizierungseinstellungen > ARC > Prüfen ob secumail.de als Trusted ARC Sealer gelistet ist
  1. Antispam-Policy prüfen (nur bei Rücklieferung, Cases B/C): Im Security Portal: Suche nach "Anti-spam policies" oder navigieren zu Richtlinien > Bedrohungsrichtlinien > Antispamrichtlinien > Default-Policy und Custom-Policies auf SPF Hard Fail prüfen

Test 1: Empfangsweg (extern -> MS365 via SecuMail)

  1. Von einem externen Postfach eine Testmail an ein MS365-Postfach senden (an eine Adresse in der konfigurierten Domain).
  2. Prüfen: a) Mail wurde zugestellt b) Im Message Header prüfen: - Received-Header zeigt SecuMail-Server als Zwischenstation - Bei Enhanced Filtering: X-MS-Exchange-SkipListedInternetSender zeigt die echte Quell-IP c) Mail wurde nicht fälschlich als Spam markiert

Message Trace im Portal: Im Exchange Admin Center: Suche nach "Message trace" oder navigieren zu Mail flow > Message trace > Empfängeradresse und Zeitraum eingeben > Prüfen ob Status "Delivered" und Quell-IP eine SecuMail-IP ist

Test 2: Sendeweg (MS365 -> extern via SecuMail)

  1. Vom MS365-Postfach eine Testmail an eine externe Adresse senden.
  2. Prüfen: a) Mail wurde zugestellt b) Im Message Trace: Mail wurde über den Outbound Connector geroutet

Message Trace im Portal: Im Exchange Admin Center: Suche nach "Message trace" oder navigieren zu Mail flow > Message trace > Absenderadresse und Zeitraum eingeben > Prüfen ob die Mail über den Connector geroutet wurde

c) Beim Empfänger: Message Header prüfen, ob die Mail über SecuMail (relay.secumail.de oder enc.secumail.de) geroutet wurde

Test 3: Interne Mails (MS365 intern)

  1. Vom MS365-Postfach eine Mail an einen internen Empfänger senden (gleiche Domain).
  2. Prüfen: a) Mail wurde direkt zugestellt (NICHT über Outbound Connector) b) Im Message Trace: Kein Routing über SecuMail

Dies stellt sicher, dass die Transport Rule interne Mails korrekt ausschliesst.

Test 4: Rücklieferung (nur bei ARC-Konfiguration, Cases B/C)

  1. Eine verschlüsselte Mail senden, die über SecuMail an MS365 zurückgeliefert wird.
  2. Prüfen: a) Mail wurde zugestellt (nicht abgelehnt) b) Im Message Header: - ARC-Seal Header vorhanden (d=secumail.de) - Authentication-Results: arc=pass c) Mail nicht als Spam markiert

Häufige Probleme

Problem: Ausgehende Mails werden nicht über SecuMail geroutet Ursache: Transport Rule greift nicht Prüfen im Portal: Mail flow > Rules — Regel-Status prüfen Prüfen (PowerShell): Get-TransportRule | Format-List Name, State, FromScope, SentToScope Lösung: FromScope und SentToScope prüfen, Rule muss Enabled sein

Problem: Eingehende Mails werden als Spam markiert Ursache: Enhanced Filtering nicht konfiguriert oder IP-Whitelist fehlt Prüfen im Portal: Mail flow > Connectors — Connector-Einstellungen prüfen Prüfen (PowerShell): Get-InboundConnector | Format-List EFSkipIPs, SenderIPAddresses Lösung: Enhanced Filtering und IP-Whitelist in Empfangsweg: IP-Whitelist

Problem: Rückgelieferte Mails werden abgelehnt (NDR) Ursache: ARC nicht konfiguriert oder SPF Hard Fail aktiv Prüfen im Portal: Security Portal — ARC und Antispam-Policy prüfen Prüfen (PowerShell): Get-ArcConfig; Get-HostedContentFilterPolicy Default | Select-Object MarkAsSpamSpfRecordHardFail Lösung: Sendeweg: Rücklieferung + ARC

Problem: TLS-Fehler bei Zustellung Ursache: TlsSettings auf CertificateValidation, aber Zertifikat passt nicht Prüfen im Portal: Mail flow > Connectors — TLS-Einstellungen prüfen Prüfen (PowerShell): Get-OutboundConnector | Format-List TlsSettings, TlsDomain Lösung: Auf EncryptionOnly zurückstellen oder TlsDomain korrigieren

Verwandte FAQ-Cases

  • Alle vorherigen FAQ-Cases sollten vor dem Funktionstest abgeschlossen sein.

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-funktionstest.txt
Hinweis: Microsoft kann die PowerShell-API ohne Vorankündigung ändern. Prüfen Sie das Ergebnis bitte sorgfältig.




Sollten Sie eine Frage haben welche hier nicht beantwortet ist, kontaktieren Sie uns bitte.

Kontakt aufnehmen
DSGVO Cookie Consent mit Real Cookie Banner