Microsoft 365

Kurzanleitung zum Einrichten von Microsoft 365 mit SecuMail®.
Für SecuMail® Filter & SecuMail® Encryption

Empfangsweg

Sendeweg

API-Sync

Pitfalls und Lösungen


Allgemeines zur Microsoft 365 Integration

Voraussetzungen | PowerShell | Hinweise


Welches Setup habe ich?


Gilt für: beide Setups

Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: NÖTIG (bestimmt, welche der folgenden Anleitungen für Sie gelten)

Kurzentscheidung in einem Schritt

Welches Setup für Sie gilt, hängt allein davon ab, welches SecuMail®-Produkt Sie einsetzen — und damit, wohin Ihr MX-Record zeigt:

  • Sie nutzen SecuMail® Filter (allein oder zusammen mit Encryption)?

-> Setup 1 – MX via SecuMail. Der Filter muss eingehende Mail prüfen, bevor Microsoft 365 sie sieht. Der MX muss deshalb zwingend auf SecuMail® zeigen.

  • Sie nutzen ausschließlich SecuMail® Encryption (S/MIME), kein Filter?

-> Sie haben die Wahl. Üblich ist Setup 2 – MX via Microsoft: Ihr MX bleibt bei Microsoft 365, nur die Verschlüsselung läuft über SecuMail®. Alternativ können Sie auch hier Setup 1 fahren.

Wichtig: Sobald SecuMail® Filter im Spiel ist, ist Setup 2 nicht möglich — der MX zeigt dann immer auf SecuMail®. Setup 2 ist Encryption-only vorbehalten.

Setup 1 – MX via SecuMail (Gateway vorgelagert)

SecuMail® ist Ihrem Microsoft 365 vorgelagert. Eingehende Mail aus dem Internet trifft zuerst auf SecuMail® (mx.secumail.de) und wird von dort an Microsoft 365 übergeben; ausgehende Mail läuft über das SecuMail®-Relay.

Das ist der Standardfall für Filter, Filter+Encryption und für Encryption-Kunden, die SecuMail® vollständig vorlagern möchten.

Ihre Bausteine:

In diesem Setup ist der eingehende Connector vom Typ Partner.

Setup 2 – MX via Microsoft (Encryption-Loop)

Ihr MX bleibt unverändert bei Microsoft 365. Nur das SecuMail®-Encryption-Gateway (enc.secumail.de) ist im Spiel — es gibt keinen mx.secumail.de. Ausgehende Mail wird zur S/MIME-Verschlüsselung an SecuMail® ausgeleitet und danach ausgeliefert.

Dieser Fall gilt nur für Encryption-only-Kunden.

Ihre Bausteine:

In diesem Setup ist der eingehende Connector vom Typ OnPremises (Mailserver der Organisation) — anders als in Setup 1. Warum, erklärt der zugehörige Case.

Für beide Setups gleich

Hinweis: Diese FAQ beschreibt die Integration mit Microsoft 365. Betreiben Sie keinen Microsoft-365-Tenant, gelten die klassischen SecuMail®-Anleitungen unter www.secumail.de.



Voraussetzungen & Rechte


Gilt für: beide Setups

Portal oder PowerShell?

Alle Schritte in diesen Anleitungen lassen sich sowohl über die Microsoft Admin-Portale (Exchange Admin Center, Entra ID Portal, Microsoft 365 Defender) 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äßig ä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 Microsoft 365-Tenant

  • Exchange Administrator (oder höher) für Connector- und Mail-Flow-Regel-Konfiguration (Empfangsweg, Sendeweg, Funktionstest)
  • Security Administrator für ARC-Konfiguration (Auslieferung via Microsoft 365)
  • Global Administrator oder Application Administrator für App-Registrierungen und Admin Consent (Graph-API-Sync)

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, Mail-Flow-Regeln, Nachrichtenverfolgung

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 (Graph-API-Sync)



PowerShell einrichten (optional)


Gilt für: beide Setups

PowerShell-Module installieren

Falls Sie PowerShell verwenden möchten:

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

  Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser

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

  Install-Module -Name Microsoft.Graph -Scope CurrentUser

Prüfung installierter Module:

  Get-Module -ListAvailable ExchangeOnlineManagement
  Get-Module -ListAvailable Microsoft.Graph

Verbindung herstellen: Exchange Online

Connect-ExchangeOnline -UserPrincipalName admin@ihredomain.de

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)

Connect-MgGraph -Scopes "Group.Read.All"

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:

  Disconnect-ExchangeOnline -Confirm:$false
  Disconnect-MgGraph


Allgemeine Hinweise & Haftungsausschluss


Gilt für: beide Setups

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 Mail-Flow-Regeln 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 dienen als Referenz und wurden im Standard-Setup geprüft. Bei Tenants mit Custom-Policies oder besonderen Sicherheitsrichtlinien können Anpassungen nötig sein. Get--Befehle (Lese-Operationen) sind unbedenklich; Set- und New--Befehle sollten Sie zuerst in einer Testumgebung validieren.

Mehrere Connectors / Mail-Flow-Regeln — Loop-Vermeidung

In Tenants mit mehreren Connectors oder bestehenden Mail-Flow-Regeln können Mails versehentlich mehrfach durch SecuMail® geleitet werden. Das SecuMail®-Standardsetup verhindert diese Schleifen durch scoped Connector, scoped Routing-Regel und Partner-Inbound-Connector.

Details, Prüfschritte und Behebung bei betroffenen Tenants: -> Pitfall: Outbound Mail-Loop verhindern -> Pitfall: OnPremises- vs. Partner-Connector

Bei spezifischen Konflikten (z.B. mehrere bestehende Smarthost-Connectors, Mehrfach-Provisionierung mit verwaisten Connectoren, Variante C mit parallelen Filter- und Encryption-Outbounds) unterstützen wir Sie gerne bei der Konfiguration.

Haftungsausschluss

Diese Anleitungen werden mit Sorgfalt gepflegt, jedoch ohne Gewähr bereitgestellt. Die Umsetzung erfolgt unter Berücksichtigung der jeweils aktuellen Tenant-Einstellungen — Abweichungen je nach Microsoft-UI-Version und Lizenztyp sind möglich. Bei kritischen Einstellungen empfehlen wir eine vorherige Prüfung in einer Testumgebung.






Microsoft 365 Konfiguration - Empfangsweg

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


MX via SecuMail · Empfangsweg - IP-Whitelist


Gilt für: MX via SecuMail

Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: EMPFOHLEN

Ziel

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

Warum

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

Voraussetzungen

  • Allgemeine Voraussetzungen: siehe Allgemeine Voraussetzungen
  • Aktuelle SecuMail-IP-Bereiche: 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27

Schritt 1: Inbound Connector anlegen EMPFOHLEN

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

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector hinzufügen (Add a connector)
  • ➜ Verbindung von: Partnerorganisation (Partner organization)
  • ➜ Trigger: Verwende die IP-Adresse des sendenden Servers (Use the sender's IP address)
  • ➜ Name: SecuMail Inbound
  • ➜ IP-Adressen: 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27
  • ➜ TLS erzwingen aktivieren
  • ➜ Enhanced Filtering konfigurieren (siehe unten)

Ergebnis: Ein Inbound Connector der Mails von SecuMail-IPs akzeptiert

Enhanced Filtering im erstellten Connector (Enhanced Filtering / Erweiterte Filterung):

TODO:

  • ➜ Skip these IP addresses / Diese IP-Adressen überspringen: 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

Prüfung per PowerShell:

  • 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):

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

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

Connector per Client-Zertifikat absichern ⇄ Alternative

Statt (oder zusätzlich zu) der IP-Whitelist kann der Connector die SecuMail-Gateways am TLS-Client-Zertifikat erkennen. Vorteil: Die Vertrauensgrenze ist nicht über die Quell-IP fälschbar und übersteht einen Wechsel der SecuMail-Netze, ohne dass der Connector nachgepflegt werden muss.

Voraussetzung: Die SecuMail-Gateways präsentieren beim Einliefern an Microsoft 365 ein TLS-Client-Zertifikat mit dem Namen *.secumail.de.

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector SecuMail Inbound öffnen (oder beim Anlegen)
  • ➜ Identifikation des Partners: Antragstellername (Subject) des Zertifikats prüfen (verify the subject name on the certificate)
  • ➜ Domänenname: *.secumail.de

Ergebnis: Der Connector behandelt nur Verbindungen als vertrauenswürdig, die das passende Client-Zertifikat vorweisen

Hinweis: Mit Zertifikatsbindung ist SenderIPAddresses nicht mehr zwingend nötig. Beide Verfahren lassen sich auch kombinieren (IP UND Zertifikat müssen dann passen).

Wichtig: EFSkipIPs (Enhanced Filtering) weiterhin mit den SecuMail-IP-Bereichen bestückt lassen — Enhanced Filtering arbeitet IP-basiert und braucht die Gateway-IPs, um die echte Quell-IP zu ermitteln (siehe Schritt 2).

Prüfung per PowerShell:

  • RestrictDomainsToCertificate: True
  • TlsSenderCertificateName: *.secumail.de
  • RequireTls: True

Schritt 2: Enhanced Filtering — Hintergrund EMPFOHLEN

Warum Enhanced Filtering (EFSkipIPs) wichtig ist: Ohne Enhanced Filtering sieht der Microsoft 365-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:

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

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

Prüfung per PowerShell:

  • 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: MX-Record umstellen NÖTIG

Sobald Connector und Mail-Flow-Regeln aktiv sind, den MX-Record der Kundendomain auf die SecuMail-Mailserver umstellen: mx-a.secumail.de (Prio 10) / mx-b.secumail.de (Prio 10)

Wichtig: MX erst umstellen, nachdem alle anderen Konfigurations- schritte abgeschlossen sind. Sonst werden Mails an SecuMail® geroutet, während Microsoft 365 sie noch nicht annehmen kann.

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

Hinweis zum SPF-Record: Der SPF-Record gehört zum Sendeweg und ist dort beschrieben (siehe Sendeweg: Relay mit Filter bzw. Sendeweg: Relay mit Encryption).

Hinweise

  • Bei Änderungen der SecuMail-Netze (neue IPs) müssen sowohl die SenderIPAddresses als auch die EFSkipIPs aktualisiert werden.
  • Dieser Connector allein schränkt den Empfang nicht ein. Microsoft 365 nimmt weiterhin auch Mails von anderen Quellen an. Für exklusiven Empfang ausschließlich über SecuMail® siehe: Empfangsweg: Exklusiver Empfang

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.



MX via SecuMail · Empfangsweg - Exklusiver Empfang


Gilt für: MX via SecuMail

Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: NÖTIG (schließt die Ghost-Sender-Lücke; Zusatz zu IP-Whitelist) Voraussetzung: Inbound Connector aus Empfangsweg: IP-Whitelist muss bereits eingerichtet sein.

Ziel

Microsoft 365-Tenant so konfigurieren, dass ausschließlich 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 Microsoft 365 zustellen, ohne dass SecuMail® diese prüfen kann (inkl. „Ghost-Sender"-Spoofing der eigenen Domain, siehe Warnung unten).
  • Maximaler Schutz: Jede eingehende Mail hat den SecuMail-Filter durchlaufen.

Voraussetzungen

Mail-Flow-Regel anlegen NÖTIG

WARNUNG — „Ghost-Sender"-Effekt: Eine Regel nur mit FromScope NotInOrganization ist NICHT exklusiv — Microsoft 365 wertet Mails mit der EIGENEN Domain im Absender als „intern", sodass Eigendomain-Spoofing direkt an den Tenant die Regel umgeht. Die Regel unten gilt daher für ALLE eingehenden Mails; Ausnahmen nur SecuMail-Pfad oder echt-interne Mail (Header X-MS-Exchange-Organization-AuthAs = Internal, extern nicht setzbar).

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Rules:

TODO:

  • ➜ Regel hinzufügen > Neue Regel erstellen
  • ➜ Name: Nur SecuMail-Empfang erlauben
  • ➜ Priorität: 0 (höchste)
  • ➜ Bedingung: Auf alle Nachrichten anwenden (Apply to all messages)
  • ➜ Ausnahme 1: Absender-IP in einem dieser Bereiche > 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27
  • ⇄ Alternative: statt IP-Ausnahme den Inbound Connector an *.secumail.de binden — fälschungssicher, IP-unabhängig (siehe Empfangsweg: IP-Whitelist)
  • ➜ Ausnahme 2: Header X-MS-Exchange-Organization-AuthAs enthält Internal
  • ➜ Aktion: Nachricht ablehnen, Text "Mail muss über SecuMail® Gateway zugestellt werden.", Statuscode 5.7.1
  • ➜ Regel aktivieren

Funktionstest

  1. Externe Testmail direkt an den Tenant (nicht über SecuMail®) -> Muss mit 5.7.1 abgelehnt werden.
  2. Ghost-Sender-Test: direkt an den Tenant, aber mit GEFÄLSCHTER eigener Domain im Absender -> Muss ebenfalls mit 5.7.1 abgelehnt werden (sonst greift nur eine NotInOrganization-Regel — Lücke).
  3. Testmail regulär über MX (via SecuMail®) -> Muss zugestellt werden.

Hinweise

  • Diese Regel hat höchste Priorität (Priority: 0), damit sie vor anderen Mail-Flow-Regeln greift.
  • Interne/authentifizierte Mails sind über die AuthAs: Internal- Ausnahme freigestellt.
  • Legitime Nicht-SecuMail-Quellen (andere Partner-Relays, externe Dienste) ggf. mit eigener IP-Ausnahme ergänzen — sonst werden auch sie abgelehnt.
  • Bei Änderungen der SecuMail-Netze muss auch diese Regel aktualisiert werden.

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.



MX via Microsoft · Empfangsweg - Encryption-Loop (eingehend entschlüsseln)


Gilt für: MX via Microsoft

Produkte:

  • Encryption

Priorität: EMPFOHLEN (für Encryption-only mit MX bei Microsoft 365)

Wann gilt dieser Case?

Dieser Case beschreibt den Empfangsweg von Setup 2 – MX via Microsoft: Ihr MX-Record bleibt bei Microsoft 365. Eingehende Mail wird zur S/MIME- Entschlüsselung und Signaturprüfung über das SecuMail®-Encryption-Gateway (enc.secumail.de) geleitet und kommt zurück.

Gehört zusammen mit dem Sendeweg (ausgehende Mail verschlüsseln): Sendeweg: Encryption-Loop (MX via Microsoft). Beide Wege bilden zusammen Setup 2.

Wichtig: Der Empfangsweg ist nötig, wenn SecuMail® eingehende verschlüsselte Mail zentral entschlüsseln soll. Entschlüsseln Ihre Empfänger S/MIME selbst (z.B. in Outlook), kann er entfallen. Setup 2 gilt nur für Encryption-only; mit SecuMail® Filter gilt Setup 1 — siehe Welches Setup habe ich?.

Ablauf

Eingehende Mail aus dem Internet nimmt diesen Weg:

Internet -> Microsoft 365 (MX) -> SecuMail® Encryption (enc.secumail.de) -> S/MIME-Entschlüsselung/Signaturprüfung -> zurück an Microsoft 365 -> Postfach

Es werden alle eingehenden externen Mails an interne Empfänger ausgeleitet; das Gateway entschlüsselt, was verschlüsselt ist, und lässt den Rest unverändert durch. Der Empfangsweg ist spiegelbildlich zum Sendeweg, nur mit FromScope = NotInOrganization.

Für den Empfangsweg werden eigene Connectoren angelegt (getrennt vom Sendeweg). Connector-Typ und TLS-Verhalten sind identisch zum Sendeweg.

Schritt 1: Sende-Connector (Microsoft 365 -> SecuMail®) EMPFOHLEN

↗ Direkt öffnen

Im Exchange Admin Center (EAC): Verbindung von Office 365 zu Mailserver der Organisation, Name SecuMail Encryption Eingang, Smarthost enc.secumail.de, Interne Exchange-Header beibehalten aktivieren.

Schritt 2: Mail-Flow-Regel (eingehende Mail ausleiten) EMPFOHLEN

↗ Direkt öffnen

Die Regel leitet eingehende externe Mail an interne Empfänger an SecuMail® aus. Die Ausnahme auf den Verarbeitungs-Header verhindert den Loop.

Wichtig: Wie im Sendeweg verhindert die Header-Ausnahme den Loop — SecuMail® markiert die bereits entschlüsselte Mail mit X-SecuMail-Encryption: inbound, sodass die zurückkehrende Mail nicht erneut ausgeleitet wird (im Sendeweg ist es X-SecuMail-Encryption: outbound).

Schritt 3: Empfangs-Connector (SecuMail® -> Microsoft 365) EMPFOHLEN

↗ Direkt öffnen

Hinweis: Wie beim Sende-Rückweg-Connector gibt es beim OnPremises-Typ kein Force-TLS auf der Empfangsseite (RequireTls $false); TLS wird am sendenden SecuMail®-MTA erzwungen.

Prüfung im Tenant

Erwartet:

  • FromScope: NotInOrganization
  • SentToScope: InOrganization
  • ExceptIfHeaderContainsMessageHeader: {X-SecuMail-Encryption}

Erwartet:

  • ConnectorType: OnPremises
  • RequireTls: False

Funktionstest

  1. Eine verschlüsselte Mail von extern an ein internes Postfach senden. -> Prüfen, ob die Mail über SecuMail Encryption Eingang ausgeleitet, entschlüsselt zurückgeliefert und zugestellt wird — ohne Loop.
  2. Eine unverschlüsselte Mail von extern senden. -> Muss normal zugestellt werden (vom Gateway unverändert durchgereicht).

Hinweise

  • Der OnPremises-Connector ist hier korrekt — anders als im Setup 1, wo ein OnPremises-Inbound-Connector Loops verursacht. Der Loop-Schutz läuft über die Header-Ausnahme. Hintergrund: Pitfall: OnPremises- vs. Partner-Connector.
  • Diese Konfiguration entspricht dem von Microsoft dokumentierten in-and-out-Routing (Dienst nach Microsoft 365, MX bei Microsoft).

Verwandte FAQ-Cases

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






Microsoft 365 Konfiguration - Sendeweg

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


MX via SecuMail · Sendeweg - Relay mit Filter


Gilt für: MX via SecuMail

Produkte:

  • Filter

Priorität: NÖTIG

Ziel

Ausgehende Mails des Microsoft 365-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 Mail-Flow-Regel muss so konfiguriert sein, dass nur Mails an externe Empfänger geroutet werden.

Voraussetzungen

Schritt 1: Outbound Connector anlegen NÖTIG

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector hinzufügen (Add a connector)
  • ➜ Verbindung von: Office 365, zu: Partnerorganisation (Partner organization)
  • ➜ Name: SecuMail Filter Outbound
  • ➜ Routing: Mails über diese Smarthosts weiterleiten > relay.secumail.de
  • ➜ TLS: Immer TLS verwenden aktivieren, Stufe Zertifikat ist gültig (Certificate validation)
  • ➜ Nur verwenden, wenn eine Transport Rule darauf verweist (IsTransportRuleScoped)
  • ➜ Connector aktivieren

Ergebnis: Ein Outbound Connector der Mails an relay.secumail.de routet

Prüfung per PowerShell:

  • ConnectorType: Partner
  • SmartHosts: { relay.secumail.de }
  • TlsSettings: CertificateValidation
  • UseMXRecord: False
  • IsTransportRuleScoped: True
  • Enabled: True

Schritt 2: Mail-Flow-Regel für ausgehende Mails NÖTIG

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

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Rules:

TODO:

  • ➜ Regel hinzufügen > Neue Regel erstellen
  • ➜ Name: Route ausgehend über SecuMail® Filter
  • ➜ Bedingung 1: Der Absender befindet sich > Innerhalb der Organisation (Inside the organization)
  • ➜ Bedingung 2: Der Empfänger befindet sich > Außerhalb der Organisation (Outside the organization)
  • ➜ Aktion: Nachricht umleiten an den folgenden Connector > SecuMail Filter Outbound
  • ➜ Aktion: Verarbeitung weiterer Regeln stoppen aktivieren (verhindert Doppel-Routings)
  • ➜ Regel aktivieren

Ergebnis: Ausgehende externe Mails werden über SecuMail® Filter geroutet, interne Mails bleiben unberührt

Erklärung der Bedingungen:

  • Absender innerhalb der Organisation: Nur Mails von internen Absendern
  • Empfänger außerhalb der Organisation: Nur Mails an externe Empfänger
  • Kombination stellt sicher: Interne Mails werden nicht geroutet

Prüfung per PowerShell:

  • 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 Zertifikat ist gültig (CertificateValidation) angelegt — TLS wird erzwungen und das Server-Zertifikat auf Gültigkeit 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.

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector SecuMail Filter Outbound öffnen
  • ➜ 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
  • CertificateValidation: TLS erzwungen UND Zertifikat wird auf Gültigkeit geprüft (ohne Domainabgleich, Standard)
  • 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.

Prüfung per PowerShell:

Falls nach Umstellung Zustellprobleme auftreten, auf EncryptionOnly zurückstellen.

Schritt 4: DNS - SPF-Record prüfen NÖTIG

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.

Beispiel-Eintrag: v=spf1 include:_spf.secumail.de include:spf.protection.outlook.com -all

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. -> In der Nachrichtenverfolgung 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

  • Bei mehreren Connectors oder bestehenden Mail-Flow-Regeln auf Loop-Vermeidung achten — siehe Pitfall: Outbound Mail-Loop verhindern.
  • Port 25 wird verwendet (relay.secumail.de:25).
  • Diese Anleitung gilt nur für Variante A (Filter only). Bei Variante B (Encryption) und C (Filter+Encryption) verwenden Sie ausschließlich Sendeweg: Relay mit Encryption — der Encryption-Relay enthält die Filterung bereits.

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 mit Encryption


Gilt für: beide Setups

Produkte:

  • Encryption
  • Filter+Encryption

Priorität: NÖTIG

Ziel

Ausgehende Mails des Microsoft 365-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 Mail-Flow-Regel muss so konfiguriert sein, dass nur Mails an externe Empfänger geroutet werden.

Voraussetzungen

Schritt 1: Outbound Connector anlegen NÖTIG

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector hinzufügen (Add a connector)
  • ➜ Verbindung von: Office 365, zu: Partnerorganisation (Partner organization)
  • ➜ Name: SecuMail Encryption Outbound
  • ➜ Routing: Mails über diese Smarthosts weiterleiten > enc.secumail.de
  • ➜ TLS: Immer TLS verwenden aktivieren, Stufe Zertifikat ist gültig (Certificate validation)
  • ➜ Nur verwenden, wenn eine Transport Rule darauf verweist (IsTransportRuleScoped)
  • ➜ Connector aktivieren

Ergebnis: Ein Outbound Connector der Mails an enc.secumail.de routet

Prüfung per PowerShell:

  • ConnectorType: Partner
  • SmartHosts: { enc.secumail.de }
  • TlsSettings: CertificateValidation
  • UseMXRecord: False
  • IsTransportRuleScoped: True
  • Enabled: True

Schritt 2: Mail-Flow-Regel für ausgehende Mails NÖTIG

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

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Rules:

TODO:

  • ➜ Regel hinzufügen > Neue Regel erstellen
  • ➜ Name: Route ausgehend über SecuMail® Encryption
  • ➜ Bedingung 1: Der Absender befindet sich > Innerhalb der Organisation (Inside the organization)
  • ➜ Bedingung 2: Der Empfänger befindet sich > Außerhalb der Organisation (Outside the organization)
  • ➜ Aktion: Nachricht umleiten an den folgenden Connector > SecuMail Encryption Outbound
  • ➜ Aktion: Verarbeitung weiterer Regeln stoppen aktivieren (verhindert Doppel-Routings)
  • ➜ 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 außerhalb der Organisation: Nur Mails an externe Empfänger
  • Kombination stellt sicher: Interne Mails werden nicht geroutet

Prüfung per PowerShell:

  • 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 Zertifikat ist gültig (CertificateValidation) angelegt — TLS wird erzwungen und das Server-Zertifikat auf Gültigkeit 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.

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector SecuMail Encryption Outbound öffnen
  • ➜ 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
  • CertificateValidation: TLS erzwungen UND Zertifikat wird auf Gültigkeit geprüft (ohne Domainabgleich, Standard)
  • 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.

Prüfung per PowerShell:

Falls nach Umstellung Zustellprobleme auftreten, auf EncryptionOnly zurückstellen.

Schritt 4: DNS - SPF-Record prüfen NÖTIG

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.

Beispiel-Eintrag: v=spf1 include:_spf.secumail.de include:spf.protection.outlook.com -all

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. -> In der Nachrichtenverfolgung 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

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 - Auslieferung via Microsoft 365 + ARC Seal


Gilt für: beide Setups

Produkte:

  • Encryption
  • Filter+Encryption

NUR wenn der Kunde die Auslieferung via Microsoft 365 wählt. Priorität: NÖTIG (wenn Auslieferung via Microsoft 365 gewählt)

Hinweis: Diese Anleitung beschreibt das ARC-Design (Partner-Connector) und gilt primär für Setup 1 – MX via SecuMail. Bei Setup 2 – MX via Microsoft (Encryption-Loop) ist das Standard-Auslieferungsdesign der OnPremises-Connector mit Header-Ausnahme (Sendeweg: Encryption-Loop (MX via Microsoft)); das hier beschriebene ARC-Verfahren ist dort eine gleichwertige Alternative.

Ziel

Verschlüsselte Mails, die SecuMail® bearbeitet hat, final via Microsoft 365 ausliefern. Microsoft 365 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 via Microsoft 365 ausliefert, sieht Microsoft 365 folgendes:

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

Microsoft 365 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 Microsoft 365 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 NÖTIG

↗ Direkt öffnen

Im Microsoft 365 Defender / Security Portal: 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.

Wichtig: Set-ArcConfig ersetzt die Liste der Trusted Sealers vollständig. Zuerst bestehende Sealers auslesen und secumail.de ergänzen, damit bestehende Einträge nicht verloren gehen:

if ("secumail.de" -notin $current) { $current += "secumail.de" }

Wenn der Tenant garantiert noch keine Trusted Sealers konfiguriert hat, genügt auch die Kurzform:

Prüfung per PowerShell:

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

Schritt 2: SPF Hard Fail prüfen (ggf. deaktivieren) NÖTIG

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

Hinweis: In der Default-Antispam-Policy steht der Wert ab Werk auf Off. Bei aktivierten Preset Security Policies (Standard oder Strict) sowie bei Custom-Policies kann er abweichen — daher ist die Prüfung pro Policy zwingend.

↗ Direkt öffnen

Im Microsoft 365 Defender / Security Portal: 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:

Prüfung per PowerShell:

  • MarkAsSpamSpfRecordHardFail: Off (bei allen relevanten Policies)

Prüfung der Gesamtkonfiguration

  1. ARC-Konfiguration prüfen: Im Microsoft 365 Defender unter Email authentication settings > ARC prüfen, ob secumail.de als Trusted ARC Sealer gelistet ist.

Prüfung per PowerShell:

  1. Antispam-Policy prüfen: Im Microsoft 365 Defender unter Anti-spam policies die Default-Policy und alle Custom-Policies auf SPF Hard Fail prüfen.

Prüfung per PowerShell:

  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 via Microsoft 365 ausgeliefert 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

  • Bei mehreren Connectors oder bestehenden Mail-Flow-Regeln auf Loop-Vermeidung achten — siehe Pitfall: Outbound Mail-Loop verhindern.
  • In diesem ARC-/Partner-Design (Setup 1) treten Loops am häufigsten auf, wenn der Inbound-Connector vom Gateway als ConnectorType = OnPremises konfiguriert ist statt als Partner. EOP markiert Re-Entry-Mails vom Gateway dann als InOrganization, und die Outbound-Routing- Regel greift erneut. Vor dem Debuggen anderer Ursachen erst Connector-Typ prüfen: siehe Pitfall: OnPremises- vs. Partner-Connector. (Im Setup-2-Design ist OnPremises dagegen korrekt — siehe Sendeweg: Encryption-Loop (MX via Microsoft).)
  • 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 Auslieferung via Microsoft 365 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.

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.



MX via Microsoft · Sendeweg - Encryption-Loop (ausgehend verschlüsseln)


Gilt für: MX via Microsoft

Produkte:

  • Encryption

Priorität: NÖTIG (für Encryption-only mit MX bei Microsoft 365)

Wann gilt dieser Case?

Dieser Case beschreibt den Sendeweg von Setup 2 – MX via Microsoft: Ihr MX-Record bleibt unverändert bei Microsoft 365, ausgehende Mail wird zur S/MIME-Verschlüsselung über das SecuMail®-Encryption-Gateway (enc.secumail.de) geleitet.

Gehört zusammen mit dem Empfangsweg (eingehende Mail entschlüsseln): Empfangsweg: Encryption-Loop (MX via Microsoft). Beide Wege bilden zusammen Setup 2.

Wichtig: Setup 2 gilt ausschließlich für Encryption-only. Sobald SecuMail® Filter im Spiel ist, muss der MX auf SecuMail® zeigen (Setup 1) — siehe Welches Setup habe ich?.

Ablauf

Ausgehende Mail an externe Empfänger nimmt diesen Weg:

Postfach -> Microsoft 365 -> SecuMail® Encryption (enc.secumail.de) -> S/MIME-Signatur/-Verschlüsselung -> Auslieferung

Für die Auslieferung gibt es zwei Varianten:

  • Variante A: SecuMail® liefert direkt ins Internet aus (häufiger, einfacher).
  • Variante B: SecuMail® liefert zurück an Microsoft 365, das final ausliefert.

Schritt 1: Ausleitung zur Verschlüsselung NÖTIG

Ausgehende Mail an externe Empfänger wird an das SecuMail®-Encryption- Gateway ausgeleitet. Dazu dienen ein gescopter Outbound-Connector und eine Mail-Flow-Regel.

Der Outbound-Connector ist vom Typ OnPremises (Mailserver der Organisation), nicht Partner. Mit CloudServicesMailEnabled = $true behält Microsoft 365 die internen Header der Mail bei, sodass die verarbeitete Mail später als vertrauenswürdig behandelt wird.

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector hinzufügen (Add a connector)
  • ➜ Verbindung von: Office 365, zu: Mailserver der Organisation (Your organization's email server)
  • ➜ Name: SecuMail Encryption Loop
  • ➜ Routing: Mails über diese Smarthosts weiterleiten > enc.secumail.de
  • ➜ TLS: Immer TLS verwenden, Stufe Domainvalidierung > *.secumail.de
  • ➜ Nur verwenden, wenn eine Transport Rule darauf verweist (IsTransportRuleScoped)
  • ➜ Interne Exchange-Header beibehalten (Retain internal Exchange email headers) aktivieren

Ergebnis: Ein Outbound Connector, der Mails an enc.secumail.de routet

Die Mail-Flow-Regel leitet nur ausgehende, noch nicht verarbeitete Mail aus. Die Ausnahme auf den Header X-SecuMail-Encryption ist der eigentliche Loop-Schutz (siehe Kasten unten).

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Rules:

TODO:

  • ➜ Regel hinzufügen > Neue Regel erstellen
  • ➜ Name: Route ausgehend über SecuMail® Encryption
  • ➜ Bedingung: Absender innerhalb der Organisation (Inside the organization)
  • ➜ Bedingung: Empfänger außerhalb der Organisation (Outside the organization)
  • ➜ Aktion: Nachricht umleiten an den folgenden Connector > SecuMail Encryption Loop
  • ➜ Ausnahme: Header X-SecuMail-Encryption enthält outbound (Loop-Schutz, siehe unten)
  • ➜ Verarbeitung weiterer Regeln stoppen aktivieren
  • ➜ Regel aktivieren

Wichtig: Die Ausnahme auf den Header X-SecuMail-Encryption: outbound verhindert den Mail-Loop. SecuMail® stampft diesen Header beim ersten Durchlauf auf. Eine bereits verarbeitete Mail trägt ihn — die Regel greift dann nicht erneut und leitet sie nicht ein zweites Mal aus. Ohne diese Ausnahme würde die zurückkehrende Mail (Variante B) endlos im Kreis laufen.

Schritt 2 / Variante A: Auslieferung direkt durch SecuMail® NÖTIG

Die häufigere und einfachere Variante: SecuMail® liefert die verschlüsselte Mail nach der Verarbeitung direkt ins Internet aus. Die Mail kehrt nicht zu Microsoft 365 zurück.

In dieser Variante ist kein eingehender Connector nötig — es gibt keine Rücklieferung an Microsoft 365.

Da SecuMail® die Mail im Namen Ihrer Domain ausliefert, muss der SPF-Record der Kundendomain die SecuMail®-Server als berechtigte Absender enthalten:

v=spf1 include:_spf.secumail.de include:spf.protection.outlook.com -all

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

Schritt 2 / Variante B: Auslieferung zurück via Microsoft 365 NÖTIG

In dieser Variante liefert SecuMail® die fertige Mail zurück an Microsoft 365, das sie final ausliefert. Dafür ist ein eingehender Connector nötig, der die Rücklieferung annimmt.

Auch dieser Connector ist vom Typ OnPremises (Mailserver der Organisation) mit CloudServicesMailEnabled = $true — passend zum Outbound-Connector aus Schritt 1, damit die internen Header erhalten bleiben.

↗ Direkt öffnen

Im Exchange Admin Center (EAC) — Mail flow > Connectors:

TODO:

  • ➜ Connector hinzufügen (Add a connector)
  • ➜ Verbindung von: Mailserver der Organisation (Your organization's email server), zu: Office 365
  • ➜ Name: SecuMail Encryption Loop Rückweg
  • ➜ Absender-Identifikation: je nach Tenant per IP-Adresse, Zertifikat oder ARC (siehe Hinweise unten)
  • ➜ Interne Exchange-Header beibehalten aktivieren

Ergebnis: Microsoft 365 nimmt die zurückgelieferten Mails von SecuMail® an

Wichtig: Beim Connector-Typ Mailserver der Organisation (OnPremises) gibt es auf der Microsoft-Empfangsseite KEINE Option zum Erzwingen von TLS — RequireTls bleibt False. Die TLS-Verschlüsselung wird ausschließlich am sendenden SecuMail®-MTA erzwungen. Das ist anders als beim Partner-Inbound- Connector in Setup 1 (Empfangsweg: IP-Whitelist), wo TLS erzwungen wird.

Hinweis zur Absender-Identifikation: Das Beispiel schränkt auf die SecuMail®-IPs ein. Microsoft 365 lässt für den Rückweg auch andere Methoden zu — z.B. per Zertifikat (-RestrictDomainsToCertificate $true -TlsSenderCertificateName "*.secumail.de") oder die ARC-basierte Variante (Sendeweg: Auslieferung via Microsoft 365 + ARC). Wählen Sie, was im Tenant unterstützt und gewünscht ist.

Hinweis: Weil Microsoft 365 in dieser Variante selbst ausliefert, stammt die ausgehende Mail aus Microsoft 365 — der SPF-Record kann auf dem Microsoft-Standardwert bleiben (include:spf.protection.outlook.com). Prüfen Sie dennoch, dass SecuMail® als vertrauenswürdige Quelle akzeptiert wird.

Optional / Alternative: Statt der OnPremises-Header-Methode kann die Rücklieferung auch über einen Partner-Connector mit ARC-Seal abgesichert werden (wie in Setup 1). Das ist gleichwertig, erfordert aber die ARC-Konfiguration — siehe Sendeweg: Auslieferung via Microsoft 365 + ARC.

Prüfung im Tenant

Erwartet:

  • ConnectorType: OnPremises
  • SmartHosts: { enc.secumail.de }
  • IsTransportRuleScoped: True
  • CloudServicesMailEnabled: True

Erwartet:

  • FromScope: InOrganization
  • ExceptIfHeaderContainsMessageHeader: {X-SecuMail-Encryption}
  • ExceptIfHeaderContainsWords: {outbound}

Nur bei Variante B zusätzlich:

Erwartet:

  • ConnectorType: OnPremises
  • RequireTls: False (kein Force-TLS auf der Empfangsseite — beabsichtigt)
  • CloudServicesMailEnabled: True

Funktionstest

  1. Eine zu verschlüsselnde Mail an einen externen Empfänger senden. -> In der Nachrichtenverfolgung prüfen, ob die Mail über den Connector SecuMail Encryption Loop geroutet wurde.
  2. Prüfen, dass die Mail verschlüsselt/signiert beim Empfänger ankommt.
  3. Nur Variante B: Prüfen, dass die zurückkehrende Mail nicht erneut ausgeleitet wird (kein Loop in der Nachrichtenverfolgung).

Hinweise

  • Der OnPremises-Connector ist hier korrekt — anders als im Setup 1, wo ein OnPremises-Inbound-Connector Loops verursacht. Der Unterschied liegt im Loop-Schutz: Setup 1 hält die Mail extern (Partner), Setup 2 hält sie intern, verhindert den Loop aber über die Header-Ausnahme. Hintergrund: Pitfall: OnPremises- vs. Partner-Connector.
  • Diese Konfiguration entspricht dem von Microsoft dokumentierten Muster zur Integration eines E-Mail-Add-on-Dienstes.

Verwandte FAQ-Cases

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






Microsoft 365 Konfiguration - API-Sync

Adress- und Benutzersynchronisation via Microsoft Graph API.


Graph API - Synchronisierung der gültigen E-Mail-Adressen


Gilt für: beide Setups

Produkte:

  • Filter
  • Filter+Encryption

Priorität: OPTIONAL

Ziel

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

Hinweis bei Filter+Encryption (Variante C)

Wenn beide Sync-Varianten (Filter und S/MIME) benötigt werden, genügt EINE gemeinsame App-Registrierung mit EINEM Client Secret. Lediglich die zugewiesenen Sicherheitsgruppen unterscheiden sich:

  • SecuMail-Filter-Users (für Filter-Sync)
  • SecuMail-Encryption-SMIME-Users (für S/MIME-Sync)

Folgen Sie der Anleitung in einer der beiden FAQs einmal und verwenden Sie die gleichen Zugangsdaten in beiden SecuMail®-Sync-Konfigurationen. So vermeiden Sie doppelten Aufwand bei der Pflege (z.B. beim Erneuern des Client Secrets).

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
  • Global Administrator oder Application Administrator für Admin Consent

Schritt 1: App Registration in Entra ID anlegen NÖTIG

↗ Direkt öffnen

Im Entra ID Portal — App registrations:

TODO:

  • ➜ Neue Registrierung (New registration)
  • ➜ Name: SecuMail Filter Sync (oder ähnlich)
  • ➜ Unterstützte Kontotypen: Nur Konten in diesem Organisationsverzeichnis (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 NÖTIG

↗ Direkt öffnen

Im Entra ID Portal, in der App-Registrierung — Certificates & secrets:

TODO:

  • ➜ 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 NÖTIG

↗ Direkt öffnen

Im Entra ID Portal, in der App-Registrierung — API permissions:

TODO:

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

Ergebnis: Berechtigungen erteilt

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

Schritt 4: Security Group anlegen OPTIONAL

Wenn nur bestimmte Benutzer synchronisiert werden sollen:

↗ Direkt öffnen

Im Entra ID Portal — Groups:

TODO:

  • ➜ 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 NÖTIG

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äßige 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 genügt eine gemeinsame App-Registrierung — siehe Hinweis oben.

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


Gilt für: beide Setups

Produkte:

  • Encryption
  • Filter+Encryption

Priorität: OPTIONAL

Ziel

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

Hinweis bei Filter+Encryption (Variante C)

Wenn beide Sync-Varianten (Filter und S/MIME) benötigt werden, genügt EINE gemeinsame App-Registrierung mit EINEM Client Secret. Lediglich die zugewiesenen Sicherheitsgruppen unterscheiden sich:

  • SecuMail-Filter-Users (für Filter-Sync)
  • SecuMail-Encryption-SMIME-Users (für S/MIME-Sync)

Folgen Sie der Anleitung in einer der beiden FAQs einmal und verwenden Sie die gleichen Zugangsdaten in beiden SecuMail®-Sync-Konfigurationen. So vermeiden Sie doppelten Aufwand bei der Pflege (z.B. beim Erneuern des Client Secrets).

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
  • Global Administrator oder Application Administrator für Admin Consent

Schritt 1: App Registration in Entra ID anlegen NÖTIG

↗ Direkt öffnen

Im Entra ID Portal — App registrations:

TODO:

  • ➜ Neue Registrierung (New registration)
  • ➜ Name: SecuMail S/MIME Sync (oder ähnlich)
  • ➜ Unterstützte Kontotypen: Nur Konten in diesem Organisationsverzeichnis (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 NÖTIG

↗ Direkt öffnen

Im Entra ID Portal, in der App-Registrierung — Certificates & secrets:

TODO:

  • ➜ 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 NÖTIG

↗ Direkt öffnen

Im Entra ID Portal, in der App-Registrierung — API permissions:

TODO:

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

Ergebnis: Berechtigungen erteilt

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

Schritt 4: Security Group anlegen OPTIONAL

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

↗ Direkt öffnen

Im Entra ID Portal — Groups:

TODO:

  • ➜ 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 NÖTIG

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äßige 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 kann die gleiche App-Registrierung wie für Filter-Sync verwendet werden — siehe Hinweis oben. Nur die zugewiesenen Sicherheitsgruppen unterscheiden sich.
  • Für Filter-Sync siehe: Graph API: Adress-Synchronisierung

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.






Microsoft 365 Konfiguration - Pitfalls und Lösungen

Funktionstest, bekannte Stolperfallen und ihre Behebung.


Funktionstest


Gilt für: beide Setups

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, Mail-Flow-Regeln, 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.

Schnellzugang zu den genutzten Portalen:

↗ Connectors

↗ Mail-Flow-Regeln

↗ Nachrichtenverfolgung

↗ ARC / E-Mail-Auth

↗ Anti-Spam

TODO:

  • ➜ Inbound Connector prüfen — Mail flow > Connectors > SecuMail Inbound (siehe Empfangsweg: IP-Whitelist)
  • ➜ Outbound Connector prüfen — Mail flow > Connectors > SecuMail Filter/Encryption Outbound (siehe Sendeweg: Relay mit Filter)
  • ➜ Mail-Flow-Regeln prüfen — Mail flow > Rules, alle SecuMail-Regeln
  • ➜ Nur Cases B/C: ARC prüfen — Defender > E-Mail-Authentifizierung > ARC, secumail.de als Trusted Sealer (siehe Sendeweg: Auslieferung via Microsoft 365 + ARC)
  • ➜ Nur Cases B/C: Antispam-Policy prüfen — Defender > Antispamrichtlinien, SPF Hard Fail

Test 1: Empfangsweg (extern -> Microsoft 365 via SecuMail®)

  1. Von einem externen Postfach eine Testmail an ein Microsoft 365-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

Nachrichtenverfolgung 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

Prüfung per PowerShell:

Test 2: Sendeweg (Microsoft 365 -> extern via SecuMail®)

  1. Vom Microsoft 365-Postfach eine Testmail an eine externe Adresse senden.
  2. Prüfen: a) Mail wurde zugestellt. b) In der Nachrichtenverfolgung: Mail wurde über den Outbound Connector geroutet. c) Beim Empfänger: Message Header prüfen, ob die Mail über SecuMail® (relay.secumail.de oder enc.secumail.de) geroutet wurde.

Nachrichtenverfolgung 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

Prüfung per PowerShell:

Test 3: Interne Mails (Microsoft 365 intern)

  1. Vom Microsoft 365-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 Nachrichtenverfolgung: Kein Routing über SecuMail®

Dies stellt sicher, dass die Mail-Flow-Regel interne Mails korrekt ausschließt.

Test 4: Auslieferung via Microsoft 365 (nur bei ARC-Konfiguration, Cases B/C)

  1. Eine verschlüsselte Mail senden, die via Microsoft 365 ausgeliefert 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

Test 5: Exklusiver Empfang (nur falls konfiguriert)

Nur relevant, wenn Empfangsweg: Exklusiver Empfang eingerichtet ist.

  1. Von einem externen Server (NICHT über SecuMail®) eine Testmail an ein Microsoft-365-Postfach senden — z.B. von einem Webmail- Anbieter, der direkt via MX zustellt.
  2. Prüfen: a) Die Mail muss mit Statuscode 5.7.1 abgelehnt werden. b) Der Reject-Text entspricht dem konfigurierten Wert (Default: "Mail muss über SecuMail® Gateway zugestellt werden.").
  3. Eine reguläre Testmail über MX/SecuMail® senden. -> Muss zugestellt werden (Ausnahme greift).

Häufige Probleme

Ausgehende Mails werden nicht über SecuMail® geroutet

  • Ursache: Mail-Flow-Regel greift nicht.
  • Prüfen (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, Regel muss Enabled sein.

Eingehende Mails werden als Spam markiert

  • Ursache: Enhanced Filtering nicht konfiguriert oder IP-Whitelist fehlt.
  • Prüfen (Portal): Mail flow > Connectors — Connector-Einstellungen prüfen.
  • Prüfen (PowerShell): Get-InboundConnector | Format-List EFSkipIPs, SenderIPAddresses
  • Lösung: Enhanced Filtering und IP-Whitelist einrichten (siehe Empfangsweg: IP-Whitelist).

Mails über die Auslieferung via Microsoft 365 werden abgelehnt (NDR)

  • Ursache: ARC nicht konfiguriert oder SPF Hard Fail aktiv.
  • Prüfen (Portal): Microsoft 365 Defender — ARC-Konfiguration und Antispam-Policy prüfen.
  • Prüfen (PowerShell): Get-ArcConfig Get-HostedContentFilterPolicy Default | Select-Object MarkAsSpamSpfRecordHardFail
  • Lösung: Sendeweg: Auslieferung via Microsoft 365 + ARC durchlaufen.

TLS-Fehler bei Zustellung

  • Ursache: TlsSettings auf CertificateValidation oder DomainValidation, aber Zertifikat des Ziels passt nicht.
  • Prüfen (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.



Pitfall - Outbound Mail-Loop verhindern


Gilt für: beide Setups

Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: ZWINGEND (gilt für alle Sendeweg-Varianten)

Symptom

Eine Mail an einen Empfänger in einem anderen Microsoft 365-Tenant verlässt den eigenen Tenant über das SecuMail®-Gateway, kommt aber unmittelbar danach zurück und wird vom eigenen Exchange Online Protection (EOP) erneut an das Gateway übergeben. Es entsteht eine Schleife:

Tenant A (Sender) -> EOP A -> SecuMail® -> EOP B (Empfänger) -> EOP B klassifiziert als Outbound -> SecuMail® -> EOP A -> EOP A nimmt die Mail erneut über den Outbound-Connector an -> Schleife

Sichtbar wird das u.a. durch wiederholte Einträge im Message-Trace mit identischer Subject/MessageID und steigender Hop-Count, bis EOP die Mail schließlich mit Loop-Detection abweist.

Ursache

Der Loop entsteht, wenn der Outbound-Connector zum Gateway ungescoped ist und/oder die Routing-Regel zurückkehrende Mails nicht ausschließt:

  1. Outbound-Connector triggert per Domain-Wildcard (RecipientDomains: *) ohne IsTransportRuleScoped. Dann nimmt EOP jede ausgehende Mail über diesen Connector - auch zurückkehrende.
  2. Routing-Regel ohne präzisen Scope (FromScope/SentToScope fehlen). Dann greift die Regel auch für Mails, die gerade vom Gateway zurückkehren.
  3. Inbound-Connector vom Gateway als Typ OnPremises statt Partner. Damit klassifiziert EOP zurückkehrende Mails als InOrganization (siehe Pitfall: OnPremises- vs. Partner-Connector) und die Outbound-Regel greift für diese Mails erneut.

Schutz im SecuMail®-Standardsetup

Das automatische Provisioning legt Connector und Regel so an, dass keiner der drei Loop-Pfade entstehen kann:

  • Outbound-Connector mit IsTransportRuleScoped = $true. Der Connector wird ausschließlich verwendet, wenn eine Mail-Flow-Regel ihn explizit referenziert; niemals automatisch für beliebige ausgehende Mails.
  • Routing-Regel mit präzisem Scope: FromScope = InOrganization, SentToScope = NotInOrganization und StopRuleProcessing = $true. Damit werden externe Mails (auch zurückkehrende vom Gateway) nicht erfasst, und nachfolgende Regeln können die Mail nicht erneut an den Connector binden.
  • Inbound-Connector vom Gateway mit ConnectorType = Partner. Zurückkehrende Mails bleiben aus EOP-Sicht extern und matchen FromScope = InOrganization nicht.

Prüfung im Tenant

Erwartet für den SecuMail®-Outbound-Connector:

  • ConnectorType: Partner
  • IsTransportRuleScoped: True
  • RecipientDomains: leer oder explizit (kein *)

Erwartet für die Routing-Regel:

  • FromScope: InOrganization
  • SentToScope: NotInOrganization
  • StopRuleProcessing: True

Erwartet für den SecuMail®-Inbound-Connector:

  • ConnectorType: Partner

Defensive Zusatzmaßnahme (Header-Exception) OPTIONAL

Bei Migrationen aus älteren Smarthost-Setups oder in Tenants mit ungewöhnlichen Hybrid-Konstellationen kann zusätzlich eine Header-basierte Exception auf der Routing-Regel gesetzt werden:

Except if: Header X-SecuMail-Encryption matches "outbound"

Wirkung: Selbst wenn EOP eine zurückkehrende Mail fälschlich als InOrganization klassifiziert, greift die Routing-Regel nicht erneut, weil das Gateway den Header bereits beim ersten Durchgang gesetzt hat.

Hinweis: Die Header-Exception ist im SecuMail®-Standardsetup nicht nötig. Sie eignet sich als zusätzliche Sicherheitsschicht in Tenants, in denen die Connector-Konfiguration nicht vollständig unter Kontrolle ist.

Behebung in einem betroffenen Tenant

TODO:

  • ➜ Outbound-Connector neu binden: IsTransportRuleScoped $true, RecipientDomains @() ($null nicht erlaubt)
  • ➜ Routing-Regel scopen: FromScope InOrganization, SentToScope NotInOrganization, StopRuleProcessing $true
  • ➜ Inbound-Connector-Typ prüfen — bei OnPremises umstellen oder Header-Exception (siehe Pitfall: OnPremises- vs. Partner-Connector)
  • ➜ Message-Trace beobachten: Loop muss innerhalb weniger Minuten abreißen

Verwandte FAQ-Cases

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



Pitfall - OnPremises- vs. Partner-Connector


Gilt für: beide Setups

Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: ZWINGEND (Connector-Typ beeinflusst Mail-Klassifizierung)

Wichtig: Dieser Pitfall betrifft Setup 1 – MX via SecuMail (SecuMail® vorgelagert). Dort ist ein OnPremises-Inbound-Connector eine Fehlkonfiguration. In Setup 2 – MX via Microsoft (Encryption-Loop) ist OnPremises dagegen korrekt — der Loop-Schutz läuft dort über eine Header-Ausnahme statt über den Connector-Typ. Welches Setup für Sie gilt: Welches Setup habe ich?. Den Setup-2-Fall beschreibt Sendeweg: Encryption-Loop (MX via Microsoft) und Empfangsweg: Encryption-Loop (MX via Microsoft).

Symptom

Trotz korrekt eingerichteter Routing-Regel mit FromScope = InOrganization gerät der Mailfluss in Schleifen oder zurückkehrende Mails vom Gateway werden erneut als ausgehend behandelt. Im Message-Header steht X-MS-Exchange-Organization-AuthAs: Internal, obwohl die Mail über das Gateway aus dem Internet kommt.

Ursache

Der Inbound-Connector zum SecuMail®-Gateway ist als ConnectorType = OnPremises konfiguriert (typisch für Hybrid- oder klassische Smarthost-Setups), nicht als Partner.

Bei OnPremises-Inbound-Connectoren behandelt Exchange Online die ankommenden Mails wie aus einer eigenen On-Premises-Umgebung und setzt:

X-MS-Exchange-Organization-AuthAs: Internal

Damit gilt die Mail aus EOP-Sicht als InOrganization. Eine Routing-Regel mit FromScope = InOrganization greift dann auch für zurückkehrende Mails vom Gateway - der Loop-Schutz greift nicht (siehe Pitfall: Outbound Mail-Loop verhindern).

Bei Partner-Inbound-Connectoren bleibt die Mail aus EOP-Sicht extern (AuthAs: Anonymous oder Partner). FromScope = InOrganization matcht nicht, der Loop-Schutz greift.

Schutz im SecuMail®-Standardsetup

Im Setup-1-Standardsetup legt das automatische Provisioning Inbound- und Outbound-Connector beide mit ConnectorType = Partner an. Damit:

  • Ankommende Gateway-Mails bleiben extern klassifiziert.
  • Die FromScope-basierte Routing-Regel verhindert Loops zuverlässig.
  • IP-Whitelist und TLS-Validierung bleiben unabhängig vom Typ weiterhin wirksam.

Prüfung im Tenant

Erwartet für den SecuMail®-Inbound-Connector:

  • ConnectorType: Partner
  • SenderIPAddresses: SecuMail-IP-Bereiche
  • RequireTls: True

Erwartet für den SecuMail®-Outbound-Connector:

  • ConnectorType: Partner
  • IsTransportRuleScoped: True

Im Header einer real empfangenen Mail vom Gateway prüfen:

  • X-MS-Exchange-Organization-AuthAs: Anonymous (gewünscht)
  • X-MS-Exchange-Organization-AuthAs: Internal (Hinweis auf OnPremises)

Wann taucht OnPremises trotzdem auf?

  • Migrationen aus klassischen SEPPmail-Setups, die das Gateway als on-premises Mail-Server modelliert haben.
  • Hybrid-Konstellationen mit echtem Exchange On-Premises, in denen ein zusätzlicher OnPremises-Connector vorhanden ist.
  • Manuell angelegte Connectoren aus älteren Microsoft-Anleitungen.

In diesen Fällen (Setup 1) entweder den Connector-Typ auf Partner umstellen (empfohlen) oder die Header-basierte Defensive aus Pitfall: Outbound Mail-Loop verhindern zusätzlich aktivieren.

Achtung: Die obigen Fälle gelten für Setup 1 – MX via SecuMail. In Setup 2 – MX via Microsoft (Encryption-Loop) ist OnPremises der vorgesehene Connector-Typ und KEIN Fehler — dort nicht auf Partner umstellen. Siehe Sendeweg: Encryption-Loop (MX via Microsoft) und Empfangsweg: Encryption-Loop (MX via Microsoft).

Behebung in einem betroffenen Tenant

Der Connector-Typ kann an einem bestehenden Connector nicht direkt geändert werden. Vorgehen:

  1. Aktuelle Connector-Konfiguration sichern:
  1. Neuen Inbound-Connector vom Typ Partner anlegen (siehe Empfangsweg: IP-Whitelist) - mit identischen SenderIPAddresses und TLS-Einstellungen.
  2. Funktionstest mit Live-Traffic durchführen (Funktionstest). Im Header prüfen, dass X-MS-Exchange-Organization-AuthAs nicht mehr Internal ist.
  3. Alten OnPremises-Connector deaktivieren, dann nach erfolgreichem Test entfernen.

Verwandte FAQ-Cases

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



MX via SecuMail · Pitfall - Whitelist/Reject allein macht nicht SecuMail-only (Ghost-Sender)


Gilt für: MX via SecuMail

Produkte:

  • Filter
  • Encryption
  • Filter+Encryption

Priorität: NÖTIG (gilt für exklusiven Empfang, Setup MX via SecuMail)

Symptom

Trotz IP-Whitelist und/oder Reject-Regel nimmt Microsoft 365 weiterhin Mails an, die NICHT über SecuMail® kamen — insbesondere gefälschte Mails mit der eigenen Domain im Absender, die direkt an den Tenant zugestellt werden.

Ursache: der „Ghost-Sender"-Effekt

  • Whitelisten ist nur Vertrauen, keine Sperre: Connection-Allow-List und SCL-Bypass markieren SecuMail® als vertrauenswürdig, schließen aber niemanden aus.
  • Der MX-Record erzwingt keinen Pfad: Der Tenant-Endpunkt (<tenant>.mail.protection.outlook.com) nimmt direkte SMTP-Zustellung von jeder Quelle an.
  • Eine Reject-Regel, die nur auf FromScope NotInOrganization prüft, ist lückenhaft: M365 stuft Mails mit der EIGENEN Domain im Absender als „intern" ein. Eigendomain-Spoofing direkt an den Tenant wird dadurch NICHT erfasst — die gefährlichste Lücke (CEO-Fraud).

Richtig konfigurieren

Reject-Regel pfadbasiert statt FromScope: gilt für ALLE eingehenden Mails an die eigenen Domains, Ausnahmen nur (a) Absender-IP in den SecuMail-Netzen (ExceptIfSenderIpRanges) ODER (b) echt-interne Mail (X-MS-Exchange-Organization-AuthAs = Internal; diesen Header kann ein externer Absender nicht setzen).

Noch robuster: Inbound Connector zusätzlich an das SecuMail-Client- Zertifikat *.secumail.de binden (fälschungssicher, übersteht IP-Wechsel; siehe Empfangsweg: IP-Whitelist).

Schnelltest

Direkt an den Tenant (nicht über SecuMail®) mit gefälschter eigener Domain senden -> muss mit 5.7.1 abgelehnt werden. Wird die Mail zugestellt, greift nur eine FromScope-Regel — Lücke offen.

Verwandte FAQ-Cases

PowerShell-Befehle: Alle Schritte dieser Anleitung als PowerShell-Befehle zum Kopieren — powershell-pitfalls-whitelist-nicht-exklusiv.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