SPF, DKIM und DMARC erklärt: E-Mail-Absender schützen

Was leisten SPF, DKIM und DMARC – und warum braucht man alle drei?

Das E-Mail-Protokoll SMTP wurde ohne Absenderprüfung entworfen: Jeder Server kann behaupten, eine Nachricht komme von info@ihre-domain.de. Betrüger nutzen das für Phishing und gefälschte Rechnungen; für Sie als Domaininhaber bedeutet es, dass Ihr Ruf missbraucht werden kann und legitime Mails von Empfängern zunehmend skeptisch behandelt werden. Drei ergänzende Verfahren schließen die Lücke:

• SPF (Sender Policy Framework, RFC 7208): Die Domain veröffentlicht eine Liste der Server, die in ihrem Namen senden dürfen. Der Empfänger vergleicht die IP-Adresse des einliefernden Servers mit dieser Liste.
• DKIM (DomainKeys Identified Mail, RFC 6376): Der sendende Server signiert Teile der Nachricht mit einem privaten Schlüssel. Den passenden öffentlichen Schlüssel veröffentlicht die Domain im DNS. Der Empfänger prüft, ob die Signatur passt und die Nachricht unterwegs unverändert blieb.
• DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489): Die Domain legt fest, ob SPF oder DKIM zur sichtbaren Absenderadresse passen müssen (Alignment), und gibt eine Handlungsanweisung (nichts tun, in den Spam, ablehnen) sowie eine Adresse für Berichte vor.

Warum nicht eines allein? SPF bricht, wenn eine Mail weitergeleitet wird, weil die weiterleitende IP nicht auf der Liste steht. DKIM überlebt die Weiterleitung in der Regel, wird aber durch Änderungen am signierten Inhalt (etwa einen von Mailinglisten angehängten Fußtext) ungültig. DMARC verlangt nur, dass eines von beiden besteht und zur Absenderdomain passt. Das macht die Kombination robust.

Alle drei Verfahren leben im DNS. Wer die Grundlagen von Einträgen, TTL und Fehlerbildern auffrischen möchte, findet sie in DNS-Fehler erkennen und beheben.

Wie funktioniert SPF und wie sieht ein Eintrag aus?

Ein SPF-Eintrag ist ein TXT-Eintrag auf dem Domainnamen selbst (nicht auf einer Subdomain wie _spf). Er beginnt mit v=spf1 und listet dann Mechanismen, deren Auswertung von links nach rechts erfolgt, bis einer zutrifft:

ihre-domain.de.  3600  IN  TXT  "v=spf1 mx include:_spf.mailanbieter.example ip4:203.0.113.25 -all"

Der entscheidende Wert ist das Ende: -all verlangt strikte Einhaltung, ~all ist die nachsichtige Variante, die viele Betreiber während der Einführung nutzen. Setzen Sie nie +all; das erlaubt jedem Server der Welt, in Ihrem Namen zu senden.

SPF prüft übrigens nicht die Absenderadresse, die der Empfänger im Mailprogramm sieht (From:), sondern die technische Absenderadresse im Umschlag der Nachricht (MAIL FROM bzw. Return-Path) sowie den Namen, mit dem sich der Server meldet (HELO). Erst DMARC schlägt die Brücke zum sichtbaren Absender.

Warum ist SPF so oft ungültig? Das 10-Abfragen-Limit

RFC 7208 begrenzt die Zahl der DNS-Abfragen, die eine SPF-Auswertung auslösen darf, auf 10 (Mechanismen include, a, mx, ptr, exists sowie das Modifikator-Element redirect). Überschreitet die Prüfung das Limit, ist das Ergebnis ein Fehler (permerror), und manche Empfänger behandeln die Mail dann wie einen SPF-Fehlschlag. Dazu kommen Grenzen für leere Abfragen („void lookups“, Standard höchstens 2).

Das Limit ist schnell erreicht: Jeder Anbieter, den Sie per include: eintragen, bringt seine eigenen Unterabfragen mit. Newsletter-Dienst, Shop-System, CRM, Support-Tool, Hoster und Buchhaltung ergeben leicht 8 bis 12 Abfragen.

Zwei weitere Regeln: Pro Domain darf es nur einen TXT-Eintrag mit v=spf1 geben. Zwei Einträge, etwa einer vom Hoster und einer vom Newsletter-Anbieter, führen zu einem permerror; fassen Sie sie zu einem zusammen. Und ein einzelner TXT-String ist auf 255 Zeichen begrenzt; längere Einträge müssen in mehrere Zeichenketten innerhalb desselben Eintrags aufgeteilt werden, was die meisten DNS-Oberflächen automatisch erledigen.

Wie funktioniert DKIM?

Bei DKIM erzeugen Sie (oder Ihr Mailanbieter) ein Schlüsselpaar. Der private Schlüssel bleibt auf dem sendenden System und signiert ausgehende Nachrichten; der öffentliche steht im DNS unter einem Selektor: selektor._domainkey.ihre-domain.de. Der Selektor erlaubt mehrere Schlüssel parallel, etwa einen je Dienst oder zum Schlüsselwechsel.

s1._domainkey.ihre-domain.de.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Jede signierte Mail enthält einen Header DKIM-Signature mit dem Selektor (s=), der Domain (d=) und der Signatur. Der Empfänger liest daraus, wo er den öffentlichen Schlüssel findet. Üblich sind RSA-Schlüssel mit 2.048 Bit; 1.024 Bit gelten als schwächer, und manche Anbieter stellen auf 2.048 Bit um. Da lange Schlüssel die 255-Zeichen-Grenze überschreiten, wird der Wert in mehrere Zeichenketten geteilt.

Wichtig: Von außen lässt sich ein DKIM-Eintrag nur finden, wenn der Selektor bekannt ist. Es gibt keine Abfrage „alle Schlüssel der Domain“. Den Selektor entnehmen Sie dem DKIM-Signature-Header einer echten, von Ihrem System gesendeten Mail (s=...) oder der Anleitung Ihres Mailanbieters. Rotieren Sie Schlüssel gelegentlich, und löschen Sie alte Selektoren erst, wenn nichts mehr damit signiert.

Wie funktioniert DMARC und was bedeuten die Policies?

DMARC ist ein TXT-Eintrag auf _dmarc.ihre-domain.de:

_dmarc.ihre-domain.de.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-berichte@ihre-domain.de; adkim=r; aspf=r"

Eine Mail besteht DMARC, wenn SPF oder DKIM bestanden haben und die dabei geprüfte Domain zur sichtbaren Absenderdomain (From:) passt. Bei „relaxed“ genügt, dass beide zur selben organisatorischen Domain gehören (mail.ihre-domain.de passt zu ihre-domain.de); bei „strict“ muss sie exakt übereinstimmen. Das ist die häufigste Falle bei Dienstleistern: Ein Newsletter-Tool kann SPF bestehen, aber mit seiner eigenen Absenderdomain im Umschlag. Dann besteht SPF zwar, passt aber nicht zu Ihrer From:-Adresse. Erst eine DKIM-Signatur mit Ihrer eigenen Domain (d=ihre-domain.de) löst das.

Von none zu reject: der empfohlene Weg

1. Beobachten: p=none und eine rua-Adresse. Es passiert nichts, aber Sie erhalten tägliche Berichte der großen Empfänger.
2. Inventarisieren: Aus den Berichten ergibt sich, welche Server und Dienste in Ihrem Namen senden. Legitime Quellen mit SPF/DKIM ausstatten, Unbekanntes klären.
3. Anziehen: p=quarantine (zunächst mit pct=10, dann steigern): Fehlschlagende Mails landen im Spam.
4. Durchsetzen: p=reject: Fehlschlagende Mails werden abgelehnt.

Zwischen den Stufen sollten Sie jeweils einige Wochen einplanen; jahreszeitliche Absender (Jahresabrechnung, Aktionsmailings) tauchen sonst zu spät auf. Beachten Sie, dass Berichte an eine Adresse bei einer anderen Domain zusätzlich eine Freigabe im DNS dieser Domain benötigen (RFC 7489 beschreibt den Mechanismus); alternativ verwenden Sie eine Adresse unter Ihrer eigenen Domain oder einen Auswertungsdienst, der die Einrichtung vorgibt.

Warum ist das heute mehr als „nice to have“?

Nach unserem Kenntnisstand verlangen große Mailanbieter wie Google und Yahoo seit 2024 von Absendern größerer Mengen (Newsletter, Shopmails) eine Authentifizierung mit SPF und DKIM sowie einen DMARC-Eintrag; auch weitere Anbieter haben ähnliche Anforderungen angekündigt oder eingeführt. Die genauen Schwellen und Fristen sollten Sie in den Richtlinien der jeweiligen Anbieter nachlesen, sie können sich ändern. Unabhängig davon gilt: Ohne saubere Authentifizierung steigt das Risiko, dass legitime Mails (Bestellbestätigung, Passwort-Reset, Rechnung) im Spam landen oder abgewiesen werden, und das ist für einen Shop ein geschäftlicher Schaden, der nicht als Ausfall erkannt wird (siehe Onlineshop überwachen).

Wie prüfen Sie SPF, DKIM und DMARC mit dig?

# SPF (TXT der Domain; auf "v=spf1" achten)
dig +short TXT ihre-domain.de

# DMARC
dig +short TXT _dmarc.ihre-domain.de

# DKIM (Selektor s1 als Beispiel)
dig +short TXT s1._domainkey.ihre-domain.de

# Mailserver der Domain
dig +short MX ihre-domain.de

# Bei einem bestimmten autoritativen Nameserver nachfragen
dig +short TXT ihre-domain.de @ns1.ihr-dns-anbieter.example

Typische Befunde: Zwei Zeilen mit v=spf1 (ungültig, siehe oben), kein _dmarc-Eintrag (leere Ausgabe), ein DKIM-Eintrag, dessen p=-Wert abgeschnitten wurde (Fehler beim Einfügen), oder ein SPF-Eintrag ohne den aktuellen Mailanbieter. Beachten Sie die TTL: Nach einer Änderung sehen Resolver zunächst den alten Wert. Eine Sendeprobe, bei der Sie sich selbst eine Mail an ein Postfach bei einem großen Anbieter schicken und im Quelltext der Mail das Ergebnis der Authentifizierung ansehen (Header Authentication-Results, Einträge spf=pass, dkim=pass, dmarc=pass), zeigt, was tatsächlich beim Empfänger ankommt.

Welche typischen Fehler passieren?

Checkliste: E-Mail-Authentifizierung einrichten

1. Alle Systeme auflisten, die Mails mit Ihrer Domain senden (Mailserver, Newsletter, Shop, CRM, Formulare, Ticketsystem).
2. Genau einen SPF-Eintrag mit allen erlaubten Quellen anlegen und auf höchstens 10 Abfragen prüfen.
3. Für jeden Dienst DKIM aktivieren und den Selektor-Eintrag im DNS setzen.
4. Einen DMARC-Eintrag mit p=none und rua anlegen.
5. Per Test-Mail an ein externes Postfach spf, dkim und dmarc auf „pass“ prüfen.
6. Berichte einige Wochen auswerten, unbekannte Quellen klären.
7. Schrittweise auf quarantine und reject erhöhen.
8. Bei jedem neuen Absenderdienst und bei jedem Hosterwechsel den DNS-Stand erneut prüfen.

Grenzen und Einordnung

SPF, DKIM und DMARC beweisen nur, dass eine Mail von einem berechtigten System Ihrer Domain stammt, nicht, dass der Inhalt seriös ist. Täuschend ähnliche Domains (ihre-dornain.de) fängt DMARC nicht ab, denn für diese Domain gelten andere Einträge. Weitergeleitete Mails können SPF verlieren, und Mailinglisten, die Inhalte verändern, können DKIM brechen; deshalb ist DMARC mit „SPF oder DKIM“ ausgelegt, schließt solche Fälle aber nicht vollständig aus. Auch ersetzt es keine Spam- oder Inhaltsfilter beim Empfänger: Authentifizierung ist Voraussetzung für gute Zustellung, kein Garant dafür.

Zudem sehen Sie von außen nur den DNS-Teil: Ob Ihr Mailserver tatsächlich mit dem privaten Schlüssel signiert, zeigt erst eine Test-Mail. Eine automatische Prüfung kann Fehler im Eintrag finden (fehlender DMARC, doppelte SPF-Einträge), aber nicht beurteilen, ob alle tatsächlichen Absender im Eintrag stehen. Die Einordnung dazu liefert auch Grenzen automatischer Website-Prüfungen.

Wie setzen Sie das mit UPTIMESHIELD um?

Der Sofort-Report liest im Bereich „DNS & E-Mail“ unter anderem A-, AAAA-, MX- und NS-Einträge sowie SPF, DMARC, CAA und DNSSEC aus und weist in der Maßnahmenliste auf Auffälligkeiten hin. Für das Ausmaß der Prüfung gilt: Er betrachtet, was öffentlich im DNS steht; ob alle Ihre Versandsysteme berücksichtigt sind, kann er nicht wissen. Dauerhaft im Blick behalten Sie die Einträge mit dem Monitortyp DNS, der die Auflösung Ihrer Domain regelmäßig prüft und bei Problemen alarmiert, sowie mit den wiederkehrenden Website-Checks im Dashboard, die DNS und Sicherheit in Abständen neu bewerten und Veränderungen als „neu“ oder „behoben“ zeigen. Da CAA-Einträge festlegen, welche Zertifizierungsstellen Zertifikate ausstellen dürfen, lohnt sich ein Blick auf die gesamte DNS-Konfiguration, siehe SSL-Zertifikate rechtzeitig prüfen. Das Konto ist kostenlos (Preise).