E-Mail-Zustellung über DNS absichern: MX, SPF, DKIM und DMARC erklärt

E-Mail ist ein offenes Protokoll. Ohne Absender-Authentifizierung kann jeder Server behaupten, in Ihrem Namen zu schreiben. Die Abwehr läuft komplett über das DNS: Vier Einträge legen fest, wohin Post zugestellt wird und welche Server sie verschicken dürfen. Dieser Ratgeber zeigt, wie MX, SPF, DKIM und DMARC ineinandergreifen, was Sie prüfen sollten und welche Fehler die Zustellung kosten.

Warum E-Mail-Sicherheit im DNS liegt

Das Simple Mail Transfer Protocol kennt von sich aus keine Echtheitsprüfung. Wer eine Mail einliefert, gibt eine Absenderadresse an, die niemand technisch belegen muss. Genau diese Lücke nutzen Phishing und Spoofing aus. Die Antwort darauf wurde nicht ins Mailprotokoll gebaut, sondern ins DNS verlagert: Die empfangende Seite schlägt vor der Annahme nach, was die Domain über ihre legitimen Absender hinterlegt hat.

Damit wird die Verwaltung der Absenderpolitik öffentlich und überprüfbar. Jeder kann die relevanten Einträge einer Domain abfragen, denn sie liegen als ganz normale Records in der Zone. Ein DNS-Lookup macht sichtbar, ob eine Domain MX, SPF, DKIM und DMARC sauber gesetzt hat oder ob eine Schicht fehlt.

MX: Wohin die Post zugestellt wird

Der MX-Eintrag (Mail Exchange) beantwortet die erste Frage jedes sendenden Servers: An welchen Host liefere ich Mail für diese Domain aus? Ohne MX gibt es keinen Empfang. Ein MX-Record verweist auf einen Hostnamen und trägt eine Priorität als Zahl. Der niedrigste Wert hat Vorrang, höhere Werte dienen als Ausweichziele.

example.de.   MX   10 mail.example.de.
example.de.   MX   20 mail2.example.de.

Wichtig: Ein MX zeigt immer auf einen Namen, nie direkt auf eine IP-Adresse. Der genannte Host braucht zusätzlich einen A- oder AAAA-Eintrag, sonst läuft die Zustellung ins Leere. Wie Sie MX-Records korrekt auslesen, steht in der Anleitung zum MX-Record.

SPF: Welche Server senden dürfen

Das Sender Policy Framework, definiert in RFC 7208, legt als TXT-Eintrag auf der Domain fest, welche Server in deren Namen senden dürfen. Der Empfänger vergleicht die einliefernde IP mit dieser Liste. Ein typischer Eintrag sieht so aus:

v=spf1 include:_spf.example.com include:_spf.google.com -all

v=spf1 markiert den Eintrag als SPF. include zieht die Freigaben eines Providers hinein, etwa des Mailhosters. Der Abschluss steuert das Verhalten bei nicht gelisteten Servern: -all (hard fail) weist sie ab, ~all (soft fail) markiert sie nur als verdächtig. Den Abschluss +all sollten Sie niemals setzen, weil er jeden Server autorisiert.

Ein zweiter Grenzwert betrifft DNS-Lookups: SPF erlaubt maximal zehn auflösende Mechanismen. Wer zu viele include-Verweise stapelt, überschreitet das Limit und produziert ebenfalls einen permerror. Die Anleitung zum SPF prüfen zeigt, wie Sie den Eintrag und die Lookup-Zahl kontrollieren.

DKIM: Die digitale Signatur jeder Nachricht

SPF prüft nur, von welchem Server eine Mail kommt, nicht ob ihr Inhalt unterwegs verändert wurde. Diese Lücke schließt DKIM (DomainKeys Identified Mail) nach RFC 6376. Der sendende Server signiert ausgewählte Header und den Nachrichtenkörper mit einem privaten Schlüssel. Der passende öffentliche Schlüssel liegt im DNS als TXT-Eintrag unter einem Selektor.

Die Struktur ist selektor._domainkey.example.de. Der Selektor ist ein frei gewählter Name, oft default, s1 oder eine vom Provider vergebene Zeichenkette. Den richtigen Selektor finden Sie im Header einer echten E-Mail dieser Domain, im Feld DKIM-Signature als Parameter s=. Der DNS-Eintrag selbst enthält den öffentlichen Schlüssel:

default._domainkey.example.de.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Empfängt ein Server die Mail, holt er diesen Schlüssel und prüft die Signatur. Stimmt sie, ist belegt, dass die Nachricht von einem berechtigten Server stammt und der signierte Teil unverändert ist.

SPF beantwortet die Frage „Darf dieser Server senden?”, DKIM die Frage „Ist diese Nachricht echt und unverändert?”. Erst beide zusammen ergeben einen belastbaren Nachweis.

DMARC: Die Richtlinie, die alles bündelt

DMARC nach RFC 7489 ist die Klammer um SPF und DKIM. Der Eintrag liegt als TXT unter _dmarc.example.de und legt zwei Dinge fest: was passieren soll, wenn die Prüfung scheitert, und wohin Reports gehen.

_dmarc.example.de.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.de; adkim=s; aspf=s"

Der zentrale Parameter ist die Richtlinie p. Drei Stufen sind möglich:

• p=none beobachtet nur und liefert Reports, ohne Mails zu blockieren.
• p=quarantine verschiebt auffällige Nachrichten in den Spam-Ordner.
• p=reject weist sie hart ab.

Entscheidend ist die sogenannte Ausrichtung (alignment). DMARC verlangt, dass die in SPF oder DKIM geprüfte Domain zur sichtbaren Absenderadresse im From-Header passt. Genau das verhindert, dass ein Angreifer eine eigene, sauber konfigurierte Domain benutzt und trotzdem fremd auftritt. Mit adkim=s und aspf=s fordern Sie eine strikte Übereinstimmung statt der lockeren Standardeinstellung.

Die Reports unter rua zeigen aggregiert, welche Server in Ihrem Namen senden, und decken oft vergessene Dienste auf, etwa ein Newsletter-Tool oder eine alte Ticket-Software. Wie Sie den Eintrag auslesen, beschreibt die Anleitung zum DMARC prüfen.

Übersicht: Welcher Eintrag wofür

Die folgende Tabelle fasst zusammen, welcher Record welche Aufgabe hat und an welcher Stelle im DNS Sie ihn finden.

Eintrag	Zweck	Wo prüfen
MX	Mailserver der Domain, Ziel der Zustellung	direkt auf example.de
SPF	Liste der erlaubten Sendeserver (TXT, v=spf1)	direkt auf example.de
DKIM	öffentlicher Schlüssel zur Signaturprüfung (TXT)	selektor._domainkey.example.de
DMARC	Richtlinie und Report-Ziel (TXT, v=DMARC1)	_dmarc.example.de

Häufige Fehler, die die Zustellung kosten

In der Praxis scheitern E-Mails selten an der Technik selbst, sondern an Konfigurationsfehlern. Die häufigsten:

• Zwei SPF-Einträge. Oft entsteht das beim Wechsel des Mailhosters, wenn der alte Eintrag stehen bleibt. Das Ergebnis ist ein permerror und eine fehlgeschlagene SPF-Prüfung.
• Fehlendes DMARC. Ohne _dmarc-Eintrag entscheidet jeder Empfänger selbst, wie er mit fehlgeschlagenem SPF oder DKIM umgeht. Die Domain bleibt für Spoofing offen.
• Zu viele SPF-Lookups. Mehr als zehn auflösende Mechanismen brechen die Prüfung ab, obwohl die erlaubten Server eigentlich korrekt gelistet sind.
• Falscher oder fehlender DKIM-Selektor. Wird die Domain umgezogen oder der Versanddienst gewechselt, zeigt der Selektor ins Leere und die Signatur lässt sich nicht prüfen.
• DMARC dauerhaft auf p=none. Der Beobachtungsmodus schützt nicht aktiv. Wer nie verschärft, behält die Reports, aber nicht die Abwehr.

Wer ein DNS-Problem tiefer eingrenzen will, findet im Ratgeber DNS-Record-Typen die Grundlagen zu A, MX, TXT und Co., und im Ratgeber DNS-Sicherheit den Blick über E-Mail hinaus. Steht ein Anbieterwechsel an, lohnt vorab der Ratgeber Domain-Umzug ohne Ausfall, denn dabei gehen MX und SPF besonders oft verloren.

So bleibt Ihre Domain abgesichert

E-Mail-Sicherheit ist kein einmaliges Projekt, sondern eine Pflege-Aufgabe. MX bringt die Post ans Ziel, SPF grenzt die erlaubten Server ein, DKIM belegt die Echtheit jeder Nachricht und DMARC zieht aus beidem eine durchsetzbare Richtlinie. Prüfen Sie nach jeder Änderung am Mailsetup die vier Einträge per Lookup, halten Sie genau einen SPF-Record sauber, pflegen Sie den passenden DKIM-Selektor und führen Sie DMARC schrittweise von p=none zu p=reject. Dann bleibt die Zustellung stabil und Ihr Name vor Missbrauch geschützt.