Domain-Check

E-Mail wurde ohne Absenderprüfung entworfen. Wer eine Nachricht einliefert, kann im sichtbaren Absenderfeld nahezu beliebige Angaben machen. SPF, DKIM und DMARC sind die drei Verfahren, mit denen sich diese Lücke nachträglich schließen lässt. Sie greifen an unterschiedlichen Stellen an, und erst im Zusammenspiel ergeben sie eine belastbare Aussage darüber, ob eine Nachricht wirklich aus Ihrer Domain stammt.

Die Prüfung auf dieser Seite liest die zugehörigen DNS-Einträge aus, wertet sie im Zusammenhang aus und baut auf Wunsch zusätzlich eine Verbindung zu den Mailservern auf, um die tatsächlich ausgehandelte Transportverschlüsselung festzuhalten. Was dabei geprüft wird und worauf es ankommt, steht im Folgenden.

Ein SPF-Record ist ein TXT-Eintrag auf der Domain, der die zum Versand berechtigten Server auflistet. Der empfangende Mailserver vergleicht die einliefernde IP-Adresse mit dieser Liste. Wichtig ist, welche Domain dabei betrachtet wird: SPF prüft den Envelope-Absender aus dem SMTP-Dialog, also den Return-Path, nicht das Absenderfeld, das der Empfänger im Mailprogramm sieht. Beide können auseinanderfallen, und genau daran setzt DMARC später an.

Zwei Fallstricke tauchen immer wieder auf. Der erste ist das Lookup-Limit: Ein SPF-Record darf beim Auswerten höchstens zehn DNS-Abfragen auslösen, wobei jeder include mitzählt und verschachtelte Includes ebenfalls. Wird die Grenze überschritten, endet die Prüfung laut RFC 7208 mit einem PermError, und das Ergebnis ist unbrauchbar — auch für berechtigte Absender. Der zweite betrifft den Abschluss des Records. Mit -all erklären Sie alles Übrige für unberechtigt, mit ~all nur für verdächtig. Solange Sie nicht sicher wissen, welche Systeme in Ihrem Namen versenden, ist der weichere Wert der ehrlichere.

Veraltet ist der Mechanismus ptr, von dem RFC 7208 ausdrücklich abrät. Wer ihn noch im Record stehen hat, kann ihn in aller Regel ersatzlos streichen.

DKIM geht einen anderen Weg. Der versendende Server signiert ausgewählte Kopfzeilen und den Nachrichtentext kryptografisch und legt die Signatur als zusätzliche Kopfzeile bei. Der öffentliche Schlüssel liegt im DNS unter einem Selektor, also unter einem Namen der Form selektor._domainkey.ihre-domain.de. Der Empfänger liest den Selektor aus der Signatur, holt den Schlüssel und prüft nach.

Weil sich Selektoren nicht auflisten lassen, muss jede Prüfung von außen mit einer Liste gebräuchlicher Namen arbeiten. Findet der Check keinen Schlüssel, heißt das also nicht zwingend, dass keiner existiert — es kann auch ein ungewöhnlicher Selektor im Einsatz sein. Den verlässlichen Nachweis liefert eine echte Testnachricht, deren Kopfzeilen Sie anschließend in die Header-Analyse geben.

Für die Schlüssellänge haben sich 2048 Bit als Normalfall durchgesetzt; 1024 Bit gelten als überholt. Ein Wechsel des Schlüssels ist unkritisch, wenn er über einen neuen Selektor läuft: Sie veröffentlichen den neuen Schlüssel, stellen den Versand um und entfernen den alten Eintrag erst, wenn keine unterwegs befindliche Nachricht ihn mehr braucht.

DMARC verbindet die beiden Verfahren mit dem Absender, den der Empfänger tatsächlich sieht. Der Record liegt unter _dmarc.ihre-domain.de und beantwortet zwei Fragen: Wie soll mit Nachrichten verfahren werden, die durchfallen, und wohin gehen die Berichte darüber.

Der entscheidende Begriff heißt Alignment. Es genügt nicht, dass SPF oder DKIM irgendein Ergebnis liefern — die geprüfte Domain muss zur Domain im sichtbaren Absenderfeld passen. Bei SPF ist das die Domain des Return-Path, bei DKIM die im Signaturfeld angegebene Domain. Eine Nachricht besteht DMARC, wenn mindestens eines von beiden übereinstimmt. In der strengen Variante muss die Domain exakt gleich sein, in der voreingestellten entspannten genügt dieselbe organisatorische Domain.

Hier scheitern die meisten Aufbauten. Ein Newsletter-Dienstleister versendet technisch unter eigener Domain, setzt aber Ihre Adresse ins Absenderfeld. SPF besteht dann für die Domain des Dienstleisters und ist trotzdem nicht ausgerichtet. Die Lösung liegt entweder in einer eigenen Versanddomain bei diesem Anbieter oder in einer DKIM-Signatur mit Ihrer Domain.

Ähnlich verhält es sich bei Weiterleitungen. Leitet ein Empfänger Ihre Nachricht weiter, liefert plötzlich ein fremder Server ein, und SPF versagt zwangsläufig. Die DKIM-Signatur übersteht den Vorgang dagegen meist, solange der Inhalt unverändert bleibt. Das ist der Hauptgrund, DKIM nicht als Kür zu behandeln.

Die großen Postfachanbieter haben ihre Anforderungen an Versender in den vergangenen Jahren angezogen. Google und Yahoo verlangen seit Februar 2024 von Absendern mit größeren Versandmengen an ihre Nutzer SPF, DKIM und einen DMARC-Record. Microsoft hat im Mai 2025 vergleichbare Anforderungen für den Versand an Outlook.com-Postfächer in Kraft gesetzt. Wer die Verfahren nicht eingerichtet hat, riskiert nicht mehr nur Missbrauch der eigenen Domain, sondern Zustellprobleme im Alltag.

Der Aufwand hält sich in Grenzen und liegt fast vollständig in der Bestandsaufnahme. Die eigentlichen DNS-Einträge sind in einer Stunde gesetzt. Beim Aufbau helfen der SPF-Generator und der DMARC-Generator. Mehrere Domains prüfen Sie in einem Durchgang mit dem Bulk-Check, die Grundstruktur einer Zone zeigt der DNS-Check. Liegt Ihr Postfach bei Microsoft 365, geht der Microsoft-365-Check auf die dortigen Eigenheiten ein.