SPF, DKIM und DMARC richtig einrichten — ein praktischer Leitfaden

Fast jede Domain hat inzwischen einen SPF-Eintrag. Bei DKIM und DMARC endet es häufig — und damit bleibt der Schutz unvollständig. Ohne DMARC bleibt selbst eine korrekte SPF- und DKIM-Konfiguration wirkungslos, weil Empfänger keine Anweisung haben, was mit gefälschten Mails passieren soll.

Die drei Einträge greifen ineinander. Dieser Beitrag erklärt, was jeder einzelne bewirkt, in welcher Reihenfolge sie eingerichtet werden und woran eine Konfiguration in der Praxis scheitert. Die formale Referenz dazu führt Microsoft in der Dokumentation zur E-Mail-Authentifizierung.

SPF: wer darf für Ihre Domain versenden

Der SPF-Eintrag ist ein TXT-Record im DNS und listet die Systeme, die im Namen Ihrer Domain versenden dürfen. Empfänger prüfen, ob der einliefernde Server auf dieser Liste steht.

Ein typischer Eintrag für Microsoft 365 mit einem zusätzlichen Newsletter-Dienst sieht so aus: v=spf1 include:spf.protection.outlook.com include:_spf.dienst.de -all

Die drei häufigsten SPF-Fehler

• Mehr als zehn DNS-Lookups. Jedes include kostet einen Lookup, und ein include kann weitere enthalten. Über zehn schlägt die Prüfung mit permerror fehl — die Wirkung ist dann so, als gäbe es keinen SPF-Eintrag.
• Zwei SPF-Einträge. Erlaubt ist genau einer. Bei zwei Einträgen ist das Ergebnis für Empfänger undefiniert; typischerweise scheitert die Prüfung.
• Dauerhaft ~all. Der Softfail ist als Übergang gedacht. Wenn die Liste vollständig ist, gehört dort -all hin.

Wichtig zu wissen: SPF prüft den technischen Absender im Envelope, nicht die Adresse, die Empfänger im Mailprogramm sehen. Deshalb genügt SPF allein nicht gegen Spoofing.

DKIM: Signatur, die den Inhalt schützt

DKIM signiert ausgehende Nachrichten mit einem privaten Schlüssel. Der öffentliche Teil liegt als DNS-Eintrag bereit, sodass Empfänger prüfen können, ob die Nachricht unterwegs verändert wurde und ob sie tatsächlich von einem berechtigten System stammt.

In Microsoft 365 sind zwei Punkte entscheidend:

• DKIM muss pro eigener Domain aktiviert werden. Der automatisch vorhandene Schlüssel gilt nur für die onmicrosoft.com-Domain und hilft Ihrer eigentlichen Domain nicht.
• Es werden zwei CNAME-Einträge (selector1 und selector2) angelegt, damit ein Schlüsselwechsel ohne Unterbrechung möglich ist.

Dienste, die in Ihrem Namen versenden — Newsletter-Plattformen, Ticketsysteme, Shopsysteme — bringen eigene DKIM-Schlüssel mit. Diese müssen einzeln hinterlegt werden, sonst gilt für deren Mails nur die SPF-Prüfung.

DMARC: Richtlinie und Berichte

DMARC verbindet SPF und DKIM mit der sichtbaren Absenderadresse und legt fest, wie Empfänger mit Fehlschlägen umgehen sollen. Zusätzlich liefert es Berichte darüber, wer für Ihre Domain versendet.

Ein Einstiegs-Eintrag: v=DMARC1; p=none; rua=mailto:dmarc@ihre-domain.de; pct=100

Die drei Stufen

• p=none — nur beobachten. Nichts wird blockiert, Berichte laufen ein.
• p=quarantine — Fehlschläge landen im Spam-Ordner.
• p=reject — Fehlschläge werden abgewiesen. Das eigentliche Ziel.

Mit pct lässt sich die Verschärfung anteilig ausrollen, etwa p=quarantine; pct=25 für ein Viertel der betroffenen Mails.

Ausrichtung: der Punkt, an dem es scheitert

DMARC verlangt, dass die Domain aus der sichtbaren Absenderadresse zur SPF- oder DKIM-geprüften Domain passt. Genau hier scheitern in der Praxis viele Konfigurationen: Ein Newsletter-Dienst versendet technisch über seine eigene Domain, zeigt aber Ihre Adresse an. SPF ist grün, DMARC schlägt trotzdem fehl.

Die Lösung liegt beim Dienst selbst — er muss eine eigene Subdomain für den Versand und einen DKIM-Schlüssel für Ihre Domain bereitstellen.

Reihenfolge in der Praxis

• Woche 1: Alle versendenden Systeme erfassen, SPF vervollständigen, DKIM für alle eigenen Domains und Dienste aktivieren.
• Woche 1: DMARC mit p=none und Berichtsadresse einrichten.
• Woche 2 bis 4: Berichte auswerten. Fehlende Systeme nachtragen, Ausrichtungsprobleme mit den Dienstleistern klären.
• Woche 5: Auf p=quarantine wechseln, zunächst mit reduziertem pct.
• Woche 6 bis 8: Wenn keine legitimen Fehlschläge mehr auftreten, auf p=reject stellen.

Wer diesen Weg überspringt und direkt auf reject geht, blockiert mit hoher Wahrscheinlichkeit eigene Systeme — meist die, die selten versenden und deshalb auf keiner Liste standen.

Berichte lesbar machen

DMARC-Berichte kommen als XML und sind unbearbeitet kaum auswertbar. Für kleinere Umgebungen genügt ein Auswertungsdienst mit Übersicht; entscheidend ist nicht das Werkzeug, sondern dass die Berichte überhaupt jemand ansieht. Ein DMARC-Eintrag ohne Auswertung dokumentiert nur, dass niemand hinsieht.

Was danach noch bleibt

SPF, DKIM und DMARC schützen Ihre Domain vor Missbrauch und verbessern die Zustellbarkeit. Sie schützen nicht vor eingehenden Angriffen — dafür sind Filter, Conditional Access und die Konfiguration in Microsoft Defender zuständig. Und sie bleiben nur wirksam, wenn neue Dienste beim Einrichten mitgedacht werden: Jedes neue System, das in Ihrem Namen versendet, gehört in SPF und braucht einen DKIM-Schlüssel.