SPF, DKIM, DMARC & Co. – Praxisleitfaden für sichere E-Mail-Kommunikation mit Microsoft 365

1. Management Summary

E-Mails sind nach wie vor das digitale Rückgrat der Geschäftskommunikation – und leider auch ein Einfallstor für Betrüger. SPF, DKIM und DMARC sind drei technische Verfahren, die Ihre E-Mail-Domänen vor Spoofing und Phishing schützen. Sie sorgen dafür, dass nur autorisierte Mailserver in Ihrem Namen senden dürfen (SPF), dass E-Mails eine fälschungssichere „Unterschrift“ tragen (DKIM) und dass Empfänger wissen, wie mit nicht authentischen Mails umzugehen ist (DMARC). Zusammen mit den Sicherheitsfunktionen von Microsoft 365 (Exchange Online Protection, Defender for Office 365, etc.) bilden sie einen wirksamen Schutzwall für Ihre E-Mail-Kommunikation.

Als IT-Berater erlebe ich oft zweifelnde Blicke, wenn ich diese Abkürzungen erwähne. Doch keine Sorge: Dieser Praxisleitfaden erklärt verständlich und Schritt für Schritt, wie Sie SPF, DKIM, DMARC & Co. in Microsoft 365 einrichten und optimal nutzen. Sie erfahren den Sinn und Zweck der einzelnen Technologien, erhalten praxisnahe Szenarien (von der reinen Cloud-Nutzung über Hybridbetrieb bis zu Multifunktionsdruckern) und lernen weitere Schutzmaßnahmen kennen, um Spam und Phishing effektiv abzuwehren. Am Ende wissen Sie genau, wie Sie Ihre E-Mail-Umgebung technisch absichern, typische Stolperfallen vermeiden und im Ernstfall die richtigen Diagnose- und Gegenmaßnahmen ergreifen.

Ich schreibe diesen Artikel in Ich-Form, weil ich alle Schritte persönlich begleite – keine Junior Consultants, kein Outsourcing. Von der Bestandsaufnahme Ihrer Mailflüsse über die DNS-Konfiguration bis zum Troubleshooting: Ich kümmere mich darum, dass alles funktioniert. Dabei soll der Ton locker und mit einem Augenzwinkern bleiben – IT darf auch Spaß machen. Fachlich nehme ich es aber ganz genau, damit Sie sich auf präzise und erprobte Empfehlungen verlassen können.

Quick-Win: Wenn Sie noch gar nichts mit SPF, DKIM und DMARC gemacht haben, können Sie direkt heute einen kleinen Erfolg verbuchen: Veröffentlichen Sie einen DMARC-Eintrag mit der Richtlinie p=none. Damit weisen Sie Empfänger an, Berichte über nicht authentifizierte Mails an Sie zu senden, ohne dass gleich etwas blockiert wird. Sie gewinnen so wertvolle Einblicke in Ihr Mail-Aufkommen – ohne Risiko für die Zustellung. Das ist ein schneller Einstieg, der Ihnen Daten liefert und den Grundstein für weitere Schritte legt.

Unterm Strich bietet dieser Leitfaden nicht nur Theorie, sondern einen umsetzbaren Fahrplan für sichere E-Mail-Kommunikation in Microsoft 365. Sie investieren etwas Zeit in die Einrichtung – und profitieren langfristig von weniger Spam, höherer Zustellrate legitimer Mails und einem guten Gefühl, dass Ihre Domain nicht als Spielball für Betrüger dient. Legen wir los!

2. Grundlagen: Was steckt hinter SPF, DKIM und DMARC?

Bevor wir in die Praxis einsteigen, lohnt sich ein kurzer Blick auf die technischen Grundlagen. E-Mail ist von Haus aus so konstruiert, dass Absender relativ leicht gefälscht werden können – vergleichbar mit einer Postkarte, auf der ich irgend einen Absendernamen schreiben kann. Hier kommen SPF, DKIM und DMARC ins Spiel. Doch was bedeuten diese Abkürzungen konkret, und wie arbeiten die Verfahren zusammen?

2.1 SPF – Sender Policy Framework (Wer darf im Namen meiner Domain senden?)

SPF (Sender Policy Framework) ist sozusagen das „Hausausweiskontrollsystem“ Ihrer Domain. In einem SPF-Eintrag (DNS-Textrecord) legen Sie fest, welche Mailserver für Ihre Domain E-Mails verschicken dürfen. Beim Empfang einer E-Mail prüft der empfangende Mailserver das SPF der absendenden Domain: Steht der absendende Server (dessen IP-Adresse) auf der Gästeliste? Wenn ja, ist alles gut – wenn nein, wird die Mail abgewiesen oder als verdächtig markiert.

Technisch gesehen funktioniert SPF über einen TXT-Eintrag im Domain Name System (DNS). Dieser beginnt immer mit v=spf1 und enthält dann eine Liste autorisierter Mailquellen. Typische Einträge sind z. B. include:spf.protection.outlook.com (um Microsoft 365 zu erlauben) oder ip4:123.45.67.89 (um eine konkrete IPv4-Adresse zu erlauben). Am Ende steht eine Anweisung wie -all oder ~all. -all bedeutet „alle nicht aufgelisteten Server sind nicht autorisiert“ (Hard Fail), während ~all ein Soft Fail darstellt („eigentlich nicht autorisiert, aber nicht strikt ablehnen“). Kurz gesagt: SPF definiert, wer senden darf.

Wichtig zu wissen: SPF prüft nur die technische Absendeadresse (den sogenannten „Envelope From“ oder Return-Path, der oft im E-Mail-Header als Return-Path auftaucht). Die Adresse, die der Endnutzer im „From:“ sieht (sichtbarer Absender), kann theoretisch eine andere sein. Das führt dazu, dass SPF alleine keinen vollständigen Schutz bietet – hier kommt DMARC ins Spiel (dazu gleich mehr), das eine Übereinstimmung fordert. Dennoch ist SPF ein essentieller erster Filter. Ohne gültigen SPF-Eintrag werden Ihre ausgehenden Mails von immer mehr Providern kritisch beäugt oder direkt abgelehnt.

Praxis-Tipp: Für Microsoft 365 muss der SPF-Eintrag Ihrer Domain mindestens include:spf.protection.outlook.com enthalten, da alle von Exchange Online versendeten E-Mails über diese Cloud-Dienste laufen. In der Regel sieht ein SPF-Eintrag für eine reine Microsoft-365-Umgebung so aus:

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

Dieser Eintrag sagt: „Erlaubt Exchange Online (und nichts sonst) als Absender für meine Domain; alles andere hart ablehnen.“ Wenn Sie zusätzliche Mail-Dienste nutzen (z. B. einen Newsletter-Service), müssen Sie deren Server ebenfalls per include oder IP-Eintrag aufnehmen. Dazu später mehr in den Szenarien.

Achtung Falle: SPF hat eine oft übersehene Grenze: Maximal 10 DNS-Lookups dürfen durch include und andere Mechanismen erfolgen. Nutzen Sie zahlreiche externe Mail-Dienste, können Sie dieses Limit schnell erreichen. Das Ergebnis ist ein sogenannter PermError (Permanenter Fehler) – die SPF-Prüfung schlägt dann komplett fehl, als ob kein SPF vorhanden wäre. Die Folge: legitime Mails könnten abgelehnt werden. Achten Sie daher auf ein schlankes SPF-Layout. Nutzen Sie if nötig Subdomains für bestimmte Dienste oder konsolidieren Sie Einträge (viele Anbieter bieten kombinierte Include-Domains an). In der Praxis sehe ich oft SPF-Einträge à la include:service1.com include:service2.com include:service3.com … -all, die in Summe das Limit sprengen. Hier muss man aufpassen und gegebenenfalls Prioritäten setzen oder Subdomains verwenden.

2.2 DKIM – DomainKeys Identified Mail (Die fälschungssichere Signatur)

DKIM (DomainKeys Identified Mail) ist im Prinzip das digitale Siegel unter Ihren E-Mails. Stellen Sie sich einen Brief mit einem Wachssiegel vor: Wenn das Siegel intakt ist, weiß der Empfänger, dass der Brief unterwegs nicht geöffnet oder verändert wurde und tatsächlich vom angeblichen Absender stammt. Genauso funktioniert DKIM für E-Mails:

Beim Versenden einer Mail erzeugt der Mailserver eine digitale Signatur und fügt sie als speziellen Header (DKIM-Signature) in die Nachricht ein. Diese Signatur wird mit einem privaten Schlüssel erzeugt, den nur Ihr Mail-System kennt. Der zugehörige öffentliche Schlüssel wird in Ihrem DNS als TXT- oder CNAME-Eintrag veröffentlicht. Empfängt ein Server nun die Mail, kann er anhand des DKIM-Headers und des öffentlichen Schlüssels prüfen, ob a) die Mail unterwegs verändert wurde und b) ob die Signatur zu Ihrer Domain gehört.

In der Praxis stehen im DKIM-Header mehrere Infos, u. a. ein d= Feld (die Domain, die signiert hat) und ein s= Feld (der sogenannte Selector, der angibt, welchen DNS-Schlüssel zu benutzen ist). Ein Beispiel für so einen Header:

DKIM-Signature: v=1; d=example.com; s=selector1; […] bh=<Hash>; b=<Signatur>

Hier würde der Empfänger im DNS nach einem Eintrag selector1._domainkey.example.com suchen, um den öffentlichen Schlüssel zu finden.

Für Microsoft 365 gilt: Standardmäßig signiert Exchange Online nicht mit Ihrer eigenen Domain, solange Sie DKIM nicht einrichten. Mails werden sonst nur mit einem Microsoft-eigenen DKIM (der .onmicrosoft.com-Domain) versehen. Daher ist es empfehlenswert, DKIM für Ihre benutzerdefinierten Domains zu aktivieren*. Das erfolgt über das Security-Portal von Microsoft 365, wo Sie zwei CNAME-Einträge erhalten, die Sie in Ihrem DNS hinterlegen müssen. Die CNAMEs zeigen auf Microsoft-Server, die die öffentlichen Schlüssel bereitstellen. Nach dem Anlegen (und etwas Wartezeit für die DNS-Verbreitung) aktivieren Sie DKIM für die Domain im Portal – und fortan signiert Microsoft alle ausgehenden Mails dieser Domain mit DKIM.

Wichtig: DKIM erfordert keinen „Match“ zwischen Absenderadresse und der signierenden Domain – das ist erlaubt. So signiert z. B. Microsoft, bevor Sie DKIM custom einrichten, mit d=eur03.onmicrosoft.com auch wenn die From-Adresse @ihredomain.de ist. Das alleine schützt den Empfänger noch nicht davor, dass jemand anders Ihre Domain als From missbraucht. Hier kommt DMARC ins Spiel, um den Abgleich zu fordern. Trotzdem bietet DKIM schon ohne DMARC Vorteile: Es gewährleistet die Integrität der Nachricht (Inhalt wurde nicht verändert) und schafft eine Grundlage, auf der Empfänger Reputation aufbauen können (eine Domain, die immer sauber signiert, genießt Vertrauen).

Übrigens kann eine Mail auch mehrere DKIM-Signaturen tragen. Beispielsweise signiert ein Newsletter-Dienst die Mail mit seiner eigenen Domain und mit der Kundendomäne, falls eingerichtet. So kann ein Weiterleitungsdienst (wie eine Mailingliste) ebenfalls seine Signatur hinzufügen. Mehrere Signaturen stören sich nicht – es reicht, wenn mindestens eine gültig ist und zur Absenderdomain passt (für DMARC).

2.3 DMARC – Domain-based Message Authentication, Reporting & Conformance (Der Wächter, der SPF und DKIM auswertet)

DMARC ist die dritte Komponente im Bunde und fungiert als eine Art Regelwerk und Policymanagement für SPF und DKIM. Die Abkürzung steht für „Domain-based Message Authentication, Reporting and Conformance“. Ganz simpel gesagt: DMARC schaut sich die Ergebnisse von SPF und DKIM an und zieht daraus Konsequenzen.

Eine DMARC-Policy wird – wie SPF – als DNS-TXT-Eintrag publiziert, unter dem speziellen Namen _dmarc.ihredomain. In diesem Eintrag legen Sie zwei Hauptsachen fest:

1. Was tun, wenn eine Mail weder einen gültigen SPF noch eine gültige DKIM Signatur aufweist, die zu Ihrer Domain passt? (Das ist der „Conformance“-Teil, konkret das p= Feld für Policy.) Hier haben Sie drei Optionen: p=none (nichts Besonderes tun, nur berichten), p=quarantine (Mails, die DMARC nicht bestehen, sollen als Spam/verdächtig behandelt werden) oder p=reject (solche Mails ganz ablehnen). Diese Policy gibt Empfängern eine klare Handlungsanweisung, wie streng sie mit vermeintlich gefälschten Mails Ihrer Domain umgehen sollen.
2. Wohin sollen Rückmeldungen geschickt werden? (Das ist der „Reporting“-Teil). Sie können im DMARC-Eintrag angeben, dass Sie Aggregate Reports (rua=) und/oder Forensic Reports (ruf=) erhalten möchten. Aggregate Reports sind tägliche Zusammenfassungen darüber, welche Server Mails mit Ihrer Domain verschickt haben und ob sie SPF/DKIM gepasst haben. Forensic Reports sind Einzelmeldungen bei jeder Fehlprüfung (werden heute seltener versendet, weil datenschutzkritisch). Typischerweise richten Sie für rua eine spezielle E-Mail-Adresse ein (z. B. dmarc-reports@ihredomain.de) oder nutzen einen externen DMARC-Report-Dienst, der die XML-Berichte für Sie aufbereitet.

Der Clou bei DMARC ist die Alignment-Prüfung: DMARC verlangt, dass entweder SPF oder DKIM (oder beide) nicht nur erfolgreich sind, sondern auch auf die sichtbare Absenderdomain bezogen. Das bedeutet konkret:

• SPF-Alignment: Die Domain, die im MAIL FROM (Envelope Absender) benutzt wurde, muss dieselbe sein wie die im sichtbaren „From:“ Header, oder zumindest eine Subdomain davon (je nach Einstellung adkim=s für strict oder relaxed). Praktisch setzt man meist relaxed ein, d. h. es reicht, wenn Haupt- und Subdomain übereinstimmen. Beispiel: MAIL FROM nutzt bounce@newsletter.ihredomain.de und From: ist info@ihredomain.de – das wäre bei relaxed Alignment okay (Subdomain vs Hauptdomain).
• DKIM-Alignment: Die Domain, die im d= Tag der DKIM-Signatur steht, muss mit der From-Domain übereinstimmen (wieder strict oder relaxed analog). Heißt: Wenn Microsoft mit onmicrosoft.com signiert, besteht diese Prüfung nicht, weil d=onmicrosoft.com und From=ihredomain.de verschieden sind. Erst wenn Sie selbst mit Ihrer Domain signieren (d=ihredomain.de), passt es.

Eine Mail besteht DMARC also, wenn entweder a) SPF erfolgreich war und die Absenderdomain gepasst hat, oder b) DKIM erfolgreich validiert wurde und die Domain passte – oder beide. Schlägt beides fehl (entweder weil SPF/DKIM selbst fehlschlagen oder weil das Alignment nicht stimmt), dann ist die Mail ein DMARC-Fail und der Empfänger schaut in Ihre Policy, was zu tun ist.

Warum ist DMARC so wichtig? Ohne DMARC könnten Betrüger z. B. eine Phishing-Mail mit Ihrer Absenderadresse schicken über irgendeinen Server. SPF würde fehlschlagen (Server nicht autorisiert), DKIM gäbe es keine – aber was macht der Empfänger damit? Viele Mailserver würden es einfach als Spam markieren, manche vielleicht durchlassen, je nach interner Heuristik. Mit DMARC signalisieren Sie als Domaininhaber: „Wenn ihr feststellt, dass eine Mail nicht von mir sein kann (SPF fail) und auch nicht signiert ist wie von mir (DKIM fail), dann bitte weg damit (oder mindestens Spam). Ich stehe dahinter.“ Damit übernehmen Sie die Regie, wie mit solchen Fällen umzugehen ist, anstatt es dem Zufall oder den einzelnen Spamfiltern zu überlassen.

Der zweite Aspekt sind die Berichte: Durch DMARC-Reports bekommen Sie plötzlich eine ganz neue Transparenz. Sie sehen, welche Server Mails in Ihrem Namen senden. Oft entdeckt man dadurch längst vergessene Systeme oder Drittanbieter, die für einen tätig sind (oder leider auch Angreifer, die es versuchen). Diese Erkenntnisse sind Gold wert, um Ihre SPF/DKIM-Konfiguration zu vervollständigen oder Missbrauch zu stoppen.

Wichtig: Starten sollte man DMARC immer mit p=none (Policy „nur beobachten“). So sammeln Sie erst Berichte, ohne dass gleich etwas blockiert wird. Nachdem Sie ein paar Wochen die Lage sondiert und eventuell legitime Quellen nachgetragen haben, können Sie schrittweise verschärfen: erst p=quarantine (um unerwünschte Mails in den Spam zu befördern) und dann p=reject (für knallhartes Ablehnen). Dieser Prozess kann je nach Größe und Komplexität Ihrer Organisation einige Zeit dauern – aber es lohnt sich.

Praxis-Notiz: In einem meiner Kundenprojekte haben wir DMARC stufenweise eingeführt. Anfangs zeigte sich in den Reports, dass ein altes ERP-System noch E-Mails direkt versandte – völlig vergessen, tauchte aber nun als „unbekannte Quelle“ auf. Durch die Reports konnten wir reagieren, SPF/DKIM für dieses System nachziehen und so sicherstellen, dass bei späterer DMARC-Verschärfung nichts Legitimes unter die Räder kommt. Fazit: DMARC macht sichtbar, was vorher im Verborgenen lief. Diese Transparenz hilft ungemein bei der Härtung der Mailumgebung.

2.4 Wie greifen die Verfahren ineinander?

SPF, DKIM und DMARC ergänzen sich, anstatt sich zu ersetzen. Stellen wir uns eine Beispiel-Mail vor und schauen, was passiert:

• Schritt 1 (SPF-Prüfung): Die empfangende Seite nimmt die technische Absenderadresse (MAIL FROM) und die IP des sendenden Servers und vergleicht beides mit dem SPF-Eintrag der Absenderdomain. Ergebnis: „Pass“ (wenn IP erlaubt), „Fail“ (wenn nicht erlaubt) oder „Softfail/Neutral“ (wenn ~all und Server nicht gelistet oder andere Sonderfälle).
• Schritt 2 (DKIM-Prüfung): Falls ein DKIM-Header vorhanden ist, wird anhand dessen die Signatur geprüft. Dazu wird der DNS-Eintrag des angebenden Selektors abgefragt. Ergebnis: „Pass“ (Signatur korrekt, Inhalt unverändert, Schlüssel passt zur Domain) oder „Fail“ (Signatur fehlt, ungültig oder Schlüssel nicht passend).
• Schritt 3 (DMARC-Auswertung): Nun schaut der Empfänger: Stimmt die From-Adresse mit einer der Domänen aus Schritt 1 oder 2 überein? Wenn z. B. SPF Pass hat und die Domain aligned ist, dann DMARC = Pass, unabhängig von DKIM. Oder SPF Fail, DKIM Pass (Signatur von der From-Domain) -> DMARC Pass. Nur wenn beides keinen Alignment-Pass ergibt, ist DMARC Fail. Dann wendet der Empfänger die angegebene Policy an: Entweder tut er nichts Besonderes (bei p=none, evtl. nur intern markieren), verschiebt die Mail in Quarantäne/Spam (p=quarantine), oder lehnt sie schon beim SMTP-Handshake ab (p=reject).

Und was ist mit Mails innerhalb derselben Organisation in Microsoft 365, also von Kollegin A an Kollegen B? Diese gehen nie „raus“ ins Internet, sondern bleiben intern – hier greifen SPF/DKIM logischerweise nicht (sie werden auch gar nicht benötigt, da die Authentifizierung auf andere Weise intern passiert). Unsere ganze Diskussion betrifft also primär externe E-Mail-Kommunikation über das Internet.

2.5 Noch mehr Abkürzungen: ARC, Bimi & Co.

Kein IT-Thema ohne zusätzliche Fachbegriffe – der Vollständigkeit halber seien zwei erwähnt:

• ARC (Authenticated Received Chain): Dieses Verfahren adressiert ein spezielles Problem: Weiterleitungen. Stellen Sie sich vor, Sie haben DMARC auf „reject“. Nun sendet jemand legitim in Ihrem Namen eine Mail an einen Empfänger, der aber eine Weiterleitungsregel hat (z. B. von seiner Firmenadresse auf Gmail weiterleitet). Gmail bekommt die Mail von einem Server, der zu der Weiterleitung gehört – SPF wird failen (denn Gmail ist nicht in Ihrer SPF-Liste), DKIM könnte auch failen, falls die Weiterleitung den Inhalt minimal ändert oder kein DKIM vorhanden war. Ergebnis: DMARC würde die Mail verwerfen – obwohl die Originalmail okay war. ARC kommt hier ins Spiel: Mailserver können mit ARC eine Art „Zeugnis“ mitsenden, dass die Mail ursprünglich DMARC-bestanden hatte, bevor sie weitergeleitet wurde. Der empfangende Server kann dieses Zeugnis prüfen und der Mail trotzdem vertrauen. Microsoft 365 unterstützt ARC (sowohl das Prüfen eingehender ARC-Infos als auch das Hinzufügen einer ARC-Signatur, wenn es Mails weiterleitet z. B. an Weiterleitungsadressen). ARC ist noch relativ neu und nicht überall umgesetzt, aber es gewinnt an Bedeutung, um die letzten Lücken zu schließen.
• BIMI (Brand Indicators for Message Identification): BIMI ist kein Anti-Spam-Mechanismus, aber ein netter Aufsatz auf DMARC. Wenn Sie DMARC mit p=quarantine oder p=reject strikt umgesetzt haben und eine gute Reputation genießen, können Sie per BIMI einen Hinweis an unterstützte Mailprogramme geben, Ihr Firmenlogo neben der Mail anzuzeigen. Das soll die Wiedererkennbarkeit erhöhen („Dieses Mail ist wirklich von Firma X, siehe offizielles Logo“). Microsoft 365 unterstützt BIMI mittlerweile auch. Allerdings ist BIMI ein rein optisches Feature – sicherheitstechnisch ist DMARC die Grundlage, BIMI nur das Sahnehäubchen obendrauf.

Jetzt, da wir die Grundlagen und Zusammenhänge kennen, wird klar: SPF verhindert, dass Fremde unautorisiert unter Ihrem Namen senden. DKIM stellt sicher, dass E-Mails unterwegs nicht manipuliert werden und wirklich von Ihrer Domain signiert wurden. DMARC verbindet die Fäden und setzt klare Regeln, wie auf Fehlversuche zu reagieren ist, plus Berichtwesen. In Kombination bilden sie ein wirkungsvolles Trio gegen Spam und Phishing.

3. Schutzszenarien in der Praxis: Von Cloud-Only bis Hybrid

Theorie ist schön und gut – aber wie wendet man das in unterschiedlichen Umgebungen an? Jedes Unternehmen ist anders aufgestellt. Im Folgenden stelle ich vier typische Szenarien vor und gebe praktische Hinweise, worauf jeweils zu achten ist. Sie werden sehen: Egal ob Sie ausschließlich Microsoft 365 nutzen oder eine bunte Mischung aus Cloud, On-Premises und Drittanbietern – für jedes Szenario gibt es einen sicheren Weg.

Szenario 1: Reine Microsoft 365 Cloud-Umgebung

Ausgangslage: Ihr gesamter E-Mail-Verkehr läuft über Exchange Online (Microsoft 365). Es gibt keine lokalen Exchange-Server mehr und auch sonst keine eigenen Mailserver. Vielleicht haben Sie ein, zwei SaaS-Dienste im Einsatz, aber die senden entweder über Ihre Office 365-Postfächer oder benutzen eigene Absenderdomains.

SPF: In diesem Fall ist das simpel. Ihr SPF-Eintrag enthält nur den einen obligatorischen Include-Eintrag für Microsoft. Microsoft hat alle seine Absenderserver unter spf.protection.outlook.com zusammengefasst. Das umfasst sowohl die weltweiten Exchange-Online-IP-Adressen als auch Dienste wie SharePoint-Benachrichtigungen, Microsoft Teams Mails etc. Ihr SPF sieht also aus wie schon erwähnt:

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

Prüfen Sie im Microsoft 365 Admin Center (unter Domains -> DNS-Einträge), ob dieser SPF-Eintrag korrekt gesetzt ist. Meistens wurde das schon bei der Einrichtung der Domain erledigt. Falls Sie noch auf ~all (Softfail) stehen, können Sie überlegen, auf -all zu gehen, da in diesem Szenario ja keine weiteren unbekannten Sender existieren.

DKIM: Da Sie eine eigene Domain verwenden, sollten Sie DKIM im Security Portal einschalten. Gehen Sie im Microsoft 365 Defender Portal zu “Threat Policies” -> “DKIM” (oder direkt über die URL https://security.microsoft.com/dkimv2). Wählen Sie Ihre Domain aus. Microsoft zeigt Ihnen hier, welche DNS-Einträge anzulegen sind. Das sind zwei CNAME-Einträge:

• selector1._domainkey.IhreDomain.de -> selector1-IhreDomain-de._domainkey.IhreTenant.onmicrosoft.com
• selector2._domainkey.IhreDomain.de -> selector2-IhreDomain-de._domainkey.IhreTenant.onmicrosoft.com

(Der genaue Name hängt von Ihrer Domain und Ihrem Tenant ab – Microsoft gibt ihn vor. „IhreDomain-de“ wäre in echt z. B. „contoso-com“, wenn Ihre Domain contoso.com ist. Wichtig ist, dass Sie diese Strings exakt so eintragen, wie angegeben.)

Nach dem Anlegen im DNS warten Sie idealerweise ein paar Stunden (Microsoft sagt 8 Stunden, praktisch reichen oft 1–2 Stunden, bis alle DNS-Server es mitbekommen). Anschließend klicken Sie im Portal auf “Signieren aktivieren”. Von nun an bekommen alle ausgehenden Mails Ihrer Domain einen DKIM-Signaturheader mit d=IhreDomain.de. Für Sie ändert sich nichts im Alltag, aber Empfänger, die DKIM auswerten, sehen jetzt Ihre Domain und ein gültiges Siegel.

DMARC: Als Cloud-Only-Organisation haben Sie es leicht, den Überblick zu behalten. Dennoch: Gehen Sie auch hier schrittweise. Zunächst erstellen Sie einen DNS-Eintrag _dmarc.ihredomain.de mit z. B.:

v=DMARC1; p=none; rua=mailto:dmarc-reports@ihredomain.de; ruf=mailto:dmarc-forensic@ihredomain.de; fo=1;

Erläuterung: p=none bedeutet erstmal nur beobachten. rua und ruf schicken Aggregate bzw. Forensic Reports an die angegebenen Adressen. (Legen Sie diese Postfächer an oder nutzen Sie einen externen DMARC-Auswerter. Einige nutzen auch kostenlose Mail-Accounts, aber Achtung bei Datenschutz – besser eine Firmenadresse.) fo=1 würde im Forensic-Fall einen Report bei jedem SPF/DKIM-Fail schicken (kann man optional setzen; viele lassen es weg, weil Forensics eh spärlich sind heutzutage).

Nach ein paar Wochen Beobachtung sollten in Ihrem Fall nur Microsoft-Server auftauchen, alles grün. Dann können Sie p=quarantine setzen. Das bewirkt, dass z. B. Gmail & Co. fremde Mails unter Ihrem Namen in den Spam packen. In den Reports sehen Sie dann, ob überhaupt welche vorkommen. Wenn auch das einige Zeit gut läuft, der Mut groß genug und die Geschäftsleitung überzeugt ist, stellen Sie auf p=reject. Ab dann werden Fälschungen Ihrer Domain von kompatiblen Mailservern abgelehnt – ein gutes Gefühl!

Besonderheiten: In einer reinen Microsoft-Welt gibt es wenig Stolperfallen. Achten Sie nur darauf, dass System-Postfächer oder no-reply-Adressen keine Mails von außen weiterleiten, die dann an DMARC scheitern könnten. Aber das ist ein Spezialfall. Insgesamt ist dies das unkomplizierteste Setup.

Szenario 2: Hybridbetrieb (Exchange On-Premises + Microsoft 365)

Ausgangslage: Ihr Unternehmen betreibt einen Hybrid Exchange – also ein Teil der Postfächer liegt in Exchange Online, ein Teil noch auf einem lokalen Exchange-Server. Möglicherweise nutzen Sie einen „zentralisierten Mailfluss“ oder lassen E-Mails teils über die Cloud, teils lokal rausgehen.

Hier müssen wir genauer hinsehen, da nun zwei Absenderquellen existieren.

SPF: Der SPF-Eintrag muss beide Welten abdecken. Das heißt, neben include:spf.protection.outlook.com für die Microsoft-Seite müssen Sie Ihre eigenen ausgehenden Mailserver/IPs autorisieren. Wenn Ihr On-Premises-Exchange die Mails direkt ans Internet ausliefert, muss dessen öffentliche IP in den SPF. Beispiel:

v=spf1 ip4:87.65.43.21 include:spf.protection.outlook.com -all

(Wobei 87.65.43.21 durch Ihre echte feste IP zu ersetzen ist, ggf. mehrere IPs oder ein IPv6 mit ip6: falls vorhanden.) Alternativ, manche Firmen lassen alle ausgehenden Mails selbst im Hybrid über Exchange Online verschicken (sog. „Outbound routing through Exchange Online“). In dem Fall genügt der Microsoft include, weil der lokale Exchange die Mail immer erst an EOP (Exchange Online Protection) übergibt und EOP sie dann ausliefert. Prüfen Sie Ihre Konfiguration: Versendet Ihr On-Prem-Server direkt an die Zieldomänen, oder routet er über einen Connector zu O365? Danach richten Sie SPF aus.

Ein typisches Fehlerbild: Das Hybrid-Setup wurde eingerichtet, aber SPF nicht angepasst. Folge: Mails, die vom lokalen Server direkt rausgingen, haben SPF Fail bei Empfängern, weil nur die Cloud im SPF stand. Hier ist also Sorgfalt nötig. Auch sollte man darauf achten, SPF im gleichen Stil zu haben – also wenn man -all nutzt, dann wirklich sicherstellen, dass nichts vergessen wurde, sonst drohen Bounces.

DKIM: Microsoft 365 kann nur für Mails DKIM-signieren, die auch über Microsoft gesendet werden. Wenn Ihr lokaler Exchange direkt verschickt, wird er standardmäßig keine DKIM-Signatur hinzufügen – Exchange (on-prem) hat von Haus aus keine DKIM-Funktion. Was tun?

Es gibt zwei Ansätze:

1. Outbound via EOP: Leiten Sie ausgehende Mails aller Postfächer über Exchange Online. Dann können Sie sich zurücklehnen – EOP (Exchange Online Protection) wird auch die On-Prem-Mails signieren, sobald sie durch die Cloud laufen. Voraussetzung: Sie haben die entsprechenden Send Connectors im Hybrid so konfiguriert und im Microsoft Admin Center die DKIM-Einstellung aktiviert (wie oben beschrieben). Dieses Vorgehen ist elegant, weil alle ausgehenden Mails einen einheitlichen Weg nehmen und einheitlich signiert/prüfbar sind.
2. DKIM on-prem implementieren: Wenn aus welchen Gründen auch immer Ihr On-Prem-Server direkt versenden soll, benötigen Sie dort eine DKIM-Lösung. Microsoft bietet das nicht nativ, aber es gibt Drittanbieter-Tools oder Scripte (z. B. OpenDKIM für Windows bzw. Exchange oder Tools wie „Exchange DKIM Signer“). Diese müssen installiert und konfiguriert werden, um ausgehende Mails zu signieren. Dann müssten Sie zudem die öffentlichen Schlüssel ins DNS stellen (oft als TXT-Records bei eigenem Selector). Das ist machbar, aber natürlich zusätzlicher Aufwand und Fehlerquelle.

Mein Rat in der Praxis: Wenn möglich, nutzen Sie die Cloud zum Versenden (Stichwort „Smarthost“). Das entlastet Sie on-prem und Sie nutzen die gut gepflegte Infrastruktur von Microsoft, inkl. DKIM-Signatur und der Tatsache, dass Microsofts Mailserver bei den meisten Empfängern einen hohen Ruf genießen (was Zustellung fördert).

DMARC: Hier liegt die Tücke vor allem in der Alignment. Angenommen, lokale Mails werden nicht DKIM-signiert (Worst Case) und auch SPF könnte tricky sein, falls z. B. jemand einen internen Relay nutzt. Dennoch: Wenn SPF korrekt konfiguriert ist (On-Prem-IP im SPF drin), dann sollten zumindest diese Mails SPF Pass haben und DMARC bestehen – solange die From-Domain dieselbe ist (was sie ja ist, es ist Ihre Domain). Problematisch wäre es, wenn Ihr Exchange on-prem für manche Mails eine andere Absenderdomain nutzt als die Ihrer Hauptdomain (z. B. eine zusätzliche Domain). Dann muss natürlich für jede Domain SPF etc. gemacht werden.

Letztlich gilt: DMARC können Sie genau so einführen wie im Cloud-Only-Fall, aber Sie müssen unbedingt sicherstellen, dass Ihr on-prem Pfad nicht durchs Raster fällt. In Reports werden Sie ja sehen, welche Quellen auftauchen. Ihre eigene IP sollte aufscheinen mit DKIM Fail (falls kein DKIM) aber SPF Pass (wenn richtig im SPF). DMARC erkennt: SPF passt, Domain passt -> alles gut. Sollte SPF mal failen (falsche IP oder so), dann hätten wir DMARC Fail – das wäre fatal, wenn Sie p=quarantine/reject schon aktiv haben. Daher erst alles glätten.

Sonderfall Hybrid: Oft hat man in Hybrid-Umgebungen noch andere Geräte oder Server, die über den lokalen Exchange Mails verschicken (z. B. Anwendungen via SMTP Relay). Wenn diese über denselben Weg rausgehen, gelten dieselben SPF-Regeln. Dokumentieren Sie möglichst alle Systeme, die Mails generieren. Hier hilft oft ein Gespräch mit den Admin-Kollegen: „Welche Geräte/Programme senden automatisiert E-Mails?“. Überraschungen (die berühmte Produktionsmaschine, die eigenständig Störungsmeldungen mailt…) kann man dann einkalkulieren.

Zusammenfassung: Hybrid = beide Welten zusammenbringen. SPF anreichern, DKIM idealerweise zentral über Cloud, DMARC beobachten und dann streng machen, wenn alle Pfade korrekt sind.

Szenario 3: Drittanbieter-Maildienste und SaaS

Ausgangslage: Ihr Marketing nutzt Mailchimp für Newsletter. Die Personalabteilung hat ein HR-System in der Cloud, das Mails (Bewerbungsbestätigungen etc.) unter eurer Domain verschickt. Der Helpdesk verwendet ein Ticket-System, das E-Mails an Benutzer sendet als „support@ihredomain.de“. Kurz: Es gibt externe Dienste, die in Ihrem Auftrag E-Mails versenden.

Dies ist ein sehr häufiges Szenario – und bringt Herausforderungen mit sich, weil diese Dienste nicht Ihre IP-Adressen nutzen und meist außerhalb von Microsoft 365 laufen.

SPF: Der erste Schritt: Ermitteln Sie, ob diese Dienste SPF-Anweisungen haben. Seriöse Anbieter dokumentieren, was in den SPF muss, damit deren Server autorisiert sind. Z. B. sagt Mailchimp: „fügen Sie include:servers.mcsv.net in Ihr SPF ein“. Andere haben fest IP-Ranges. Wichtig ist, dass Sie alle diese Drittanbieter in Ihrem SPF-Eintrag aufnehmen. Leider führt das oft zu überlangen SPF-Records, siehe Warnung zur Lookup-Limitierung. Es gibt aber oft Kompromisse: Manche Anbieter erlauben, die Absenderadresse auf eine Subdomain zu legen oder eigene Versanddomains zu nutzen.

Beste Praxis: Ich empfehle, kritische Drittanbieter auf Subdomains auszulagern. Beispiel: Statt Newsletter von marketing@firma.de zu senden, nutzen Sie marketing@news.firma.de. Dann können Sie für news.firma.de einen eigenen SPF aufsetzen, der nur Mailchimp (bzw. den Dienst) enthält. Die Hauptdomain firma.de bleibt sauber für Ihre normalen Mails. Außerdem wirkt sich ein eventuelles Problem (z. B. Mailchimp wird geblacklistet) nicht unmittelbar auf die Reputation Ihrer Hauptdomain aus. Microsoft 365 erlaubt es ohne weiteres, Aliases oder Absender auf Subdomains zu haben, solange Sie diese Domain auch als Akzeptierte Domäne eingerichtet haben.

Wenn Subdomain nicht gewünscht ist, dann müssen Sie dem Drittanbieter vertrauen und ihn in Ihr SPF aufnehmen. Prüfen Sie regelmäßig, ob der Eintrag aktuell bleibt. Ein Risiko: Wenn so ein Dienst seine Infrastruktur ändert und Sie verpassen das, könnten plötzlich Mails von dort SPF-Fails produzieren.

DKIM: Viele SaaS-Anbieter bieten DKIM-Signierung in Ihrem Namen an. Das läuft dann so: In der Web-Oberfläche des Dienstes gibt es eine Option „DKIM/Domain Authentication einrichten“. Meist müssen Sie zwei CNAME oder TXT-Einträge bei sich im DNS setzen, damit der Dienst nachweisen kann, dass Sie Domaininhaber sind und damit er dort seinen öffentlichen Schlüssel hinterlegen kann. Wenn Sie das tun, signiert fortan z. B. Mailchimp jede versendete Mail mit „d=ihredomain.de“ und einem Schlüssel, den sie (Mailchimp) verwalten. Das ist gut für Sie, denn es erhöht die Zustellchance und alles fügt sich nahtlos in DMARC ein. Also ja: Schalten Sie DKIM bei Drittanbietern ein, wenn verfügbar!

Falls ein Dienst das nicht bietet, überlegt man sich wieder: Subdomain-Workaround (manche signieren zumindest mit ihrer eigenen Domain, was DMARC Alignment aber nicht erfüllt) oder Druck auf den Anbieter (heutzutage sollten sie es eigentlich haben).

DMARC: Hier zahlt sich die Vorarbeit aus. DMARC wird funktionieren, wenn entweder SPF oder DKIM (oder beide) greift und aligned ist. Ihre Aufgabe ist es also, dafür zu sorgen, dass jeder legitime Dienst mindestens eine dieser Prüfungen besteht. SPF-Alignment kann tricky sein, wenn z. B. das Return-Path vom SaaS anders ist (manche nutzen eigene Bounce-Domains). DKIM ist dann oft der bessere Weg, weil es sich auf die From-Domain konzentriert.

In den DMARC-Berichten werden Sie die Drittanbieter klar erkennen können (an deren Domainnamen oder IPs). Anfangs, bei p=none, sieht man dann eventuell „Oh, da ist noch ein Newsletter-Dienst XY, von dem wir gar nichts wussten“. Durch die Reports decken Sie das auf und können nachjustieren.

Besonderheiten: Achten Sie auf Berechtigungen und Governance – nicht dass irgendwelche Abteilungen eigenmächtig neue Dienste nutzen und Firmen-E-Mails darüber senden, ohne das IT/Security einbindet. Mit DMARC würden diese dann im schlimmsten Fall blockiert. Hier ist internes Monitoring und Kommunikation wichtig: DMARC erzieht ein bisschen zu besserer Disziplin, was die Nutzung externer Mailtools angeht.

Szenario 4: Multifunktionsgeräte, Drucker & Applikationen inhouse

Ausgangslage: Der Klassiker: Ein Multifunktionsdrucker soll eingescannte Dokumente per E-Mail versenden. Oder ein Webshop schickt automatische Bestellbestätigungen. Oder ein Überwachungssystem verschickt Alarm-Mails. Diese Geräte/Apps sind bei Ihnen vor Ort und wollen Mails oft an externe Empfänger schicken – gerne mal als „noreply@ihredomain.de“ oder ähnliches.

Solche Mails können leicht an SPF/DMARC scheitern, wenn sie nicht richtig angebunden sind. Denn der Drucker zum Beispiel hat keine eigene öffentlichen IP, und wenn er direkt an z. B. gmail.com mailt, steht als Absender Ihr Domainname, aber die Mail kommt von einer x-beliebigen IP Ihres Internetanschlusses – SPF Fail garantiert.

Lösungen gibt es aber: Microsoft hat hierfür drei Ansätze parat:

1. SMTP-Auth (Client Submission): Sie richten für das Gerät ein normales Postfach oder zumindest einen freigegebenen Postfach-Account ein (z. B. scanner@ihredomain.de). In den Einstellungen des Druckers tragen Sie smtp.office365.com als SMTP-Server ein, Port 587, STARTTLS und die Anmeldedaten des Accounts. Das Gerät loggt sich also ein wie ein E-Mail-Programm und sendet die Mail authentifiziert durch Ihre Microsoft 365-Organisation. Vorteil: Die E-Mail durchläuft Exchange Online wie jede andere aus Ihrem Haus, wird also auch korrekt mit DKIM signiert und von Microsofts Servern verschickt (SPF passt somit auch). Nachteil: Manche älteren Geräte unterstützen kein TLS oder keine Authentifizierung mit modernen Verfahren. Auch blockt Microsoft standardmäßig unsichere Authentifizierung – man muss möglicherweise SMTP-Authentifizierung explizit aktivieren für diesen Account, da Microsoft aus Sicherheitsgründen Basic Auth für viele Dienste abgeschaltet hat. Aber SMTP Auth geht in der Regel noch, muss aber im Tenant erlaubt sein.
2. Direct Send über O365: Hier verwendet das Gerät keine Authentifizierung, sondern sendet an den MX-Endpunkt Ihrer Microsoft 365 (z. B. <ihredomain>.mail.protection.outlook.com). Microsoft nimmt die Mail an, wenn die Absenderadresse zu Ihrer Domain gehört. Allerdings funktioniert Direct Send in Office 365 nur für interne Empfänger! Sprich, das ist geeignet, wenn der Drucker nur Kollegen etwas mailt (z. B. “Scan fertig”). Für Mails an externe Empfänger geht das nicht, weil Microsoft diese als Spoofingversuch erkennen würde (was ja auch richtig ist, es ist unverifiziert). Direct Send hat zudem den Nachteil, dass keine Authentifizierung erfolgt – man muss bei Microsoft IP-Adress-Regeln konfigurieren, damit es nicht als Relaying missbraucht wird. Ich persönlich nutze Direct Send selten, meist nur in reinen internen Szenarien.
3. Eigener SMTP-Relayserver on-premises: Man kann einen kleinen SMTP-Server (z. B. Windows IIS SMTP Relay oder spezialisierten Mailrelay) lokal aufsetzen, der alle Geräte-E-Mails annimmt und dann weiterleitet – entweder wiederum an O365 oder direkt raus. Wenn direkt raus, muss dessen IP im SPF stehen (und idealerweise signiert er DKIM, was wieder Aufwand ist). Wenn er an O365 weiterleitet (mit Auth oder Connector), dann sind wir wieder bei Methode 1 im Grunde, nur dass alle Geräte an einen internen Knoten schicken. Dies kann sinnvoll sein, wenn man viele Geräte hat und diese zentralisieren will, oder wenn Geräte kein TLS können (interne Kommunikation unsicher erlauben und dann der Relay spricht per TLS zu O365).

In der Praxis bevorzuge ich Methode 1 (SMTP-Auth). Es ist am transparentesten: Jede Mail geht brav über Microsoft und wird dort geprüft, geloggt und verschickt. Ich richte etwa ein Konto scanner@ an, setze ein langes Kennwort und aktiviere SMTP-Auth. In den Geräte configuriere ich dieses Konto. Funktioniert zuverlässig.

SPF/DMARC Implikation: Wenn Sie den SMTP-Auth-Weg gehen, kommt die Mail von Microsofts IPs, mit Ihrem Absender -> SPF passt (Microsoft im include), DKIM wird durch O365 gemacht -> passt, DMARC passt. Alles gut.
Wenn Sie allerdings aus Versehen einen Drucker direkt senden lassen, sehen Sie im DMARC-Report genau das: eine fremde IP (die Ihres ISP) mit SPF Fail, DKIM none, DMARC Fail. Und je nach Policy wird die Mail dann geblockt oder landet im Spam beim Empfänger. Viele Unternehmen haben sich schon gewundert: „Unsere Scanner-Mails kommen gar nicht mehr an“ – nach Einführung von DMARC (oder auch schon strengem SPF) passiert genau das, wenn man hier nichts unternimmt.

Tipp: Schauen Sie sich im Microsoft Admin Center unter „Berichte“ mal die Spam-Erkennungen an: Geräte, die falsch senden, tauchen manchmal auch dort auf, wenn Microsoft sie als potenziell gefährlichen Outbound verkehr sieht. Es gibt auch in Defender die Möglichkeit, Ausnahmen zu definieren, aber besser ist es, die Ursache zu beheben.

Zusammengefasst: Inventarisieren Sie alle lokalen Sender. Geben Sie ihnen einen sauberen Pfad (idealerweise via Auth über O365). Dann integrieren sich diese Mails auch in Ihre SPF/DKIM/DMARC-Welt nahtlos. Andernfalls müssen Sie kreative SPF-Einträge machen (z. B. Ihre ganze Büro-IP-Range erlauben – was man nicht will, weil das auch Angreifer nützen könnten, wenn sie sich reinhacken). Also lieber restriktiv und per Auth.

Szenario 5: Sonstige Spezialfälle

Neben den obigen Hauptszenarien gibt es natürlich noch weitere mögliche Konstellationen:

• Mehrere E-Mail-Domains im Unternehmen: Haben Sie z. B. @firma.de und @firma.com parallel in Gebrauch, müssen Sie für jede Domain SPF, DKIM, DMARC einrichten. Oft vergisst man die Zweit- oder Drittdomain (besonders Aliases). Microsoft 365 ermöglicht DKIM für jede akzeptierte Domain separat (also DNS-Einträge je Domain). DMARC muss pro Domain ins DNS. SPF ebenso. Halten Sie die Konfiguration konsistent. Wenn Domains gar nicht mailen, setzen Sie dennoch einen SPF (v=spf1 -all) und DMARC (p=reject) auf, um Missbrauch zu unterbinden.
• Partnerunternehmen/Delegation: Manchmal soll ein Partner im Auftrag mit Ihrer Adresse senden dürfen (z. B. PR-Agentur verschickt Einladung in Ihrem Namen). Solche Fälle sind heikel. Im Grunde müssten Sie deren Server in SPF aufnehmen und idealerweise denen einen DKIM-Schlüssel geben. Meist ist es besser, über kontrollierte Kanäle zu gehen (z. B. die Agentur nutzt einen bereitgestellten Office-365-Account von Ihnen, sodass Mails von Ihrer Infrastruktur kommen).
• No-Reply-Adressen, die extern verteilt werden: Oft generieren no-reply@ Adressen Mails wie Newsletters. Stellen Sie sicher, dass diese Postfächer dennoch existieren und zumindest DKIM signieren. Sie können so konfigurieren, dass eingehende Antworten ins Leere laufen, aber die Absenderadresse sollte echt sein, um Authprobleme zu vermeiden.

Wir sehen: Für jedes Szenario lässt sich eine Lösung finden, solange man die Prinzipien anwendet. Der Schlüssel ist, alle legitimen Mailquellen zu kennen und einzubinden, und unautorisierte zu blockieren.

4. Weitere Schutzmaßnahmen für E-Mails in Microsoft 365

SPF, DKIM und DMARC sind zentrale Bausteine – aber E-Mail-Sicherheit umfasst noch mehr. Microsoft 365 bringt von Haus aus zahlreiche Mechanismen mit, um Ihre Mailboxen zu schützen. Hier ein Überblick, wie Sie Spam, Malware und Phishing zusätzlich begegnen können, mit Fokus auf Microsoft 365-Funktionen:

4.1 Exchange Online Protection (EOP) – Die eingebaute Spam-Filterung

Exchange Online Protection ist Microsofts Standard-Spam- und Malwarefilter, der für alle Exchange-Online-Kunden aktiv ist. EOP prüft eingehende E-Mails nach bekannten Spam-Mustern, Absenderreputation, bekannten schädlichen Links/Anhängen und vielen weiteren Kriterien. Ohne dass Sie etwas tun müssen, werden bereits massenhaft Spam-Mails geblockt oder in den Junk-Ordner umgeleitet.

SPF, DKIM, DMARC in EOP: EOP wertet SPF und DKIM automatisch bei eingehenden Mails aus. Wenn SPF fehlschlägt, wird die Mail als Spam markiert (oder in Kopfzeilen vermerkt). Wenn eine Mail scheinbar von Ihrer eigenen Domain kommt, aber SPF/DKIM nicht stimmt und Sie DMARC im Einsatz haben, greift ein zusätzlicher Spoofing-Schutz. Microsoft behandelt Ihre Domain dann mit erhöhter Sensibilität, um interne Spoofing zu verhindern. Im Security Portal unter „Anti-Phishing“ gibt es Einstellungen, wie strikt EOP mit Impersonation umgehen soll (z. B. wenn jemand Ihren Domainnamen mit kleinem Unterschied benutzt, oder Ihren CEO-Namen fälscht). Diese greifen auch ohne DMARC, aber mit DMARC haben Sie doppelte Sicherheit.

Per PowerShell oder im neuen „Anti-Spam-Richtlinien“ Interface können Sie festlegen, was EOP bei SPF-Fehler tun soll – z. B. bei SPF HardFail direkt ablehnen oder Junk. Standard ist, SPF-Fails zu junk-markieren. Sie können das an Ihre Bedürfnisse anpassen. Ich rate aber: Lassen Sie EOP seine Arbeit tun; greifen Sie nur ein, wenn echte Bedarf gibt. Microsofts Filter werden ständig aktualisiert und treffen meist gute Entscheidungen.

Outbound Protection: EOP checkt auch ausgehende Mails – vor allem um zu verhindern, dass Ihr Tenant Spam verschickt (z. B. wenn ein Account kompromittiert wurde). Sollte ein Ihrer Konten plötzlich massenhaft Spam versenden, kann Microsoft es temporär sperren. Das ist ein wichtiges Feature, um Ihre Domainreputation zu schützen. Im Idealfall passiert es nie, aber gut zu wissen, dass Mechanismen da sind.

4.2 Microsoft Defender for Office 365 – Erweiterter Schutz vor Phishing & Malware

Defender for Office 365 (Plan 1 oder 2, früher ATP = Advanced Threat Protection) erweitert den Basis-Schutz um proaktive Sicherheit. Hier einige relevante Funktionen:

• Safe Attachments: Verdächtige Anhänge werden in einer Sandbox ausgeführt, bevor sie zum Benutzer gelangen. So filtert man neue, unbekannte Malware heraus. Das schützt vor Trojanern & Co., hat aber weniger mit unseren Mailauth-Themen zu tun. Dennoch Teil der ganzheitlichen Sicherheit.
• Safe Links: URLs in E-Mails können beim Anklicken in Echtzeit geprüft werden. Bekannte Phishing-Links werden blockiert, auch wenn sie beim Eintreffen noch unauffällig wirkten. Gerade bei Phishing-Mails (die oft über kompromittierte Konten kommen, also trotz SPF/DKIM legitime Absender haben) ist Safe Links ein wichtiges Netz.
• Anti-Phishing Policies: Hiermit kann man gezielt Impersonation-Schutz konfigurieren. Z. B. definieren, dass E-Mails, die scheinbar vom eigenen Domänennamen kommen aber extern eintrafen, genauer geprüft oder geblockt werden. Oder man hinterlegt VIP-Namen (Geschäftsführer etc.), damit Mails mit diesen Namen als Absender, die aber extern herkommen, geblockt werden. Microsoft hat viele dieser Regeln schon intelligent aktiviert, aber man kann Feinjustierung betreiben.

Insbesondere mit Defender Plan 2 gibt es auch Attack Simulation Training – das heißt, man kann z. B. Phishing-Testmails an Mitarbeiter senden, um Awareness zu erhöhen. Das ist mehr Security Awareness Maßnahme als technisches Filtering.

Für unser Thema heißt das: Auch wenn SPF/DKIM/DMARC helfen, sollten Sie nicht auf die restlichen Schutzmechanismen verzichten. Sie ergänzen sich. Beispiel: Wenn ein Angreifer doch mal eine legitime Domain kapert (also die Mail authentisch ist), greifen DMARC & Co. nicht – dann springen die inhaltlichen Filter an (z. B. Machine Learning erkennt ungewöhnlichen Text oder Safe Links fängt böse URL).

4.3 Transportregeln (Mailflow-Regeln) – Maßgeschneiderte E-Mail-Policies

Transportregeln in Exchange Online sind ein mächtiges Werkzeug, mit dem Sie eigene Bedingungen und Aktionen für den E-Mail-Fluss definieren können. Denken Sie an sie wie an „Wenn-Dann“-Regeln für Mails. Ein paar Anwendungsfälle relevant für Sicherheit:

• Warn-Banner für externe E-Mails: Viele Firmen versehen jede E-Mail, die von außerhalb kommt, mit einem Banner oder Text à la „Achtung, diese E-Mail stammt von außerhalb Ihrer Organisation“. Das kann man per Transportregel umsetzen: Bedingung „Absender ist extern, Empfänger intern“ -> Aktion „Text in Kopf der Mail einfügen“ (oder in Betreff [EXTERN] taggen). So werden Mitarbeiter visuell erinnert, dass der Absender kein Kollege ist – hilfreich gegen CEO-Fraud (wenn Chef scheinbar schreibt, aber Banner zeigt extern).
• Blockieren bestimmter Absender/Domainen: Obwohl Microsoft global schon viel blockiert, kann es Gründe geben, eigene Blacklists zu pflegen. Mit Transportregeln können Sie etwa alle Mails von einer bestimmten Domain abweisen oder in Quarantäne stecken.
• DLP (Data Loss Prevention): Gehört zwar zum Compliance-Bereich, aber sei erwähnt: Man kann Regeln definieren, die erkennen, ob z. B. Kreditkartennummern oder Personalausweisnummern im Mailtext/Anhang sind und dann den Versand blockieren oder verschlüsseln. Das dient dem Schutz vertraulicher Daten und indirekt auch gegen Angreifer (z. B. Trojaner, der Daten exfiltriert per Mail, würde so evtl. gestoppt).
• Weiterleitungsblockade: Eine oft empfohlene Maßnahme: automatische Weiterleitungen nach extern unterbinden. Viele Phishing-Attacken basieren darauf, dass kompromittierte Accounts eine Regel einrichten „leite alle Mails an extern weiter“. Mit einer Transportregel können Sie erkennen „wenn Absender intern und Empfänger extern und X-Header enthält ‚auto-forward‘, dann blockieren“. Microsoft bietet mittlerweile auch einen Toggle „Externes Auto-Forward verbieten“ im Security Center. Das schützt davor, dass interne Kommunikation nach draußen gespiegelt wird.
• Verschlüsselung erzwingen: Wenn Sie sicherstellen wollen, dass bestimmte E-Mails nur verschlüsselt rausgehen (z. B. immer wenn ans Aufsichtsratsvorsitzender extern, dann Office Message Encryption aktivieren), geht das per Regel.

Transportregeln greifen nach den Anti-Malware/Spam Filtern und können Ihre Sicherheitsstrategie verfeinern. Sie sollten mit Bedacht eingesetzt werden (jede Regel kostet auch Performance), aber in Maßen sind sie sehr hilfreich.

4.4 Benutzer-Schulung und Awareness

Bei aller Technik darf man den Faktor Mensch nicht vergessen: Informieren Sie Ihre Mitarbeiter über die Bedeutung von authentifizierten E-Mails. Gerade wenn DMARC greift, kann es vorkommen, dass ein Mitarbeiter sagt: „Herr X hat mir gesagt er hat was geschickt, aber ich hab nichts erhalten.“ Mögliche Ursache: Herr X’s Organisation hat DMARC auf reject, aber seine Mail wurde durch einen Drittserver umgeleitet und dadurch geblockt. Solche Stories mögen selten sein, aber erklären Sie, warum bestimmte Mails evtl. geblockt werden (nämlich zum Schutz).

Auch sollten Mitarbeiter Phishing erkennen können. Trotz aller Filter wird immer mal was durchkommen (z. B. eine perfekt gefälschte Mail von einem Partner, dessen Account gehackt wurde – da helfen SPF/DKIM auch nicht, weil es echt vom Partner kam!). Schulungen, regelmäßige Hinweise („Klicken Sie nicht unbedacht auf Anhänge, melden Sie verdächtige Mails dem IT-Sicherheitsteam“) sind essentiell. Microsoft bietet auch einen „Report Message“ Button/Add-In an, mit dem Nutzer verdächtige Mails an Microsoft und interne Analysten melden können. Nutzen Sie solche Tools – sie binden den Menschen als Sensor ein.

4.5 Verschlüsselung und sichere Kommunikation

Abschließend der Hinweis: E-Mail-Authentifizierung schützt vor Identitätsbetrug, aber nicht vor unbefugtem Mitlesen. Wenn wir über „sichere E-Mail-Kommunikation“ sprechen, gehört auch Verschlüsselung der Inhalte dazu. In Microsoft 365 können Sie auf TLS vertrauen (Transportverschlüsselung zwischen Mailservern ist heute Standard und in EOP Pflicht, Mails werden fast immer verschlüsselt übertragen). Für echte Inhaltsverschlüsselung können Sie S/MIME oder Office 365 Message Encryption (OME) einsetzen, um E-Mails so zu verschlüsseln, dass nur der Empfänger sie lesen kann. Das ist allerdings ein eigenes Thema und würde den Rahmen sprengen. Wichtig ist: Unsere Authentifizierungsmaßnahmen (SPF/DKIM/DMARC) ergänzen sich mit Verschlüsselung – sie lösen ein anderes Problem. Perfekt ist Ihre Mail-Security, wenn Sie beides haben: Authentifizierung (dann wissen die Empfänger, die Mail ist echt von Ihnen) und Verschlüsselung (dann kann auch kein Unbefugter mitlesen).

Gerade für vertrauliche Inhalte oder verpflichtende Datenschutzvorgaben (Stichwort DSGVO: Versand personenbezogener Daten per Mail) sollten Sie über OME oder S/MIME nachdenken. Microsoft 365 bietet diese Möglichkeiten nativ an (z. B. Verschlüsselungsregeln, Sensitivity Labels etc.). Oft setzt man z. B. Transportregeln „wenn Betreff enthält #verschlüsseln, dann Verschlüsselung aktivieren“.

Für unseren Kontext belassen wir es dabei: Wissen Sie, dass verschlüsselte Mails nicht von Anti-Spam-Systemen gelesen werden können. Man muss hier eine Balance finden. Ein verschlüsselter Schädling im Anhang würde unerkannt bleiben – weshalb man nicht blind alles verschlüsseln sollte. Es ist immer eine Gratwanderung zwischen Sicherheit vor Angriff und Schutz der Vertraulichkeit.

Nun aber zurück zum Kernthema und der Umsetzung.

5. Umsetzung in Microsoft 365: Schritt-für-Schritt-Anleitung

Jetzt geht’s ans Eingemachte – wie setzen Sie all das konkret um? Keine Angst: Es ist durchaus machbar, und ich führe Sie in einer sinnvollen Reihenfolge durch die Schritte. Schnallen Sie sich an, hier kommt unsere Checkliste für die Implementierung:

Checkliste: Einführung von SPF, DKIM und DMARC in Microsoft 365

1. Bestandsaufnahme aller E-Mail-Quellen: Sammeln Sie, wer oder was alles E-Mails mit Ihrer Domain als Absender verschickt. Fragen Sie in die Runden der Admins/Abteilungen. Typische Punkte: Exchange (cloud/on-prem), Scanner/Printer, Anwendungen, externe Dienste (Newsletter, Monitoring, CRM). Nur was Sie kennen, können Sie autorisieren.
2. SPF-Eintrag prüfen und ergänzen: Schauen Sie im DNS nach dem TXT-Eintrag für SPF. Wenn keiner da ist: jetzt erstellen (z. B. im Format v=spf1 include:spf.protection.outlook.com -all für reinen O365 Einsatz). Wenn vorhanden: checken, ob alle identifizierten Mailquellen abgedeckt sind. Fügen Sie fehlende include: oder ip4: Einträge hinzu. Aber denken Sie ans 10-Lookup-Limit! Bei mehreren Einträgen eventuell Prioritäten setzen oder Subdomains nutzen. Stellen Sie sicher, dass nur ein SPF-Eintrag pro Domain existiert (manchmal tragen Leute zwei ein, das ist syntaktisch falsch – kombinieren Sie dann die Inhalte in einen).
3. SPF zunächst im Softfail-Modus belassen (falls unsicher): Falls Sie nicht 100% sicher sind, dass alle Quellen erfasst sind, lassen Sie ~all am Ende stehen. Das gibt etwas Puffer: Mails von nicht gelisteten Servern werden dann nur als „nicht sicher“ markiert statt komplett geblockt. Sobald Klarheit herrscht, kann man zu -all wechseln.
4. DKIM in Microsoft 365 aktivieren: Im Microsoft 365 Defender Portal (bzw. Security Center) navigieren Sie zu den DKIM-Einstellungen. Für jede Ihrer Domains (außer .onmicrosoft.com, das macht Microsoft automatisch) generieren Sie die DKIM-Einträge. Tragen Sie die zwei CNAMEs in Ihrem DNS-Portal ein. Warten Sie, bis die Einträge aktiv sind (mind. 1-2 Stunden). Dann zurück ins Portal und klicken Sie „Signaturen aktivieren“ für die Domain. Ergebnis überprüfen: Senden Sie z. B. eine E-Mail von dieser Domain an ein externes Postfach (Gmail etc.), schauen Sie im Header nach „DKIM-Signature“ und „d=ihredomain.de“. Wenn vorhanden -> Erfolg! (Es gibt auch Tools wie dkimvalidator oder MXToolbox DKIM Check*, wo Sie testweise hinsenden und Feedback kriegen, siehe unten Troubleshooting).
5. DKIM für On-Premises (falls nötig): Wenn Sie Hybrid mit direktem Versand haben, überlegen Sie, ob Sie eine On-Prem-Lösung brauchen. Evtl. können Sie sich das sparen durch Routen über die Cloud (siehe Szenario 2). Falls nicht: Planen Sie die Implementierung eines DKIM-Signers auf Ihrem Server. Testen Sie gründlich, da Dritttools im Spiel sind. Veröffentlichen Sie auch diese öffentlichen Schlüssel im DNS. (Für jede Domain/Subdomain, die on-prem signiert wird, entsprechend eigene Selector-Einträge.)
6. DMARC-Eintrag erstellen (Monitoring-Modus): Jetzt, da SPF und DKIM „da“ sind, ist Zeit für DMARC. Setzen Sie im DNS einen TXT-Record namens _dmarc.ihredomain.de. Inhalt zunächst: v=DMARC1; p=none; rua=mailto:dmarc-reports@ihredomain.de; ruf=mailto:dmarc-reports@ihredomain.de; fo=0; pct=100;. (Erklärung: p=none = keine Durchsetzung, nur Monitor. fo=0 = nur aggregierte Reports, keine Forensics; pct=100 = gilt für alle Mails.) Richten Sie das Postfach dmarc-reports@ ein oder leiten Sie es an jemanden, der die XML-Berichte auswertet. Alternativ tragen Sie als rua einen Reporting-Service ein (viele nutzen z. B. kostenlose Dienste, aber da landen Ihre Daten bei Dritten – aus Datenschutzsicht lieber selbst behalten oder geprüften Dienst).
7. Erste DMARC-Reports auswerten: Nach 24 Stunden sollten die ersten Rückmeldungen eintrudeln. Typischerweise senden große Mailanbieter (GMX, Gmail, Microsoft etc.) täglich Berichte. Analysieren Sie: Taucht dort irgendeine Quelle auf, die rot markiert ist (SPF/DKIM fail)? Ist das was Legitimes? Falls ja, handeln Sie: Nehmen Sie die Quelle in SPF auf oder richten Sie für sie DKIM ein. Oft sieht man überraschende Dinge – nutzen Sie die Chance, Ihr Bild zu komplettieren.
8. Feintuning anhand der Berichte: Passen Sie Ihre SPF-Einträge an, bis in den Berichten alle legitimen Mails SPF=Pass oder DKIM=Pass haben (idealerweise beides). Wenn nötig, sprechen Sie mit Abteilungen, dass Dienst X nicht mit persönlicher Absenderadresse, sondern mit einem service-Account senden soll (dann kann man SPF/DKIM besser in den Griff kriegen). Ziel: Klarheit, wer sendet und dass diese Auth erfüllt.
9. DMARC-Policy verschärfen – Quarantine: Nachdem ein paar Wochen alles rund läuft (je größer die Organisation, desto länger warten, mind. 2-4 Wochen, bei kleineren kann auch 1-2 Woche reichen), stellen Sie p=quarantine. Damit teilen Sie der Welt mit: „Wenn eine Mail meine DMARC-Prüfung nicht besteht, bitte als Spam markieren/quarantänisieren.“ Beobachten Sie wiederum einige Zeit. Idealerweise bemerken Ihre User gar nichts, außer dass vielleicht noch weniger Phishing ankommt. Schauen Sie in die Quarantäne/Spam-Reports in O365, ob vermehrt legitime Sachen hängenbleiben – sollte nicht, wenn Schritt 7/8 sauber war.
10. DMARC-Policy zu Reject erhöhen: Wenn Sie sich 100% sicher sind, dass nun alle legitimen Mails DMARC passieren, können Sie den letzten Schritt gehen: p=reject. Ab diesem Punkt weist z. B. Gmail eine Mail von Ihnen, die DMARC failt, sofort ab (SMTP 550 error). Das heißt, diese Mail kommt gar nicht in den Nutzerpostfächern an – maximal sieht der Absender einen Bounce. Damit ist Ihre Domain quasi „spoofing-immun“ gegenüber allen, die DMARC auswerten. Es wird weiterhin ein paar geben, die das nicht tun (einige kleinere Mailserver oder alte Systeme), aber alle großen und mittelgroßen respektieren es. Gratulation – Sie haben das Maximum an Schutz erreicht.
11. Betrieb etablieren: Ab jetzt heißt es: dranbleiben. Dokumentieren Sie die Einstellungen, so dass es im Team bekannt ist. Schulen Sie gegebenenfalls Helpdesk-Mitarbeiter, damit sie wissen: Bei Mail-Zustellproblemen immer auch DMARC/SPF im Blick haben. Richten Sie idealerweise eine automatische Auswertung der DMARC-Aggregate ein (es gibt Tools, die können die Berichte visualisieren, inkl. Open-Source-Tools). So sehen Sie trends oder neue Quellen sofort.
12. Weiterführende Verbesserungen: Überlegen Sie, ob Sie ARC in Ihrem Tenant aktivieren möchten (Microsoft macht das in Anti-Phishing Policies steuerbar: „Trust incoming ARC“ etc. – ist meist default an). Prüfen Sie, ob Sie BIMI einsetzen wollen – jetzt da DMARC policy streng ist, könnten Sie ein BIMI-Record veröffentlichen, um Ihr Logo anzuzeigen. Und: Werten Sie ruhig die Effekte aus – hat sich Spam/Phishing im Unternehmen reduziert? Häufig ja, insbesondere Spoof-Mails mit Ihrer eigenen Domain verschwinden fast vollständig.

Das war die Checkliste in Kurzform. Nun sind Realwelt-Projekte selten ganz so linear – man stolpert über Einzelprobleme. Deshalb im nächsten Abschnitt ein paar Hinweise zum laufenden Betrieb, Monitoring und Troubleshooting.

6. Betrieb, Monitoring und Troubleshooting

Die Implementierung mag abgeschlossen sein, aber Sicherheit ist kein Zustand, sondern ein Prozess. Hier erfahren Sie, wie Sie im Alltag mit SPF, DKIM, DMARC & Co. umgehen, Probleme lösen und die Übersicht behalten.

6.1 Kontinuierliches Monitoring (DMARC-Berichte und mehr)

Haben Sie DMARC-Berichte aktiviert, nutzen Sie diese auch fortlaufend! Anfangs schaut man täglich rein, später reicht vielleicht monatlich ein Check, ob neue unbekannte Absender auftauchen. Einige Unternehmen schicken die Berichte an einen speziellen Analyzer (es gibt kommerzielle wie Dmarcian, Barracuda, oder Community-Tools wie dmarc.pm, OpenDMARC, usw.). So ein Tool bereitet die XML-Dateien grafisch auf: man sieht Prozentwerte an authentifizierten vs. gefailten Mails pro Absender. Das kann Ihnen zeigen, ob z. B. eine bestimmte Mailquelle öfter Probleme hat.

Was könnte neu auftauchen? Beispielsweise ein neuer SaaS-Dienst, den jemand eingeführt hat, ohne Bescheid zu sagen (dann tauchen dessen Mails als DMARC-Fail auf – rotes Signal, um nachzufragen). Oder im schlimmsten Fall: Jemand misbraucht Ihre Domain. Tatsächlich, DMARC-Reports zeigen auch Mails, die von IPs kommen, die garantiert nichts mit Ihnen zu tun haben. Häufig sind das Spamwellen, wo Ihre Domain als Absender gefälscht wird. Wenn Sie p=reject haben, können Sie etwas entspannter sein, denn bei den meisten Empfängern fliegt der Kram eh in den Orkus. Dennoch interessant zu sehen, wer versucht, Sie zu spoofen – diese Informationen könnten auch ans CERT oder Behörden gemeldet werden, wenn es massiv ist. Aber meist sind das Botnets und die Anbieter (Google/Microsoft) blocken die eh.

Neben DMARC lohnt auch ein Blick in Exchange Online Reports: Im Security & Compliance Center gibt es Dashboards für Malwares, Spam, Phishing. Diese zeigen z. B. auch ausgehende Mails, die als Spam erkannt wurden – falls mal ein Account gekapert und Spam verschickt wurde, werden Sie es dort sehen (und Microsoft hat es idR geblockt). Setzen Sie ggf. Alarme, dass Sie proaktiv benachrichtigt werden.

6.2 Pflege der DNS-Einträge

Die DNS-Einträge für SPF, DKIM, DMARC sollten Sie bei Änderungen in Ihrer Umgebung anpassen:

• Neue Mail-Domäne? Neue Domain anschaffen und Mails darüber senden? Vergessen Sie nicht, SPF/DKIM/DMARC auch dort von Anfang an einzurichten. Sonst fangen Sie wieder bei Null an.
• Neuer Dienst oder externes System? Sobald IT oder Fachbereiche sagen „wir wollen Tool X nutzen, das Mails verschickt“, planen Sie SPF/DKIM dafür ein. Im Idealfall gibt es eine Policy: kein neuer Mailsender ohne Abstimmung mit IT-Security, um Auth einzurichten.
• Schlüsselmanagement: Microsoft wechselt die DKIM-Schlüssel im Hintergrund alle paar maanden/jahre automatisch nicht (es sei denn, Sie klicken manuell auf „rotate“ – das kann man tun, muss aber nicht dringend). Andere Systeme: Denken Sie dran, falls Sie z. B. einen eigenen DKIM-Signer auf On-Prem haben, dass Sie die Schlüssel regelmäßig rotieren (Empfehlung so alle 1-2 Jahre mindestens). Das heißt: neuen Schlüssel generieren, ins DNS, alten nach einiger Zeit raus. Bei Microsoft direkt wird das durch die CNAME zu MS managt – da passiert Rotation intern. Falls Sie die rotate-Funktion in O365 nutzen, beachten: Sie müssen nach Knopfdruck ~ 1 Tag warten, dann updated MS den DNS-Eintrag (bzw. den hinterlegten Key) automatisch. Theoretisch kann man’s tun, aber aus Erfahrung: Wenn ein Schlüssel kompromittiert wäre, würde Microsoft eh reagieren. Es ist aber kein Fehler, z. B. im jährlichen Security-Maintenance-Plan „DKIM-Rotation“ aufzunehmen.
• Anpassen der Policy bei False Positives: Sollten Sie feststellen, dass legitime Mails wegen DMARC geblockt werden (was nicht passieren sollte, wenn alles richtig gemacht ist), müssen Sie reagieren. Beispiel: Ein Partner leitet eine Mail weiter und Ihr DMARC reject killt sie auf dem Weg. Hier kann man überlegen, temporär eine Ausnahme zu machen: etwa eine Transportregel, die Mails von dieser Partnerdomain immer annimmt (Bypass Spam Filtering). Das ist aber mit Vorsicht zu genießen, um kein Loch zu reißen. Alternativ bittet man den Partner, die Weiterleitung anders zu konfigurieren (z. B. per Attachment forward, was DMARC-intakt bliebe).

6.3 Troubleshooting: Häufige Probleme und Lösungen

Hier eine kleine FAQ der Fehlerbilder aus meiner Praxis und wie man sie analysiert:

• „Meine E-Mails landen beim Empfänger im Spam.“ – Zunächst prüfen: Ist SPF ok? (z. B. mit online Tools oder einfach den Mailheader vom Empfänger geben lassen: Dort sollte stehen „Received-SPF: Pass“). Wenn SPF failt, Ursache beheben (IP nicht im SPF? SPF-Syntax kaputt?). Wenn SPF ok, liegt es evtl. an Inhalten oder Reputation. DKIM vorhanden? „Authentication-Results:“ im Header zeigen auch DKIM und DMARC Status bei vielen großen Providern. Möglicherweise war DMARC noch nicht auf reject, aber Empfänger hat Spamheuristik. In O365 kann man Nachrichtenkopf analysieren (im Security Center gibt’s einen Header Analyzer oder nutzen Sie externe wie mxtoolbox). Das zeigt oft, welcher Filter zugeschlagen hat.
• „Ich bekomme Bounces mit SPF Fail von bestimmten Empfängern.“ – Bounce-Nachricht anschauen. Steht da was wie „SPF check failed, domain owner discourages use of this host“? Dann versucht wahrscheinlich ein Mailserver streng -all durchzusetzen. Mögliche Ursachen: Sie haben -all in SPF, aber die Mail ging von einem nicht gelisteten Server. Oft bei Weiterleitungen oder beim ersten E-Mail an eine neue Mailingliste etc. Workaround: Wenn es ein einmaliger Fall ist (User hat Mail via fremden Server gesendet?), Absender korrigieren. Wenn strukturell (z. B. ein System benutzt falschen Weg), dort anpassen. SPF-Bounces sind Segen und Fluch – sie zeigen, dass was nicht stimmt, aber manchmal auch wegen trivialen Sachen (z. B. Kollege hat am Heim-PC alten SMTP-Relay benutzt).
• „DKIM lässt sich nicht aktivieren – Portal sagt ‚Einträge nicht gefunden‘.“ – Das passiert, wenn die CNAME-Einträge nicht richtig gesetzt sind oder der DNS noch nicht verbreitet ist. Prüfen Sie mittels nslookup oder einem Online-DNS-Checker: Gibt selector1._domainkey.ihredomain.de den richtigen CNAME zurück? Häufige Fehler: Tippfehler im Eintrag; Manche DNS-Anbieter verlangen keinen .ihredomain.de im Host-Feld (man trägt nur selector1._domainkey ein, weil Domain ohnehin klar ist). Oder die Einträge sind als TXT statt CNAME gesetzt (Microsoft erfordert CNAME). Lösung: Korrigieren und ein bisschen Geduld.
• „Empfänger sagt: Deine Mail war nicht zustellbar wegen DMARC.“ – Das heißt, Ihr DMARC (vermutlich auf reject) hat dafür gesorgt, dass die Mail abgelehnt wurde. Interessanterweise sind es ja die Empfänger, die das entscheiden basierend auf Ihrer Policy. Das passiert z. B. wenn Sie eine Mail an jemanden geschickt haben, der sie wiederum automatisch weiterleitet. In dem Fall sieht der eigentliche finale Empfänger die Mail von Ihrem Absender, aber kommend von einem fremden Forwarder-Server. DMARC Fail, Empfänger-Server lehnt ab. Hier kann man argumentieren: Das Problem liegt in der Forwarding-Konstruktion, und ARC wäre die Lösung, aber noch nicht alle nutzen ARC. Kurzfristig: Absender bekommt Bounce, soll Mail direkt schicken, nicht über Weiterleitung. Das sind Einzelfälle, muss man kommunikativ lösen. Über Zeit wird sich das verbessern, da ARC mehr Verbreitung findet.
• „Unser Scanner kann keine Emails mehr senden seit Umstellung.“ – Wie befürchtet: DMARC oder SPF blockt sie. Lösung hatten wir: Gerät entsprechend konfigurieren (SMTP Auth über O365) statt direkt. Also Troubleshooting = Config ändern, weniger ein „Fehler“ im Protokoll.
• „Zu viele DNS-Lookups in SPF – PermError.“ – Dies sieht man z. B. in DMARC Reports (dann steht dort SPF Result = PermError) oder via Tools. Hier muss man SPF optimieren: Evtl. überflüssige includes entfernen, oder schauen, ob man mehrere Dienste auf Subdomain auslagert. Es gibt auch Trick: statt include mit vielen unterincludes kann man die IPs direkt aufzählen, aber das ist mühsam und verliert Dynamik (wenn Dienst IP ändert, merkt man es nicht). Oft kann man z. B. include:spf.protection.outlook.com und include:spf.protection.outlook.de weglassen, wenn man weiß welche man braucht (die .de war für deutsche Cloud, die meisten brauchen nur .com). Oder wenn man z. B. mehrere Microsoft includes aus versehen drin hat – braucht nur einmal. So kann man unter 10 bleiben.
• „Jemand missbraucht unsere Domain, können wir da außer DMARC noch was tun?“ – Diese Frage kommt, wenn trotz DMARC auf reject immer noch Spam mit gefälschter Domain zirkuliert (zu altbackenen Mailservern z.B.). DMARC schützt, aber verhindert nicht das Versenden ansich – nur die Zustellung bei den Guten. Man kann den Versand bei der Quelle kaum stoppen (Außer rechtlich gegen Spammer vorgehen, unrealistisch). Was man tun kann: BIMI einsetzen, so dass bei seriösen Providern Ihr Markenlogo nur erscheint, wenn DMARC passt – das schreckt Phisher teilweise ab, weil ihre Mails so nackt aussehen. Und falls wirklich mal solch Spam durchgeht zum Empfänger, den Nutzer sensibilisieren, auf die kleinen Details zu achten (Headers, Schreibfehler etc.). Kurz: DMARC ist das stärkste Schwert, mehr geht technisch kaum, außer man würde gänzlich PGP/Signaturen für Inhalt durchsetzen (was aber im B2B nicht praktikabel ist aktuell).

Tool-Tipps: Nutzen Sie folgende kostenlose Tools in der Fehlersuche: – MXToolbox (SPF / DKIM / DMARC Check): Geben Sie Ihre Domain ein, es prüft ob DNS-Einträge korrekt sind. Bei DKIM können Sie dort einen Selector prüfen. – DKIMValidator: Schickt man eine Testmail hin, analysiert es SPF, DKIM, Spam-Score etc. Nützlich z.B. nach Einrichten von DKIM um zu checken. – Microsoft Remote Connectivity Analyzer: Hat u.a. einen Test für ausgehende E-Mails (validating email), zeigt DKIM/SPF Ergebnis aus Microsoft-Sicht. – Message Header Analyzer (Microsoft): Kopieren Sie den gesamten Header einer E-Mail dort rein, das Tool visualisiert die verschiedenen Felder incl. Auth Ergebnisse.

Zu guter Letzt: Dokumentieren Sie Ihre Einstellungen und Änderungen. Gerade bei DNS-Einträgen vergisst man nach Monaten leicht, warum etwas so gesetzt wurde. Halten Sie fest, welche Dienste im SPF enthalten sind, wo DKIM Keys liegen (und wer Zugriff hat) etc. Im Idealfall haben Sie eine kleine Architekturskizze „Mailflow“ – das hilft neuen Administratoren und im Troubleshooting.

Damit haben wir unser E-Mail-Haus nicht nur gebaut, sondern auch einen Putzplan aufgestellt. SPF, DKIM, DMARC laufen, wir wissen wie wir sie pflegen. Glückwunsch, der harte Teil ist geschafft!

7. Glossar – Wichtige Begriffe rund um E-Mail-Sicherheit

Zum Schluss ein kompaktes Glossar mit den wichtigsten Fachbegriffen aus diesem Leitfaden. Falls Ihnen ein Begriff begegnet, den Sie nicht direkt einordnen können, finden Sie hier eine kurze Erklärung in Klartext:

• Absenderdomain: Die Domain (Firmenname.de) im From-Absender der E-Mail. Diese steht sichtbar für den Empfänger. Unsere Authentifizierungsverfahren zielen darauf ab, sicherzustellen, dass nur berechtigte Server unter dieser Domain Mails senden.
• Alignment (Ausrichtung): In DMARC der Begriff dafür, dass zwei Domains übereinstimmen. SPF-Alignment meint: die MAIL FROM Domain = From-Domain. DKIM-Alignment: die DKIM-signierende Domain = From-Domain. Nur dann gilt es als „aligned“ (bei relaxed darf es Subdomain sein).
• ARC (Authenticated Received Chain): Ein Verfahren, das die Authentifizierungsinformationen einer Mail bei Weiterleitungen mitnimmt. Vertrauenswürdige weiterleitende Server fügen eine ARC-Signatur hinzu, sodass der Endempfänger nachvollziehen kann, dass die Mail ursprünglich ok war, auch wenn SPF/DKIM durch die Weiterleitung kaputt gingen.
• BEC (Business Email Compromise): Eine Betrugsmasche, bei der Angreifer per E-Mail versuchen, Mitarbeiter zu täuschen, um Geld oder Daten zu ergaunern. Häufig durch gefälschte Absender (z. B. „Chef fordert Überweisung“). DMARC hilft, BEC durch Spoofing der eigenen Domain zu verhindern.
• DNS (Domain Name System): Das Internet-Telefonbuch, das Domainnamen in IP-Adressen auflöst. Wir nutzen DNS auch, um spezielle Text-Einträge zu veröffentlichen (SPF, DKIM, DMARC Records). Änderungen im DNS verbreiten sich mit geringer Verzögerung (TTL) weltweit.
• DNS TXT-Record: Ein frei gestaltbarer Texteintag im DNS. SPF und DMARC sind als solche TXT-Einträge realisiert. Beispiel eines TXT-Records: _dmarc.firma.de -> „v=DMARC1; p=none; …“. DKIM-Schlüssel können ebenfalls als TXT vorliegen (bei Microsoft aber als CNAME auf deren Records).
• Exchange Online Protection (EOP): Microsofts integrierter Basisschutz für E-Mails in Office 365. Filtert Spam, Viren, prüft SPF/DKIM, blockiert bekannte Phishing-Mails. EOP ist für alle Exchange Online-Kunden aktiv, unabhängig von zusätzlichem Defender.
• Forensic Report (DMARC): Ein detaillierter Fehlbericht (auch Failure Report genannt), der bei DMARC-Verletzungen direkt eine Kopie der betreffenden Mail oder Header enthält. Aus Datenschutzgründen sind diese oft deaktiviert oder stark eingeschränkt; kaum ein Provider sendet noch Forensics by default.
• Forwarding (Weiterleitung): Automatisches Weiterleiten einer E-Mail von A nach B. Problematisch bei DMARC, weil der weiterleitende Server zum „neuen Absender“ wird, aber die ursprüngliche From-Domain beibehält. Ohne ARC führt das meist zu DMARC-Fail beim Endziel.
• IMAP/POP/SMTP Auth.: Protokolle zum E-Mail-Abruf (IMAP/POP) bzw. Versand (SMTP). In Microsoft 365 sind modernere Auth-Mechanismen (OAuth) Standard, Basic Auth (Benutzer+PW) wird größtenteils abgeklemmt. Für SMTP gibt es noch Ausnahmen, z. B. bei Gerätenutzung (SMTP Auth can be enabled per mailbox).
• Microsoft Defender for Office 365: Erweiterter E-Mail-Schutz (Plan 1/2) mit Features wie Safe Links, Safe Attachments, Anti-Phishing-Policen, Attack Simulator etc. Ehemals ATP. Ergänzt EOP um proaktive und intelligente Filter gegen gezielte Angriffe.
• Phishing: Der Versuch, per gefälschter E-Mail (oder Webseite) an vertrauliche Informationen zu kommen (Passwörter, Bankdaten) oder Nutzer zu Aktionen zu verleiten (z. B. Überweisung). Oft über Social Engineering und Absender-Spoofing. SPF/DKIM/DMARC adressieren vor allem das Absender-Spoofing.
• Quarantäne: Bereich, in den E-Mails vom System verschoben werden, die verdächtig oder unerwünscht sind. In Exchange Online gibt es z. B. die „Quarantäne“, wo Admins/Benutzer blockierte Mails einsehen und ggf. freigeben können. DMARC p=quarantine bewirkt typischerweise, dass Mails als Spam einsortiert (Junk-Ordner) oder in die Quarantäne gestellt werden.
• Return-Path: Die Envelope-Absenderadresse, die für die technische Zustellung und Bounces verwendet wird. Sichtbar im E-Mail-Header als Return-Path: <…>. SPF prüft gegen diese Adresse. Sie kann sich von der From:-Adresse unterscheiden und tut es oft (bei Mailinglisten, Newslettern etc.).
• Selector (DKIM): Ein frei wählbarer Bezeichner, der beim DKIM-Schlüsselpaar genutzt wird, um mehrere Schlüssel pro Domain unterscheiden zu können. Steht im DKIM-Header (s=). In DNS wird der Selector als Präfix vor ._domainkey genutzt. Microsoft nutzt standardmäßig „selector1“ und „selector2“ für zwei parallel gültige Schlüssel.
• SMTP (Simple Mail Transfer Protocol): Das grundlegende Protokoll zum Übertragen von E-Mails zwischen Servern. SMTP selbst kennt keine Absenderauthentifizierung – daher brauchen wir SPF/DKIM als aufgesetzte Lösungen.
• Spam: Unerwünschte Massen-E-Mails (Werbung, Betrug etc.). Spam-Filter (wie EOP) versuchen Spam automatisch zu erkennen und auszuselektieren. SPF/DKIM/DMARC helfen Spam einzudämmen, aber Spam kann auch von „echten“ Absendern kommen (gehackte Accounts z.B.), daher bleibt klassische Inhaltsfilterung weiter wichtig.
• Spoofing: Das Fälschen des Absenders einer Nachricht. Bei E-Mail bezieht es sich meist auf die Absenderadresse/Domain. Ziel ist, dass die Mail von einer vertrauenswürdigen Quelle zu kommen scheint. SPF/DKIM/DMARC sind explizit dafür da, Spoofing schwer bzw. sinnlos zu machen.
• TLS (Transport Layer Security): Verschlüsselungsschicht, die bei der Übertragung von E-Mails zwischen Servern zum Einsatz kommt (STARTTLS in SMTP). Gewährleistet, dass der Transportweg abhörsicher ist. Wird von den meisten Mailservern automatisch genutzt. Microsoft EOP erzwingt TLS zu bekannten Domains und bietet „TLS-Verschlüsselungsregeln“ an, um z. B. für bestimmte Partner stets TLS zu verlangen.
• Transportregel (Mailflow Rule): Eine vom Exchange-Admin definierte Regel, die E-Mails beim Ein- oder Ausgehen anhand von Kriterien filtert/manipuliert. Ermöglicht z. B. das Hinzufügen von Fußzeilen, Blockieren bestimmter Inhalte, automatische Klassifizierung, Weiterleitungen, Benachrichtigungen etc. Gutes Mittel für individuelle Policen.
• TXT-Record: Siehe DNS TXT-Record oben – wird oft einfach als „TXT-Eintrag“ bezeichnet. Darin können SPF oder DMARC Informationen stehen, aber auch andere Sachen (z. B. Microsoft verifiziert Domainbesitz via TXT-Eintrag).
• Zentraler Mailfluss (Centralized Mailflow): Im Hybrid-Setup die Konfiguration, dass alle Mails – auch von Cloud-Postfächern – erst on-premises gehen und von dort raus, oder umgekehrt. In Kontext SPF: Wenn zentral über EOP geschickt, vereinfacht es SPF (nur MS IPs), wenn umgekehrt (erst zu on-prem) dann muss On-Prem IP in SPF etc. Diese Strategie beeinflusst Auth.

Dieses Glossar deckt die häufigsten Begriffe ab, die im Zusammenhang mit E-Mail-Sicherheit und unseren Authentifizierungsverfahren vorkommen. Damit sollten Abkürzungen wie DMARC, DKIM & Co. keine böhmischen Dörfer mehr sein.

8. FAQ – Häufige Fragen aus der Praxis

Zum Abschluss noch ein FAQ mit häufig gestellten Fragen (und Antworten), die erfahrungsgemäß im Zusammenhang mit der Einführung und Nutzung von SPF, DKIM und DMARC in Microsoft 365 auftauchen:

Frage 1: „Brauche ich wirklich alle drei – SPF, DKIM und DMARC? Reicht nicht eines davon, um sicher zu sein?“
Antwort: SPF und DKIM einzeln sind hilfreich, aber erst DMARC verbindet beide und schafft verbindliche Regeln. Nur SPF würde z. B. nicht schützen, wenn der Absender im Mail-From anders ist als im sichtbaren From. Nur DKIM hilft nicht, wenn ein Angreifer Ihre Domain ohne DKIM-Signatur missbraucht – Empfänger ohne DMARC würden es evtl. trotzdem annehmen. Fazit: Die drei im Verbund bieten den besten Schutz. Man kann mit SPF anfangen, dann DKIM ergänzen, aber ohne DMARC haben Sie keine Steuerungsmöglichkeit, was beim Empfänger passiert.

Frage 2: „Wir nutzen nur Microsoft 365 und keine anderen Mailserver. Ist es dann einfacher?“
Antwort: Ja, ein reines Cloud-Setup ist vergleichsweise einfach. Microsoft gibt Ihnen den richtigen SPF-Eintrag vor, DKIM ist ein paar Klicks mit DNS-Einträgen, und DMARC können Sie stringent durchziehen, da es keine abweichenden Senderquellen gibt. Trotzdem die Schritte einhalten und sauber testen, aber Sie haben weniger Variablen – insofern: Cloud-only ist dankbar.

Frage 3: „Was ist, wenn ein externer Partner keine DMARC/​DKIM hat – können deren Mails an uns dann Probleme machen?“
Antwort: Ihre eigenen Einstellungen (SPF/DKIM) betreffen Mails, die Sie versenden. Für eingehende Mails von Partnern gilt: Ihr Exchange Online (EOP) prüft deren SPF/DKIM/DMARC, aber selbst wenn die nichts davon haben, kommen die Mails in der Regel trotzdem an – EOP bewertet sie dann halt ggf. als Spam, wenn andere Faktoren schlecht sind. Ihr Setup hindert Sie also nicht am Empfangen von Mails von jemand ohne Auth. Allerdings: Wenn Sie in EOP die Policy streng einstellen („Reject DMARC Fail“), dann lehnen Sie Mails ab, deren Absenderdomain p=reject hat und Fail ist. Hat Ihr Partner aber gar keinen DMARC, greift diese Sonderbehandlung nicht, EOP wendet seine generischen Filter an. Kurz: Ihr ausgehendes DMARC hindert nicht das Eintreffen fremder Mails.

Frage 4: „Unsere Marketingabteilung will einen neuen Newsletter-Dienst nutzen, der aber Mails als @firma.de rausschickt. Worauf müssen wir achten?“
Antwort: Binden Sie die IT unbedingt ein. Sie müssen SPF erweitern (um den Anbieter) und DKIM für den Anbieter einrichten, sofern möglich. Fragen Sie den Dienst: „Können wir unsere Domain authentifizieren?“. Meist gibt es einen DKIM-Schlüssel zum Eintragen und einen SPF include. Testen Sie dann unbedingt, am besten bevor der große Newsletter an alle Kunden geht. Oder nutzen Sie alternativ eine Subdomain für den Newsletter – dann bleibt Ihre Hauptdomain-Konfiguration unberührt und Sie richten für die Subdomain eigene Einträge ein.

Frage 5: „Wie kann ich überprüfen, ob unsere SPF/DKIM/DMARC richtig funktionieren?“
Antwort: Mehrere Möglichkeiten:
– Online-Tools (wie MXToolbox, dmarcian’s tester etc.) für einen groben Check der DNS-Einträge.
– Einen Test-Newsletter oder Testmails an private Accounts senden (Gmail, GMX) und dort in den Header schauen: Steht da „spf=pass“, „dmarc=pass“? Gmail z.B. zeigt Details unter „Original anzeigen“.
– Spezielle Checker: Senden Sie eine Mail an check-auth@verifier.port25.com (gibt es noch als Community-Tool) oder nutzen Sie den DKIM-Validator-Webdienst – die liefern einen Report zurück.
– Und natürlich: DMARC-Berichte sind die langfristige Kontrolle, da sie genau sagen, was Empfänger sehen.

Frage 6: „Was bedeutet p=none genau? Ignorieren Empfänger dann meine DMARC-Info komplett?“
Antwort: p=none heißt: „Bitte wertet SPF/DKIM aus und berichtet, aber ich gebe keine Anweisung, streng zu handeln.“ Empfänger, die DMARC unterstützen, schauen trotzdem nach Alignment und führen eine Art „virtuellen“ DMARC-Check durch. Sie liefern Report an Sie, aber beim Mailrouting behandeln sie die Mail wie ohne DMARC-Policy, es sei denn ihre eigenen Spamfilter greifen. Manche Mailprovider markieren solche Mails ggf. als unsicher (z. B. Gmail zeigt manchmal an „Absender konnte nicht verifiziert werden“ mit einem Fragezeichen-Avatar, wenn DMARC none und die Mail failt). Also ganz ignoriert wird es nicht immer – es kann Einfluss auf die Spamwertung haben – aber keine harten Aktionen. p=none ist ideal zum Starten und Beobachten.

Frage 7: „Was passiert mit Weiterleitungen bei DMARC? Unsere Mitarbeiter leiten teilweise Mails an private Postfächer weiter.“
Antwort: Weiterleitungen sind das bekannte Problem bei DMARC. Wenn ein Mitarbeiter seine @firma.de Mails an @gmail.com weiterleitet, passieren zwei Dinge: a) Ausgehende Mail vom Firmenserver an Gmail – wird normal zugestellt; b) Gmail sieht eine Mail, die angeblich von Absender X (@externedomain), aber via Ihrem Firmenserver kam – Ihr Server steht vielleicht nicht im SPF der externen Domain. Ergebnis: DMARC von X könnte failen. Das betrifft also eher die Absenderdomain X, nicht Ihre. Umgekehrt, wenn jemand von intern z.B. seine Mails an extern weiterleitet, könnte eine Mail von Chef@firma.de -> Kollege@firma.de -> weiter an extern, beim externen Empfänger als DMARC fail enden, weil Absender firma.de, aber weitergeleitet durch Kollege’s externe Adresse. Klingt komplex – ist es auch. Deshalb gibt es ARC, das Gmail und O365 unterstützen. Kurz: Weiterleitungen können legitime Mails blocken, wenn DMARC strikt ist und der Empfangsserver keine ARC-Infos berücksichtigt. Leider kann der Endnutzer hier wenig tun, außer diese Auto-Forwards möglichst zu vermeiden oder alternative Methoden (Outlook-Regel „als Anhang weiterleiten“ statt direkt weiterleiten, das erhält Originalheader). In der Praxis sind Auto-Forwards oft aus Sicherheitsgründen ohnehin untersagt. Wenn nicht, muss man das Risiko akzeptieren oder mitigieren (ARC auf Empfängerseite oder ausnahmsweise p=quarantine statt reject – aber das schwächt den Schutz).

Frage 8: „Sollte ich p=quarantine lassen oder unbedingt auf p=reject gehen bei DMARC?“
Antwort: Langfristig ist reject das Ziel – nur dann haben Sie maximale Wirkung, dass Fakes geblockt werden. quarantine ist ein guter Zwischen- oder Kompromisszustand, falls Sie Restzweifel haben. Einige Organisationen belassen es auf quarantine, damit im Worst Case eine Mail im Spam landet statt komplett weg. Aber viele große Domains (Microsoft, Gov-Domains etc.) stehen auf reject ohne Probleme. Ich empfehle: erst auf quarantine, einige Zeit beobachten, dann auf reject und gut. Den Unterschied merkt man vor allem als Empfänger: bei reject kommt nichts ins Postfach, bei quarantine evtl. im Junk. Für Ihren Schutz nach außen ist reject konsequenter.

Frage 9: „Kostet uns das etwas extra in Microsoft 365? Brauchen wir eine bestimmte Lizenz für diese Funktionen?“
Antwort: Die Einrichtung von SPF, DKIM, DMARC kostet nichts extra. SPF/DKIM sind Standardfunktionen (DKIM im Security Center ist auch für alle Pläne verfügbar). DMARC ist ja nur DNS – also frei. Exchange Online Protection haben Sie automatisch mit jedem Exchange Online Postfach (also jedem Business/Enterprise Plan). Defender for Office 365 (Safe Links, etc.) wäre eine Extra-Lizenz (entweder E5 inkl. oder als Add-on zu E3/Business). Aber das Kernthema Authentifizierung können Sie mit einem ganz normalen Office 365 Tenant umsetzen, egal ob Business Basic oder E3.

Frage 10: „Wir haben noch alte On-Premises-Systeme. Kann DMARC da überhaupt was ausrichten?“
Antwort: DMARC wirkt auf Empfängerseite. Wenn Sie z. B. einen alten Exchange 2010 haben, können Sie trotzdem DMARC für Ihre Domain publizieren – die Empfänger werten das aus. Wichtig ist, dass Sie die technischen Voraussetzungen schaffen (SPF-Eintrag, DKIM-Signatur – letzteres könnte ohne Drittsoftware auf Exchange 2010 schwierig sein). Notfalls könnte man auch ohne DKIM arbeiten, nur mit SPF+DMARC, wenn man SPF überall enforced kriegt. Heimvorteil: Wenn Ihre Empfänger auch in Ihrer Kontrolle sind (z. B. Kommunikation nur Partner mit definierter Infrastruktur), dann kann man sogar ohne Cloud DMARC “leben”. Aber heute mischt sich eh alles, und Ihre Mails gehen zu Gmail & Co – da lohnt es sich auf jeden Fall. Die meiste Arbeit (DNS Einträge) ist unabhängig von lokal oder Cloud. Für On-Prem muss man lediglich Tools nachrüsten für DKIM-Signaturen. Viele entscheiden sich bei so einem Projekt sogar, den Mailversand komplett über O365 laufen zu lassen (Hybrid Outbound), selbst wenn sie On-Prem halten – weil es die Auth einfacher macht.

Frage 11: „Was, wenn wir mal den E-Mail-Anbieter wechseln? Müssen wir alles neu machen?“
Antwort: Nehmen wir an, Sie wechseln von Microsoft 365 zu einem anderen Hoster – dann ändern sich die Details, aber die DNS-Einträge bleiben unter Ihrer Kontrolle. Sie müssten dann den SPF-Eintrag anpassen (neuer Anbieter -> anderer include oder IPs), Sie würden neue DKIM-Keys vom neuen Anbieter bekommen (alte aus MS kann man löschen) und DMARC bleibt im Prinzip gleich (vielleicht die rua-Adresse ändern, falls Berichte woanders hin sollen). Es ist also portierbar, solange Sie die Domain behalten. Wichtig: Koordinieren Sie das beim Umzug, damit nicht in der Übergangsphase Mails abgewiesen werden. Aber es ist gut machbar – Auth ist heute Standard, jeder Mailprovider bietet die Möglichkeiten.

Frage 12: „Können wir Berichte auch bekommen, wer alles uns Mails geschickt hat (Inbound)?“
Antwort: Die DMARC-Aggregate geben Auskunft über Mails, die Ihre Domain als Absender genutzt haben. Das ist immer Outbound-Perspektive. Für eingehende Mails kriegen Sie solche Berichte nicht von DMARC. Aber Microsoft 365 bietet im Security Center sehr wohl Message Trace und Reports an: Sie können nach Absender/Empfänger filtern, sehen Zustellstatus etc. Und es gibt eine Funktion „Mailflow Dashboard“ für Admins mit Top-Sendern, Top-Empfängern usw. Das ist aber in Tenant-intern. Externe Absender, die keine DMARC haben, können Ihnen keine ähnlichen Reports liefern. DMARC ist immer von Senderdomain gesteuert. Allerdings: Einige große Organisationen fordern von Partnern, DMARC einzusetzen – so kommt man sich gegenseitig entgegen.

Frage 13: „Unsere Geschäftsführung fragt, ob wir damit DSGVO/Compliance gerecht werden – was soll ich antworten?“
Antwort: SPF/DKIM/DMARC an sich sind Best Practices zur IT-Sicherheit und werden von diversen Stellen (BSI, Bundesamt für Sicherheit, und auch EU NIS2 Richtlinie indirekt) empfohlen. Es gibt (soweit ich weiß) keine gesetzliche Pflicht dazu, aber im Rahmen der Sorgfaltspflicht und ISO27001 etc. sind solche Maßnahmen absolut positiv. Sie schützen auch personenbezogene Daten indirekt, weil weniger Phishing bedeutet weniger Risiko für Datenabfluss. Man kann also sagen: Ja, es erhöht die Compliance, indem es Sicherheit erhöht und empfohlenen Standards entspricht. Und DMARC-Reports enthalten kaum personenbezogene Daten (nur Statistiken), DSGVO-Themen tangieren die nicht kritisch – trotzdem evtl. erwähnen: Berichte gehen auch an US-Mailprovider (Google, MS schicken von US-Servern oft), das nur als Note, aber sie enthalten keine inhaltlichen Daten.

Frage 14: „Beeinflusst das unsere E-Mail-Performance oder -Geschwindigkeit?“
Antwort: Kaum. Die Prüfungen SPF/DKIM finden beim Empfänger statt, für Sie als Sender macht Ihr Mailserver minimal mehr (DKIM signieren kostet CPU, aber vernachlässigbar gering). Microsofts Server verkraften das locker. Beim Empfänger fügt es ein paar DNS-Lookups und kryptografische Prüfungen hinzu – alles in Millisekundenbereichen. Die Verzögerung ist nicht spürbar. Selbst DMARC mit Reporting ist nur ein DNS-Lookup plus ggf. am Tagesende ein Report zusammensammeln. Also: Nein, Ihr Mailversand und -empfang bleibt quasi so schnell wie vorher. Was schneller geht: legitime Mails kommen evtl. häufiger direkt in den Posteingang durch, da Absenderauth vorhanden -> das könnte die Zustellzeit indirekt verbessern.

Frage 15: „Können wir das alles auch wieder rückgängig machen, falls es Probleme gibt?“
Antwort: Im Notfall, ja. SPF-Eintrag kann man ändern oder löschen (würde ich aber nie empfehlen zu löschen – lieber weit offen lassen als ganz weg). DKIM kann man deaktivieren (Knopf im Portal) und die DNS-Einträge entfernen. DMARC kann man von reject wieder auf none stellen oder entfernen. Die Änderungen im DNS greifen i.d.R. in Minuten bis Stunden. Aber: Überlegen Sie warum rückgängig? Wenn schlimm was schief läuft, kann man temporär DMARC auf none setzen, um die Last runterzunehmen. Doch normalerweise, wenn sauber implementiert, gibt es keinen Grund zurückzugehen. Ich hatte noch keinen Fall, wo wir DMARC wieder abgeschafft haben – eher wächst die Reife und keiner will zurück in die unsichere Welt. Dennoch ist es gut zu wissen, dass Sie die Kontrolle haben; es ist kein unumkehrbarer Schritt.

Sie sehen, die meisten Fragen lassen sich beruhigend beantworten: Mit Planung und schrittweisem Vorgehen sind SPF, DKIM und DMARC beherrschbar. Viele Bedenken („brechen wir uns was?“, „geht dann X noch?“) lösen sich in Luft auf, sobald man es mal testweise aktiviert und die Reports studiert. Wichtig ist, die Kollegen und die Organisation mitzunehmen – dann wird E-Mail-Sicherheit zum gemeinsamen Projekt und nicht zum Hindernis.

9. Mein Beratungsangebot: E-Mail-Sicherheit in drei Paketen

Die Umsetzung von SPF, DKIM, DMARC und all den flankierenden Maßnahmen kann komplex wirken – muss sie aber nicht sein. Wenn Sie dennoch feststellen, dass Ihnen die Ressourcen oder das Spezialwissen fehlen, helfe ich Ihnen gerne persönlich weiter. Als Ulrich B. Boddenberg, IT-Berater mit langjähriger Erfahrung, biete ich maßgeschneiderte Beratungspakete an, um Ihre E-Mail-Kommunikation mit Microsoft 365 sicher aufzusetzen. Wichtig: Ich führe alle Leistungen selbst durch – keine Weitergabe an anonyme Teams, kein „Managed Service“, sondern punktuelle, persönliche Beratung und Umsetzung. So stelle ich sicher, dass Sie und Ihr Team genau verstehen, was getan wurde, und die Kontrolle behalten.

Ich habe drei Pakete geschnürt, um unterschiedlichen Bedürfnissen gerecht zu werden:

Paket „Starter“

Ideal für kleinere Unternehmen oder solche, die gerade erst beginnen, sich mit E-Mail-Authentifizierung zu befassen. Im Starter-Paket führe ich einen Quick-Check und die Basiskonfiguration durch:

• Analyse Ihrer bestehenden DNS-Einträge und Mailstruktur (Cloud/On-Prem).
• Einrichtung oder Korrektur des SPF-Eintrags für bis zu 1 Domain.
• Aktivierung von DKIM für Ihre Domain in Microsoft 365.
• Einrichtung eines DMARC-Records mit p=none (Monitoring) und Erklärung, wie Sie Reports erhalten.
• Kurze Schulung (hands-on während des Tages) für Ihre Admins: Was bedeuten die Einstellungen, wie weiter vorgehen.
• Dauer: ca. 2 Tage (typischerweise 1 Tag Analyse/Umsetzung, 1 Tag Puffer für Tests & Nachjustierung).
• Ergebnis: Sofortiger Grundschutz – Ihre E-Mails sind korrekt authentifiziert und Sie bekommen erste Einblicke durch DMARC-Berichte. Ein einfacher Maßnahmenplan für die nächsten Schritte liegt vor.

Paket „Professional“

Für mittelständische Unternehmen oder komplexere Umgebungen (z. B. Hybrid, mehrere Mail-Quellen). Das Professional-Paket umfasst eine umfassende Implementierung und Optimierung:

• Workshop zu Beginn: Aufnahme aller Mail-Szenarien, Ziele definieren (z. B. DMARC innerhalb 8 Wochen auf reject).
• SPF-Setup für mehrere Domains oder komplizierte SPF-Situationen (inkl. Drittanbieter-Integration, Aufsplittung Subdomains falls nötig).
• Vollständige DKIM-Konfiguration für alle genutzten Domains, inkl. Unterstützung bei evtl. On-Prem DKIM Lösungen.
• Stufenweise DMARC-Einführung: von Monitoring bis zur definierten Ziel-Policy. Ich begleite Sie beim Auswerten der Berichte und justiere die Einstellungen.
• Einrichtung von Anti-Phishing- und Spoofing-Schutz-Features in Microsoft 365 (EOP/Defender) auf Best-Practice-Niveau: z. B. Anti-Imperso­nation-Policy, Spamfilter-Tuning, ggf. Transportregeln für externe Markierungen.
• Guideline-Dokumentation: Sie erhalten eine Doku der vorgenommenen Änderungen und Richtlinienempfehlungen (z. B. Umgang mit neuen Diensten, Monitoring-Plan).
• Dauer: ca. 5 Tage netto, verteilt auf mehrere Wochen nach Bedarf (z. B. 3 Tage initial, später 2 Tage für Feinschliff und Workshops).
• Ergebnis: Rundum geschützte Mailumgebung – authentifizierte Mails, deutlich reduziertes Spoofing/Phishing-Risiko, informierte IT-Mannschaft. Ihre Domain wird bei Partnern und Kunden als verlässlich und sicher wahrgenommen (und landet weniger im Spam).

Paket „Enterprise & Compliance“

Für große Organisationen, Konzerne oder besonders regulierte Branchen (Banken, Healthcare, Behörden), die höchste Ansprüche an Sicherheit und Nachweisbarkeit haben. Dieses Paket ist ein komplettes Projekt inkl. Compliance-Beratung:

• Tiefgehende Analyse der bestehenden Infrastruktur, inkl. evtl. Audit vorhandener Policies, Compliance-Vorgaben (DSGVO, NIS2, ISO27001 Anforderungen).
• Entwicklung einer maßgeschneiderten E-Mail-Sicherheitsstrategie: neben SPF/DKIM/DMARC auch Betrachtung von Verschlüsselung (S/MIME, OME), DLP-Regeln, Archivierung falls relevant.
• Umsetzung SPF/DKIM/DMARC für beliebig viele Domains, inkl. Sonderfälle (z. B. viele Drittanbieter, Partner-Schnittstellen). Koordination mit Ihren DNS-Verantwortlichen und Drittanbietern.
• Erweiterte Konfiguration von Microsoft 365 Defender: z. B. Szenarien für VIP-Protection, Tagging externer Mails, SIEM-Integration (Security Information Event Management) für Mail-Logs.
• Erstellen von Compliance-Dokumentation: Richtlinien-Dokument, Konzepte, Benutzerkommunikation (z. B. Infoblatt an Mitarbeiter, warum Mails jetzt ein Banner tragen). Schulungsmaterial für Helpdesk/Security-Team.
• Begleitung des Change-Managements: Ich unterstütze bei der Kommunikation an Stakeholder, ggf. Präsentation vor Management zu den erzielten Verbesserungen.
• Dauer: 10+ Tage (je nach Umfang; oft als 2-wöchiges Projekt anberaumt oder über einen Monat verteilt). Flexibilität für Abstimmungsrunden mit Compliance/​Datenschutzbeauftragten eingeplant.
• Ergebnis: Enterprise-grade E-Mail-Sicherheit, auditierbar und abgestimmt mit Ihren Compliance-Vorgaben. Sie erhalten alle Unterlagen, um bei Prüfungen darzulegen, welche Schutzmaßnahmen implementiert sind. Zudem sind Ihre Anwender sensibilisiert und die IT hat klar definierte Prozesse zum Betrieb und zur Wartung der E-Mail-Sicherheit.

Alle Pakete sind so gestaltet, dass Sie am Ende selbst handlungsfähig sind. Ich verlasse nicht einfach die Baustelle, sondern sorge dafür, dass Ihr Team versteht, was umgesetzt wurde und wie man es weiter pflegt. Und natürlich stehe ich auch nach Abschluss für Rückfragen zur Verfügung.

Tagessatz & Konditionen: Mein Tagessatz beträgt 1.500 € (zzgl. MwSt.). Reise- und Übernachtungskosten werden separat nach Aufwand berechnet (wir stimmen das vorher ab – oft lässt sich vieles auch remote erledigen, um Kosten zu sparen). Bei den genannten Paketen können Sie also die Investition grob kalkulieren: Starter ~2 Tage = 3.000 €, Professional ~5 Tage = 7.500 €, Enterprise entsprechend. Mir ist Transparenz wichtig: Sie kaufen kein Blackbox-Produkt, sondern Beratungszeit und Expertise.

Nachfolgend eine Vergleichstabelle der drei Pakete, um auf einen Blick Zielgruppe, Umfang, Dauer und Ergebnis gegenüberzustellen:

Paket	Zielgruppe (für wen?)	Umfang & Leistungen	Dauer	Ergebnis / Benefit
Starter	Kleine Unternehmen, unkomplizierte Umgebung (Microsoft 365 allein)	– SPF, DKIM, DMARC Basis-Einrichtung<br>– 1 Domain<br>– Kurze Admin-Einweisung	ca. 2 Tage	Grundlegende Absicherung sofort wirksam; IT kann DMARC-Berichte lesen und hat Fahrplan
Professional	Mittelstand, mehrere Mail-Quellen oder Hybrid-Einsatz	– Umfassende Implementierung für bis zu ~5 Domains<br>– Integration von Drittservices<br>– Defender/Transport-Regeln Feintuning<br>– Doku & Admin-Workshop	ca. 5 Tage	Rundum geschützte Mailumgebung; deutlich weniger Spam/Phishing; Team ist geschult und Prozesse definiert
Enterprise & Compliance	Große Organisationen, regulierte Branchen mit Compliance-Fokus	– Projekt inkl. Strategie & Policy-Erstellung<br>– Umsetzung für viele Domains & komplexe Szenarien<br>– Einbindung in Compliance (Berichte, DLP, Archiv)<br>– Schulungsmaterial & Management-Berichte	ca. 10+ Tage (nach Bedarf)	Maximale E-Mail-Sicherheit & Compliance-Nachweis; nachhaltiges Konzept, audit-sicher; Mitarbeiter sensibilisiert, Management buy-in erzielt

(Die genannten Tage beziehen sich auf Berater-Tage. Termine und genaue Inhalte werden individuell abgesprochen – ich richte mich nach Ihrem konkreten Bedarf.)

Sie können natürlich auch erst mit dem Starter beginnen und bei Bedarf upgraden – je nach Entwicklung Ihrer Anforderungen. Wichtig ist: Ihr Mehrwert steht im Vordergrund. Sie sollen sich nachher darauf verlassen können, dass Ihre E-Mails sicher sind, und verstehen, was dafür getan wurde.

Interessiert? Dann nehmen Sie gerne Kontakt mit mir auf (Kontaktinfos finden Sie auf meiner Website). Gemeinsam machen wir Ihre E-Mail-Kommunikation fit gegen aktuelle und kommende Bedrohungen – pragmatisch, persönlich und kompetent.

10. Ausblick – Bleiben Sie am Ball!

E-Mail-Sicherheit ist kein einmaliges Projekt, sondern eine dauerhafte Aufgabe. Mit SPF, DKIM, DMARC & Co. haben Sie nun die wichtigsten Stellschrauben kennengelernt und idealerweise schon umgesetzt. Doch die Bedrohungslage entwickelt sich stetig weiter. Cyberkriminelle schlafen nicht – sie werden neue Tricks finden, um Filter zu umgehen oder Menschen zu täuschen. Daher mein Appell: Bleiben Sie am Ball!

Die gute Nachricht: Mit der Einführung dieser Maßnahmen haben Sie einen großen Schritt getan, um das „Low Hanging Fruit“ zu pflücken – einfache Spoofing-Angriffe prallen an Ihnen ab, und Ihr Unternehmen präsentiert sich nach außen hin als seriöser, sicherer Kommunikationspartner. Das schafft Vertrauen bei Ihren Kunden und Partnern. Vielleicht haben Sie auch intern gemerkt, dass das Thema IT-Sicherheit dadurch an Sichtbarkeit gewonnen hat – nutzen Sie diesen Schwung! Schulen Sie Mitarbeiter weiter, frischen Sie Richtlinien auf (z. B. Passwort-Policies, MFA-Zwang – eine andere Baustelle, aber ebenso wichtig).

Microsoft 365 wird auch laufend verbessert. Halten Sie Ausschau nach neuen Features: Vielleicht wird BIMI bald noch verbreiteter und Ihr Firmenlogo erscheint bei allen Empfängern – ein netter Nebeneffekt der guten DMARC-Policy. Oder Microsoft integriert DMARC-Auswertung direkt ins Security Center, wer weiß. Es lohnt sich, regelmäßig die Roadmap zu lesen oder Newsletter zum Thema zu abonnieren.

Und falls mal wieder eine Abkürzung um die Ecke kommt – keine Scheu: Nach SPF, DKIM, DMARC haben Sie nun Erfahrung damit, scheinbar kryptische Technologien erfolgreich in die Praxis umzusetzen. Sie wissen: Hinter jedem Kürzel steckt ein durchaus greifbares Prinzip, und mit dem richtigen Ansprechpartner (sei es ein Berater oder die Community) lassen sich die Herausforderungen meistern.

Ich persönlich finde, es gibt kaum ein befriedigenderes Gefühl, als wenn die E-Mail-Infrastruktur reibungslos funktioniert und man dabei die Sicherheit im Griff hat. Wenn man weiß: „Unsere Domain kann nicht mehr einfach missbraucht werden. Wir haben den Überblick.“ – dann darf man sich ruhig auf die Schulter klopfen. Dieses Fundament erlaubt es Ihnen, sich auf andere wichtige Projekte zu konzentrieren, ohne ständig „Feuerwehr“ bei Mailproblemen spielen zu müssen.

Zum Schluss bedanke ich mich, dass Sie bis hierher drangeblieben sind – das zeigt Ihr echtes Interesse an sicherer E-Mail-Kommunikation. Lassen Sie sich nicht entmutigen von eventuell auftretenden Hürden. Die Investition in SPF, DKIM, DMARC & Co. zahlt sich aus, in Form von weniger Risiken und mehr Vertrauenswürdigkeit. Sollten Sie Unterstützung benötigen, wissen Sie ja, wo Sie mich finden. Gemeinsam machen wir E-Mails wieder ein Stück sicherer.

In diesem Sinne: Auf eine sichere Kommunikation! Bleiben Sie wachsam und up-to-date – dann haben Spam und Phishing keine Chance.

Viel Erfolg und sichere Emails wünscht Ihnen
Ulrich B. Boddenberg

 

Weitere Beiträge zum Thema Security und Compliance