Was das Mail-Modul täglich abdeckt
Mail-Authentication ist eine der unterschätztesten Sicherheits-Disziplinen im Microsoft-365-Umfeld. SPF, DKIM und DMARC zusammen verhindern, dass jemand im Namen Ihrer Domain mailt - also klassisches Spoofing, CEO-Fraud, Phishing mit gefälschten Absendern. Korrekt konfiguriert sind sie ein wirksamer Schutz, der ohne Mehrbelastung für die User funktioniert. Falsch konfiguriert sind sie entweder wirkungslos (DMARC auf „none”) oder gefährlich (zu strenges DMARC blockiert legitime Mails).
Das Mail-Modul übernimmt die kontinuierliche Beobachtung dieser Drei-Säulen-Konfiguration. Es liest DMARC-Aggregate-Reports automatisch ein (sobald der RUA-Record beim Onboarding gesetzt ist), prüft SPF und DKIM tagesaktuell, und liefert für vier typische Mail-Auth-Themen sofort einsetzbare Erkenntnisse.
Szenario 1 - Jemand versucht, im Namen der Geschäftsführung zu mailen
Trigger
Jemand versucht im Namen der Geschäftsführung zu mailen.
Der Hintergrund
CEO-Fraud ist eine der profitabelsten Angriffsarten im Mittelstand. Angreifer schicken Mails, die exakt aussehen wie eine Anweisung der Geschäftsführung an die Buchhaltung („überweisen Sie schnell auf folgendes Konto, vertraulich, ich melde mich später”). Wenn die Absender-Domain stimmt, fallen erschreckend viele Buchhalter darauf rein - nicht aus Unachtsamkeit, sondern weil das Setup technisch überzeugend ist.
Was Angreifer dafür brauchen, ist eine Domain, die kein durchgesetztes DMARC hat. Bei „none”-Policy kommen die Spoof-Mails ungefiltert beim Empfänger an, weil empfangende Mailserver wissen: der Domain-Inhaber will keine Aktion. Sie sehen das nicht - Microsoft Defender for Office 365 schützt Sie als Empfänger gegen Inbound-Phishing, aber nicht gegen Spoofing-Versuche, die in fremden Mailboxen landen.
Was clarios konkret macht
clarios sammelt die DMARC-Aggregate-Reports, die Mail-Provider weltweit täglich an die hinterlegte RUA-Adresse senden. Diese Reports enthalten anonymisierte Statistiken: Source-IP, Anzahl Mails, SPF/DKIM-Ergebnis, ggf. Header-From-Domain. clarios korreliert diese Daten zu Spoofing-Quellen-Profilen.
Im Cockpit sehen Sie eine Karte aller Mail-Sender, die in den letzten Tagen Mails mit Ihrer Domain als Absender verschickt haben - gruppiert nach legitim (Ihr Exchange Online, Ihre eingetragenen SaaS-Tools wie Mailchimp oder Salesforce) und verdächtig (unbekannte IPs, oft aus Ländern, in denen Sie keine Mail-Infrastruktur betreiben). Bei verdächtigen Spitzen (z.B. „gestern 4.200 versuchte Mails von einer russischen IP mit Ihrer Domain als Absender”) wird ein Alert ausgelöst.
Das Ergebnis
Spoofing-Versuche werden sichtbar, bevor sie zum Reputations-Schaden eskalieren. Bei dokumentierten Versuchen können Sie aktiv reagieren: betroffene Kunden informieren, DMARC strenger stellen, ggf. Anzeige erstatten mit konkreter IP-Liste.
Szenario 2 - DMARC ist gesetzt, aber Policy steht auf „none”
Trigger
Ihre Domain hat DMARC veröffentlicht, aber Policy ist „none”.
Der Hintergrund
Eine DMARC-Policy auf „none” bedeutet: der Domain-Inhaber sammelt Reports, fordert aber keine Aktion von empfangenden Mailservern. Das ist ein sinnvoller Startpunkt, weil man so die eigene Mail-Landschaft kennenlernen kann, ohne legitime Mails zu blockieren. Es ist aber kein Endzustand. Bei „none” haben Spoofer freie Hand - sie können beliebige Mails mit Ihrer Domain versenden, und niemand stoppt sie.
Die Migration auf „quarantine” und schließlich „reject” ist die zentrale Mail-Auth-Aufgabe der nächsten 12 Monate für die meisten Mittelständler. Die Schwierigkeit: wenn Sie zu schnell auf „reject” gehen, blockieren Sie versehentlich legitime Mails von SaaS-Diensten, die Sie nicht in Ihrem SPF hatten (Mailchimp, Salesforce, Personio, Microsoft Dynamics, viele andere). Das Resultat: Buchhaltung beschwert sich, weil Rechnungen nicht ankommen - und der DMARC-Vorstoß wird zurückgerollt.
Was clarios konkret macht
clarios führt einen strukturierten Migrations-Pfad. Phase 1 (typisch 4 Wochen): Reports analysieren, alle legitimen Sender identifizieren, SPF- und DKIM-Lücken schließen. Phase 2 (typisch 2-4 Wochen): DMARC auf „quarantine” mit Prozentual-Hochregulierung - erst 25 Prozent, dann 50, dann 100 Prozent der nicht-authentifizierten Mails in den Spam-Ordner. Phase 3 (typisch 2 Wochen): Übergang auf „reject” mit gleicher Stufenfahrt.
Für jede Phase generiert clarios konkrete Vorschläge: „Hier sind die SPF-Includes, die Sie ergänzen sollten.” „Hier ist der DKIM-Selector, den Sie bei diesem Provider aktivieren müssen.” „Hier ist eine Test-Sequenz mit Provider-Echo-Mails, um die Migration zu validieren.” Im Cockpit sehen Sie täglich, wie viele Mails authentifiziert durchkommen, wie viele rejected wurden, und ob es einen Anstieg von „echten Mails, die fälschlich rejected wurden” gibt (Frühwarnsystem).
Das Ergebnis
Vollwertige DMARC-Durchsetzung in 8 bis 12 Wochen, ohne dass legitime Mails verschwinden. Anschließend laufende Überwachung - wenn ein neuer SaaS-Sender hinzukommt, der noch nicht in SPF eingetragen ist, fällt das sofort auf.
Szenario 3 - SPF-Record hat 12 DNS-Lookups, Limit ist 10
Trigger
SPF-Record hat 12 DNS-Lookups - Limit ist 10.
Der Hintergrund
Der SPF-Record (Sender Policy Framework) hat ein hartes technisches Limit: maximal 10 DNS-Lookups beim Auswerten. Jeder include: zählt mit, auch verschachtelte. Bei vielen Mittelstands-Tenants sieht der SPF-Record nach 5 Jahren so aus: Exchange Online, plus alte Mail-Provider (die schon abgelöst, aber nicht entfernt wurden), plus Marketing-Tool, plus Helpdesk-Tool, plus Newsletter-Tool, plus ERP-Notification-Sender. Schnell über dem Limit.
Bei Überschreitung passieren zwei unangenehme Dinge: erstens schlagen alle SPF-Checks fehl mit „PermError” - was wiederum DMARC scheitern lässt, also gehen legitime Mails durch. Zweitens (je nach Empfangsserver) werden manche Mails komplett rejected. Das passiert oft schleichend, weil viele kleine Provider laxer prüfen, während große (Gmail, Outlook.com, Yahoo) konsequent rejecten.
Was clarios konkret macht
clarios prüft täglich den DNS-Lookup-Count des SPF-Records aller verwalteten Domains und alarmiert ab 8 Lookups (Frühwarnung) und ab 10 Lookups (kritisch). Im Cockpit wird der Record visualisiert: welche Includes sind aktiv, wie viele Lookups verursacht jeder, welche sind vermutlich obsolet (z.B. ein eingetragener Mail-Provider, der nach den DMARC-Reports schon Monate keine Mail mehr versendet hat).
Lösungsvorschläge sind dreistufig: Bereinigung (obsolete Includes entfernen), Flattening (Includes durch konkrete IPs ersetzen - risikoreich, weil sich Provider-IPs ändern können), oder Subdomain-Strategie (z.B. marketing.firma.de als separate Domain mit eigenem SPF für Newsletter-Tools). Für jede Variante gibt es Pro- und Contra-Hinweise.
Das Ergebnis
Mail-Zustellbarkeit bleibt stabil, kein E-Mail-Outage. Der SPF bleibt unter dem Lookup-Limit und gut wartbar - neue Mail-Provider können kontrolliert aufgenommen werden, ohne dass der Record sofort wieder kippt.
Szenario 4 - Plötzlich versendet eine unbekannte IP in Ihrem Namen
Trigger
Plötzlich versendet eine unbekannte IP in Ihrem Namen.
Der Hintergrund
Schatten-IT zeigt sich oft zuerst in den DMARC-Reports. Eine Abteilung hat ein neues Tool angeschafft (HR-System, Survey-Tool, eine kleine Marketing-App), das automatisierte Mails verschickt. Die IT-Abteilung weiß davon nichts. Die Mails gehen raus, die Empfänger sehen sie, alles funktioniert auf den ersten Blick. Aber: weil das Tool nicht in SPF eingetragen ist, schlägt SPF fehl, DMARC schlägt fehl, und sobald Sie auf „quarantine” oder „reject” stellen, landen diese Mails im Spam-Ordner oder werden komplett verworfen.
Das wäre nicht weiter dramatisch, wenn man wüsste, dass es passiert. In der Praxis fällt es erst auf, wenn die HR-Abteilung sich wundert, warum Vorstellungsgespräch-Einladungen plötzlich nicht mehr ankommen - und bis dahin sind oft mehrere Wochen vergangen.
Was clarios konkret macht
clarios analysiert die DMARC-Aggregate-Reports nicht nur auf bösartige Sender, sondern auch auf neue, unbekannte legitime Sender. Ein neuer Source-IP, der innerhalb weniger Tage konstant Mails mit Ihrer Domain versendet, wird als „neuer Versender” markiert. Im Cockpit ist die Quelle anhand der reverse DNS-Lookups oft schnell identifizierbar (z.B. „smtp.example-hr-tool.com”).
Sie erhalten eine Empfehlung: handelt es sich um einen legitimen, gewollten Sender, fügen Sie ihn dem SPF-Record hinzu (clarios liefert den Snippet zum Einfügen). Handelt es sich um einen versehentlichen Sender (z.B. eine Test-Konfiguration eines neuen Tools), informieren Sie den verantwortlichen Fachbereich. Handelt es sich um einen unerwünschten Sender (jemand versucht, sich als Sie auszugeben), eskalieren Sie an die IT-Sicherheit.
Das Ergebnis
Shadow-IT-Mailversender werden Teil Ihrer Authentifizierungs-Strategie, statt unentdeckt zu bleiben. Bei der DMARC-Migration verlieren Sie keine versehentlich legitimen Mails, weil neue Sender vor der Verschärfung der DMARC-Policy erfasst sind.