Anforderungsprofil: Secure Mail für M365
Herstellerneutrales technisches Anforderungs- und Beschaffungspaket zum Entscheidungspaket „Secure Mail für M365“.
Am Ende stehen ein dokumentiertes Zielbild für den Mailflow, harte Muss-Kriterien, ein begrenzter Pilot mit messbaren Sicherheits- und Betriebswerten sowie eine nachvollziehbare Entscheidung für oder gegen eine zusätzliche Secure-Mail-Schicht.
Thema: securemail · Stand 2026-09-20Welle 4 · Access, Endpoints & Detection
WLAN, Gerätemanagement, SIEM/SOC und sichere E-Mail auf den zuvor definierten Netz-, Identity- und Betriebsgrundlagen aufsetzen.
Vor jeder Punktebewertung nachweisen
Diese Kriterien sind als technische Mindestnachweise formuliert. Nicht erfüllte Muss-Kriterien sollten nicht durch Komfort- oder Preisvorteile kompensiert werden.
| ID | Kriterium | Geforderter Nachweis |
|---|---|---|
| M01 | Realen Mailflow inklusive MX, SPF, DKIM, DMARC, Connectoren und Hybrid-Routing vor Umstellung vollständig dokumentieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M02 | Phishing-, BEC-, Malware- und Post-Delivery-Use-Cases mit einem repräsentativen Testset und klarer False-Positive-Behandlung pilotieren. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M03 | Verschlüsselungs-, Portal-, S/MIME- und Fallback-Verfahren mit internen und externen Empfängern praktisch testen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M04 | Continuity, Quarantäne, Delegation, Journaling/Archiv und Verhalten bei Ausfall der primären Mailplattform abnehmen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
| M05 | Datenstandort, Auftragsverarbeitung, Retention, Logging, Adminrollen und Exit-/Mailflow-Rückbau vor Vertragsabschluss prüfen. | Hersteller-/Angebotsnachweis plus Pilot- oder Betriebsnachweis. |
Mehrwert nur mit realem Betriebsnutzen bewerten
| ID | Kriterium | Bewertungshinweis |
|---|---|---|
| K01 | Gateway- und API/Post-Delivery-Verfahren können in einem kontrollierten Betriebsmodell kombiniert werden. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K02 | Sandboxing/Detonation und nachgelagerte Entfernung bereits zugestellter Nachrichten. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K03 | Integrierte Benutzer-Meldung verdächtiger Nachrichten und Übergabe an Incident-/SOC-Prozesse. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
| K04 | Mail-Continuity mit nachvollziehbarem Verhalten bei Ausfall der primären Plattform. | Als Mehrwert nur bewerten, wenn die Funktion für den Zielbetrieb nachweisbar nutzbar ist. |
Fragen für Angebot, Workshop und technische Klärung
Bleiben Routing, Original-IP, Header und Absenderauthentisierung im gewählten Integrationsmodell korrekt auswertbar?
Schließt die zusätzliche Schicht nachweisbar eine konkrete Lücke gegenüber der vorhandenen M365-Schutzkette?
Sind Quarantäne, Freigaben, Störungen, Updates und Eskalation mit dem vorhandenen Team beherrschbar?
Funktionieren SPF, DKIM, DMARC, ARC, TLS und Connectoren im realen Nachrichtenfluss ohne unkontrollierte Ausnahmen?
Existiert ein getesteter Fallback, wenn der zusätzliche Dienst oder ein Routingpfad ausfällt?
Sind Lizenzierung, Datenhaltung, Support, Exit und Produktlebenszyklus ausreichend transparent?
Gates als objektive Abnahmekriterien verwenden
Der Pilot startet nicht mit einer Produktdemo, sondern mit einem dokumentierten Zielbild und messbaren Kriterien.
Die gewählte Integration erhält relevante Absender- und Authentisierungsinformationen und erzeugt keinen unkontrollierten Bypass.
Jeder verbleibende Kandidat erfüllt die dokumentierten Muss-Kriterien oder trägt einen expliziten offenen Prüfpunkt.
Der Schutzgewinn ist messbar, ohne dass der Betrieb durch nicht beherrschte Routing- oder Quarantäneprobleme instabil wird.
Die Entscheidung dokumentiert Nutzen, Rest-Risiken, Betriebsaufwand und einen kontrollierten Rückbaupfad.
Vor Produktivsetzung klären
- Mailflow, Connectoren und Queue-Zustand kontinuierlich überwachen.
- Quarantäne-, False-Positive- und Policy-Änderungsprozess mit Ownern betreiben.
- Continuity- und Rückfallpfad regelmäßig testen.
- Security-Logs und Admin-Aktionen in Incident-/SOC-Prozesse integrieren.
Vor Vertragsbindung nachweisen
- MX-/Connector-/API-Integration reversibel dokumentieren und Rückbau testen.
- Policies, Allow-/Blocklisten, Logs und relevante Quarantäne-/Forensikdaten exportieren können.
- Koexistenz- und Cutover-Plan für eine Folgelösung ohne unkontrollierte Mailflow-Lücke vorsehen.
Gewichtete Bewertung erst nach den Muss-Kriterien
Die Gewichte ergeben zusammen 100 %. Die Skala bewertet nachgewiesene Eignung – nicht Herstellergröße oder Markenpräferenz.
| Kategorie | Gewicht | Skala | Dokumentation |
|---|---|---|---|
| Schutzwirkung & Detection | 30 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Mailflow & Integration | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Betrieb & Continuity | 20 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Governance & Nachweise | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
| Commercial & Exit | 15 % | 0 = nicht nachgewiesen · 1 = teilweise · 2 = erfüllt · 3 = übertroffen | Nachweis/Kommentar |
Für Pilot, Entscheidung und Vertrag dokumentieren
- Mailflow-Diagramm
- Muss-/Kann-Kriterien
- Authentisierungs-/Connector-Matrix
- Finder-Anforderungsprofil
- Vergleichsmatrix
- Pilot-Testkatalog
- False-Positive-/False-Negative-Protokoll
- Quarantäne-/Helpdesk-Runbook
- Rollback-Verfahren
- Entscheidungsprotokoll