Cybersicherheit

E-Mail-Authentifizierung für eine persönliche Domain — Wie SPF, DKIM und DMARC zusammenspielen

Geschrieben von Adam Muiz 21 Aug 2026 Aktualisiert: 21 Aug 2026 11 Min. gelesen

Eine persönliche Domain kann das Zurücksetzen eines Passworts über einen Webhoster, die Antwort auf ein Kontaktformular über einen Mailbox-Anbieter und einen Newsletter über einen dritten Dienst versenden. Für Leser können alle drei Nachrichten dieselbe Domain hinter From: anzeigen. Beim empfangenden Mailserver treffen sie jedoch über unterschiedliche Systeme und mit unterschiedlichen technischen Identitäten ein.

Genau an dieser Lücke setzen SPF, DKIM und DMARC an. Häufig werden sie als drei DNS-Einträge vorgestellt, die lediglich kopiert werden müssen. Diese Darstellung verdeckt jedoch die schwierigere Frage: Welche Identität prüft der jeweilige Mechanismus tatsächlich? Ein Eintrag kann syntaktisch gültig sein, während legitime E-Mails trotzdem die Authentifizierung nicht bestehen. Eine Nachricht kann außerdem SPF oder DKIM bestehen, ohne das zu beweisen, was eine flüchtige Betrachtung des sichtbaren Absenders vermuten lässt.

Dieser Leitfaden entwickelt zunächst ein praktisches Denkmodell für eine persönliche Domain und leitet daraus anschließend eine vorsichtige Einführungsreihenfolge ab. Er ist keine anbieterspezifische Anleitung. Die richtigen Werte hängen von sämtlichen Diensten ab, die E-Mails für die Domain versenden dürfen.

Eine Nachricht kann mehrere Absenderidentitäten enthalten

Das Wort „Absender“ ist bei E-Mails mehrdeutig. Drei Domainidentitäten sind besonders relevant:

Header From: die Autorenadresse, die Mailprogramme dem Leser üblicherweise anzeigen, beispielsweise [email protected].
Envelope Sender: die über SMTP MAIL FROM angegebene Adresse, die später häufig als Return-Path sichtbar wird. Zustellfehler verwenden diese Transportidentität, deren Domain von der sichtbaren From-Domain abweichen kann.
DKIM Signing Domain: die Domain im Tag d= einer gültigen DKIM-Signatur. Ein Dienst kann mit seiner eigenen Domain oder, bei konfiguriertem Custom-Domain-Signing, mit der Domain des Kunden signieren.

Diese Unterscheidung ist keine technische Randnotiz. SPF bewertet die SMTP-Identität, während DKIM eine Signing Domain validiert. DMARC fragt, ob mindestens ein erfolgreiches Ergebnis zusätzlich mit der Domain in der sichtbaren From-Adresse in Beziehung steht, also aligned ist.

SPF beantwortet eine Frage zur Autorisierung des Versandwegs

Das Sender Policy Framework ermöglicht einer Domain zu veröffentlichen, welche Hosts diese Domain in SMTP MAIL FROM oder HELO/EHLO verwenden dürfen. Ein empfangender Server vergleicht die IP-Adresse der Verbindung mit der im DNS gefundenen Policy. Vereinfacht fragt SPF: „Ist dieser Server berechtigt, mit dieser SMTP-Domain zu senden?“

Ein rein illustrativer Eintrag könnte so aussehen:

example.com. TXT "v=spf1 include:spf.mail-provider.example -all"

Der Hostname ist absichtlich fiktiv. Ein echter Eintrag muss genau die Mechanismen verwenden, die der tatsächliche Anbieter vorgibt. Eine Domain sollte unter einem Namen nur einen SPF-Eintrag veröffentlichen; mehrere getrennte v=spf1-Einträge erzeugen einen Fehler, statt zusammengeführt zu werden. Die SPF-Auswertung begrenzt außerdem auf zehn Terme, die DNS-Abfragen verursachen. Fortlaufend weitere include:-Einträge hinzuzufügen, ist daher keine unbegrenzte Strategie.

Was ein SPF Pass nicht aussagt

SPF authentifiziert normalerweise nicht die Adresse, die eine Person im From-Feld sieht. Ein Dienst könnte SPF für bounce.service.example bestehen, während die Nachricht [email protected] anzeigt. Dieses Ergebnis enthält eine nützliche Aussage über den Transportweg, stellt für sich allein aber keine Verbindung zwischen der Domain des Dienstes und example.com her.

Weiterleitungen bringen eine weitere Einschränkung mit sich. Ein Forwarder überträgt die Nachricht von einem neuen Server erneut. Dieser Server ist üblicherweise nicht in der SPF-Policy des ursprünglichen Absenders aufgeführt. Ändert der Forwarder den Envelope Sender auf eine eigene Domain, kann SPF für die Domain des Forwarders bestehen, ist aber nicht mehr mit der ursprünglichen sichtbaren From-Domain aligned. Deshalb ist SPF allein eine fragile Grundlage zur Bewertung indirekter E-Mail-Flüsse.

DKIM versieht die Nachricht mit einer Domain-Signatur

DomainKeys Identified Mail verfolgt einen anderen Ansatz. Das sendende System berechnet Hashes über ausgewählte Header und Nachrichteninhalte, signiert sie mit einem Private Key und fügt einen DKIM-Signature-Header hinzu. Der Empfänger ruft den zugehörigen Public Key aus dem DNS ab und prüft die Signatur.

Ein Key-Eintrag wird unterhalb eines Selectors veröffentlicht:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_PROVIDER"

Der Selector ermöglicht mehrere Schlüssel pro Domain und unterstützt damit Delegation und Schlüsselrotation. Der Private Key muss beim signierenden System bleiben; im DNS steht nur der Public Key. Bei einer gehosteten Lösung erzeugt der Anbieter normalerweise die erforderlichen TXT- oder CNAME-Werte und beschreibt, wie das Signieren für eine benutzerdefinierte Domain aktiviert wird.

Was eine gültige DKIM-Signatur nicht aussagt

Eine gültige Signatur zeigt, dass die signierten Teile unverändert geblieben sind, seit ein Besitzer des Private Keys dieser Domain sie signiert hat. Sie verschlüsselt die Nachricht nicht. Sie beweist nicht, dass der Inhalt wahr oder ungefährlich ist. DKIM erlaubt zudem Signing Domains, die von der sichtbaren Autorendomain abweichen. „DKIM pass“ bedeutet daher nicht automatisch: „Diese From-Domain ist authentifiziert.“

Änderungen an der Nachricht können die Signatur ungültig machen. Mailinglisten können dem Betreff einen Zusatz oder der Nachricht einen Footer hinzufügen; Sicherheits-Gateways können Links umschreiben oder einen Anhang entfernen. Manche harmlosen Änderungen während des Transports überstehen die DKIM-Canonicalization, substanzielle Änderungen jedoch häufig nicht. Diese Grenze wird wichtig, wenn eine Domain später eine strikte DMARC-Behandlung anfordert.

DMARC verbindet die Authentifizierung mit der sichtbaren From-Domain

DMARC ersetzt SPF oder DKIM nicht. Es verwendet deren Ergebnisse und vergleicht die authentifizierten Domains mit der RFC5322.From-Domain, also mit der Domain, die Leser normalerweise sehen.

Eine Nachricht besteht DMARC, wenn mindestens einer dieser Wege erfolgreich ist:

SPF besteht und die authentifizierte Envelope-Sender-Domain ist mit der From-Domain aligned.
DKIM besteht und die Signing Domain ist mit der From-Domain aligned.

Es müssen nicht beide Prüfungen bestehen, obwohl die Konfiguration beider Mechanismen mehr Widerstandsfähigkeit bietet. Beim standardmäßigen relaxed Alignment von DMARC können Subdomains aligned sein, wenn sie dieselbe Organizational Domain teilen. Strict Alignment verlangt eine exakte Übereinstimmung der Domains. „Relaxed“ beschreibt hier die Beziehung zwischen Domains; dies ist unabhängig von der gleichnamigen Canonicalization-Einstellung von DKIM.

Eine Policy ist eine Bitte, keine Zustellgarantie

Eine Domain veröffentlicht DMARC unter _dmarc.example.com. Ein Monitoring-Eintrag könnte lauten:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Der Wert p bittet Empfänger um eine bestimmte Behandlung von Nachrichten, die DMARC nicht bestehen:

none fordert keine bestimmte Zustellmaßnahme an und eignet sich für die Beobachtung von Reports.
quarantine bittet Empfänger, Fehlschläge als verdächtig zu behandeln, häufig durch eine Ablage im Spamordner.
reject bittet Empfänger, fehlgeschlagene Nachrichten möglichst bereits während der SMTP-Transaktion abzulehnen.

Empfänger behalten den Spielraum ihrer lokalen Policy, und eine erfolgreiche Authentifizierung garantiert keine Zustellung in den Posteingang. Reputation, Zustimmung des Empfängers, Nachrichtenformatierung, Beschwerderaten und empfängerspezifische Regeln bleiben eigenständige Faktoren. Anforderungen von Empfängern verändern sich außerdem im Laufe der Zeit. Betreiber, die an Gmail senden, sollten beispielsweise Googles aktuelle email sender guidelines prüfen, statt sich auf eine alte Checkliste zu verlassen.

Eine direkte und eine weitergeleitete Nachricht verhalten sich unterschiedlich

Das folgende Beispiel zeigt eine Quittung, die direkt von einem konfigurierten Anbieter gesendet wird:

Die sichtbare Adresse lautet [email protected].
Der Anbieter verwendet eine aligned Envelope-Sender-Domain, sodass SPF besteht und aligned ist.
Der Anbieter signiert außerdem mit d=example.com, sodass DKIM besteht und aligned ist.
DMARC besteht über einen der beiden Wege.

Nun leitet eine Mailbox diese Quittung automatisch an ein anderes Ziel weiter. Die IP-Adresse des weiterleitenden Servers ist nicht durch die ursprüngliche SPF-Policy autorisiert, sodass SPF fehlschlagen kann. Lässt der Forwarder die signierten Inhalte unverändert, kann die ursprüngliche aligned DKIM-Signatur weiterhin gültig sein und DMARC bestehen. Verändert ein Vermittler zusätzlich signierte Inhalte, kann auch DKIM fehlschlagen.

Diese Probleme indirekter E-Mail-Flüsse sind in RFC 7960 dokumentiert; sie sind kein Beleg dafür, dass jede fehlgeschlagene Nachricht gefälscht ist. ARC ist ein experimentelles Protokoll, mit dem Vermittler frühere Authentifizierungsbewertungen in einer überprüfbaren Kette weitergeben können. Ein Empfänger kann diese Informationen in lokale Entscheidungen einbeziehen, doch ARC ist weder eine universelle Reparatur noch eine Annahmegarantie.

Eine sicherere Einführung beginnt mit einer Bestandsaufnahme

Die gefährliche Abkürzung besteht darin, p=reject zu veröffentlichen, bevor sämtliche legitimen Absender gefunden wurden. Eine persönliche Website versendet vielleicht weniger E-Mails als eine große Organisation, doch ihre Versandlandschaft kann trotzdem vergessene Systeme enthalten: ein Hosting-Control-Panel, ein CMS-Kontaktformular, einen Uptime-Monitor, einen Zahlungsdienst, eine Newsletter-Plattform, eine Support-Mailbox oder einen alten Automatisierungsjob.

Alle Mail-Flüsse inventarisieren. Sichtbare From-Domain, Envelope Sender, DKIM Signing Domain, verantwortliche Stelle und direkte oder indirekte Versandart festhalten.
SPF konsolidieren. Eine Policy beibehalten und nur aktuelle Absender autorisieren. Den offiziellen Eintrag des Anbieters prüfen, statt IP-Bereiche oder Include-Domains zu erraten.
Aligned DKIM aktivieren. Custom-Domain-Signing bevorzugen, wenn der Anbieter es unterstützt. Zuständigkeit für Selectors und Schlüsselrotation dokumentieren.
Kontrollierte Tests senden. Jeden Mail-Fluss an überprüfbare Empfänger testen. SPF-, DKIM- und DMARC-Ergebnisse einschließlich der für das Alignment verwendeten Domains untersuchen.
DMARC im Monitoring-Modus veröffentlichen. Eine eigene Mailbox für Aggregate Reports oder einen geeigneten Report-Prozessor verwenden. Reports können zahlreich sein und bestehen aus maschinenorientiertem XML, nicht aus einer einfachen Angriffsliste.
Unbekannte und nicht aligned Quellen korrigieren. Zwischen veralteten Absendern, legitimen Diensten mit unvollständiger Custom-Domain-Konfiguration und tatsächlich unbefugter Nutzung unterscheiden.
Enforcement bewusst wählen. Erst dann zu Quarantine oder Reject übergehen, wenn legitime Flüsse verstanden und überwacht werden. Der richtige Zeitpunkt hängt von den Mailwegen der Domain und ihrer Toleranz gegenüber fälschlichen Ablehnungen ab.

Diese beobachtungsorientierte Reihenfolge findet sich auch in Googles aktueller DMARC-Einrichtungsanleitung. Sie ist eine betriebliche Empfehlung und keine Regel, die jeder Anbieter identisch umsetzt.

Ergebnisse prüfen, ohne dem falschen Header zu vertrauen

Empfangende Systeme schreiben Ergebnisse üblicherweise in einen Authentication-Results-Header. RFC 8601 definiert dessen maschinenlesbares Format, enthält aber auch eine wichtige Warnung: Der Header ist nur innerhalb der Trust Boundary des Empfängers aussagekräftig. Ein Angreifer kann vor dem Versand einen überzeugend wirkenden Header hinzufügen. Vertrauenswürdig ist die Instanz, die von der empfangenden Infrastruktur hinzugefügt wurde, nicht irgendein von außen übernommenes Vorkommen.

Bei jedem kontrollierten Test sollte geprüft werden:

welche Domain SPF ausgewertet hat und ob die Prüfung bestanden wurde;
welche d=-Domain und welchen Selector DKIM verwendet hat und ob die Signatur gültig war;
ob DMARC bestanden wurde und welcher Mechanismus das aligned Ergebnis geliefert hat;
ob direkte, weitergeleitete und Mailinglisten-Pfade sich unterschiedlich verhalten;
ob Aggregate Reports einen legitimen Absender offenlegen, der in der Bestandsaufnahme fehlt.

Was diese Kontrollen weiterhin nicht lösen können

SPF, DKIM und DMARC erschweren die Nachahmung einer exakten Domain und liefern Anhaltspunkte für die Policy des Empfängers. Sie authentifizieren nicht die Person hinter jeder Mailbox, prüfen nicht, ob eine Nachricht wahrheitsgemäß ist, und verhindern nicht die Registrierung einer optisch ähnlichen Domain durch einen Angreifer. DMARC schützt außerdem nicht vor irreführenden Display Names, verschlüsselt keine Nachrichteninhalte, entfernt keine Malware und erteilt keine Erlaubnis zum Versand unerwünschter E-Mails.

Die sinnvolle Schlussfolgerung ist daher enger als „E-Mail ist sicher“. Ein Domaininhaber kann veröffentlichen, wer bestimmte Transportidentitäten verwenden darf, ausgewählte Nachrichtenbestandteile signieren, diese Ergebnisse mit der sichtbaren From-Domain verbinden, Fehlschläge beobachten und eine strengere Behandlung anfordern. Das ist ein bedeutsamer Schutz, bleibt aber nur eine Schicht in einem größeren Mailsystem.

Die verantwortungsvollste Einführung ist nicht diejenige mit dem strengsten Eintrag am ersten Tag. Es ist diejenige, deren legitime Absender bekannt sind, deren Alignment geprüft wurde, deren Reports ausgewertet werden und deren Enforcement zur vorhandenen Evidenz passt.