So lesen Sie SPF-, DKIM- und DMARC-Ergebnisse in einem E-Mail-Header

E-Mail-Header enthalten häufig SPF-, DKIM- und DMARC-Ergebnisse. Diese Mechanismen liefern Hinweise auf die an der Bereitstellung beteiligten Domänen und Systeme. Sie prüfen nicht jede Art von Täuschung und beweisen nicht, dass eine Nachricht, ein Absender oder ein Link sicher ist.

In diesem Handbuch wird die vom Once Email E-Mail-Header-Analysegerät erstellte Ergebniszusammenfassung erläutert. Der Analysator liest eingefügten Text lokal im Browser. Es führt keine DNS-, Reputations-, Malware- oder Live-Richtliniensuche durch.

SPF: Wurde dieses System für eine Umschlagdomäne autorisiert?

Mit dem Sender Policy Framework kann eine Domäne mithilfe einer SPF-Identität veröffentlichen, welche Systeme zum Senden berechtigt sind. Ein empfangendes System vergleicht den verbindenden Absender mit dieser veröffentlichten Richtlinie und zeichnet ein Ergebnis wie pass, fail, softfail, neutral oder none auf.

Bei SPF handelt es sich nicht einfach um eine Überprüfung der Adresse, die eine Person im sichtbaren Feld „Von“ sieht. DMARC verwendet das SPF-Ergebnis für die SMTP-MAIL-FROM-Identität und bewertet dann, ob ihre Domäne mit der sichtbaren Autorendomäne übereinstimmt.

Die Weiterleitung kann SPF erschweren, da der Weiterleitungsserver zum System wird, das eine Verbindung zum endgültigen Empfänger herstellt. Ein fehlgeschlagenes SPF-Ergebnis benötigt daher Kontext; Es ist kein vollständiges Urteil über die Botschaft.

DKIM: Wurde ein signierter Teil der Nachricht validiert?

DomainKeys Identified Mail fügt eine kryptografische Signatur hinzu, die einer signierenden Domäne zugeordnet ist. Ein Empfänger ruft den öffentlichen Schlüssel vom DNS ab und prüft, ob die signierten Header-Felder und der Hauptteil noch gültig sind.

Ein DKIM-Pass ist ein Beweis dafür, dass das signierte Material für die Signaturdomäne validiert ist. Es stellt nicht sicher, dass der Anzeigename ehrlich ist, dass jedes sichtbare Element signiert wurde oder dass eine verlinkte Website sicher ist. Mailing-Systeme können Nachrichten auch legitimerweise so ändern, dass eine Signatur beschädigt wird.

DMARC: Stimmt die authentifizierte Identität mit der sichtbaren Autorendomäne überein?

DMARC baut auf SPF und DKIM auf. Es vergleicht eine authentifizierte SPF- oder DKIM-Domäne mit der Domäne in der sichtbaren Absenderadresse und wendet die veröffentlichte Richtlinie und Empfängerrichtlinie des Domänenbesitzers an.

In der aktuellen IETF-Spezifikation RFC 9989 wird erklärt, dass DMARC Identifikatoren auf Domänenebene authentifiziert und keine Anzeigenamenangriffe bekämpft oder Nachrichteninhalte analysiert. Es ersetzte im Mai 2026 den älteren RFC 7489.

Was sich in der DMARC-Revision 2026 geändert hat

RFC 9989 ist kein Beweis dafür, dass jedes Nachrichtensystem im Jahr 2026 plötzlich sein Verhalten geändert hat. Es konsolidiert die aktuelle Protokolldefinition, macht RFC 7489 und RFC 9091 ausdrücklich überflüssig und trennt Aggregat- und Fehlerberichtsformate in Begleitspezifikationen. Die praktische Leseregel bleibt stabil: Ein DMARC-Pass bedeutet eine abgestimmte SPF- oder DKIM-Identität, die die Nutzung der sichtbaren Autorendomäne autorisiert. Dabei handelt es sich nicht um eine Reputationsbewertung, eine Identitätsprüfung der Person, die die Nachricht geschrieben hat, oder um einen Scan von Links und Anhängen.

Diese Unterscheidung ist wichtig, wenn es um die Interpretation „neuer DMARC-Anforderungen“ in Produktankündigungen geht. Ein Anbieter kann seine Zustellungsrichtlinien oder Anforderungen an Massenversender unabhängig vom Basisprotokoll ändern. Beispielsweise gelten in den Absenderrichtlinien von Gmail je nach Sendevolumen unterschiedliche Authentifizierungsanforderungen. Behandeln Sie Anbieterrichtlinien, Protokollvalidierung und Nachrichtensicherheit als drei separate Ebenen.

Ein DMARC-Bestand bedeutet, dass mindestens ein unterstützter Authentifizierungspfad mit der erforderlichen Ausrichtung bestanden wurde. Dies bedeutet nicht, dass der Autor persönlich verifiziert ist, das Konto nicht kompromittiert wurde oder die Nachricht harmlos ist.

Authentifizierungsergebnisse lesen

Ein vereinfachter Header könnte so aussehen:

„text Authentication-Results: mx.example; spf=pass smtp.mailfrom=mailer.example; dkim=pass header.d=mailer.example; dmarc=pass header.from=mailer.example “.

Überprüfen Sie diese Werte gemeinsam:

1. Welcher Server hat das Authentication-Results-Feld geschrieben?
2. Welche Domain hat SPF bestanden?
3. Welche Domain ist mit DKIM signiert?
4. Welche Domain erscheint in der sichtbaren Absenderadresse?
5. Meldet DMARC eine Ausrichtung, einen Fehler oder keine Richtlinie?
6. Ist der Zustellweg für den von Ihnen erwarteten Absender sinnvoll?

Header können mehrere Ergebnisfelder enthalten, da mehrere Systeme die Nachricht verarbeitet haben. Das Ergebnis des neuesten vertrauenswürdigen Empfängers ist oft das relevanteste, aber um zu entscheiden, welcher Vermittler vertrauenswürdig ist, sind Kenntnisse über den Postfachanbieter und den Zustellungspfad erforderlich.

Warum ein Pass keine Sicherheitsgarantie ist

Ein Angreifer kann eine von ihm kontrollierte Domäne authentifizieren. Das Konto eines legitimen Absenders kann kompromittiert werden. Eine korrekt authentifizierte Nachricht kann dennoch eine irreführende Anfrage, einen böswilligen Anhang oder einen gefährlichen Link enthalten.

Die Gmail-Absenderrichtlinien erfordern unterschiedliche Authentifizierungskontrollen je nach Sendevolumen und beschreiben die Authentifizierung als Zustellbarkeits- und Missbrauchsschutzmaßnahme. Sie verwandeln die Authentifizierung nicht in ein allgemeines Urteil zur Inhaltssicherheit.

Wenn in einer Nachricht nach Anmeldeinformationen, Geld, dringenden Maßnahmen oder vertraulichen Dateien gefragt wird, überprüfen Sie die Anfrage über einen bekannten Kontaktkanal. Verlassen Sie sich nicht allein auf den Absendernamen oder ein grünes Authentifizierungsergebnis.

Verwenden Sie den Analysator konservativ

Fügen Sie nur Header-Felder ein, nicht den Nachrichtentext oder die Anhänge. Vergleichen Sie die Zusammenfassung des Analysators mit dem Kontext, in dem die Nachricht eingegangen ist. Behandeln Sie fehlende, fehlerhafte oder widersprüchliche Beweise als Grund für eine zusätzliche Überprüfung und nicht als automatischen Beweis für Betrug.

Für die Reaktion auf Vorfälle, die Domänenkonfiguration oder wichtige Entscheidungen verwenden Sie die ursprüngliche Nachrichtenansicht Ihres Postfachanbieters und wenden Sie sich an einen qualifizierten E-Mail-Administrator oder Sicherheitsexperten.