Zum Inhalt springen

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.

Zuletzt geprüft: Gedacht für: Zustellbarkeit und Absenderschutz

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 über quarantine nach reject.

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 Weiterleitungschützt die sichtbare From-Zeile
SPFsendende IP gegen eine Listeneinnein
DKIMSignatur über Header und Textja, wenn unverändertnein
DMARCVerknüpfung beider mit Fromjaja

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"
  • mx erlaubt die Server, die in deinem MX-Record stehen.
  • include: bindet den SPF-Eintrag eines Dienstleisters ein.
  • -all weist alles andere hart ab. ~all ist 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:

  1. p=none, mindestens zwei bis vier Wochen. Berichte auswerten.
  2. Jeden legitimen Versender mit SPF und DKIM ausstatten und das Alignment prüfen.
  3. p=quarantine; pct=10, dann schrittweise pct erhöhen.
  4. 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.