{"id":13467,"date":"2026-10-06T12:45:00","date_gmt":"2026-10-06T10:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13467"},"modified":"2026-09-25T09:45:52","modified_gmt":"2026-09-25T07:45:52","slug":"spf-dkim-und-dmarc-einfach-erklart-was-jeder-eintrag-pruft-und-welcher-e","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/it-networks-de\/tutorials-de-it-networks-de\/spf-dkim-und-dmarc-einfach-erklart-was-jeder-eintrag-pruft-und-welcher-e\/","title":{"rendered":"SPF, DKIM und DMARC einfach erkl\u00e4rt: Was jeder Eintrag pr\u00fcft und welcher E-Mails abweist"},"content":{"rendered":"

Auf einen Umschlag l\u00e4sst 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.<\/p>\n

Dagegen gibt es drei DNS-Eintr\u00e4ge. Zwei davon sind Pr\u00fcfungen. Nur einer ist eine Anweisung – und dieser Unterschied entscheidet dar\u00fcber, ob eine gef\u00e4lschte Nachricht im Namen einer Domain ankommt oder abprallt.<\/p>\n

\n\"Eine
Alle drei sehen dieselbe Nachricht. Nur die dritte kann auf das reagieren, was sie sieht.<\/figcaption><\/figure>\n

Was SPF, DKIM und DMARC jeweils sind<\/h2>\n

SPF ist eine Liste von Servern.<\/strong> Die Domaininhaberin ver\u00f6ffentlicht, welche Maschinen im Namen dieser Domain Post verschicken d\u00fcrfen. Ein empfangender Mailserver vergleicht die sendende Maschine mit der Liste und bekommt ein Ja oder ein Nein.<\/p>\n

DKIM ist eine Unterschrift.<\/strong> Der sendende Server unterschreibt die Nachricht mit einem geheimen Schl\u00fcssel; der passende \u00f6ffentliche Schl\u00fcssel steht im DNS. Passt die Unterschrift beim Ankommen noch, wurde unterwegs nichts ver\u00e4ndert und die Nachricht stammt tats\u00e4chlich aus einem System mit diesem Schl\u00fcssel.<\/p>\n

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

Das ist der ganze Aufbau. Zwei Fragen und eine Antwort darauf. \u00dcberraschend ist meist, welcher Teil auf den meisten Domains fehlt – es ist der dritte.<\/p>\n

Warum SPF allein nichts aufh\u00e4lt<\/h2>\n

Eine SPF-Pr\u00fcfung erzeugt ein Ergebnis. Sie erzeugt keine Folge.<\/p>\n

Der empfangende Server erf\u00e4hrt, dass die sendende Maschine nicht auf der Liste steht. Was er mit diesem Wissen anf\u00e4ngt, liegt vollst\u00e4ndig bei ihm, und ohne weitere Anweisung tun die meisten das Vorsichtige: zustellen, vielleicht mit einer Markierung. Eine berechtigte Nachricht abzuweisen ist f\u00fcr einen Mailanbieter weit schlimmer, als eine gef\u00e4lschte anzunehmen – im Zweifel wird also angenommen.<\/p>\n

Die SPF-Eintr\u00e4ge selbst sagen dazu etwas. Ein Eintrag kann auf -all<\/code> enden, was bedeutet \u201ealles \u00dcbrige ist F\u00e4lschung”, oder auf ~all<\/code>, was bedeutet \u201ealles \u00dcbrige ist verd\u00e4chtig”. Das zweite ist eine Bitte um Nachsicht, und genau das ver\u00f6ffentlicht die Mehrheit der Domains – oft, weil es in einer Anleitung so voreingestellt war, und nicht, weil es jemand entschieden h\u00e4tte.<\/p>\n

DKIM hat dieselbe Grenze. Eine gescheiterte Unterschrift ist ein Befund, kein Urteil.<\/p>\n

Das versteckte Budget: zehn Nachfragen und keine mehr<\/h2>\n

SPF hat eine Grenze, \u00fcber die viele Domains stolpern, weil im Eintrag selbst nichts davon zu sehen ist.<\/p>\n

Ein Eintrag darf auf andere Eintr\u00e4ge verweisen. include:_spf.google.com<\/code> hei\u00dft: \u201ealles, was dort erlaubt ist, gilt hier auch”. Bequem, und so werden Versanddienste hinzugef\u00fcgt. Aber jeder solche Verweis kostet eine DNS-Nachfrage, der verwiesene Eintrag darf weiterverweisen, und in der Summe sind zehn erlaubt.<\/p>\n

Jenseits von zehn scheitert die Pr\u00fcfung nicht blo\u00df – sie endet in einem dauerhaften Fehler, und nach den Regeln z\u00e4hlt der ganze Eintrag dann nicht mehr. Jeder Posten darin, auch die korrekt eingetragenen Server.<\/p>\n

Der Haken: diese Grenze l\u00e4sst sich \u00fcberschreiten, ohne den eigenen Eintrag anzur\u00fchren. Ein Versanddienst f\u00fcgt 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\u00e4ndert. Die Pr\u00fcfung h\u00f6rt einfach auf zu funktionieren.<\/p>\n

Ein bekannter Zahlungsanbieter steht zurzeit bei neun von zehn. Das ist keine Nachl\u00e4ssigkeit – so sieht es bei einem Konzern mit vielen Versandsystemen aus, und es ist einen Verweis vom Ausfall entfernt.<\/p>\n

\n\"Drei
\n<\/figure>\n

Wie lang ein DKIM-Schl\u00fcssel sein muss<\/h2>\n

Ein DKIM-Schl\u00fcssel l\u00e4sst sich finden und lesen, und seine L\u00e4nge lohnt das Lesen.<\/p>\n

1024 Bit war jahrelang der Standard und ist noch weit verbreitet. Als ausreichend gilt das nicht mehr; empfohlen sind heute 2048. Der Schl\u00fcssel ist nicht geheim – die \u00f6ffentliche H\u00e4lfte steht im DNS und ist f\u00fcr jeden abrufbar – und ein knackbarer Schl\u00fcssel erlaubt es Fremden, Unterschriften zu erzeugen, die aufgehen.<\/p>\n

Es gibt einen zweiten Grund, warum kurze Schl\u00fcssel \u00fcberleben: ein 2048-Bit-Schl\u00fcssel passt nicht am St\u00fcck in einen DNS-Eintrag und muss geteilt werden. Das funktioniert, ist aber ein Schritt, der \u00fcbersprungen wird – und der alte Schl\u00fcssel bleibt liegen.<\/p>\n

Eine ehrliche Grenze geh\u00f6rt hierher. DKIM-Schl\u00fcssel liegen unter einem Selektor, einem frei gew\u00e4hlten Namen, und das DNS bietet keine M\u00f6glichkeit, die Selektoren einer Domain aufzulisten. Jede Pr\u00fcfung von au\u00dfen kann nur gebr\u00e4uchliche Namen durchprobieren – default<\/code>, google<\/code>, selector1<\/code>, s1<\/code> und ein paar Dutzend mehr. Eine Domain, deren Selektor nicht darunter ist, zeigt keine Schl\u00fcssel, und das hei\u00dft \u201ehier wurde keiner gefunden”, nie \u201ees gibt keinen”.<\/p>\n

Warum die meisten Domains bei p=none stehen bleiben<\/h2>\n

DMARC ist das einzige der drei, das eine Abweisung anordnen kann, und es ist dasjenige, das die meisten Domains nie fertig einrichten.<\/p>\n

Ein DMARC-Eintrag enth\u00e4lt eine Richtlinie: p=none<\/code>, p=quarantine<\/code> oder p=reject<\/code>. Nur das letzte weist Nachrichten tats\u00e4chlich ab. p=none<\/code> bedeutet: pr\u00fcfen, berichten, trotzdem zustellen.<\/p>\n

p=none<\/code> ist der richtige Anfang. Berichte kommen an, das Bild davon, wer im Namen der Domain verschickt, f\u00fcllt 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.<\/p>\n

Dann folgt der Schritt auf quarantine<\/code>, dann auf reject<\/code>, und an diesem Schritt bleibt es h\u00e4ngen, denn er ist der einzige, der sichtbar schiefgehen kann. Solange die Richtlinie auf none<\/code> steht, ist der Eintrag vorhanden und sch\u00fctzt nichts.<\/p>\n

So entsteht der h\u00e4ufigste Zustand im Netz: drei Eintr\u00e4ge, alle korrekt, alle lesbar, alle bestehen jede oberfl\u00e4chliche Pr\u00fcfung – und eine gef\u00e4lschte Nachricht im Namen dieser Domain kommt trotzdem an.<\/p>\n

Was f\u00fcnf Minuten Pr\u00fcfung zeigen<\/h2>\n

All das ist \u00f6ffentlich. SPF, DKIM und DMARC stehen im DNS, f\u00fcr jede Domain von jedem lesbar, und es gibt vier Fragen, die sich f\u00fcr jede davon lohnen.<\/p>\n

Gibt es einen SPF-Eintrag, endet er auf -all<\/code> oder ~all<\/code>, und wie nah liegt er an der Grenze von zehn Nachfragen. Sind DKIM-Schl\u00fcssel auffindbar, und wie lang sind sie. Gibt es einen DMARC-Eintrag, und was sagt seine Richtlinie. Und sind die Mailserver der Domain \u00fcberhaupt erreichbar.<\/p>\n

Der E-Mail-Authentifizierungs-Pr\u00fcfer<\/a> beantwortet alle vier f\u00fcr eine beliebige Domain. Er z\u00e4hlt die Nachfragen so, wie ein empfangender Server sie z\u00e4hlt, probiert die gebr\u00e4uchlichen DKIM-Selektoren durch, liest die DMARC-Richtlinie und sagt deutlich, welche Befunde Tatsachen sind und welche die Grenzen einer Pr\u00fcfung von au\u00dfen.<\/p>\n

Die brauchbare Antwort ist kurz: ob eine gef\u00e4lschte Nachricht im Namen dieser Domain abgewiesen w\u00fcrde – oder nur bemerkt.<\/p>\n

\n

Fragen und Antworten<\/h2>\n

Warum kann eine gef\u00e4lschte Nachricht SPF bestehen und trotzdem an DMARC scheitern?<\/h3>\n

Weil SPF eine andere Adresse pr\u00fcft als die, die im Postfach erscheint. SPF bezieht sich auf die Absenderadresse des Umschlags, die beim Einliefern genannt wird und sp\u00e4ter als Return-Path in der Nachricht steht. Die sichtbare Absenderzeile (From) ist davon unabh\u00e4ngig. Wer f\u00e4lscht, kann also eine eigene Domain mit passendem SPF-Eintrag in den Umschlag schreiben, eine fremde in die Absenderzeile setzen und besteht die SPF-Pr\u00fcfung.<\/p>\n

DMARC schlie\u00dft diese L\u00fccke mit einer zus\u00e4tzlichen Bedingung, der Ausrichtung (Alignment): Ein bestandenes SPF oder DKIM z\u00e4hlt nur, wenn die gepr\u00fcfte Domain zur Domain in der sichtbaren Absenderzeile passt. Bei DKIM ist das die Domain, die in der Unterschrift steht. Eine Nachricht besteht DMARC, sobald eine der beiden Pr\u00fcfungen besteht und ausgerichtet ist.<\/p>\n

F\u00fcr den Schritt auf reject ergibt sich daraus eine Reihenfolge. Bei weitergeleiteter Post geht das ausgerichtete SPF-Ergebnis meist verloren, weil nun ein anderer Server einliefert; die DKIM-Unterschrift \u00fcbersteht die Weiterleitung, solange niemand die Nachricht ver\u00e4ndert. Mailinglisten, die den Betreff \u00e4ndern oder eine Fu\u00dfzeile anh\u00e4ngen, brechen dagegen auch die Unterschrift. Bevor die Richtlinie versch\u00e4rft wird, sollte deshalb jedes System, das im Namen der Domain verschickt, mit einer ausgerichteten DKIM-Unterschrift senden. Die Berichte aus der Phase mit p=none zeigen, wo das noch fehlt.<\/p>\n

Braucht eine Domain, die gar keine E-Mails verschickt, diese Eintr\u00e4ge \u00fcberhaupt?<\/h3>\n

Gerade sie. Eine Domain ohne Versand l\u00e4sst sich ohne jedes Risiko sperren: mit einem SPF-Eintrag v=spf1 -all<\/code>, der keinen Server erlaubt, und einem DMARC-Eintrag mit p=reject<\/code>. Da es keine berechtigte Nachricht gibt, kann auch keine f\u00e4lschlich abgewiesen werden, und die Wochen mit p=none entfallen.<\/p>\n<\/div>\n

\n

Quellen<\/h2>\n