Smarte, fokussierte E-Mails.
Perfekte Cross-Platform-Mails für mehr Ordnung – so können Sie sich aufs Wesentliche konzentrieren.
💡 ARC (Authenticated Received Chain): Ein E-Mail-Authentifizierungsprotokoll, das im Grunde nachverfolgt, was mit Ihrer Nachricht passiert, während sie über verschiedene Server weitergeleitet wird. Wenn E-Mails weitergeleitet oder von Mailinglisten verändert werden, bewahrt ARC die ursprünglichen Authentifizierungsergebnisse, damit legitime Nachrichten nicht als Spam markiert werden.
Hier ist das Problem, das es löst: Sie senden eine E-Mail, die alle Authentifizierungsprüfungen besteht (SPF, DKIM, DMARC). Perfekt. Aber dann leitet jemand sie über den E-Mail-Server seines Unternehmens weiter, oder sie läuft über eine Mailingliste, die eine Fußzeile hinzufügt. Diese Änderungen können die ursprünglichen Authentifizierungssignaturen ungültig machen.
Was passiert als Nächstes? Der empfangende Server sieht eine Nachricht, die vorgibt, von Ihnen zu sein, die aber die Authentifizierung nicht mehr besteht. Spam-Ordner. Oder schlimmer noch: vollständig abgewiesen.
ARC löst dieses Problem, indem es eine Vertrauenskette erstellt. Jeder Server, der die Nachricht verarbeitet, fügt seine eigene ARC-Signatur hinzu und dokumentiert damit: Ja, diese E-Mail war legitim, als sie hier ankam, auch wenn wir sie vor dem Weiterleiten leicht verändert haben. Stellen Sie es sich wie einen Staffellauf vor, bei dem jeder Läufer bestätigt, dass er den Staffelstab auf legitime Weise erhalten hat.
Laut den Richtlinien von Google für E-Mail-Absender ist es bei weitergeleiteten E-Mails ohne ARC deutlich wahrscheinlicher, dass Authentifizierungsprüfungen fehlschlagen. Das ist eine Menge legitimer E-Mails, die blockiert werden.
Das Protokoll fügt Ihrer E-Mail auf dem Weg durch die Server drei wichtige Header hinzu:
ARC-Authentication-Results zeichnet auf, welche Authentifizierungsprüfungen durchgeführt wurden und ob sie erfolgreich waren. Es ist wie ein Zeugnis, das dokumentiert, dass Ihre E-Mail gültige DKIM- und SPF-Einträge hatte, als sie erstmals auf diesem Server ankam.
ARC-Message-Signature erstellt an diesem Punkt der Übertragung eine kryptografische Signatur des Nachrichteninhalts. Das beweist, dass die Nachricht zwischen den Stationen nicht böswillig manipuliert wurde (kleine Änderungen für die Weiterleitung sind in Ordnung und zu erwarten).
ARC-Seal verknüpft alles mit einer weiteren Signatur, die die gesamte Kette validiert. Jeder Server fügt sein eigenes Seal hinzu und erstellt so eine verknüpfte Sequenz. Wenn ein Glied in der Kette fehlt oder verdächtig ist, können empfangende Server das erkennen.
Praktischerweise ist die Kette nummeriert. ARC-Seal: i=1, dann i=2, dann i=3. Empfangende Server können überprüfen, dass nichts fehlt und jeder legitime zwischengeschaltete Server den vorherigen Schritt korrekt authentifiziert hat.
Und anders als ältere Protokolle, die bei Inhaltsänderungen versagen, rechnet ARC mit Änderungen. Genau darum geht es. Es dokumentiert lediglich, dass diese Änderungen auf vertrauenswürdigen Servern passiert sind und nicht durch einen Angreifer, der Ihre E-Mails abfängt.
ARC erfordert eine Konfiguration sowohl auf den zwischengeschalteten Servern (diejenigen, die Nachrichten weiterleiten oder verändern) als auch auf den empfangenden Servern (diejenigen, die die ARC-Kette validieren). Die meisten Nutzer müssen nichts tun, es sei denn, sie betreiben ihre eigene Mail-Infrastruktur.
Gmail validiert ARC-Signaturen beim Empfang weitergeleiteter Nachrichten. Wenn Sie E-Mails an Gmail weiterleiten, sollte der zwischengeschaltete Server ARC-Header hinzufügen. Wenn Sie Google Workspace verwenden und E-Mails über Ihre Server an andere Ziele weiterleiten, konfigurieren Sie Ihre Mailserver so, dass sie ARC-Header hinzufügen. Google bietet detaillierte Hinweise in seinen Richtlinien für E-Mail-Absender für Administratoren, die Weiterleitungsdienste verwalten.
Exchange Online unterstützt die ARC-Validierung, aber Administratoren müssen vertrauenswürdige ARC-Sealer konfigurieren. Gehen Sie zum Microsoft Defender-Portal und navigieren Sie zu E-Mail & Zusammenarbeit > Richtlinien & Regeln > Bedrohungsrichtlinien > Einstellungen für die E-Mail-Authentifizierung > ARC. Fügen Sie die Domains aller zwischengeschalteten Dienste hinzu, die Ihre E-Mails verarbeiten (diese müssen mit dem „d“-Tag im ARC-Seal-Header übereinstimmen). Die gute Nachricht: Microsoft 365-Organisationen vertrauen ARC-Signaturen anderer Microsoft 365-Organisationen automatisch, dieser Teil ist also bereits erledigt.
Spark stützt sich auf die E-Mail-Authentifizierungs-Einstellungen, die von Ihrem E-Mail-Anbieter konfiguriert werden (Gmail, Outlook, benutzerdefinierter IMAP-Server oder EWS-Konten wie Microsoft 365). Als E-Mail-Client übernimmt Spark ARC-Signierung oder -Validierung nicht direkt. Das geschieht auf Serverebene, noch bevor Nachrichten Ihren Posteingang erreichen.
Wenn Sie Ihre eigene Infrastruktur betreiben, müssen Sie Ihren SMTP-Server um ARC-Unterstützung erweitern. OpenARC ist die gängigste Implementierung für Postfix und Sendmail. Sie installieren es, konfigurieren es so, dass ausgehende E-Mails signiert und eingehende Ketten validiert werden, und fügen die erforderliche Konfiguration hinzu (ähnlich wie beim DKIM-Setup, aber für ARC sind keine DNS-Einträge erforderlich).
Der Haken? ARC hilft nur, wenn sowohl die zwischengeschalteten Server als auch der endgültige empfangende Server es unterstützen. Wenn das Ziel ARC nicht validiert, spielt die Kette keine Rolle. Aber die Verbreitung nimmt schnell zu. Gmail, Yahoo, Microsoft und die meisten großen Anbieter validieren inzwischen ARC-Ketten.
Richten Sie zuerst die Kernprotokolle ein. ARC ergänzt SPF, DKIM und DMARC, ersetzt sie aber nicht. Konfigurieren Sie diese Authentifizierungsmethoden, bevor Sie sich um ARC kümmern. Ohne eine korrekte grundlegende Authentifizierung hat ARC nichts Nützliches zu bewahren.
Überwachen Sie Ihre Authentifizierungsergebnisse. Die meisten E-Mail-Dienstanbieter bieten Berichte an, die zeigen, wie oft Ihre Nachrichten Authentifizierungsprüfungen bestehen. Wenn Sie selbst mit ARC bei weitergeleiteten E-Mails hohe Fehlerraten sehen, ist etwas falsch konfiguriert. Prüfen Sie Ihre Header.
Bewahren Sie Ihre DKIM-Schlüssel sicher auf. ARC baut auf DKIM-Signaturen auf. Wenn Ihre DKIM-Schlüssel also kompromittiert sind, ist auch die ARC-Kette nicht vertrauenswürdig. Tauschen Sie Schlüssel regelmäßig aus (alle sechs bis 12 Monate ist Standard).
Testen Sie Weiterleitungsszenarien. Senden Sie Test-E-Mails über Mailinglisten, Weiterleitungsdienste und verschiedene E-Mail-Clients, um zu überprüfen, ob ARC korrekt funktioniert. Tools wie MXToolbox können dabei helfen, Ihr Setup zu validieren und Header zu prüfen.
Dokumentieren Sie Ihre vertrauenswürdigen Sealer. Wenn Sie die ARC-Validierung konfigurieren, führen Sie eine Liste der zwischengeschalteten Dienste, denen Sie vertrauen. Überprüfen Sie diese Liste vierteljährlich. Dienste wechseln den Besitzer, werden kompromittiert oder eingestellt. Vertrauen Sie keinen ARC-Signaturen von Diensten, die Sie nicht mehr nutzen.
Akzeptieren Sie, dass es noch nicht von allen unterstützt wird. Einige kleinere E-Mail-Anbieter haben die ARC-Validierung noch nicht implementiert. Ihre weitergeleiteten E-Mails könnten dort trotzdem markiert werden. Aber alle großen Anbieter unterstützen es, was die überwiegende Mehrheit Ihrer Empfänger abdeckt.