Warum die E-Mail, die Sie sich selbst weitergeleitet haben, im Spam landen — redaktionelle Illustration

read receipts

Warum die E-Mail, die Sie sich selbst weitergeleitet haben, im Spam landen

Sie haben nichts falsch gemacht. SPF war es. Hier ist der Mechanismus, den Ihnen niemand bei Ihrem Provider erklären wird.

·3 Min.

Richten Sie eine automatische Weiterleitung von Ihrem alten Konto zu Ihrem neuen ein, und einige dieser E-Mails verschwinden stillschweigend im Spam — nicht weil Ihr Provider defekt ist, sondern weil die Weiterleitung ändert, wer die Nachricht sendet, ohne den kryptografischen Beweis umzuschreiben. SPF überprüft den falschen Server, das DMARC-Ergebnis kippt zu Fehler, und eine legitime E-Mail, die Sie sich selbst gesendet haben, wird unter Quarantäne gestellt. Die Lösung hat einen Namen: ARC, definiert in RFC 8617 zurück in 2019.

Warum lässt die Weiterleitung meine E-Mail bei SPF fehlschlagen?

Weil SPF den letzten Server überprüft, der die Nachricht weitergeleitet hat, und die Weiterleitung diesen Server ändert. SPF — Sender Policy Framework — ist ein DNS-Eintrag, der auflistet, welche IP-Adressen zum Versand von E-Mails für eine Domain autorisiert sind. Wenn bank.com Ihnen eine Quittung sendet, prüft der empfangende Server: Kam dies von einer IP, die bank.com autorisiert hat? Ja. Bestanden.

Leiten Sie diese Quittung jetzt von Ihrem Gmail an Ihre neue Adresse weiter. Googles Server leiten sie weiter. Der endgültige empfangende Server führt die SPF-Prüfung aus und fragt: Ist Google autorisiert, E-Mails für bank.com zu versenden? Nein, das ist es nicht. SPF schlägt fehl. Googles eigene Workspace-Dokumentation erklärt dies deutlich — weitergeleitete Nachrichten schlagen bei SPF fehl, weil der Weiterleitungsserver nicht im SPF-Eintrag der ursprünglichen Domain aufgeführt ist. Nichts wurde gefälscht. Die Prüfung schaut einfach auf den falschen Hop.

Warum landet das also im Spam?

DMARC. SPF-Fehler allein waren früher verkraftbar; DMARC machte daraus ein Ergebnis. DMARC bindet SPF und DKIM zusammen und teilt den Empfängern mit, was zu tun ist, wenn beide fehlschlagen: nichts, unter Quarantäne stellen oder ablehnen. Bis 2024 hatten große Sender keine andere Wahl — Google und Yahoo begannen, DMARC von allen zu verlangen, die mehr als 5.000 Nachrichten pro Tag an ihre Nutzer versenden.

DKIM, die andere Säule, ist eine Signatur, die in die Nachricht eingebettet ist. Theoretisch übersteht sie die Weiterleitung, weil sie den Inhalt signiert, nicht die Route. In der Praxis zerstört alles, was die Nachricht berührt, sie. Eine Mailingliste, die eine Fußzeile anhängt wie „Sie sind abonniert, hier abmelden", ein Server, der die Betreffzeile umschreibt, sogar eine Änderung beim Zeilenumbruch — die Signatur stimmt nicht mehr überein, und DKIM schlägt auch fehl. Jetzt sind beide Säulen weg, DMARC sagt Fehler, und Ihre eigene Quittung liegt im Junk-Ordner.

Was ist ARC und behebt es das tatsächlich?

ARC — Authenticated Received Chain, RFC 8617 — lässt einen ehrlichen Weiterleitungsserver dafür garantieren, dass die E-Mail die Authentifizierung bestanden hat, bevor er sie berührte. Der Weiterleitungsserver versieht die Nachricht mit einem versiegelten Datensatz, der besagt „als dies mich erreichte, waren SPF und DKIM gültig — vertrauen Sie meinem Wort für den Abschnitt, den Sie nicht überprüfen können." Der endgültige Empfänger kann, wenn er diesem Weiterleitungsserver vertraut, den DMARC-Fehler überschreiben und zustellen.

Der Haken liegt in „wenn er vertraut". ARC ist kein Passwort; es ist ein Reputationssystem. Ein Empfänger wägt ab, ob der ARC-Unterzeichner ein bekannter, wohlbekannter Betreiber ist. Google versieht ARC-Header und berücksichtigt sie von Sendern, denen es vertraut, weshalb eine Weiterleitung von Gmail zu Gmail normalerweise überlebt, während eine Weiterleitung durch ein altes Universitätsrelais nicht überlebt.

Wenn Sie die Weiterleitung selbst betreiben, helfen zwei konkrete Maßnahmen. Verwenden Sie Server-Side Redirect / SRS-Umschreibung, wenn Ihr Host dies anbietet, was den Umschlag-Absender umschreibt, damit die SPF-Prüfung sich gegen Ihren Weiterleitungsserver statt gegen die ursprüngliche Domain richtet. Und bevorzugen Sie Weiterleitungen zwischen Providern, die beide ARC unterstützen. Wenn Sie Konten konsolidieren und möchten, dass das Ziel das Authentifizierungs-Durcheinander einfach für Sie verwaltet, ist genau das die Art von Rohren, die eine KI-E-Mail-Plattform aufnehmen soll.

Wann sollte ich damit aufhören, meinen Provider zu beschuldigen?

Wenn das Muster „nur weitergeleitete E-Mails schlagen fehl" ist, tut der Provider seinen Job richtig — das Protokoll ist das Problem. Hier ist das Erkennungszeichen: Öffnen Sie die Header der fehlenden Nachricht und suchen Sie nach der Authentication-Results-Zeile. Wenn Sie spf=fail neben einer Absende-IP sehen, die zu einem Weiterleitungsserver und nicht zum ursprünglichen Absender gehört, dann überprüft SPF den falschen Hop. Wenn dkim=fail bei E-Mail erscheint, die durch eine Liste oder ein Relay ging, das Nachrichten bearbeitet, ist das eine zerstörte Signatur, keine Fälschung.

Die unbequeme Wahrheit ist, dass E-Mail-Authentifizierung über zwei Jahrzehnte hinweg Schicht für Schicht auf ein System geklebt wurde, das nie davon ausging, dass jemand lügen würde. SPF kam 2006, DKIM 2007, DMARC 2015, ARC 2019 — jeder patcht ein Loch, das der letzte aufgerissen hat. Weiterleitung ist die Naht, wo alle vier aneinander reiben, und Ihr Posteingang ist, wo Sie die Reibung spüren.

@@END@@
daily messages that trigger Google & Yahoo's DMARC requirement (2024)

Quellen

  1. IETF RFC 8617 — Authenticated Received Chain (ARC) specification, 2019
  2. Google Workspace Admin Help — SPF, forwarding and authentication for forwarded mail
  3. Google Email sender guidelines — 2024 bulk sender DMARC requirements and 5,000/day threshold

← Alle Artikel