SPF, DKIM und DMARC einrichten
Die drei DNS-Einträge in der richtigen Reihenfolge aufsetzen, typische Syntaxfehler vermeiden und von p=none schrittweise auf p=reject kommen, ohne Mails zu verlieren.
Das Wichtigste
- SPF prüft die sendende IP, DKIM die Unversehrtheit über eine Signatur, DMARC verbindet beides mit einer Regel und einem Bericht.
- Pro Domain ist genau ein SPF-Eintrag erlaubt. Zwei Einträge sind ein permanenter Fehler, kein additives Verhalten.
- SPF erlaubt höchstens zehn DNS-Abfragen. Jedes
include:zählt mit, und die Grenze ist schneller erreicht als gedacht. - DMARC beginnt immer mit
p=none. Erst wenn die Berichte sauber sind, geht es überquarantinenachreject.
Die drei Einträge lösen unterschiedliche Probleme und ergeben erst zusammen einen Absenderschutz, auf den man sich verlassen kann.
Was jeder Eintrag leistet
| prüft | überlebt Weiterleitung | schützt die sichtbare From-Zeile | |
|---|---|---|---|
| SPF | sendende IP gegen eine Liste | nein | nein |
| DKIM | Signatur über Header und Text | ja, wenn unverändert | nein |
| DMARC | Verknüpfung beider mit From | ja | ja |
Der letzte Punkt ist der Grund, warum SPF allein nicht genügt: SPF prüft die Envelope-Absenderdomain, der Empfänger sieht aber die Domain im From-Header. Ein Absender kann SPF sauber bestehen und trotzdem in der Anzeige deine Domain tragen.
Schritt 1: SPF
example.com. TXT "v=spf1 mx include:_spf.dienstleister.de -all"
mxerlaubt die Server, die in deinem MX-Record stehen.include:bindet den SPF-Eintrag eines Dienstleisters ein.-allweist alles andere hart ab.~allist die weiche Variante für die Einführungsphase.
Zwei Fehler, die sich hartnäckig halten:
Zwei SPF-Einträge. Der Standard erlaubt genau einen. Zwei TXT-Einträge mit v=spf1 ergeben permerror – nicht die Vereinigung beider Listen. Alle Freigaben gehören in eine Zeile.
Zu viele DNS-Abfragen. Die Obergrenze liegt bei zehn. Jedes include, a, mx, ptr und exists zählt, und include zählt auch die Abfragen, die im eingebundenen Eintrag stecken. Wer Mailhoster, Newsletter-Dienst und Shopsystem einbindet, ist oft schon darüber.
# Auswertung inklusive Abfragezähler
dig +short TXT example.com | grep spf1
Schritt 2: DKIM
DKIM signiert Header und Text mit einem privaten Schlüssel. Der öffentliche liegt im DNS.
# Schlüsselpaar erzeugen (OpenDKIM)
opendkim-genkey -b 2048 -d example.com -s mail2026
Der erzeugte DNS-Eintrag sieht so aus:
mail2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
Der Selektor (mail2026) ist frei wählbar. Ein Datum darin macht die Rotation einfach: Neuen Schlüssel mit neuem Selektor anlegen, veröffentlichen, umschalten, alten Selektor erst nach einigen Tagen entfernen – so bleiben unterwegs befindliche Mails prüfbar.
2048 Bit sind der praktische Standard. 1024 gilt als schwach, alles darüber passt oft nicht mehr in einen TXT-Eintrag ohne Aufteilung.
Schritt 3: DMARC
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; adkim=r; aspf=r"
p=none heisst: nichts ablehnen, nur berichten. Genau so fängt man an. Die Berichte zeigen, welche Systeme in deinem Namen versenden – erfahrungsgemäss sind darunter immer welche, an die niemand gedacht hat: Ticketsystem, Monitoring, ein altes Kontaktformular, der Newsletter-Dienst einer einzelnen Abteilung.
Der Weg zur Durchsetzung:
p=none, mindestens zwei bis vier Wochen. Berichte auswerten.- Jeden legitimen Versender mit SPF und DKIM ausstatten und das Alignment prüfen.
p=quarantine; pct=10, dann schrittweisepcterhöhen.p=reject, wenn die Berichte über mehrere Wochen sauber sind.
adkim und aspf steuern, wie streng das Alignment gilt: r (relaxed) erlaubt Subdomains, s (strict) verlangt exakte Übereinstimmung. Relaxed ist der sinnvolle Startwert.
Alignment: der Punkt, an dem es klemmt
Ein Newsletter-Dienstleister versendet typischerweise mit eigener Envelope-Domain:
Envelope-From: bounce-123@mail.dienstleister.de -> SPF prüft dienstleister.de
From: news@example.com -> DMARC erwartet example.com
SPF besteht, DMARC scheitert. Zwei Auswege:
- Der Dienstleister versendet über eine Subdomain von dir (
news.example.com), für die du den SPF-Eintrag setzt. - Der Dienstleister signiert mit DKIM unter deiner Domain. Dafür veröffentlichst du seinen öffentlichen Schlüssel unter deinem
_domainkey.
Beides zusammen ist die robuste Variante.
Prüfen
dig +short TXT example.com | grep spf1
dig +short TXT mail2026._domainkey.example.com
dig +short TXT _dmarc.example.com
Der aussagekräftigere Test ist eine echte Mail an ein Postfach bei einem grossen Anbieter. Im Quelltext der empfangenen Nachricht steht das Ergebnis:
Authentication-Results: mx.example-provider.de;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
Drei Mal pass – erst dann ist der Weg zu p=reject frei. Und teste jeden Versandweg einzeln: Der Newsletter kann bestehen, während das Kontaktformular durchfällt.
Häufige Fragen
Reicht SPF allein nicht aus?
Nein. SPF bricht bei jeder Weiterleitung, weil die weiterleitende Instanz eine andere IP hat. DKIM übersteht Weiterleitungen, solange der Text unverändert bleibt. Erst DMARC verknüpft beide Prüfungen mit dem sichtbaren Absender in der From-Zeile – und genau den sieht der Empfänger.
Was bedeutet der Alignment-Fehler bei DMARC?
DMARC verlangt, dass die Domain aus der From-Zeile zur Domain passt, die SPF oder DKIM geprüft haben. Ein Newsletter-Dienst, der mit eigener Envelope-Domain versendet, besteht SPF, scheitert aber am Alignment. Lösung ist eine eigene Versanddomain beim Dienstleister plus DKIM mit deiner Domain.
Wie viele DNS-Abfragen erlaubt SPF?
Zehn. Jedes include, a, mx, ptr und exists zählt. Wer drei Dienstleister einbindet, ist oft schon darüber – das Ergebnis ist permerror, und strenge Empfänger werten das wie ein Fail.
Wohin gehen die DMARC-Berichte?
An die Adressen in rua und ruf. rua liefert aggregierte XML-Berichte, meist täglich, und ist der nützliche Teil. ruf enthält einzelne fehlgeschlagene Nachrichten und wird von vielen Providern aus Datenschutzgründen gar nicht erst gesendet.
Weiterlesen
- Greylisting: Funktionsweise, Nutzen und Grenzen
Warum ein temporäres Ablehnen den Grossteil des Bot-Spams stoppt, was es an Zustellverzögerung kostet und wie Whitelists den Ärger begrenzen.
- Postfix-Grundkonfiguration für kleine Server
main.cf-Einstellungen, die wirklich zählen: Restriktionen, TLS, Limits und ein Setup, das kein offenes Relay wird.
- Mailadressen auf Webseiten vor Harvestern schützen
Was gegen automatisiertes Absammeln wirkt, was nur Barrierefreiheit kostet, und warum das Kontaktformular meist die bessere Antwort ist.
- PHP-Mailformulare gegen Header-Injection absichern
Eingaben validieren, Header-Zeilen filtern, Rate-Limits setzen und Spam abfangen, ohne echte Anfragen zu blockieren.