Jede Person, die E-Mail-Administration betreibt, hat dieses Support-Ticket schon gesehen: "Ich habe eine wichtige E-Mail an meine Kollegin weitergeleitet, und sie landete in deren Spam-Ordner. Warum?" Die Antwort betrifft einen der frustrierendsten Randfälle im E-Mail-Bereich—die Art und Weise, wie Weiterleitungen die Authentifizierung aushebeln.
Wenn Sie eine E-Mail weiterleiten, senden Sie sie im Grunde erneut von einem anderen Server. Der ursprüngliche SPF-Record autorisierte den Server der Absenderin, nicht Ihren. Die ursprüngliche DKIM-Signatur deckte den genauen Nachrichteninhalt ab, den Weiterleitungen oft verändern. Wenn die E-Mail ihr endgültiges Ziel erreicht, schlagen alle Authentifizierungsprüfungen fehl. Die Nachricht wirkt wie eine Fälschung, obwohl sie völlig legitim ist.
ARC—Authenticated Received Chain—wurde entwickelt, um dieses Problem zu lösen. Es schafft eine Nachweiskette für Authentifizierungsergebnisse und ermöglicht jedem Server, der eine Nachricht verarbeitet, für das zu bürgen, was er gesehen hat.
Warum Weiterleitungen die Authentifizierung aushebeln
Um ARC zu verstehen, müssen Sie genau verstehen, wie Weiterleitungen Dinge kaputt machen.
SPF prüft, ob die IP-Adresse des sendenden Servers für die Domain in der Envelope-'From'-Adresse autorisiert ist. Wenn Sie eine E-Mail weiterleiten, wird Ihr Server zum Absender. Ihre IP steht nicht im SPF-Record des ursprünglichen Absenders, also schlägt SPF fehl. Das ist so vorgesehen—SPF soll fehlschlagen, wenn ein nicht autorisierter Server E-Mails versendet.
DKIM ist kniffliger. Eine DKIM-Signatur deckt bestimmte Teile der Nachricht ab, typischerweise den Body und ausgewählte Header. Viele Weiterleitungssysteme verändern Nachrichten: fügen Footer hinzu, ändern Betreffzeilen, verpacken Inhalte neu. Jede Änderung macht die Signatur ungültig. Selbst wenn die Weiterleitung nichts verändert, sind einige DKIM-Implementierungen so fragil, dass schon kleine Änderungen bei Leerzeichen oder der Reihenfolge der Header die Validierung scheitern lassen.
DMARC verknüpft beides. Wenn sowohl SPF als auch DKIM scheitern, schlägt DMARC fehl. Und wenn die ursprüngliche Absenderin eine strikte DMARC-Policy hat (p=reject), wird die weitergeleitete Nachricht vollständig abgewiesen. Der Empfänger sieht sie nie.
Das führt zu einem echten Problem. Mailinglisten, E-Mail-Weiterleitungsdienste und unternehmensinternes Mail-Routing beinhalten legitime Weiterleitungen. Ohne Lösung würden strikte Authentifizierungsrichtlinien große Teile der normalen E-Mail-Nutzung lahmlegen.
Wie ARC funktioniert
ARC repariert SPF oder DKIM nicht—es arbeitet ergänzend dazu. Die Idee ist einfach: Jeder Server, der eine Nachricht verarbeitet, protokolliert, was er beobachtet hat, und signiert dieses Protokoll. Nachgelagerte Server können dann die vollständige Historie der Authentifizierungsergebnisse sehen.
Wenn eine Nachricht auf einem ARC-fähigen Server ankommt, führt der Server die normalen Authentifizierungsprüfungen aus: SPF, DKIM, DMARC. Anschließend erstellt er drei neue Header.
Der ARC-Authentication-Results-Header zeichnet auf, was der Server beobachtet hat. Hat SPF bestanden oder ist es fehlgeschlagen? Wurde DKIM validiert? Was war das DMARC-Ergebnis? Das ist im Wesentlichen eine Momentaufnahme des Authentifizierungsstatus an diesem Punkt der Reise der Nachricht.
Der ARC-Message-Signature-Header ist eine DKIM-ähnliche Signatur, die den Nachrichteninhalt abdeckt. So können nachgelagerte Server prüfen, dass die Nachricht seit der Verarbeitung durch diesen Server nicht verändert wurde.
Der ARC-Seal-Header verbindet alles miteinander. Er signiert die ARC-Header selbst und schafft so eine manipulationssichere Kette. Jeder Server fügt seinen eigenen Satz ARC-Header hinzu, erhöht eine Sequenznummer und signiert über alle vorherigen ARC-Header plus seine eigenen.
Das Ergebnis ist eine Nachweiskette. Der endgültige Empfänger kann sehen: "Server A hat diese Nachricht erhalten und SPF bestand. Server B hat sie weitergeleitet und DKIM war weiterhin gültig. Server C stellt sie jetzt zu." Selbst wenn die aktuelle Authentifizierung fehlschlägt, zeigt die Kette, dass Authentifizierung zuvor gültig war.
ARC in der Praxis
Verfolgen wir ein reales Szenario. Sie senden eine E-Mail von Ihrer Unternehmensdomain an eine Mailingliste. Die Liste leitet sie an alle Abonnenten weiter.
Ihre E-Mail verlässt Ihren Server mit gültigem SPF und DKIM. Sie kommt beim Server der Mailingliste an. Der Listenserver prüft die Authentifizierung—alles besteht. Er fügt ARC-Header hinzu, die diese Ergebnisse festhalten, und signiert sie.
Der Listenserver leitet die Nachricht dann an die Abonnenten weiter. Dabei fügt er einen Footer hinzu und ändert den Envelope-Absender (damit Bounces an die Liste zurückgehen, nicht an Sie). Diese Änderungen brechen Ihre ursprüngliche DKIM-Signatur und lassen SPF scheitern.
Wenn die Nachricht beim Mailserver eines Abonnenten ankommt, schlägt die aktuelle Authentifizierung fehl. Aber der Server sieht die ARC-Kette. Er kann die ARC-Signaturen verifizieren und erkennen, dass die Authentifizierung bestanden hat, als die Mailingliste die Nachricht erhalten hat. Wenn der Server der Mailingliste vertraut (basierend auf ihrer Reputation), kann er die Nachricht trotz aktueller Authentifizierungsfehlschläge akzeptieren.
Das ist der entscheidende Punkt: ARC macht weitergeleitete E-Mails nicht automatisch vertrauenswürdig. Es liefert Informationen, die empfangende Server nutzen können, um bessere Entscheidungen zu treffen. Vertrauen hängt weiterhin von der Reputation der Zwischenserver ab.
ARC implementieren
Wenn Sie einen Mailserver betreiben, der Nachrichten weiterleitet—eine Mailingliste, einen Weiterleitungsdienst oder unternehmensinternes Mail-Routing—sollten Sie ARC implementieren. Sie sind derjenige, der die Authentifizierung bricht; Sie sollten die Nachweiskette bereitstellen, die Empfängern hilft, dem Ergebnis zu vertrauen.
Die meisten modernen Mailserver-Softwares unterstützen ARC. Postfix, Exim und Microsoft Exchange haben alle ARC-Funktionen. Die Konfiguration umfasst typischerweise das Erzeugen eines Schlüsselpaares (ähnlich wie bei DKIM), die Veröffentlichung des öffentlichen Schlüssels in DNS und das Aktivieren der ARC-Signierung in Ihrer Serverkonfiguration.
Der DNS-Record sieht aus wie ein DKIM-Record, weil er im Grunde einer ist. ARC verwendet dasselbe Schlüsselformat und denselben Validierungsmechanismus. Sie veröffentlichen einen TXT-Record unter selector._domainkey.yourdomain.com, der Ihren öffentlichen Schlüssel enthält.
Für empfangende Server ist die ARC-Validierung normalerweise automatisch, wenn Ihre Software sie unterstützt. Die Entscheidung, ob ARC-Ergebnisse vertraut werden—und welchen Zwischenstationen vertraut wird—ist eine Policy-Entscheidung. Die meisten Server nutzen Reputationsdaten: Wenn ein bekannter Betreiber einer Mailingliste eine ARC-Kette signiert, hat das mehr Gewicht als ein unbekannter Server.
Die Grenzen von ARC
ARC ist kein Allheilmittel. Es gibt echte Einschränkungen, die Sie kennen sollten.
Erstens erfordert ARC Vertrauen in Zwischenserver. Wenn ein bösartiger Server gefälschte ARC-Header hinzufügt, die behaupten, die Authentifizierung sei bestanden, könnten nachgelagerte Server getäuscht werden. Deshalb ist Reputation wichtig—Sie sollten ARC-Ketten von unbekannten oder wenig vertrauenswürdigen Quellen nicht vertrauen.
Zweitens hilft ARC nicht, wenn der erste Hop bösartig ist. Wenn eine Angreiferin eine gespoofte Nachricht direkt an eine Mailingliste sendet, wird die Liste gewissenhaft festhalten, dass die Authentifizierung fehlgeschlagen ist, und sie trotzdem weiterleiten. ARC bewahrt Authentifizierungsergebnisse; es schafft keine Authentifizierung, wo keine vorhanden ist.
Drittens ist die Verbreitung noch unvollständig. Während große Anbieter wie Google und Microsoft ARC validieren, tun das viele kleinere Mailserver nicht. Ihre sorgfältig aufgebaute ARC-Kette könnte vollständig ignoriert werden.
Schließlich erhöht ARC die Komplexität. Mehr Header, mehr Signaturen, mehr Dinge, die kaputtgehen können. Das Debuggen von Zustellproblemen wird schwieriger, wenn Sie mehrere Ebenen der ARC-Validierung nachverfolgen müssen.
Zusammenspiel von ARC und DMARC
Die Beziehung zwischen ARC und DMARC ist wichtig. DMARC-Policies sagen Empfängern, was zu tun ist, wenn die Authentifizierung fehlschlägt. ARC liefert zusätzlichen Kontext, der diese Entscheidung beeinflussen kann.
Wenn eine Nachricht bei DMARC scheitert, aber eine gültige ARC-Kette hat, die einen früheren Authentifizierungserfolg zeigt, steht der Empfänger vor einer Entscheidung. Eine strikte Befolgung der DMARC-Policy würde die Nachricht ablehnen. Aber die ARC-Kette deutet darauf hin, dass es sich um legitime, weitergeleitete Post handelt.
Die meisten Empfänger, die ARC unterstützen, werden DMARC-Fehlschläge für Nachrichten mit vertrauenswürdigen ARC-Ketten übersteuern. Das ist der ganze Punkt—legitime weitergeleitete Post trotz Authentifizierungsfehlschlägen durchzulassen. Aber das ist eine lokale Policy-Entscheidung, keine Standardanforderung.
Wenn Sie Domaininhaberin oder -inhaber mit einer strikten DMARC-Policy sind, verstehen Sie, dass ARC dazu führen kann, dass Ihre Policy für weitergeleitete Post übersteuert wird. Das ist im Allgemeinen, was Sie wollen—Sie möchten wahrscheinlich nicht, dass Ihre E-Mails nur deshalb abgelehnt werden, weil jemand sie weitergeleitet hat. Aber wenn Sie spezifische Sicherheitsanforderungen haben, sollten Sie dieses Zusammenspiel verstehen.
Sollten Sie sich für ARC interessieren?
Wenn Sie Mail-Infrastruktur betreiben, die Nachrichten weiterleitet: ja. ARC zu implementieren, ist gute Netiquette—Sie helfen dem E-Mail-Ökosystem, besser zu funktionieren.
Wenn Sie nur E-Mails von Ihrer Domain senden, ist ARC weniger direkt relevant. Sie müssen nichts Besonderes tun; ARC wird von Zwischenstationen gehandhabt. Aber ARC zu verstehen, hilft Ihnen, Zustellprobleme zu debuggen, wenn Ihre E-Mails weitergeleitet werden.
Wenn Sie E-Mail-Deliverability bewerten, hilft Wissen über ARC zu erklären, warum manche weitergeleiteten Nachrichten durchkommen und andere nicht. Eine Nachricht, die über einen großen Anbieter mit guter ARC-Implementierung weitergeleitet wird, hat bessere Chancen als eine, die über einen kleinen Server ohne ARC-Unterstützung weitergeleitet wird.
Frequently asked questions
Ersetzt ARC DKIM?
Nein. ARC ergänzt DKIM. Sie benötigen weiterhin DKIM für Ihre ausgehenden Nachrichten. ARC hilft, Authentifizierungsergebnisse zu bewahren, wenn Nachrichten weitergeleitet werden und DKIM-Signaturen brechen.
Kann ich ARC ohne DKIM implementieren?
Technisch ja, aber es ergibt wenig Sinn. ARC ist dafür gedacht, Authentifizierungsergebnisse zu bewahren, einschließlich DKIM. Wenn Sie kein DKIM machen, gibt es weniger zu bewahren.
Woran erkenne ich, ob meine E-Mails beim Weiterleiten mit ARC signiert werden?
Prüfen Sie die Header weitergeleiteter Nachrichten. Suchen Sie nach ARC-Authentication-Results-, ARC-Message-Signature- und ARC-Seal-Headern. Diese weisen darauf hin, dass ARC-Verarbeitung stattgefunden hat.
Unterstützt Gmail ARC?
Ja. Google war eine der treibenden Kräfte hinter ARC und unterstützt sowohl Signierung als auch Validierung vollständig. Nachrichten, die über Gmail weitergeleitet werden, enthalten ARC-Header, und Gmail berücksichtigt ARC-Ketten bei der Bewertung eingehender E-Mails.