Vor ein paar Jahren habe ich drei Tage damit verbracht zu debuggen, warum die transaktionalen E-Mails eines Kunden im Spam landeten. Der Inhalt war in Ordnung. SPF und DKIM waren korrekt konfiguriert. DMARC wurde bestanden. Alles sah perfekt aus—bis ich mir die Roh-Header tatsächlich durchgelesen habe.
In der Nachricht versteckt befand sich ein Header mit "X-Spam-Status: Yes, score=8.2". Der eigene Mailserver des Kunden markierte die Nachrichten als Spam, noch bevor sie das Gebäude verließen. Ein falsch konfigurierter Spamfilter fügte diesen Header hinzu, und nachgelagerte Server vertrauten ihm.
E-Mail-Header erzählen eine Geschichte. Sie protokollieren jeden Server, der die Nachricht berührt hat, jede Authentifizierungsprüfung, die ausgeführt wurde, und jeden berechneten Spam-Score. Sie lesen zu lernen ist wie das Lesen einer Patientenakte—plötzlich können Sie Probleme diagnostizieren, die zuvor rätselhaft wirkten.
Die Anatomie von E-Mail-Headern
E-Mail-Header stehen am Anfang jeder Nachricht, auch wenn die meisten E-Mail-Clients sie standardmäßig ausblenden. Es handelt sich um eine Reihe von Schlüssel-Wert-Paaren, jeweils in einer eigenen Zeile, die Metadaten über die Nachricht und ihren Weg protokollieren.
Header werden in umgekehrt chronologischer Reihenfolge hinzugefügt. Der jüngste Header steht oben; die ursprünglichen Header des Absenders stehen unten. Das ist wichtig, wenn Sie den Weg einer Nachricht nachverfolgen—man liest von unten nach oben, um die chronologische Reise zu verfolgen.
Einige Header werden vom Absender gesetzt: From, To, Subject, Date. Andere werden von Servern entlang des Weges hinzugefügt: Received-Header von jedem Mailserver, Authentifizierungsergebnisse, Spam-Scores. Zu verstehen, welche Header woher stammen, hilft Ihnen, das Gesehene richtig zu interpretieren.
Received-Header: den Pfad nachverfolgen
Jeder Mailserver, der eine Nachricht verarbeitet, fügt einen Received-Header hinzu. Diese bilden eine Spur aus Brotkrumen, die genau zeigt, wie die Nachricht vom Absender zum Empfänger gereist ist.
Ein typischer Received-Header enthält den Server, der die Nachricht empfangen hat, den Server, von dem er sie erhalten hat, das verwendete Protokoll und einen Zeitstempel. Wenn Sie diese von unten nach oben lesen, sehen Sie die komplette Reise.
Das ist unschätzbar für das Debugging. Wenn eine Nachricht verzögert wird, zeigen Received-Header, wo sie stecken blieb. Wenn sie abgelehnt wird, sehen Sie, welcher Server sie abgelehnt hat. Wenn sie unterwegs verändert wird, können Sie identifizieren, welcher Server Änderungen vorgenommen hat.
Achten Sie auf verdächtige Muster. Eine Nachricht, die vorgibt, von einem großen Unternehmen zu stammen, deren Received-Header jedoch zeigen, dass sie von einer privaten IP-Adresse ausging, ist fast sicher betrügerisch. Legitime Unternehmens-E-Mail kommt nicht über den Internetanschluss zu Hause.
Authentication-Results: das Urteil
Der Authentication-Results-Header ist der Ort, an dem empfangende Server die Ergebnisse von Authentifizierungsprüfungen festhalten. Dieser einzelne Header sagt Ihnen, ob SPF, DKIM und DMARC bestanden oder fehlgeschlagen sind, und enthält oft Details zum Warum.
Ein typischer Authentication-Results-Header kann zeigen, dass SPF mit der geprüften IP-Adresse bestanden hat, DKIM mit der Domain, die die Nachricht signiert hat, bestanden hat und DMARC mit der angewandten Policy bestanden hat. Oder er kann Fehler zeigen, mit Begründungscodes, die erklären, was schiefgelaufen ist.
Beim Debuggen der Zustellbarkeit ist dies oft der erste Header, den Sie prüfen. Wenn die Authentifizierung fehlschlägt, steht der Grund normalerweise genau hier. "SPF softfail" bedeutet, dass Ihr SPF-Record nicht ganz korrekt ist. "DKIM signature verification failed" deutet darauf hin, dass die Nachricht unterwegs verändert wurde oder die Signatur fehlerhaft ist.
Verschiedene empfangende Server formatieren diesen Header leicht unterschiedlich, aber die Informationen sind ähnlich. Gmail, Microsoft, Yahoo—sie alle zeichnen Authentifizierungsergebnisse auf, nur mit kleinen Unterschieden in der Syntax.
DKIM-Signature: der kryptografische Beweis
Der DKIM-Signature-Header enthält die kryptografische Signatur, die beweist, dass eine Nachricht seit dem Verlassen des signierenden Servers nicht manipuliert wurde. Er wirkt komplex, folgt aber einer konsistenten Struktur.
Der Header gibt an, welcher Algorithmus verwendet wurde, welche Domain die Nachricht signiert hat, welchen Selector man für die öffentliche Schlüsselsuche verwenden soll, welche Header durch die Signatur abgedeckt sind, einen Hash des Bodys und die Signatur selbst.
Für das Debugging sind die Domain (d=) und der Selector (s=) am nützlichsten. Diese sagen Ihnen, wo Sie den öffentlichen Schlüssel nachschlagen müssen. Wenn DKIM fehlschlägt, können Sie manuell prüfen, ob der DNS-Eintrag existiert und einen gültigen Schlüssel enthält.
Auch die von der Signatur abgedeckten Header (h=) sind wichtig. Wenn ein dort aufgeführter Header unterwegs geändert wurde, bricht die Signatur. Häufige Übeltäter sind Betreffzeilen, die von Mailinglisten geändert wurden, oder From-Header, die von Weiterleitungsdiensten umgeschrieben werden.
X-Spam-Header: die Reputationssignale
Viele Mailserver fügen Header hinzu, die ihre Spam-Bewertung anzeigen. Diese sind nicht standardisiert—verschiedene Server verwenden unterschiedliche Headernamen und Formate—aber sie sind enorm hilfreich, um zu verstehen, warum Nachrichten gefiltert werden.
SpamAssassin, einer der gängigsten Spamfilter, fügt die Header X-Spam-Status und X-Spam-Score hinzu. Der Status zeigt, ob die Nachricht als Spam klassifiziert wurde, und der Score zeigt die numerische Bewertung. Höhere Werte bedeuten spam-ähnlicher.
X-Spam-Flag ist ein einfacher Ja/Nein-Indikator. X-Spam-Report enthält oft eine detaillierte Aufschlüsselung, welche Regeln ausgelöst wurden und wie viele Punkte jede beigetragen hat. Diese Aufschlüsselung ist Gold fürs Debugging—sie zeigt Ihnen genau, was dem Filter nicht gefiel.
Wenn Sie Probleme mit Spamklassifizierungen sehen, suchen Sie nach diesen Headern. Sie decken oft spezifische Probleme auf: "MISSING_DATE" bedeutet, dass Sie den Date-Header vergessen haben, "HTML_IMAGE_ONLY" bedeutet, dass Ihre Nachricht nur aus Bildern ohne Text besteht, "RCVD_IN_BRBL" bedeutet, dass Ihre sendende IP auf einer Blacklist steht.
List-Unsubscribe: der Compliance-Header
Der List-Unsubscribe-Header betrifft nicht klassische Sicherheit, ist aber entscheidend für Zustellbarkeit und Compliance. Er teilt E-Mail-Clients mit, wie Empfänger sich von Ihren Nachrichten abmelden können.
Moderne E-Mail-Clients—Gmail, Apple Mail, Outlook—zeigen einen Abmeldelink prominent an, wenn dieser Header vorhanden ist. Das ist gut für Empfänger und gut für Sie: Eine einfache Abmeldung bedeutet weniger Spam-Beschwerden, was zu besserer Zustellbarkeit führt.
Der Header kann einen mailto-Link, eine HTTPS-URL oder beides enthalten. Best Practice ist, beides einzufügen, um E-Mail-Clients Optionen zu geben. Der neuere List-Unsubscribe-Post-Header ermöglicht das Abmelden mit einem Klick, ohne dass der Nutzer eine Webseite besuchen oder eine E-Mail senden muss.
Für Marketing- und Massen-E-Mails ist dieser Header im Grunde Pflicht. Gmail und andere Anbieter benachteiligen Nachrichten ohne ihn. Für transaktionale E-Mails ist er weniger kritisch, aber für wiederkehrende Benachrichtigungen dennoch gute Praxis.
Message-ID: der eindeutige Bezeichner
Jede E-Mail sollte einen eindeutigen Message-ID-Header haben. Dieser Bezeichner ermöglicht es Mailsystemen, Nachrichten zu verfolgen, Duplikate zu erkennen und Konversationen korrekt zu bündeln.
Eine korrekte Message-ID sieht aus wie eine zufällige Zeichenfolge, gefolgt von @ und einem Domainnamen. Die Domain sollte eine sein, die Sie kontrollieren—die Verwendung Ihrer sendenden Domain ist Standardpraxis. Der zufällige Teil sollte wirklich eindeutig sein; UUIDs funktionieren gut.
Fehlende oder fehlerhafte Message-IDs verursachen Probleme. Einige Spamfilter markieren Nachrichten ohne sie. Die Thread-Darstellung in E-Mail-Clients bricht. Die Duplikaterkennung schlägt fehl, was potenziell dazu führt, dass dieselbe Nachricht mehrfach zugestellt wird.
Wenn Sie E-Mail-Versandsysteme bauen, erzeugen Sie korrekte Message-IDs. Das ist ein kleines Detail, das später lästige Probleme verhindert.
Reply-To vs From: die Antwortsteuerung
Der From-Header zeigt, wer die Nachricht gesendet hat. Der Reply-To-Header gibt, sofern vorhanden, an, wohin Antworten gesendet werden sollen. Diese können unterschiedlich sein, und zu verstehen, wann man Reply-To verwendet, ist wichtig.
Ein gängiges Muster: Marketing-E-Mails kommen von [email protected], haben aber Reply-To auf [email protected] gesetzt. So können Sie von einer dedizierten Marketing-Adresse senden, während Antworten an Ihr Support-Team gehen.
Seien Sie vorsichtig mit Reply-To. Manche Spamfilter betrachten nicht übereinstimmende From- und Reply-To-Adressen mit Misstrauen, insbesondere wenn die Domains unterschiedlich sind. Das ist eine Technik, die von Phishing-Betrügern verwendet wird, um betrügerische E-Mails legitim wirken zu lassen und gleichzeitig Antworten abzugreifen.
Für transaktionale E-Mails ist es in der Regel am besten, From und Reply-To gleich zu lassen (oder Reply-To ganz wegzulassen). Für Marketing-E-Mails ergibt es Sinn, mit Reply-To Antworten an ein betreutes Postfach zu routen.
Header in der Praxis lesen
Wenn Sie ein E-Mail-Problem debuggen, ist hier ein systematischer Ansatz zum Lesen der Header.
Beginnen Sie mit Authentication-Results. Haben SPF, DKIM und DMARC bestanden? Wenn nicht, haben Sie Ihr Problem wahrscheinlich gefunden. Die Details in diesem Header erklären normalerweise, was schiefging.
Prüfen Sie als Nächstes die Received-Header. Verfolgen Sie den Nachrichtenpfad von unten nach oben. Achten Sie auf unerwartete Server, lange Verzögerungen zwischen den Hops oder Server, die die Nachricht möglicherweise verändert haben.
Suchen Sie nach spambezogenen Headern. X-Spam-Status, X-Spam-Score, X-Spam-Flag—jede davon kann aufdecken, warum eine Nachricht gefiltert wurde. Die detaillierten Reports zeigen oft konkrete, behebbare Punkte.
Prüfen Sie zum Schluss die Basics. Gibt es eine gültige Message-ID? Ist der Date-Header vorhanden und plausibel? Ist From korrekt gesetzt? Fehlende oder fehlerhafte Basis-Header lösen Spamfilter aus.
Frequently asked questions
Wie kann ich E-Mail-Header anzeigen?
In Gmail öffnen Sie die Nachricht und klicken auf das Drei-Punkte-Menü, dann 'Original anzeigen'. In Outlook öffnen Sie die Nachricht, klicken auf Datei und dann auf Eigenschaften. Die meisten E-Mail-Clients haben eine ähnliche Option wie 'Quelltext anzeigen' oder 'Header anzeigen'.
Können E-Mail-Header gefälscht werden?
Header, die vom Absender gesetzt werden (From, Subject usw.), können gefälscht werden. Header, die von empfangenden Servern hinzugefügt werden (Received, Authentication-Results), sind schwerer zu fälschen, weil sie erst nach Eingang der Nachricht hinzugefügt werden. Deshalb sind Authentifizierungsergebnisse des empfangenden Servers vertrauenswürdig.
Warum sehe ich mehrere Authentication-Results-Header?
Jeder Server, der Authentifizierungsprüfungen durchführt, kann seinen eigenen Header hinzufügen. Sie könnten einen von Ihrem eingehenden Server des E-Mail-Anbieters und einen weiteren von einem internen Spamfilter sehen. Der relevanteste ist in der Regel der vom finalen empfangenden Server.
Was ist der Unterschied zwischen Return-Path und From?
From ist die Adresse, die Empfängern angezeigt wird. Return-Path (auch Envelope Sender genannt) ist die Adresse, an die Unzustellbarkeitsmeldungen gesendet werden. Oft sind sie gleich, können sich aber unterscheiden. SPF prüft die Return-Path-Domain, nicht die From-Domain—deshalb existiert DMARC, um sie abzugleichen.