Microsoft 365

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

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:

Empfangsweg (1/2): Inbound Connector (Empfangsweg (1/2): Inbound Connector)
Empfangsweg (2/2): Exklusiver Empfang (Empfangsweg (2/2): Exklusiver Empfang)
Sendeweg: Relay (Sendeweg: Relay mit Filter bzw. Sendeweg: Relay mit Encryption)
Bei Encryption mit Auslieferung via Microsoft 365 zusätzlich: Sendeweg: Auslieferung via Microsoft 365 + ARC

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:

Sendeweg: Encryption-Loop, ausgehend verschlüsseln (Sendeweg: Encryption-Loop (MX via Microsoft))
Empfangsweg: Encryption-Loop, eingehend entschlüsseln (Empfangsweg: Encryption-Loop (MX via Microsoft))

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

Allgemeine Voraussetzungen (Allgemeine Voraussetzungen)
PowerShell-Grundlagen (Allgemein Powershell)
Graph-API-Synchronisierung (Graph API: Adress-Synchronisierung, Graph API: S/MIME-Sync)
Funktionstest (Funktionstest)

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 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)
Global Administrator für ARC-Konfiguration im Microsoft Defender-Portal (E-Mail-Authentifizierungseinstellungen). Hinweis: Die Entra-Rolle Security Administrator kann diese Portal-Einstellungen NICHT öffnen; per PowerShell (Set-ArcConfig) genügen die Exchange-Rollengruppen Organization Management oder Security Administrator.
App-Registrierung darf Application Administrator; der Admin Consent auf Graph-Application-Permissions erfordert jedoch Global Administrator oder Privileged Role Administrator (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 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)

Vorbereitung - Automatische Einrichtung durch die SecuMail®-App

Gilt für: beide Setups

Produkte:

Filter
Encryption
Filter+Encryption

Priorität: NÖTIG für die automatische Einrichtung (bei manueller Einrichtung per PowerShell nicht erforderlich)

Ziel

Die SecuMail®-App darf Connectoren und Transportregeln in Ihrem Microsoft 365-Tenant automatisch einrichten. Dafür genügt im Normalfall **eine** einmalige Freigabe: Ihre Zustimmung als Administrator (Schritt 1). Die Einrichtung läuft dann mit den Rechten des angemeldeten Administrators.

Schritt 2 (Rollenzuweisung) ist NUR nötig, wenn ohne interaktive Admin-Anmeldung provisioniert werden soll (App-only-Betrieb, z.B. für spätere unbeaufsichtigte Läufe). Für die normale Einrichtung überspringen Sie ihn.

Voraussetzungen

Ein Konto mit der Rolle Global Administrator in Ihrem Tenant. Beide Schritte kann nur dieses Konto ausführen.
Der Einrichtungs-Link von SecuMail® (erhalten Sie von uns).

Schritt 1: Zustimmung erteilen NÖTIG

TODO:

➜ Den Einrichtungs-Link von SecuMail® öffnen und mit dem Global Administrator-Konto anmelden
➜ Die angezeigten Berechtigungen der App SecuMail® MS365 Provisioning prüfen und mit Akzeptieren bestätigen

Ergebnis: Die App ist in Ihrem Tenant registriert und erscheint unter Entra Admin Center > Unternehmensanwendungen.

Schritt 2: Rolle "Exchange Administrator" zuweisen [NUR für App-only-Betrieb]

Diesen Schritt brauchen Sie NICHT für die normale Einrichtung — dort genügt Ihre Anmeldung aus Schritt 1. Er ist nur nötig, wenn die App ohne interaktive Anmeldung arbeiten soll (unbeaufsichtigte Läufe). Dann braucht der App-Dienst selbst die Entra-Rolle Exchange Administrator, um Connectoren und Regeln anlegen zu dürfen.

↗ Direkt öffnen

Im Entra Admin Center — Rollen und Administratoren:

TODO:

➜ In der Rollenliste auf den Namen Exchange-Administrator klicken — der Rollenname selbst ist der Link (die Checkbox davor führt nicht zur Zuweisung)
➜ + Zuweisung hinzufügen wählen
➜ Im Suchfeld den exakten App-Namen SecuMail® MS365 Provisioning eintippen — Apps erscheinen erst nach Eingabe des Namens, nicht beim Durchblättern
➜ Die App auswählen und mit Hinzufügen bestätigen
➜ 5–10 Minuten warten, bis die Zuweisung zu Exchange übertragen ist

PowerShell (Alternative, falls das Portal die App nicht anbietet):

  Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
  $sp = Get-MgServicePrincipal -Filter "appId eq '9f62ef0d-f7ae-4d38-b7ef-de22a4d059f5'"
  New-MgRoleManagementDirectoryRoleAssignment `
      -PrincipalId $sp.Id `
      -RoleDefinitionId "29232cdf-9323-42fd-ade2-1d097af3e4de" `
      -DirectoryScopeId "/"

(29232cdf-… ist die feste Microsoft-ID der Rolle Exchange Administrator, in jedem Tenant identisch.)

Prüfung: Auf der Rollenseite erscheint SecuMail® MS365 Provisioning unter Zuweisungen. Danach kann die automatische Einrichtung starten.

Hinweise

Die Zuweisung funktioniert nur im Entra Admin Center. Das Microsoft 365 Admin Center und das Exchange Admin Center können diese Rolle nicht an Apps vergeben — die dort sichtbare Rollengruppe ExchangeServiceAdmins_... ist eine schreibgeschützte Spiegelung.
Nutzt Ihr Tenant Privileged Identity Management (PIM), wählen Sie beim Hinzufügen den Zuweisungstyp Aktiv.
Beide Schritte sind einmalig pro Tenant. Die Rolle lässt sich jederzeit wieder entziehen (gleiche Stelle, Zuweisung entfernen).

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.

Empfangsweg oder Sendeweg? Zuerst einordnen

Bei jeder Frage rund um Mailrouting, Connectoren und Regeln zuerst klären: geht es um EINGEHENDE Mail an Ihre Postfächer (Empfangsweg) oder um AUSGEHENDE Mail Ihrer Organisation (Sendeweg)? Diese Doku trennt beide sauber — die Regeln sind nach Empfänger-Richtung gescoped und beeinflussen sich nicht.

Beispiel: Ein Signatur-Service für den Sendeweg berührt die Empfangsweg-Regeln (Ghost-Sender) nicht — VORAUSGESETZT seine Connectoren sind klar auf ausgehende Mail gescoped.

Achtung Rückweg: Liefert ein Sendeweg-Dienst Mail in den Tenant ZURÜCK (z.B. ein Server-Side-Dienst), bringt er einen INBOUND-Connector mit. Der ist Teil der Empfangsweg-Angriffsfläche und muss eng gescoped werden (IP/Zert) — sonst entsteht ein neuer Ghost-Sender-Pfad. -> Empfangsweg (2/2): Exklusiver Empfang

Konkrete Anleitung für einen Signatur-Service siehe Pitfalls und Lösungen: -> Lösung: Mehrere Dienste auf dem Sendeweg einbinden (z.B. Signatur-Service)

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 (1/2): Inbound Connector

Gilt für: MX via SecuMail

Produkte:

Filter
Encryption
Filter+Encryption

Priorität: NÖTIG (Schritt 1 von 2; Voraussetzung für Schritt 2)

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
Von SecuMail vorgegebene Netzbereiche (vollständig eintragen): 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27

Schritt 1: Inbound Connector anlegen NÖTIG

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

Immer die VOLLSTÄNDIGEN Netzbereiche eintragen (212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27), nicht nur einzelne aktuell sendende IPs — SecuMail® stellt aus jeder Adresse dieser Netze zu.

↗ 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 mit Zertifikatsvalidierung aktivieren (Zertifikatsname *.secumail.de; Cert-Erkennung als Alternative siehe unten)

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

Bestehende IP-Bereiche aktualisieren:

Enhanced Filtering aktivieren NÖTIG

Enhanced Filtering wird im Microsoft Defender Portal konfiguriert — NICHT im Exchange Admin Center bei den Connectoren. Das Portal-Feld akzeptiert keine Netz-Notation (CIDR), daher am einfachsten per PowerShell (unten).

↗ Direkt öffnen

TODO:

➜ Auf Connector SecuMail Inbound die vollen SecuMail-Netze als EFSkipIPs eintragen (keine Auswahlliste — manuell eingeben): 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27. NICHT die Option „letzte IP überspringen“ verwenden.

Per PowerShell:

Überprüfung

➜ Header X-MS-Exchange-SkipListedInternetSender zeigt die ECHTE externe Absender-IP (keine SecuMail-IP)
➜ Fehlt der Header oder zeigt er eine SecuMail-IP? Dann hebt evtl. eine alte „SCL -1“-Regel (Spam-Bypass) die Filterung auf → diese Regel deaktivieren.

Zweck: EOP bewertet den echten Absender statt der SecuMail-IP → SPF/DMARC bestehen wieder. Verhindert die harte Ablehnung 5.7.509 legitimer Mail, die Einsortierung in den Junk-Ordner und das „Ungeprüft"-Kennzeichen (siehe Pitfall: Microsoft prüft DMARC (abgewiesen, Junk, „Ungeprüft“)).

Ausblick: Inbound-ARC (Trusted ARC Sealer secumail.de) würde EF künftig ablösen — SecuMail sealt eingehend noch nicht (Pitfall: Microsoft prüft DMARC (abgewiesen, Junk, „Ungeprüft“)).

Zertifikats-Erkennung & S/MIME EMPFOHLEN

Alternative zur Connector-IP-Whitelist: SecuMail am Zertifikat erkennen — fälschungssicher, übersteht IP-Wechsel des Connectors ohne Nachpflege.

TODO:

➜ Connector zusätzlich auf Zertifikatserkennung setzen — die IP-Prüfung (RestrictDomainsToIPAddresses) bleibt dabei unverändert aktiv
➜ Prüfen: RestrictDomainsToCertificate = True, TlsSenderCertificateName = *.secumail.de

Wichtig: Das Zertifikat wirkt nur am Connector. Reject-Regel und Enhanced Filtering brauchen die SecuMail-Netze weiterhin — beide haben keinen Zert-Weg, ganz ohne IP-Liste geht erst mit ARC. Ob die IP-Liste am Connector selbst entfallen kann, hängt vom Zusammenspiel beider Schalter ab; im Zweifel beide aktiv lassen.

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

Directory Based Edge Blocking (DBEB) aktivieren EMPFOHLEN

Microsoft 365 so einstellen, dass es Mails an unbekannte Empfänger der eigenen Domain selbst abweist — Backstop gegen Spam/Backscatter an nicht existierende Adressen.

TODO:

➜ Akzeptierte Domain auf Authoritative setzen (Exchange Admin Center > Mail flow > Accepted domains) — DBEB ist dann aktiv
➜ Sicherstellen, dass alle gültigen Adressen inkl. Aliase (proxyAddresses) im M365-Verzeichnis stehen — pflegt der Adress-Sync (siehe Graph API: Adress-Synchronisierung)

Hinweis: M365 weist ungültige Empfänger erst NACH DATA ab, nicht synchron am RCPT TO (Schutz gegen Directory-Harvest). DBEB ist daher ein M365-interner Backstop — kein Signal für eine vorgelagerte Echtzeit- Rejection. Die Empfänger-Filterung am SecuMail®-Edge läuft über den Adress-Sync.

Weiter geht's: Schritt 2 von 2

Der Connector allein lässt Microsoft 365 noch Mail von beliebigen Quellen annehmen. Als Nächstes NÖTIG: den exklusiven Empfang einrichten (Ghost-Sender-Schutz). Den MX-Record erst dort umstellen — ganz zuletzt, wenn auch die Reject-Regel steht.

➜ Weiter mit Schritt 2: Empfangsweg (2/2): Exklusiver Empfang

Hinweise

Bei Änderungen der SecuMail-Netze müssen ALLE drei Stellen nachgezogen werden: SenderIPAddresses und EFSkipIPs am Connector (beide oben) sowie die Reject-Regel (Empfangsweg (2/2): Exklusiver Empfang). Wird EFSkipIPs vergessen, ist Enhanced Filtering wirkungslos — siehe Pitfall: Microsoft prüft DMARC (abgewiesen, Junk, „Ungeprüft“).
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 (2/2): Exklusiver Empfang

Vorher nötig: Schritt 1 von 2

Dieser Schritt setzt den Inbound Connector aus Schritt 1 voraus.

➜ Zuerst Schritt 1: Empfangsweg (1/2): Inbound Connector

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

Allgemeine Voraussetzungen: siehe Allgemeine Voraussetzungen
Inbound Connector SecuMail Inbound bereits eingerichtet (siehe Empfangsweg (1/2): Inbound Connector)
Liste der SecuMail-Netze: 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27

Mail-Flow-Regel anlegen NÖTIG

WARNUNG — „Ghost-Sender"-Effekt: Eine Regel nur mit FromScope NotInOrganization ist NICHT exklusiv — sie erzwingt keinen Zustellpfad. Direkt an den Tenant zugestellte Mail (inkl. Direct Send und über authentifizierte/kompromittierte interne Konten) wird so nicht zuverlässig geblockt (CEO-Fraud). Die Regel unten gilt daher für alle Mails AN Ihre Postfächer (interne Empfänger); Ausnahmen nur SecuMail-Pfad oder echt-interne Mail (Header X-MS-Exchange-Organization-AuthAs = Internal, extern nicht setzbar).

Warum „interne Empfänger" als Bedingung: Damit trennt die Regel sauber Empfangsweg (Mail an Sie) von Sendeweg (Mail von Ihnen nach extern). Ausgangs-Loops — Signatur-, DLP-, Verschlüsselungsdienste — liefern an EXTERNE Empfänger und liegen dadurch strukturell außerhalb der Regel; sie werden nicht fälschlich abgelehnt, ganz ohne IP-Ausnahme pro Dienst.

↗ 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) — im EAC erst NACH dem Erstellen setzbar (siehe letzter Schritt); per PowerShell direkt mit -Priority 0
➜ Bedingung (Diese Regel anwenden, wenn): Der Empfänger > ist extern/intern > InOrganization
➜ Aktion (Gehen Sie wie folgt vor): Die Nachricht blockieren > Nachricht ablehnen und Erläuterung einfügen mit "Mail muss über SecuMail® Gateway zugestellt werden." (nutzt automatisch 5.7.1)
➜ Ausnahme 1 (Außer wenn): Der Absender > IP liegt in einem dieser Bereiche > 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27
➜ Ausnahme 2 (Oder): Die Nachrichtenköpfe > Entspricht diesen Textmustern > X-MS-Exchange-Organization-AuthAs = Internal
➜ Modus: Erzwingen — NICHT Nur testen/Mit Richtlinientipps testen (matcht sonst nur, blockt nicht)
➜ Abschluss: Überprüfen und fertigstellen; danach Regel aktivieren (MUSS enabled sein) und auf Priorität 0 (oben) schieben

Zuletzt: MX-Record umstellen NÖTIG

Erst jetzt — wenn Connector (Schritt 1) und die Reject-Regel oben aktiv sind — den MX-Record umstellen. Vorher würden Mails an SecuMail® geroutet, während Microsoft 365 sie noch nicht annehmen kann.

TODO:

➜ MX-Record der Kundendomain auf die SecuMail-Mailserver umstellen: mx-a.secumail.de (Prio 10) / mx-b.secumail.de (Prio 10)
➜ Prüfen: nslookup -type=MX ihredomain.de

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).

Funktionstest

Externe Testmail direkt an den Tenant (nicht über SecuMail®) -> Muss mit 5.7.1 abgelehnt werden.
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).
Testmail regulär über MX (via SecuMail®) -> Muss zugestellt werden.

Geht der Ghost-Test trotz Priorität 0 + aktiver Regel durch (Mail landet im Postfach, kein NDR)? Dann steht die Regel im TEST-Modus — sie matcht, blockt aber nicht. Modus muss Enforce (Erzwingen) sein:

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.
Hybrides Setup (eigener On-Prem-Exchange): Die AuthAs: Internal-Ausnahme greift nur, wenn die On-Prem-Mail auch wirklich als Internal ankommt. Prüfen: Header einer On-Prem-Mail (X-MS-Exchange-Organization-AuthAs) bzw. Get-InboundConnector auf einen OnPremises-Connector — sonst lehnt diese Regel den On-Prem-Server ab. ➜ Lösung: Hybrid Setup (On-Prem-Exchange + Ghost-Sender)
Die Bedingung interne Empfänger (SentToScope InOrganization) grenzt die Regel auf den Empfangsweg ein — Sendeweg-Loops (Signatur, DLP, Verschlüsselung) an externe Empfänger sind strukturell ausgenommen.
Eigene Zusatzquellen (CRM, Monitoring) an interne Empfänger: eigener Connector + Ausnahme NUR mit exklusiver Quell-IP, nie Büro-Sammel-IP. ➜ Fallstricke: Pitfall: Whitelist ≠ SecuMail-only (Ghost-Sender)
Bei Änderungen der SecuMail-Netze muss auch diese Regel aktualisiert werden.

Ziel

Der MX-Record Ihrer Domain zeigt auf die SecuMail®-Mailserver. Ab dann läuft jede eingehende Mail zuerst über den SecuMail®-Filter.

Wichtig: Erst umstellen, wenn die Empfangsseite steht — bei Microsoft 365 Connector und Reject-Regel (Empfangsweg (2/2): Exklusiver Empfang), bei eigenem Mailserver die Firewall-Freigabe (Firewall: Zustellung nur aus SecuMail-Netzen).

MX-Records setzen NÖTIG

TODO:

➜ Im DNS Ihrer Domain die bestehenden MX-Einträge ersetzen durch:

MX-Record

meinedomain.de.   IN MX 10 mx-a.secumail.de.
                  IN MX 10 mx-b.secumail.de.

Beide Einträge mit GLEICHER Priorität setzen
Den Punkt am Ende von mx-a.secumail.de. beachten (die meisten Hoster verlangen ihn; einzelne setzen ihn selbst und verhindern die manuelle Eingabe)
Alle anderen MX-Einträge entfernen — nur die SecuMail®-Einträge bleiben
Prüfen: nslookup -type=MX meinedomain.de

Ihr ursprünglicher Mailserver bleibt unverändert bestehen — nur der Zustellweg aus dem Internet ändert sich.

Falls Ihr Hoster zwei Einträge gleicher Priorität technisch nicht zulässt, ist alternativ dieser Einzeleintrag erlaubt:

MX-Record

meinedomain.de.   IN MX 10 mx.secumail.de.

Hinweise

DNS-Änderungen brauchen je nach TTL bis zu 48 Stunden, bis sie weltweit propagiert sind.
Der Wechsel ist jederzeit umkehrbar: MX-Records zurückstellen beendet die Zustellung über SecuMail®.

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) — Mail flow > Connectors:

TODO:

➜ Connector hinzufügen; Verbindung von Office 365 zu Mailserver der Organisation
➜ Name: SecuMail Encryption Eingang
➜ Routing: Smarthost enc.secumail.de
➜ TLS: Immer TLS verwenden, Domainvalidierung > *.secumail.de
➜ Interne Exchange-Header beibehalten (Retain internal headers) aktivieren
➜ Nur verwenden, wenn eine Transport Rule darauf verweist (IsTransportRuleScoped)

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.

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

TODO:

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

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

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

TODO:

➜ Connector hinzufügen; Verbindung von Mailserver der Organisation zu Office 365
➜ Name: SecuMail Encryption Eingang Rückweg
➜ Authentifizierung: per Zertifikat — Antragstellername des Zertifikats stimmt mit dieser Domäne überein > *.secumail.de (OnPremises identifiziert per Zertifikat, NICHT per IP)
➜ Immer TLS verwenden aktivieren
➜ Interne Exchange-Header beibehalten aktivieren

Hinweis: Der OnPremises-Connector identifiziert SecuMail® per Zertifikat (TlsSenderCertificateName), NICHT per IP — SenderIPAddresses gilt nur für Partner-Connectoren. TLS wird über die Zertifikatsprüfung erzwungen (RequireTls $true + RestrictDomainsToCertificate $true).

Funktionstest

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.
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).

Ziel

Ihr Mailserver nimmt SMTP-Verbindungen ausschließlich aus den SecuMail®-Netzen an. Damit kann der SecuMail®-Filter nicht durch direkte Einlieferung am MX vorbei umgangen werden — dieselbe Aufgabe, die bei Microsoft 365 die Exklusiv-Regel übernimmt.

Firewall-Freigabe einrichten NÖTIG

TODO:

➜ Eingehend SMTP (Port 25) auf Ihrem Mailserver nur aus diesen Netzen erlauben: 212.11.224.0/24, 212.11.225.0/24, 212.11.240.64/27
➜ Alle drei Netzbereiche vollständig freischalten — SecuMail® stellt aus jeder Adresse dieser Netze zu
➜ Eigene Systeme ergänzen, die intern zustellen dürfen (interne Netze, Außenstellen, Monitoring, CRM)
➜ Sonstige SMTP-Verbindungen aus dem Internet abweisen

Hinweise

Die SPF-Prüfung auf Ihrem eigenen Server MUSS deaktiviert werden — SPF darf nur der erste Mailserver in der Kette prüfen (das ist SecuMail®). Andernfalls können E-Mails verloren gehen.
Ist die Einschränkung nicht möglich (z.B. Hoster mit Multi-Domain-Mailserver), reduziert sich direkte Zustellung am Filter vorbei erfahrungsgemäß nach wenigen Wochen gegen Null — der Schutz fehlt dann aber.
Bei Änderungen der SecuMail®-Netze muss die Firewall-Regel nachgezogen werden.

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

Allgemeine Voraussetzungen: siehe Allgemeine 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

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

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.

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 — sonst werden ausgehende Mails vom Empfänger als Spam oder Spoofing eingestuft.

TODO:

➜ SPF-Record der Kundendomain um _spf.secumail.de ergänzen
➜ Prüfen: nslookup -type=TXT ihredomain.de (Eintrag v=spf1 muss _spf.secumail.de enthalten)

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

Eine Mail an eine externe Adresse senden. -> In der Nachrichtenverfolgung prüfen, ob die Mail über den Connector SecuMail Filter Outbound geroutet wurde.
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.

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

Voraussetzungen

Allgemeine Voraussetzungen: siehe Allgemeine 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

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

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.

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 — sonst werden ausgehende Mails vom Empfänger als Spam oder Spoofing eingestuft.

TODO:

➜ SPF-Record der Kundendomain um _spf.secumail.de ergänzen
➜ Prüfen: nslookup -type=TXT ihredomain.de (Eintrag v=spf1 muss _spf.secumail.de enthalten)

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

Eine Mail an eine externe Adresse senden. -> In der Nachrichtenverfolgung prüfen, ob die Mail über den Connector SecuMail Encryption Outbound geroutet wurde.
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 (enc.secumail.de:25).
Wenn der Kunde die Auslieferung verschlüsselter Mails via Microsoft 365 wählt, muss zusätzlich ARC konfiguriert werden: Sendeweg: Auslieferung via Microsoft 365 + ARC
Signatur-Services müssen VOR der S/MIME-Verarbeitung greifen — sonst bricht die Signatur oder fehlt: Lösung: Mehrere Dienste auf dem Sendeweg einbinden (z.B. Signatur-Service)
Für Filter-only-Produkte siehe stattdessen: Sendeweg: Relay mit Filter

Ziel

Der SPF-Record Ihrer Domain autorisiert die SecuMail®-Server als Versender. Empfänger können damit Mails Ihrer Domain als legitim erkennen; gefälschte Absender fallen auf.

SPF-Record setzen NÖTIG

TODO:

➜ Sie haben noch KEINEN SPF-Record? Diesen TXT-Record im DNS setzen:

TXT-Record

ihre.domain.de   IN TXT   "v=spf1 include:spf.secumail.de -all"

Sie haben BEREITS einen SPF-Record? Den bestehenden Eintrag um include:spf.secumail.de ergänzen — KEINEN zweiten TXT-Record anlegen
Alle weiteren legitimen Versandwege (eigener Mailserver, Webserver, Newsletter-Dienst) müssen im selben Record erfasst bleiben
Prüfen: nslookup -type=TXT ihre.domain.de

Hilfreich beim Zusammenbauen: https://www.spf-record.de/generator

Hinweise

SPF hat Nebenwirkungen: Weiterleitungen an externe Adressen (andere Domains) werden durch -all praktisch verhindert. Vor dem Setzen die Auswirkungen prüfen — im Zweifel support@secumail.de fragen.
Für vollständigen Schutz vor Absender-Fälschung zusätzlich einen DMARC-Record anlegen (siehe alte FAQ: www.secumail.de/f-a-q/).

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:

secumail.de als vertrauenswürdigen ARC Sealer hinterlegen
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 Defender / Security Portal für ARC-Konfiguration

Schritt 1: Trusted ARC Sealer hinterlegen NÖTIG

↗ Direkt öffnen

Im Microsoft Defender (Security-Portal) — Email & collaboration > Policies & rules > Threat policies > Abschnitt Rules > Email authentication settings > Tab ARC:

TODO:

➜ 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:

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: MarkAsSpamSpfRecordHardFail (SPF Hard Fail) ist eine Advanced-Spam-Filter-(ASF)-Einstellung und steht ab Werk auf Off. Standard-/Strict-Preset-Policies aktivieren ASF NICHT (ASF ist in Presets generell aus). Abweichen kann der Wert daher nur in der Default-Policy oder in Custom-Policies — diese pro Policy prüfen.

↗ Direkt öffnen

Im Microsoft Defender (Security-Portal) — Email & collaboration > Policies & rules > Threat policies > Abschnitt Policies > Anti-spam:

TODO:

➜ Standardrichtlinie (Default) öffnen
➜ Einstellung SPF-Eintrag: Schwerer Fehler (SPF record: hard fail, MarkAsSpamSpfRecordHardFail) suchen
➜ Wert auf Aus (Off) setzen (falls Ein)
➜ Dasselbe für alle Custom-Policies

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 der Gesamtkonfiguration

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

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

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

Eine verschlüsselte Mail über SecuMail® senden, die via Microsoft 365 ausgeliefert wird.
Im Message Header der empfangenen Mail prüfen: - ARC-Seal Header muss vorhanden sein (d=secumail.de) - Im ARC-Authentication-Results-Header steht arc=pass (oda=1) - Im Authentication-Results-Header bestätigt compauth=pass den DMARC-Override
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.

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.

TODO:

➜ SPF-Record der Kundendomain um _spf.secumail.de ergänzen
➜ Prüfen: nslookup -type=TXT ihredomain.de (Eintrag v=spf1 muss _spf.secumail.de enthalten)

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.

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
➜ Authentifizierung: per Zertifikat — Zertifikatsdomäne *.secumail.de (OnPremises identifiziert per Zertifikat, NICHT per IP)
➜ Immer TLS verwenden aktivieren
➜ Interne Exchange-Header beibehalten aktivieren

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

Wichtig: Beim OnPremises-Connector erfolgt die Identifikation per Zertifikat, nicht per IP — SenderIPAddresses/RestrictDomainsToIPAddresses gelten nur für Partner-Connectoren. TLS wird über die Zertifikatsprüfung erzwungen (RequireTls $true + RestrictDomainsToCertificate $true + TlsSenderCertificateName), entsprechend dem von Microsoft dokumentierten Add-on-Service-Muster.

Hinweis zur Absender-Identifikation: OnPremises-Connectoren werden per Zertifikat identifiziert (TlsSenderCertificateName), nicht per IP (SenderIPAddresses gilt nur für Partner). Alternativ zur OnPremises- Header-Methode kann die Rücklieferung auch ARC-basiert abgesichert werden (Sendeweg: Auslieferung via Microsoft 365 + ARC).

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.

Funktionstest

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.
Prüfen, dass die Mail verschlüsselt/signiert beim Empfänger ankommt.
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.

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 Privileged Role Administrator für den Admin Consent auf Graph-Application-Permissions (Application Administrator darf zwar die App registrieren, den Consent darauf aber NICHT erteilen)

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

TODO:

➜ Anwendungs-ID (Client ID) und Verzeichnis-ID (Tenant ID) notieren (Übersichtsseite der App)

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

TODO:

➜ An SecuMail® übermitteln: Tenant ID, Application (Client) ID, Client Secret (und Gruppenname, falls Gruppeneinschränkung)

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:

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.
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.

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)

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 Privileged Role Administrator für den Admin Consent auf Graph-Application-Permissions (Application Administrator darf zwar die App registrieren, den Consent darauf aber NICHT erteilen)

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

TODO:

➜ Anwendungs-ID (Client ID) und Verzeichnis-ID (Tenant ID) notieren (Übersichtsseite der App)

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

TODO:

➜ An SecuMail® übermitteln: Tenant ID, Application (Client) ID, Client Secret (und Gruppenname, falls Gruppeneinschränkung)

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:

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.
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

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 (1/2): Inbound Connector)
➜ 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 > Threat policies > Email authentication settings > ARC, secumail.de als Trusted Sealer (siehe Sendeweg: Auslieferung via Microsoft 365 + ARC)
➜ Nur Cases B/C: Antispam-Policy prüfen — Defender > Threat policies > Anti-spam, SPF Hard Fail

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

Von einem externen Postfach eine Testmail an ein Microsoft 365-Postfach senden (an eine Adresse in der konfigurierten Domain).
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

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

Vom Microsoft 365-Postfach eine Testmail an eine externe Adresse senden.
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

Test 3: Interne Mails (Microsoft 365 intern)

Vom Microsoft 365-Postfach eine Mail an einen internen Empfänger senden (gleiche Domain).
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)

Eine verschlüsselte Mail senden, die via Microsoft 365 ausgeliefert wird.
Prüfen: a) Mail wurde zugestellt (nicht abgelehnt) b) Im Message Header: - ARC-Seal Header vorhanden (d=secumail.de) - ARC-Authentication-Results enthält arc=pass; Authentication-Results zeigt compauth=pass c) Mail nicht als Spam markiert

Test 5: Exklusiver Empfang (nur falls konfiguriert)

Nur relevant, wenn Empfangsweg (2/2): Exklusiver Empfang eingerichtet ist.

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.
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.").
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 aktiv oder IP-Whitelist fehlt.
Prüfen (Portal): Defender > Threat policies > Rules > Enhanced filtering (security.microsoft.com/skiplisting) — Connector auf „letzte IP überspringen".
Prüfen (PowerShell): Get-InboundConnector | Format-List EFSkipLastIP, EFSkipIPs, SenderIPAddresses
Lösung: Enhanced Filtering („letzte IP überspringen") und IP-Whitelist einrichten (siehe Empfangsweg (1/2): Inbound Connector).

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

Ursache: ARC nicht konfiguriert oder SPF Hard Fail aktiv.
Prüfen (Portal): Microsoft 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.

Message Trace zeigt die greifende Regel

Im Message Trace sehen Sie — UNABHÄNGIG von Lizenz und Regel-Modus —, welche Transportregel eine Mail behandelt hat. Der Regelname steht in der Detailansicht (z.B. Nur SecuMail-Empfang erlauben, also „SecuMail …") — samt Reject-Grund und Statuscode (5.7.1). Damit erkennen Sie sofort, warum eine Mail abgelehnt oder gefiltert wurde.

Im Exchange Admin Center (EAC) — Mail flow > Message trace (bzw. Microsoft 365 Defender > Email & collaboration > Exchange message trace):

TODO:

➜ Nachricht suchen (Absender/Empfänger/Zeitraum) und öffnen
➜ Abschnitt Events / More information → Eintrag „Transport rule" mit dem Regelnamen und dem Reject-Grund/Statuscode

Wichtig: Test-/Audit-Modus nicht verwenden

Den Regel-Test-Modus (Mit Richtlinientipps testen) NICHT einsetzen: Er muss lizenziert werden (Policy Tips) und blockt ohnehin nicht — die Regel matcht nur, die Mail wird trotzdem zugestellt. Regeln immer im Modus Enforce (Erzwingen) betreiben. ➜ Empfangsweg (2/2): Exklusiver Empfang

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:

Outbound-Connector triggert per Domain-Wildcard (RecipientDomains: *) ohne IsTransportRuleScoped. Dann nimmt EOP jede ausgehende Mail über diesen Connector - auch zurückkehrende.
Routing-Regel ohne präzisen Scope (FromScope/SentToScope fehlen). Dann greift die Regel auch für Mails, die gerade vom Gateway zurückkehren.
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.

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

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 (SenderIPAddresses bei RestrictDomainsToIPAddresses=$true) und TLS-Validierung (RequireTls/RestrictDomainsToCertificate) sind Partner-Connector-Eigenschaften und im Standardsetup (Partner) wirksam — bei OnPremises greifen sie nicht (dort Identifikation per Zertifikat).

Prüfung im Tenant

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:

Aktuelle Connector-Konfiguration sichern:

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

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: Sie erzwingt KEINEN Zustellpfad. Direkt an den Tenant zugestellte Mail (inkl. Microsoft Direct Send und über authentifizierte bzw. kompromittierte interne Konten) lässt sich so nicht zuverlässig ausschließen — die gefährlichste Lücke (CEO-Fraud). (Hinweis: Rein anonymes Eigendomain-Spoofing kommt unauthentifiziert an und gilt laut Microsoft als NotInOrganization; eine FromScope-Regel würde es erfassen. Die Lücke ist also der fehlende Pfad-Zwang, nicht die Klassifizierung.)
Oder die Reject-Regel steht im TEST-/Audit-Modus: Sie matcht (Trace zeigt ein Policy-Ereignis), blockt aber nicht — die Mail landet trotz Priorität 0 im Postfach. Modus muss Enforce sein: Set-TransportRule "Nur SecuMail-Empfang erlauben" -Mode Enforce

Richtig konfigurieren

Reject-Regel pfadbasiert statt FromScope: gilt für alle Mails an INTERNE Empfänger (SentToScope InOrganization, = Ihre 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). Die Empfänger- Bedingung trennt den Empfangsweg sauber vom Sendeweg — Ausgangs-Loops (Signatur, DLP) an externe Empfänger sind dadurch ausgenommen.

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

Mehrere eigene Quellen (CRM, Monitoring, Newsletter)

Je Quelle ein EIGENER Inbound Connector — nie Sammel-Ausnahme. (einzeln abschaltbar, eigene TLS-/Zertbindung, nachvollziehbar)
Freigabe steht in der EINEN Reject-Regel — der Connector allein nimmt die Quelle nicht aus der Regel.
Ausnahme = dedizierte, EXKLUSIVE Quell-IP. Nicht der Büro-Egress (Arbeitsplätze/Gast-WLAN/VPN → dahinter kann jeder spoofen).
Connector-Typ OnPremises stempelt X-MS-Exchange-Organization-AuthAs = Internal → automatisch freigestellt → wird selbst zum Spoofing-Pfad. Relay-Quellen an Client-Zertifikat binden.

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.

Symptom

Je nach DMARC-Policy der Absenderdomain eines von drei Anzeichen:

Der Absender erhält einen NDR: 550/554 5.7.509 Access denied, sending domain <domain> does not pass DMARC verification and has a DMARC policy of reject. (Absender-Policy p=reject)
Legitime Mail landet im Junk-E-Mail-Ordner oder in der Quarantäne (Absender-Policy p=quarantine)
Outlook markiert die Mail mit „Ungeprüft" (Unverified) — compauth=fail, unabhängig von der Policy

Kein SecuMail-Fehler: SecuMail® filtert in allen drei Fällen weiter.

Ursache

Auslöser ist eine Entscheidung von Microsoft: Im Zuge der Ghost-Sender-Problematik hat Microsoft reagiert und einen eher ungünstigen Workaround gewählt — die DMARC-Prüfung im Tenant obligatorisch durchzusetzen. Das trifft jedes Setup mit einem vorgeschalteten System: Hybrid-Konfigurationen ebenso wie vorgeschaltete E-Mail-Security-Dienste wie SecuMail®. Alle brauchen jetzt eine zusätzliche Einstellung.

Der Mechanismus dahinter: Hinter SecuMail® bricht SPF am zusätzlichen Hop → DMARC schlägt fehl → Microsoft wendet die Policy der Absenderdomain an. Deshalb tritt das jetzt auf, obwohl sich an Ihrem Tenant und an SecuMail® nichts geändert hat — geändert hat nur Microsoft.

Lösung

Enhanced Filtering auf dem Inbound Connector aktivieren: Microsoft bewertet dann den echten Absender statt der SecuMail-IP, SPF/DMARC bestehen wieder.

➜ Anleitung: Empfangsweg (1/2): Inbound Connector, Abschnitt „Enhanced Filtering aktivieren"

Schon aktiv und trotzdem betroffen? Im Header einer betroffenen Mail X-MS-Exchange-SkipListedInternetSender prüfen — steht dort eine SecuMail-IP statt der echten Absender-IP, ist Enhanced Filtering wirkungslos (gleiche Anleitung).

Hinweis

Enhanced Filtering ist IP-basiert und braucht die vollständigen SecuMail-Netze. Die Zertifikatserkennung ersetzt sie an dieser Stelle nicht; ohne IP-Liste funktioniert es erst mit ARC (in Vorbereitung).

Die Absenderdomain muss nichts ändern, ihre Policy ist korrekt. Die DMARC-Durchsetzung im Tenant abzuschalten stoppt zwar Ablehnung und Junk-Einsortierung, behebt aber das „Ungeprüft"-Kennzeichen nicht und wirkt tenant-weit.

Absender ganz ohne ausgerichtetes SPF/DKIM bleiben markiert — das ist nur absender-seitig behebbar.

Ziel

Einen oder mehrere inhaltsverändernde Dienste auf dem Sendeweg (z.B. einen Signatur-Service) so einbinden, dass sie mit der SecuMail®-Verschlüsselung/ -Signatur (S/MIME) zusammenspielen.

Kernregel: S/MIME als letzter Schritt

S/MIME muss als letzter Schritt eingebunden sein — danach darf der Mailinhalt nicht mehr geändert werden. Jeder inhaltsverändernde Dienst (Signatur-Service, Disclaimer …) muss also VOR dem SecuMail®-S/MIME-Relay laufen. Sonst:

Nach dem Verschlüsseln ist der Body opak → es kann nichts mehr eingefügt werden.
Nach dem Signieren ändert jeder Eingriff den Body → die S/MIME-Signatur wird ungültig.

Reine Filter-Produkte sind nicht betroffen: Der Ausgangsfilter verändert den Body nicht reihenfolgeabhängig — die Reihenfolge ist dort egal.

Soll-Flow: Tenant → Signatur-Service (auf Klartext) → zurück in Tenant → SecuMail®-Relay (S/MIME) → Empfänger

Vorgehen: Regel-Pipeline mit Marker-Headern

Wichtig: Jeder externe Dienst schickt die Mail raus und wieder ZURÜCK. Jede Rückkehr ist eine NEUE Einlieferung — die Transportregeln laufen dann von vorne (ab Priorität 0). Die Bedingung „intern → extern" ist auf JEDEM Durchlauf wahr und kann die Stufen nicht unterscheiden. Die Reihenfolge erzwingen Sie deshalb über einen Header-Marker pro Stufe (Regel-Aktion „Nachrichtenkopf festlegen"), nicht über Prioritäten. Jeder Marker schaltet die eigene Regel ab (kein Loop) und die nächste scharf.

Ablauf als Regeln (Bedingung jeweils intern → extern):

R1 (hohe Priorität): kein Sign-Marker und kein Enc-Marker → an Sign-Service-Connector routen, StopRuleProcessing. (Dienst signiert, liefert zurück in den Tenant = Durchlauf 2)
R2 (darunter): Sign-Marker vorhanden, kein Enc-Marker → an SecuMail-Enc-Connector routen, StopRuleProcessing. (SecuMail verschlüsselt per S/MIME)
Fertig: beide Marker vorhanden → keine Routing-Regel greift → MS liefert an den externen Empfänger aus.

Beachten:

Marker am verlässlichsten der Header, den der Dienst SELBST setzt (beweist echte Verarbeitung; muss den Roundtrip überleben — prüfen). SecuMail setzt X-SecuMail-Encryption.
Rückweg = Inbound-Connector und damit Teil der Empfangsweg-Angriffsfläche: eng scopen (IP/Zertifikat) und Typ Partner (nicht OnPremises), sonst greifen FromScope-Regeln erneut bzw. es entsteht ein neuer Ghost-Sender-Pfad. ➜ Empfangsweg (2/2): Exklusiver Empfang, Pitfall: Outbound Mail-Loop verhindern
Je Dienst ein eigener Outbound- + Inbound-Connector; der Outbound mit IsTransportRuleScoped = True.
Durchlauf 3 (Rücklieferung von SecuMail) nur bei „Auslieferung via Microsoft 365" → dann zusätzlich ARC (Sendeweg: Auslieferung via Microsoft 365 + ARC). Liefert SecuMail direkt aus, endet es nach Durchlauf 2.
TLS auf den zusätzlichen externen Hops erzwingen.

Modus wählen

Server-Side (Cloud): Der Dienst routet die Mail aus dem Tenant zu seinem Cloud-Dienst und liefert sie über einen Inbound-Connector zurück. Verarbeitet Mail aus ALLEN Quellen — auch CRM-/automatisch erzeugte und mobile. Für server-/CRM-generierte Mail ist das der einzige Modus, der greift.
Client-Side (Add-in): Die Signatur wird nur in Outlook/OWA beim Schreiben eingefügt — erfasst KEINE server-/CRM-generierte Mail.
Für Encryption zählt in beiden Fällen die Reihenfolge (siehe oben): Der Dienst muss vor dem SecuMail®-S/MIME-Relay liegen.
Viele Signatur-Services weisen selbst darauf hin, dass bei Smarthost-/ Mailrelay-Diensten (= SecuMail®) zusätzliche Konfiguration nötig ist. Details in der jeweiligen Hersteller-Doku.

Funktionstest

Verschlüsselte Testmail an einen externen Empfänger senden:

Signatur/Ergänzung vorhanden? -> Reihenfolge stimmt.
S/MIME-Signatur beim Empfänger gültig? -> kein nachträglicher Eingriff.
Message-Trace: Mail läuft über den Dienst UND danach über das SecuMail®-Relay.

Symptom

Nach Einrichten des Ghost-Sender-Schutzes (Reject-Regel + MX auf SecuMail) stellt der eigene On-Prem-Exchange-Server keine Mail mehr an interne Postfächer zu — Ablehnung mit 5.7.1.

Ursache: es fehlt `AuthAs: Internal`

Die Reject-Regel lässt Mail an interne Empfänger nur durch, wenn sie (a) aus den SecuMail-Netzen kommt ODER (b) den Header X-MS-Exchange-Organization-AuthAs = Internal trägt. Die On-Prem-Mail kam als Anonymous an → Reject.

Wichtig: AuthAs=Internal entsteht NICHT dadurch, dass die Absenderdomäne „deine" ist, sondern allein durch Connector-Attribution:

authentifiziertes Postfach/Dienst im Tenant, ODER
Einlieferung über einen Inbound-Connector vom Typ OnPremises, dessen Kennung die Verbindung TATSÄCHLICH trifft — TLS-Zertifikat passend zu TlsSenderCertificateName ODER Quell-IP in SenderIPAddresses.

Kein Connector-Match → Anonymous (obwohl eigener Server, eigene Domäne) → Reject.

Häufige Gründe, warum kein Internal:

Gar kein OnPremises-Connector (kein echtes Hybrid, nur SMTP-Relay an M365).
Connector da, aber Kennung matcht nicht (kein TLS / falsches Zertifikat / IP nicht in SenderIPAddresses).
Pfad durch MX→SecuMail geändert; EOP sieht eine andere Quelle als erwartet.

Prüfen

Message Trace auf eine abgelehnte Mail → bestätigt den 5.7.1-Reject.
Header einer solchen Mail → X-MS-Exchange-Organization-AuthAs. Steht dort Anonymous, ist die Attribution das Problem.
Connector prüfen:

→ Gibt es einen OnPremises-Connector? Wodurch identifiziert er sich?

Sendet der On-Prem-Server mit TLS + passendem Zertifikat (bzw. aus der IP in SenderIPAddresses) an EXO?

Beheben

Weg 1 (robust, zukunftssicher): On-Prem→EXO so einrichten, dass die Verbindung den OnPremises-Connector trifft (zertifikatsbasiert, wie vom Hybrid Configuration Wizard). Dann AuthAs=Internal → durch die bestehende Ausnahme automatisch erlaubt, ohne IP-Pflege.
Weg 2 (Fallback): die TATSÄCHLICHE Sende-IP des On-Prem-Servers (die EOP im Header als CIP= sieht — per Trace verifizieren) als EXKLUSIVE IP in die SenderIpRanges-Ausnahme der Reject-Regel. In Hybrid/zentralisiertem Transport kann die ausgewertete IP abweichen — daher ist Weg 1 vorzuziehen.

Nicht empfohlen: IP-Bereiche „auf Vorrat" eintragen — das verbreitert die Ghost-Sender-Angriffsfläche. Nur reale, exklusive Quell-IPs.

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

Kontakt aufnehmen

Microsoft 365

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

Kurzentscheidung in einem Schritt

Setup 1 – MX via SecuMail (Gateway vorgelagert)

Setup 2 – MX via Microsoft (Encryption-Loop)

Für beide Setups gleich

Portal oder PowerShell?

Benötigte Rechte im Microsoft 365-Tenant

Admin-Portale (Übersicht)

Ziel

Voraussetzungen

Schritt 1: Zustimmung erteilen NÖTIG

Schritt 2: Rolle "Exchange Administrator" zuweisen [NUR für App-only-Betrieb]

Hinweise

Verwandte FAQ-Cases

PowerShell-Module installieren

Verbindung herstellen: Exchange Online

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

Verbindung trennen

Allgemeine Hinweise

Empfangsweg oder Sendeweg? Zuerst einordnen

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

Haftungsausschluss

Ziel

Warum

Voraussetzungen

Schritt 1: Inbound Connector anlegen NÖTIG

Enhanced Filtering aktivieren NÖTIG

Zertifikats-Erkennung & S/MIME EMPFOHLEN

Directory Based Edge Blocking (DBEB) aktivieren EMPFOHLEN

Weiter geht's: Schritt 2 von 2

Hinweise

Verwandte FAQ-Cases

Vorher nötig: Schritt 1 von 2

Ziel

Warum

Voraussetzungen

Mail-Flow-Regel anlegen NÖTIG

Zuletzt: MX-Record umstellen NÖTIG

Funktionstest

Hinweise

Verwandte FAQ-Cases

Ziel

MX-Records setzen NÖTIG

Hinweise

Verwandte FAQ-Cases

Wann gilt dieser Case?

Ablauf

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

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

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

Funktionstest

Hinweise

Verwandte FAQ-Cases

Ziel

Firewall-Freigabe einrichten NÖTIG

Hinweise

Verwandte FAQ-Cases

Ziel

Wichtig

Voraussetzungen

Schritt 1: Outbound Connector anlegen NÖTIG

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

Schritt 3: TLS für den Sendeweg EMPFOHLEN

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

Funktionstest

Hinweise

Verwandte FAQ-Cases

Ziel

Wichtig

Voraussetzungen

Schritt 1: Outbound Connector anlegen NÖTIG

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

Schritt 3: TLS für den Sendeweg STARK EMPFOHLEN

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

Funktionstest

Hinweise

Verwandte FAQ-Cases

Ziel

SPF-Record setzen NÖTIG

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