SPF, DKIM und DMARC einfach erklärt: Was jeder Eintrag prüft und welcher E-Mails abweist

Auf einen Umschlag lässt sich jeder Name schreiben. Bei E-Mail ist es genauso: die Absenderadresse in einer Nachricht ist eine Textzeile, geschrieben von derjenigen Stelle, die sendet, und nichts im Protokoll verlangt, dass sie stimmt.

Dagegen gibt es drei DNS-Einträge. Zwei davon sind Prüfungen. Nur einer ist eine Anweisung – und dieser Unterschied entscheidet darüber, ob eine gefälschte Nachricht im Namen einer Domain ankommt oder abprallt.

Was SPF, DKIM und DMARC jeweils sind

SPF ist eine Liste von Servern. Die Domaininhaberin veröffentlicht, welche Maschinen im Namen dieser Domain Post verschicken dürfen. Ein empfangender Mailserver vergleicht die sendende Maschine mit der Liste und bekommt ein Ja oder ein Nein.

DKIM ist eine Unterschrift. Der sendende Server unterschreibt die Nachricht mit einem geheimen Schlüssel; der passende öffentliche Schlüssel steht im DNS. Passt die Unterschrift beim Ankommen noch, wurde unterwegs nichts verändert und die Nachricht stammt tatsächlich aus einem System mit diesem Schlüssel.

DMARC ist eine Anweisung. Darin steht, was geschehen soll, wenn die ersten beiden scheitern: trotzdem durchlassen, in den Spam-Ordner legen oder rundweg abweisen.

Das ist der ganze Aufbau. Zwei Fragen und eine Antwort darauf. Überraschend ist meist, welcher Teil auf den meisten Domains fehlt – es ist der dritte.

Warum SPF allein nichts aufhält

Eine SPF-Prüfung erzeugt ein Ergebnis. Sie erzeugt keine Folge.

Der empfangende Server erfährt, dass die sendende Maschine nicht auf der Liste steht. Was er mit diesem Wissen anfängt, liegt vollständig bei ihm, und ohne weitere Anweisung tun die meisten das Vorsichtige: zustellen, vielleicht mit einer Markierung. Eine berechtigte Nachricht abzuweisen ist für einen Mailanbieter weit schlimmer, als eine gefälschte anzunehmen – im Zweifel wird also angenommen.

Die SPF-Einträge selbst sagen dazu etwas. Ein Eintrag kann auf -all enden, was bedeutet „alles Übrige ist Fälschung”, oder auf ~all, was bedeutet „alles Übrige ist verdächtig”. Das zweite ist eine Bitte um Nachsicht, und genau das veröffentlicht die Mehrheit der Domains – oft, weil es in einer Anleitung so voreingestellt war, und nicht, weil es jemand entschieden hätte.

DKIM hat dieselbe Grenze. Eine gescheiterte Unterschrift ist ein Befund, kein Urteil.

Das versteckte Budget: zehn Nachfragen und keine mehr

SPF hat eine Grenze, über die viele Domains stolpern, weil im Eintrag selbst nichts davon zu sehen ist.

Ein Eintrag darf auf andere Einträge verweisen. include:_spf.google.com heißt: „alles, was dort erlaubt ist, gilt hier auch”. Bequem, und so werden Versanddienste hinzugefügt. Aber jeder solche Verweis kostet eine DNS-Nachfrage, der verwiesene Eintrag darf weiterverweisen, und in der Summe sind zehn erlaubt.

Jenseits von zehn scheitert die Prüfung nicht bloß – sie endet in einem dauerhaften Fehler, und nach den Regeln zählt der ganze Eintrag dann nicht mehr. Jeder Posten darin, auch die korrekt eingetragenen Server.

Der Haken: diese Grenze lässt sich überschreiten, ohne den eigenen Eintrag anzurühren. Ein Versanddienst fügt in seinem eigenen Eintrag einen Verweis hinzu, dieser Eintrag kostet nun eine Nachfrage mehr, und eine Domain, die bei zehn stand, steht still bei elf. An der Domain hat sich nichts geändert. Die Prüfung hört einfach auf zu funktionieren.

Ein bekannter Zahlungsanbieter steht zurzeit bei neun von zehn. Das ist keine Nachlässigkeit – so sieht es bei einem Konzern mit vielen Versandsystemen aus, und es ist einen Verweis vom Ausfall entfernt.

Wie lang ein DKIM-Schlüssel sein muss

Ein DKIM-Schlüssel lässt sich finden und lesen, und seine Länge lohnt das Lesen.

1024 Bit war jahrelang der Standard und ist noch weit verbreitet. Als ausreichend gilt das nicht mehr; empfohlen sind heute 2048. Der Schlüssel ist nicht geheim – die öffentliche Hälfte steht im DNS und ist für jeden abrufbar – und ein knackbarer Schlüssel erlaubt es Fremden, Unterschriften zu erzeugen, die aufgehen.

Es gibt einen zweiten Grund, warum kurze Schlüssel überleben: ein 2048-Bit-Schlüssel passt nicht am Stück in einen DNS-Eintrag und muss geteilt werden. Das funktioniert, ist aber ein Schritt, der übersprungen wird – und der alte Schlüssel bleibt liegen.

Eine ehrliche Grenze gehört hierher. DKIM-Schlüssel liegen unter einem Selektor, einem frei gewählten Namen, und das DNS bietet keine Möglichkeit, die Selektoren einer Domain aufzulisten. Jede Prüfung von außen kann nur gebräuchliche Namen durchprobieren – default, google, selector1, s1 und ein paar Dutzend mehr. Eine Domain, deren Selektor nicht darunter ist, zeigt keine Schlüssel, und das heißt „hier wurde keiner gefunden”, nie „es gibt keinen”.

Warum die meisten Domains bei p=none stehen bleiben

DMARC ist das einzige der drei, das eine Abweisung anordnen kann, und es ist dasjenige, das die meisten Domains nie fertig einrichten.

Ein DMARC-Eintrag enthält eine Richtlinie: p=none, p=quarantine oder p=reject. Nur das letzte weist Nachrichten tatsächlich ab. p=none bedeutet: prüfen, berichten, trotzdem zustellen.

p=none ist der richtige Anfang. Berichte kommen an, das Bild davon, wer im Namen der Domain verschickt, füllt sich, und vergessene Systeme tauchen auf – das Rechnungswerkzeug, der Newsletter-Dienst, der alte Shop, an den niemand mehr gedacht hat. Das dauert ein paar Wochen.

Dann folgt der Schritt auf quarantine, dann auf reject, und an diesem Schritt bleibt es hängen, denn er ist der einzige, der sichtbar schiefgehen kann. Solange die Richtlinie auf none steht, ist der Eintrag vorhanden und schützt nichts.

So entsteht der häufigste Zustand im Netz: drei Einträge, alle korrekt, alle lesbar, alle bestehen jede oberflächliche Prüfung – und eine gefälschte Nachricht im Namen dieser Domain kommt trotzdem an.

Was fünf Minuten Prüfung zeigen

All das ist öffentlich. SPF, DKIM und DMARC stehen im DNS, für jede Domain von jedem lesbar, und es gibt vier Fragen, die sich für jede davon lohnen.

Gibt es einen SPF-Eintrag, endet er auf -all oder ~all, und wie nah liegt er an der Grenze von zehn Nachfragen. Sind DKIM-Schlüssel auffindbar, und wie lang sind sie. Gibt es einen DMARC-Eintrag, und was sagt seine Richtlinie. Und sind die Mailserver der Domain überhaupt erreichbar.

Der E-Mail-Authentifizierungs-Prüfer beantwortet alle vier für eine beliebige Domain. Er zählt die Nachfragen so, wie ein empfangender Server sie zählt, probiert die gebräuchlichen DKIM-Selektoren durch, liest die DMARC-Richtlinie und sagt deutlich, welche Befunde Tatsachen sind und welche die Grenzen einer Prüfung von außen.

Die brauchbare Antwort ist kurz: ob eine gefälschte Nachricht im Namen dieser Domain abgewiesen würde – oder nur bemerkt.