SPF, DKIM und DMARC

Jeder kann deine Domain in die Absenderzeile einer Mail schreiben – das Mailprotokoll hält niemanden davon ab. Drei DNS-Einträge sorgen dafür, dass empfangende Server deine Mails von Fälschungen unterscheiden können.

Kurz gesagt

SPF, DKIM und DMARC sind drei DNS-gestützte Prüfungen gegen gefälschte Absender. SPF nennt die Rechner, die für eine Domain Mails verschicken dürfen [1], DKIM ergänzt eine kryptografische Signatur, deren öffentlicher Schlüssel im DNS steht [2], und DMARC legt fest, was Empfänger mit durchgefallenen Mails tun sollen und wohin sie Berichte schicken [4]. Was hat sich 2026 geändert? Seit Mai 2026 regelt RFC 9989 DMARC als Standards-Track-Dokument und ersetzt RFC 7489 [4]. Unsere Einschätzung: Richte alle drei ein, starte DMARC mit p=none und zieh die Regel erst an, wenn die Berichte sauber aussehen.

So funktioniert’s

1. SPF. Eine Domain veröffentlicht einen TXT-Eintrag, der mit v=spf1 beginnt und die Rechner nennt, die die Domain verwenden dürfen [1]. SPF prüft den Umschlag-Absender (MAIL FROM) und den HELO-Namen, nicht die Absenderzeile, die du im Mailprogramm siehst [1]. Ein Qualifier legt das Ergebnis je Mechanismus fest: + für pass, - für fail, ~ für softfail und ? für neutral [1]. Eine Auswertung darf höchstens 10 Begriffe mit DNS-Abfrage nutzen, etwa include, a, mx, ptr und exists; mehr führen zu einem dauerhaften Fehler [1].
2. DKIM. Der sendende Server signiert ausgewählte Kopfzeilen und den Inhalt der Mail. Der Header DKIM-Signature nennt in d= die signierende Domain und in s= einen Selektor, und der Empfänger holt den öffentlichen Schlüssel aus einem TXT-Eintrag unter selector._domainkey.domain [2]. RFC 8301 verbietet rsa-sha1 und verlangt RSA-Schlüssel mit mindestens 1.024 Bit, empfohlen sind mindestens 2.048 Bit [3].
3. DMARC. Der Eintrag steht unter _dmarc vor deiner Domain [4]. Eine Mail besteht DMARC, wenn SPF oder DKIM für eine Domain gelingt, die zur Autoren-Domain in der Absenderzeile passt, entweder locker (gleiche Organisationsdomain) oder streng (identisch) [4]. Das Tag p legt die Regel fest: none, quarantine oder reject [4].
4. Was RFC 9989 ändert. Das Tag pct fällt weg; mit dem neuen Tag t=y bittet eine Domain um einen Testmodus, in dem Empfänger eine Stufe milder handeln als veröffentlicht [4]. Die Organisationsdomain wird jetzt per „DNS Tree Walk“ ermittelt statt über eine Public Suffix List, und np legt eine Regel für nicht existierende Subdomains fest [4]. Die Berichtsformate stehen nun in RFC 9990 (Sammelberichte) und RFC 9991 (Fehlerberichte) [4].
5. Berichte. Mit rua schicken Empfänger Sammelberichte an eine Adresse deiner Wahl [4]. Daran siehst du, welche Server in deinem Namen Mails verschicken, auch die, die du vergessen hattest.

Ein Praxisbeispiel

Für example.com, das über einen einzigen Anbieter verschickt, könnten die drei Einträge so aussehen; Anbietername und Schlüssel sind Platzhalter:

example.com.                  TXT "v=spf1 include:spf.provider.example -all"
sel1._domainkey.example.com.  TXT "v=DKIM1; k=rsa; p=<öffentlicher Schlüssel vom Anbieter>"
_dmarc.example.com.           TXT "v=DMARC1; p=none; rua=mailto:dmarc-berichte@example.com"

Was das öffentliche DNS liefert, prüfst du etwa mit dig +short TXT _dmarc.example.com. Zeigen die Berichte nur noch deine eigenen Server, stellst du p auf quarantine und später auf reject [4]. Domain und Anbieter sind ausgedacht und nicht unser Aufbau.

Prüfliste

• Liste alle Dienste auf, die für deine Domain Mails verschicken, auch Newsletter- und Ticketsysteme, bevor du den SPF-Eintrag schreibst [1].
• Bleib bei SPF innerhalb von 10 DNS-Abfragen; verschachtelte include-Angaben zählen mit [1].
• Nutze DKIM-Schlüssel mit mindestens 2.048 Bit, wenn dein Anbieter die Wahl lässt [3].
• Starte DMARC mit p=none und einer rua-Adresse und lies die Berichte [4].
• Wechsle erst zu quarantine oder reject, wenn alle echten Mails bestehen [4].
• Entferne das Tag pct, wenn du einen alten Eintrag überarbeitest, denn RFC 9989 kennt es nicht mehr [4].