SPF, DKIM und DMARC: was die drei wirklich tun

Fast jede Firma, deren Mailkonfiguration wir uns ansehen, hat SPF. Viele haben zusätzlich DKIM. Und trotzdem kann jeder Fremde in ihrem Namen Rechnungen verschicken.

Das liegt nicht daran, dass die Einträge falsch wären. Es liegt daran, dass SPF und DKIM ohne DMARC folgenlos bleiben: Sie stellen fest, dass etwas nicht stimmt, sagen dem Empfänger aber nicht, was er dann tun soll. Also stellt er zu.

Die kurze Antwort

SPF legt fest, welche Server für eure Domain senden dürfen. DKIM unterschreibt jede Mail kryptografisch. DMARC verbindet beides, sagt dem Empfänger was bei einem Durchfall zu tun ist, und schickt euch Berichte darüber.

Alle drei sind TXT-Einträge im DNS. Keiner davon kostet Geld. Zusammen brauchen sie einen Nachmittag, plus einige Wochen Beobachtung, bevor man scharf stellt.

SPF: Wer darf senden?

Ein SPF-Eintrag ist eine Liste erlaubter Absender:

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

Übersetzt: „Microsoft 365 und Mailjet dürfen für uns senden. Alle anderen nicht.“ Das -all am Ende ist der entscheidende Teil, es sagt „alles Übrige ablehnen“. Steht dort ~all, heißt das nur „verdächtig, aber zustellen“. Fehlt das all ganz, ist die Liste eine Empfehlung ohne Wirkung.

Die Grenze von zehn Lookups

Hier liegt der Fehler, den wir am häufigsten finden und der am wenigsten bekannt ist:

Ein SPF-Eintrag darf beim Auswerten höchstens zehn DNS-Abfragen auslösen. Wer darüber liegt, dessen SPF gilt als fehlerhaft, manche Empfänger ignorieren ihn dann vollständig.

Jedes include: zählt. Und zwar nicht nur einmal: Was hinter dem include steht, bindet oft selbst wieder etwas ein. Microsoft 365 allein kostet mehrere Lookups. Wer dazu ein Newslettersystem, ein CRM, einen Shop und einen Rechnungsdienst einbindet, ist über der Grenze, ohne es zu merken. Der Eintrag sieht ja weiterhin richtig aus.

Wie ihr die Kette selbst nachzählt, warum das oft empfohlene „Flattening“ die falsche Antwort ist und was stattdessen hilft, steht ausführlich in SPF und die Grenze von zehn Lookups.

DKIM: die Unterschrift

DKIM hängt an jede ausgehende Mail eine kryptografische Signatur. Der Empfänger holt sich den öffentlichen Schlüssel aus eurem DNS und prüft, ob die Mail unterwegs verändert wurde.

Der Schlüssel liegt unter einem Selektor, einem frei gewählten Namen:

selector1._domainkey.firma.de

Deshalb kann ein Prüfwerkzeug DKIM nie mit Sicherheit ausschließen: Es müsste den Namen erraten. Unser DMARC-Check probiert zwölf verbreitete Selektoren von Microsoft 365, Google Workspace, IONOS und anderen durch. Findet er keinen, heißt das nur: nicht unter einem der üblichen Namen.

DMARC: die Entscheidung

DMARC ist der Eintrag, der aus den beiden anderen Schutz macht:

v=DMARC1; p=none; rua=mailto:dmarc@firma.de

Zwei Angaben zählen.

p= ist die Richtlinie. Sie sagt dem Empfänger, was er mit einer Mail tun soll, die weder SPF noch DKIM besteht:

rua= ist die Berichtsadresse. Dorthin schicken Google, Microsoft und die anderen großen Empfänger täglich eine Zusammenfassung: Wer hat in eurem Namen gesendet, und hat es die Prüfung bestanden? Ohne rua fliegt man blind.

Warum p=none kein Schutz ist

Bei p=none wird nur beobachtet. Gefälschte Mails werden trotzdem zugestellt.

Als Startpunkt ist das genau richtig, man braucht die Berichte, bevor man verschärft. Als Dauerzustand ist es eine Attrappe: Der Eintrag ist da, das Prüfwerkzeug zeigt grün, und schützen tut er nichts.

Wir sehen p=none bei der Mehrheit der Domains, die wir prüfen. Meistens, weil jemand vor zwei Jahren den ersten Schritt gemacht und den zweiten nie nachgeholt hat.

Die Spezifikation dahinter ist frei einsehbar: RFC 7489 beschreibt DMARC im Wortlaut, dmarc.org fasst dasselbe kürzer zusammen. Was Google und Microsoft von größeren Versendern konkret verlangen, steht in den Richtlinien für E-Mail-Absender.

Warum besteht SPF, und DMARC fällt trotzdem durch?

Hier hören die meisten Anleitungen auf, und hier kommen die meisten überraschenden Berichte her. Der Fachbegriff ist Ausrichtung, im Englischen alignment.

SPF und DKIM prüfen nämlich gar nicht die Adresse, die im Postfach steht.

• SPF prüft den Absender auf dem Umschlag, den Return-Path. Den sieht kein Mensch, und bei einem Versanddienst gehört er meist dem Dienst: bounces.dienstleister.com.
• DKIM unterschreibt für die Domain, die in der Signatur unter d= steht. Auch die gehört oft dem Dienst.
• DMARC interessiert sich für die dritte Adresse: die im Feld Von, die eure Kunden lesen.

DMARC ist nur bestanden, wenn mindestens eine der beiden ersten Domains zur Adresse im Feld Von passt. Tut sie das nicht, war die Prüfung technisch erfolgreich und trotzdem wertlos.

Der Klassiker sieht so aus: Ein Newsletter geht über einen Dienstleister raus, im Postfach steht info@firma.de als Absender. SPF besteht, für die Domain des Dienstleisters. DKIM besteht, für die Domain des Dienstleisters. DMARC fällt durch, weil keine der beiden firma.de ist. Bei p=reject wäre der Newsletter verschwunden.

Der Ausweg steht bei jedem größeren Versanddienst unter „eigene Domain verifizieren“: eine eigene Bounce-Subdomain per CNAME und ein DKIM-Schlüssel, der mit d=firma.de unterschreibt. Danach passt die Ausrichtung, und der nächste Bericht zeigt es.

Wie streng verglichen wird, steuert ihr selbst. Voreingestellt genügt die Organisationsdomain, mail.firma.de passt also zu firma.de. Wer aspf=s oder adkim=s setzt, verlangt exakte Gleichheit. Das ist strenger, als die meisten gewachsenen Aufbauten vertragen, und selten nötig.

Weiterleitungen: warum Schritt 4 nicht optional ist

Es gibt einen Fall, in dem eine vollkommen echte Mail die Prüfung nicht besteht, und der ist häufiger als jede Fälschung: die Weiterleitung.

Wird eine Mail von einer Adresse an eine andere weitergereicht, kommt sie beim Ziel von einem anderen Server als dem, der in eurem SPF-Eintrag steht. SPF fällt durch, und zwar zu Recht, denn der weiterleitende Server steht ja nicht auf der Liste. Betroffen ist genau das, was in kleineren Firmen üblich ist: info@ verteilt auf mehrere Postfächer, eine alte Adresse zeigt auf die neue, ein Verteiler streut an zwanzig Leute.

In diesem Fall rettet nur DKIM. Die Unterschrift überlebt die Weiterleitung, weil sie an der Mail hängt und nicht am Server. Deshalb ist DKIM auf jedem sendenden System die Bedingung dafür, dass p=reject gefahrlos ist, und keine Fleißaufgabe.

Eine Einschränkung bleibt: Verteiler, die den Betreff ergänzen oder unten eine Fußzeile anhängen, verändern die Mail und machen die Unterschrift ungültig. Dann fällt auch DKIM durch. Wer solche Listen betreibt, sieht das in den Berichten und stellt sie um, bevor er verschärft.

Die Falle mit der Subdomain

Ein DMARC-Eintrag auf mail.firma.de schützt firma.de nicht.

Das ist uns selbst passiert. Ein Aggregatbericht meldete 20 von 20 bestandenen Prüfungen, für unsere Versand-Subdomain. Unter der Hauptdomain, unter der uns die Kunden kennen und unter der sie Rechnungen von uns erwarten, gab es gar keinen DMARC-Eintrag.

DMARC wird von der Organisationsdomain aus vererbt, nicht umgekehrt. Wer eine Subdomain absichert, hat die Hauptdomain nicht abgesichert. Für Subdomains gibt es dafür sp=, die eigene Richtlinie für alles unterhalb.

Die Reihenfolge, die niemand abkürzen sollte

1. SPF vervollständigen. Alle sendenden Systeme aufnehmen, danach die Lookups zählen.
2. DKIM einschalten, bei jedem sendenden System einzeln.
3. DMARC mit p=none und rua= anlegen. Ab hier laufen Berichte ein.
4. Zwei bis vier Wochen Berichte auswerten. Sie zeigen Systeme, an die sich niemand mehr erinnert: das alte Ticketsystem, den Drucker, den Dienstleister von 2019.
5. Auf p=quarantine, beobachten.
6. Auf p=reject, erst wenn über mehrere Wochen nichts Eigenes mehr durchfällt.

Wer Schritt 4 überspringt und direkt auf p=reject geht, verliert echte Mail. Nicht theoretisch: Rechnungen, Bestellbestätigungen, Newsletter. Und man merkt es erst, wenn sich jemand beschwert.

Wie ein Aggregatbericht aufgebaut ist, welche vier Felder zählen und woran ihr erkennt, dass Schritt 5 gefahrlos ist, steht in DMARC-Berichte auswerten. Wer den Transportweg zusätzlich absichern will, findet den Weg dorthin in MTA-STS und TLS-RPT einrichten.

Wie es bei euch aussieht

Der kostenlose DMARC-Check liest eure öffentlichen DNS-Einträge und zeigt in zehn Sekunden, wo ihr steht: SPF samt Lookup-Zählung, DMARC-Richtlinie, DKIM-Selektoren, dazu MTA-STS und TLS-RPT. Ohne Anmeldung, ohne E-Mail-Adresse.

Wie eine Fälschung praktisch abläuft und was sie bei euren Kunden anrichtet, steht in E-Mail-Spoofing: wie Fremde in eurem Namen schreiben.

Wenn dabei etwas herauskommt, das jemand geradeziehen soll: Wir machen das seit über 25 Jahren und stellen schrittweise scharf, ohne dass unterwegs Mail verloren geht. Bei laufender Wartung schauen wir die Berichte turnusmäßig mit an, weil sich sonst niemand daran erinnert, sobald der erste Monat vorbei ist.

Erstgespräch vereinbaren: 30 Minuten, kostenlos, mit einer ehrlichen Einschätzung, auch wenn sie lautet, dass bei euch eine Stunde Handarbeit reicht.