SPF, DKIM und DMARC: wie die drei Einträge zusammenarbeiten

Wer E-Mails mit der eigenen Domain verschickt, kommt an drei Abkürzungen nicht vorbei: SPF, DKIM und DMARC. Alle drei stehen als TXT-Einträge im DNS deiner Domain, und alle drei sollen verhindern, dass Fremde in deinem Namen Mails versenden. Sie prüfen dabei aber verschiedene Dinge. Erst zusammen schützen sie die Adresse, die der Empfänger in seinem Postfach sieht. Wie du jeden Eintrag einzeln anlegst, steht auf den Seiten zu SPF, DKIM und DMARC.

Zwei Absender in jeder Mail

Eine E-Mail hat zwei Absenderangaben. Die erste ist der Umschlagabsender, technisch MAIL FROM. Ihn nennt der sendende Server beim Einliefern, und an ihn gehen Fehlermeldungen wie "Postfach voll". Der Empfänger sieht ihn normalerweise nicht. Die zweite ist das Feld From im Kopf der Mail. Diese Adresse zeigt das Mailprogramm als Absender an.

Beide Angaben können völlig verschieden sein. Ein Newsletterdienst verschickt deine Rundmail zum Beispiel mit einem Umschlagabsender aus seiner eigenen Domain, während im From-Feld deine Adresse steht. Genau diese Lücke nutzen Fälscher: Sie setzen eine fremde Adresse ins From-Feld und verschicken die Mail von einem beliebigen Server.

SPF: welche Server senden dürfen

Mit SPF (Sender Policy Framework) veröffentlichst du eine Liste der Server, die Mails für deine Domain einliefern dürfen. Der Eintrag beginnt mit "v=spf1" und steht als TXT-Eintrag auf der Domain ^[1]. Der empfangende Server vergleicht die IP-Adresse des einliefernden Servers mit dieser Liste. Das Ergebnis heißt dann etwa pass (erlaubt), fail (nicht erlaubt) oder softfail (wahrscheinlich nicht erlaubt) ^[1].

SPF prüft dabei den Umschlagabsender und den Namen, mit dem sich der Server meldet (HELO). Das sichtbare From-Feld prüft SPF nicht ^[1]. Eine Mail kann also SPF bestehen, obwohl im From-Feld eine gefälschte Adresse steht, solange der Fälscher einen Umschlagabsender aus einer Domain verwendet, deren SPF ihn erlaubt.

Eine zweite Schwäche zeigt sich bei Weiterleitungen. Leitet ein Postfach deine Mail an eine andere Adresse weiter, liefert ein fremder Server sie ein, der in deinem SPF-Eintrag nicht steht. RFC 7208 beschreibt dieses Problem ausdrücklich; eine Lösung ist, dass der Weiterleiter den Umschlagabsender auf seine eigene Domain umschreibt ^[1]. Ohne diese Umschreibung schlägt die SPF-Prüfung bei der Weiterleitung fehl ^[1].

DKIM: eine Signatur für jede Mail

DKIM (DomainKeys Identified Mail) arbeitet mit Schlüsselpaaren. Der sendende Server unterschreibt jede Mail mit einem privaten Schlüssel und fügt eine Kopfzeile DKIM-Signature hinzu. Darin stehen unter anderem die signierende Domain (d=) und ein Selektor (s=) ^[2]. Den passenden öffentlichen Schlüssel legst du als TXT-Eintrag unter selektor._domainkey.deine-domain.de ab ^[2]. Der Empfänger holt sich den Schlüssel aus dem DNS und prüft, ob die Signatur stimmt.

Das Feld From muss immer mitsigniert werden ^[2]. Eine geprüfte DKIM-Signatur belegt also, dass die Mail mit dem Schlüssel der signierenden Domain unterschrieben wurde und danach nicht verändert worden ist ^[2]. Die Signatur gilt für Kopf und Inhalt der Mail, die IP-Adresse des Servers spielt dabei keine Rolle. Bei einfachen Weiterleitungen bleibt sie deshalb im Allgemeinen gültig ^[4]. Ändert ein Verteiler unterwegs den Betreff oder hängt eine Fußzeile an, ist sie dagegen oft ungültig ^[2].

Auch DKIM allein schützt das From-Feld nicht. RFC 6376 verlangt nicht, dass die signierende Domain mit der Adresse im From-Feld übereinstimmt ^[2]. Ein Fälscher kann eine Mail mit gefälschtem From-Feld also mit seiner eigenen Domain gültig signieren. Für die Schlüssellänge gilt seit RFC 8301: mindestens 1.024 Bit, empfohlen sind 2.048 Bit, und das alte Verfahren rsa-sha1 darf nicht mehr verwendet werden ^[3].

DMARC: die Verbindung zum sichtbaren Absender

DMARC schließt die Lücke, die SPF und DKIM offenlassen. Der Eintrag steht unter _dmarc.deine-domain.de und beginnt mit "v=DMARC1" ^[4]. Eine Mail besteht DMARC nur, wenn SPF oder DKIM erfolgreich war und die geprüfte Domain zur Domain im From-Feld passt. Diese Übereinstimmung heißt Alignment ^[4]. Im entspannten Modus (relaxed, Standard) genügt dieselbe Organisationsdomain, also etwa news.beispiel.de zu beispiel.de. Im strengen Modus (strict) müssen beide Namen gleich sein ^[4].

Außerdem legt DMARC fest, was der Empfänger mit Mails tun soll, die durchfallen. Die Angabe p=none heißt nur beobachten, p=quarantine bedeutet, dass du solche Mails für verdächtig hältst, und p=reject erklärt die Nutzung deiner Domain in diesen Mails für ungültig ^[4]. Was der Empfänger daraus macht, entscheidet er selbst. RFC 9989 verlangt, dass er Mails nicht allein wegen p=reject ablehnt und sie ohne weitere Prüfung wie bei p=quarantine behandelt ^[4]. Mit rua= nennst du eine Adresse, an die Empfänger regelmäßig Sammelberichte schicken. Daraus siehst du, welche Server Mails mit deiner Domain verschicken und ob sie SPF und DKIM bestehen.

Für Subdomains kannst du eigene Regeln setzen. Die Angabe sp= gilt für vorhandene Subdomains, np= für Subdomains, die es im DNS gar nicht gibt. Fehlen beide, greift die Hauptrichtlinie p= ^[4]. Mit np=reject erklärst du zum Beispiel Mails von einem ausgedachten Absender wie rechnung.deine-domain.de für ungültig, auch wenn deine Hauptdomain noch im Beobachtungsmodus läuft ^[4].

Seit Mai 2026 ist DMARC in RFC 9989 als Standard der IETF beschrieben. Es löst RFC 7489 ab, das nur den Status einer Information hatte ^[4]. Bestehende Einträge mit "v=DMARC1" bleiben gültig. Die Angabe pct= für eine prozentuale Einführung gibt es im neuen Standard nicht mehr; an ihre Stelle tritt ein Testmodus t= ^[4].

Wie die drei zusammen entscheiden

Die folgende Übersicht zeigt, was jedes Verfahren prüft und wo es im DNS steht.

Ein Beispiel: Du verschickst Rechnungen über deinen eigenen Mailserver und einen Newsletter über einen Dienst. Die Rechnungen bestehen SPF, weil dein Server im Eintrag steht, und das passt zur Domain im From-Feld. Der Newsletter besteht SPF vielleicht nur für die Domain des Dienstes. Für DMARC zählt dann allein DKIM, und zwar nur, wenn der Dienst mit deiner Domain signiert. Damit DMARC besteht, muss der Dienst deshalb mit deiner Domain signieren, und dafür legst du den öffentlichen Schlüssel unter deiner Domain im DNS ab ^[2].

Was große Postfachanbieter verlangen

Google hat für Mails an Gmail-Konten seit dem 01.02.2024 feste Regeln. Wer an Gmail sendet, braucht mindestens SPF oder DKIM. Wer mehr als 5.000 Mails am Tag an Gmail-Konten schickt, braucht SPF und DKIM und einen DMARC-Eintrag; dabei reicht die Richtlinie p=none. Die Domain im From-Feld muss außerdem zur Domain von SPF oder DKIM passen ^[5]. Die in den Postmaster Tools gemessene Spamrate soll unter 0,3 Prozent bleiben ^[5].

Auch das Bundesamt für Sicherheit in der Informationstechnik hat das Thema aufgegriffen. Die Technische Richtlinie BSI TR-03182 stellt prüfbare Anforderungen an die E-Mail-Authentifizierung bei Mailanbietern und bei Betreibern eigener Mailserver in Organisationen ^[6].

Reihenfolge beim Einrichten

1. Liste alle Dienste auf, die Mails mit deiner Domain verschicken: eigener Mailserver, Postfachanbieter, Newsletterdienst, Shop, Kontaktformular, Rechnungsprogramm.
2. Lege den SPF-Eintrag an und nimm jeden dieser Dienste auf. Achte auf die Grenze von zehn DNS-Abfragen, die auf der Seite SPF-Eintrag erstellen und prüfen erklärt ist.
3. Schalte DKIM bei jedem Dienst ein, der es anbietet, und trage die öffentlichen Schlüssel ein.
4. Veröffentliche DMARC mit p=none und einer Adresse für Berichte. RFC 9989 nennt diesen Start ausdrücklich als üblichen Weg, um übersehene Absender zu finden ^[4].
5. Werte die Berichte einige Wochen aus und korrigiere fehlende Einträge.
6. Stelle dann auf p=quarantine und später auf p=reject um.

Den letzten Schritt solltest du nicht überstürzen. RFC 9989 warnt, dass p=reject bei Mailinglisten, Weiterleitungen und anderen indirekten Mailwegen Probleme macht. Domains, deren Nutzer an Mailinglisten schreiben, sollen p=reject möglichst nicht veröffentlichen. Wer es doch will, soll zuvor mindestens einen Monat p=none und danach gleich lange p=quarantine einsetzen und die Berichte vergleichen ^[4]. Mit dem DNS-Check kannst du prüfen, ob deine TXT-Einträge veröffentlicht sind.

Was die drei nicht leisten

SPF, DKIM und DMARC schützen deine eigene Domain vor Missbrauch. Gegen Mails von ähnlich klingenden Domains wie beispie1.de helfen sie nicht, denn diese Domains haben ihre eigenen, gültigen Einträge. Verschlüsselt wird die Mail durch die drei Einträge auch nicht, dafür ist TLS zuständig. Wie du gefälschte Absender als Empfänger erkennst, erklärt betrug.domain-root.de im Beitrag Gefälschte Absender erkennen. Wenn deine eigenen Mails trotz aller Einträge im Spam landen, hilft die Seite Eigene E-Mails landen im Spam weiter.

1. Gesetz RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. IETF, S. Kitterman. Stand April 2014. abgerufen am 29.10.2026
2. Gesetz RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. IETF. Stand September 2011. abgerufen am 29.10.2026
3. Gesetz RFC 8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM). IETF. Stand Januar 2018. abgerufen am 29.10.2026
4. Gesetz RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC). IETF, T. Herr, J. Levine. Stand Mai 2026. abgerufen am 29.10.2026
5. Organisation Richtlinien für E-Mail-Absender. Google, Gmail-Hilfe. Stand 2026. abgerufen am 29.10.2026
6. Behörde Technische Richtlinie BSI TR-03182 E-Mail-Authentifizierung. Bundesamt für Sicherheit in der Informationstechnik. Stand Version 1.0. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.