E-Mail-Sicherheit mit Microsoft 365, Teil 1: SPF, DKIM und DMARC richtig einrichten

SPF, DKIM und DMARC gelten als Grundausstattung jeder Domain. Trotzdem sehen wir in Microsoft-365-Umgebungen immer wieder dieselben Lücken: doppelte SPF-Einträge, nie aktiviertes DKIM, DMARC im reinen Beobachtungsmodus. Dieser Beitrag erklärt die drei Verfahren in einfacher Sprache, zeigt, was ohne sie passiert, und beschreibt die Einrichtung in Exchange Online. Teil 2 behandelt anschließend den Schutz eingehender Mails mit Microsoft Defender for Office 365.

Was passiert, wenn SPF, DKIM und DMARC fehlen?

Ohne diese drei Einträge kann jeder E-Mails versenden, die im Absenderfeld Ihre Domain tragen. Für die Geschäftsführung heißt das konkret:

• Kriminelle schreiben Ihren Kunden, Lieferanten oder Ihrer Bank mit Ihrer Absenderadresse, etwa mit einer „korrigierten“ Bankverbindung auf einer Rechnung.
• Ihre echten Mails landen im Spam, weil Partner mit strenger Absenderprüfung Angebote und Rechnungen aussortieren, deren Domain sich nicht ausweist.
• Wird Ihre Domain für Spam missbraucht, leidet ihr Ruf bei den großen Mailanbietern, und das trifft auch Ihren legitimen Versand.
• Cyber-Versicherer und Auditoren fragen nach SPF, DKIM und DMARC. Eine Lücke müssen Sie dort erklären.

Die Entscheidung, die bei Ihnen liegt: Wer ist intern dafür zuständig, und wer prüft die Berichte regelmäßig?

Was macht SPF und wie richte ich es für Exchange Online ein?

SPF (Sender Policy Framework) ist eine öffentliche Liste der Server, die für Ihre Domain Mails versenden dürfen. Bildlich gesprochen: Sie hinterlegen bei der Post, welche Briefkästen Ihre Briefe einwerfen dürfen. Ein Brief aus einem anderen Briefkasten fällt auf.

Wenn SPF fehlt oder falsch ist: Empfangende Systeme können nicht prüfen, ob eine Mail von einem berechtigten Server kommt. Ein fehlerhafter Eintrag ist dabei oft schlimmer als keiner, denn er kann dazu führen, dass Ihre eigenen Mails abgelehnt werden.

Umsetzung: SPF ist ein TXT-Eintrag im DNS Ihrer Domain, also beim Registrar oder DNS-Anbieter, nicht im Microsoft-365-Portal. Wenn ausschließlich Exchange Online versendet, lautet er:

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

Setzen Sie -all (harte Ablehnung), weil DMARC sonst bei Mails ohne DKIM-Signatur kaum greifen kann. Zwei Grenzen sind wichtig: Pro Domain darf es nur einen SPF-Eintrag geben, und die Prüfung darf höchstens 10 DNS-Abfragen auslösen. Jedes include: zählt mindestens einmal, verschachtelte Einträge zählen zusätzlich. Wird die Grenze überschritten, schlägt SPF mit einem permanenten Fehler fehl.

Was macht DKIM und warum muss ich es in Microsoft 365 selbst einschalten?

DKIM (DomainKeys Identified Mail) versieht jede ausgehende Mail mit einer digitalen Signatur. Im Bild: ein Siegel auf dem Umschlag. Der Empfänger prüft mit einem öffentlich hinterlegten Schlüssel, ob das Siegel echt ist und der Inhalt unterwegs nicht verändert wurde.

Wenn DKIM fehlt: Ohne eigenes Siegel kann niemand nachweisen, dass eine Mail wirklich von Ihnen stammt und unverändert ist. Zudem fehlt DMARC dann eine der beiden Prüfgrundlagen.

Umsetzung: Microsoft 365 signiert für eigene Domains nicht automatisch mit einer Signatur, die zur Absenderdomain passt. Die Einrichtung erfolgt im Microsoft-Defender-Portal unter Email & collaboration > Policies & rules > Threat policies > Email authentication settings (direkt: security.microsoft.com/authentication), Registerkarte DKIM:

1. Domain auswählen und DKIM aktivieren. Das Portal zeigt die beiden benötigten CNAME-Werte an.
2. Beim DNS-Anbieter zwei CNAME-Einträge anlegen: selector1._domainkey und selector2._domainkey, jeweils mit dem angezeigten Ziel.
3. Nachdem Microsoft die Einträge erkannt hat, DKIM einschalten und den Status prüfen.

Was macht DMARC und wie komme ich sicher zu p=reject?

DMARC (Domain-based Message Authentication, Reporting and Conformance) verbindet SPF und DKIM mit einer Anweisung an den Empfänger: Was soll mit Mails passieren, die die Prüfung nicht bestehen? Dazu prüft DMARC, ob die sichtbare Absenderdomain zu SPF oder DKIM passt. Im Bild: Sie teilen der Post mit, was mit Briefen ohne gültiges Siegel und aus fremden Briefkästen geschehen soll, und lassen sich regelmäßig berichten.

Wenn DMARC fehlt oder auf p=none steht: Empfänger entscheiden selbst. Gefälschte Mails werden zwar erkannt, aber zugestellt. Genau hier entsteht der Rechnungsbetrug mit „korrigierten“ Bankdaten.

Umsetzung: DMARC ist ein TXT-Eintrag unter _dmarc.ihredomain.de. Bewährt hat sich ein schrittweises Vorgehen:

1. Start mit Beobachtung: v=DMARC1; p=none; rua=mailto:dmarc-berichte@ihredomain.de. Die Sammelberichte (rua) zeigen, welche Systeme in Ihrem Namen senden.
2. Nach Auswertung auf p=quarantine anheben. Mit pct= lässt sich der Anteil schrittweise erhöhen.
3. Danach p=reject. Erst jetzt weisen Empfänger gefälschte Mails ab.

Beginnen Sie mit Subdomains mit wenig Versand und stellen Sie die Hauptdomain zuletzt um. Leiten Sie die Berichte in ein eigenes Postfach oder eine Microsoft-365-Gruppe, nicht in ein persönliches Postfach, und benennen Sie feste Verantwortliche für die Auswertung.

Warum ist p=none auf Dauer der häufigste Fehler?

p=none ist ein Messmodus, kein Schutz. Viele Umgebungen bleiben dort stehen, weil die Umstellung auf p=reject die Sorge auslöst, eigene Mails könnten verloren gehen. Diese Sorge ist berechtigt, solange niemand die Berichte auswertet. Sie verschwindet, sobald alle legitimen Absender bekannt und korrekt eingebunden sind. Ein Projekt mit klarem Enddatum für p=reject ist deshalb sinnvoller als ein offener Beobachtungsmodus.

Welche Fehler sehen wir bei SPF, DKIM und DMARC am häufigsten?

• Zwei SPF-Einträge für dieselbe Domain: Das führt zu einem Fehler bei der Prüfung. Alle Absender gehören in einen Eintrag.
• Vergessene Drittanbieter: Newsletter-System, ERP, Ticketsystem oder Bewerberportal versenden im Namen der Domain, stehen aber weder im SPF-Eintrag noch signieren sie mit Ihrer Domain. Für solche Dienste sind eigene Subdomains der saubere Weg.
• DKIM nie eingeschaltet: Die CNAME-Einträge wurden angelegt, die Signatur im Portal aber nicht aktiviert, oder umgekehrt.
• Subdomains übersehen: DMARC der Hauptdomain gilt auch für Subdomains, SPF und DKIM dagegen nicht. Jede sendende Subdomain braucht eigene SPF- und DKIM-Einträge.
• Niemand liest die Berichte: Ohne Auswertung bleibt DMARC eine Formalie.
• Ungenutzte Domains ungeschützt: Geparkte Domains brauchen v=spf1 -all und v=DMARC1; p=reject;, damit niemand sie für Betrug nutzt.

Was kommt nach SPF, DKIM und DMARC?

Der nächste Schritt betrifft den Transportweg. MTA-STS legt fest, dass sendende Server Mails an Ihre Domain nur verschlüsselt und nur an einen Server mit gültigem Zertifikat zustellen. Dazu gehören ein DNS-Eintrag und eine Richtliniendatei, die Sie selbst per HTTPS bereitstellen, Exchange Online hostet sie nicht. TLS-RPT ergänzt das um Berichte über fehlgeschlagene verschlüsselte Zustellungen. Beides lohnt sich, sobald DMARC auf p=reject steht.

Der nächste Schritt

Sie tragen die Verantwortung dafür, dass niemand in Ihrem Namen Ihre Kunden betrügt. Wir liefern die Nachweise, dass Ihre Domain korrekt abgesichert ist. Im Gap Assessment prüfen wir SPF, DKIM, DMARC und die übrigen Exchange-Online-Einstellungen und liefern eine priorisierte Maßnahmenliste. Die laufende Auswertung der DMARC-Berichte übernehmen wir auf Wunsch im Rahmen von Managed Security.

Erstgespräch vereinbaren

Häufig gestellte Fragen

Wie lange dauert die Umstellung von DMARC p=none auf p=reject?

Das hängt davon ab, wie viele Systeme in Ihrem Namen senden. Die DNS-Einträge selbst sind in Minuten gesetzt. Zeit kostet die Auswertung der Berichte und die Anpassung von Drittanbietern wie Newsletter- oder ERP-Systemen. Planen Sie die Umstellung als Projekt mit festem Enddatum und gehen Sie Domain für Domain vor.

Signiert Microsoft 365 meine Mails nicht automatisch mit DKIM?

Automatisch signiert werden nur Mails von Absendern der onmicrosoft.com-Domain Ihres Tenants. Für Ihre eigene Domain müssen Sie DKIM im Microsoft-Defender-Portal aktivieren und zwei CNAME-Einträge beim DNS-Anbieter anlegen. Erst dann passt die Signatur zu Ihrer Absenderdomain und zählt für DMARC.

Müssen wir auch Domains absichern, über die wir keine E-Mails versenden?

Ja. Ungenutzte Domains lassen sich sonst für gefälschte Mails missbrauchen. Ein SPF-Eintrag mit v=spf1 -all und ein DMARC-Eintrag mit p=reject signalisieren, dass von dieser Domain keine legitimen Mails kommen. DKIM-Einträge sollten Sie für solche Domains nicht anlegen.