DKIM-Pflicht für E-Mails ab dem 10. Juni - wer muss was tun?

Spätestens ab dem 10. Juni müssen Versender E-Mails mit Hilfe des DomainKeys Identified Mail(DKIM)-Verfahrens signieren, falls sie weiterhin ein Whitelisting der Certified Senders Alliance (CSA) genießen möchten. Bislang kannten die CSA-Regularien Ausnahmefälle. So entfiel die DKIM-Pflicht, falls die Mailsoftware das Verfahren nicht unterstützte. Dies ist bald passé.

Was bedeutet die Änderung für Versender? Und was genau ist eigentlich „DKIM“?

 

Für wen ändert sich etwas?

Gute Nachricht: Für viele Marketer wird sich nichts ändern, da DKIM mittlerweile quasi Standard auf dem internationalen E-Mail-Marketing-Parkett geworden ist. Große Postfach-Anbieter wie Gmail fordern es seit langem von Werbern ein. Der Grund ist weniger, weil das Vorhandensein einer DKIM-Signatur an sich ein relatives gutes Ham-Signal für E-Mails ist, sondern mehr, um per Authentifizierung neben einer IP- auch eine Absender-bezogene Reputation für die Spamfilterung valide erfassen zu können. (Gmail merkt sich also nicht nur, ob Nachrichten von einem Mailserver erwünscht sind, den sich mehrere Werber teilen können, sondern auch, wie es um den einzelnen Absender bestellt ist. Dies bedeutet z. B., dass der Wechsel des Versanddienstleisters keine Sofortlösung für Zustellbarkeitsprobleme sein kann; stattdessen muss behutsam nach Bereinigung der Liste eine gute Absender-Reputation aufgebaut werden.)

Ein Blick in die Inbox von letzter Woche bestätigt entsprechend, dass professionelle Marketer zum großen Teil dem DKIM-Wunsch der Freemailer nachkommen und ihre E-Mails signieren. Die beiden untenstehenden Grafiken zeigen den Anteil der Versender, die DKIM (nicht) nutzen, aufgeschlüsselt und sortiert nach Popularität der verwendeten Mailsoftware (Stand KW 19 2014). Dabei beschränkt sich die rechte Abbildung auf Versender, deren Software auch ein CSA-Zertifikat vorgibt:



dkim
 
dkim_csa

Die Versender in den blauen Balken rechts hätten zum 10. Juni theoretisch Nachholbedarf, da diese scheinbar CSA-zertifiziert sind und gleichsam eine DKIM-Signatur fehlt. Das Segment ist von überschaubarer Größe (26,5 %) und betrifft primär ausgewählte Mailsoftwares. Zum Glück ist DKIM auch nicht so kompliziert, wie es vielleicht scheint:

 

„DKIM-Signatur“ – was ist das eigentlich?

Der Kern der DKIM-Signatur sind zwei eindeutige kryptografische Prüfsummen (Hashes): Bevor eine E-Mail auf den Weg gebracht wird, errechnet die Versandsoftware die Summen mit Hilfe eines privaten (geheimen) Schlüssels über (1) den E-Mail-Inhalt und über (2) Kopfzeilen wie „From:“ (Absender) und „Subject:“ (Betreff).

Die Ergebnisse werden in einer weiteren Kopfzeile namens „DKIM-Signature:“ vermerkt. Anhand der Prüfsummen kann wiederum die Empfänger-Mailsoftware bei E-Mail-Eingang überprüfen, ob die Nachricht echt und unversehrt ist, ob sie also wirklich vom Absender stammt und zudem inhaltlich nicht unterwegs verändert wurde. Dazu ruft sie beim Versender einen öffentlichen Schlüssel ab und versucht damit, die notierten Hashes zu reproduzieren.

Klingt kryptisch, ist es (im technischen Sinne) auch, klärt sich aber mit Blick auf ein Beispiel. Schauen wir in den Quelltext des vergangenen optivo Trend-Newsletters (so geht‘s), dann offenbart sich folgende DKIM-Signatur:


dkim-signature

In der Kopfzeile „DKIM-Signature:“ finden sich mehrere Angaben („Tags“), die allesamt Semikolon-separiert sind. Jede Angabe enthält einen Wert (z.B. „1“), der mit Gleichheitszeichen vom Bezeichner (z.B. „v“) getrennt ist. Was bedeuten die Angaben im Beispiel?

  • v=1 Die Signatur in der E-Mail basiert auf Version 1 der DKIM-Spezifikation. (Eine andere Version gibt es derzeit nicht.)
  • a=rsa-sha1 Die beiden Prüfsummen in den Tags b= und bh= (siehe unten) wurden mit dem Verschlüsselungsalgorithmus „RSA-SHA1“ berechnet. RSA-SHA1 ist gegenüber der Alternative RSA-SHA256 - entgegen der offiziellen Empfehlung - populärer:
    dkim_algorithms
  • c=relaxed/relaxed Die Kopfzeilen der E-Mail bzw. („/“) der E-Mail-Inhalt wurden vor Berechnung der Prüfsummen durch den Algorithmus „relaxed“ normalisiert. D.h. sie wurden auf eine gegenüber kleinen Veränderungen möglichst tolerante und konsistente Form gebracht. Veränderungen wie z.B. neue Zeilenumbrüche oder Umschreibungen können beim Nachrichten-Transport durchs Web auftreten. Typische Normalisierungsschritte sind daher die Entfernung überflüssiger Leerzeichen und Zeilenumbrüche sowie Kleinschreibung. In der Praxis machen Mailsoftwares mitunter nur eine Angabe im c- Tag, also ohne Schrägstrich; in diesem Fall gilt diese Angabe für die Kopfzeilen und für den E-Mail-Inhalt nimmt die Software des Empfängers „simple“ an. „Simple“ beschränkt sich als Alternative zu „relaxed“ auf ein Minimum an Änderungen im Inhaltsbereich bzw. lässt die Ausgangsdaten bei den Kopfzeilen gänzlich unberührt:
    dkim_c
  • [email protected] Der Verantwortliche, für den die E-Mail signiert wurde, ist unter [email protected] zu erreichen. Diese Angabe ist bei DKIM optional und für Werbemails meist überflüssig. In der Praxis wird das i-Tag daher oft ausgespart (siehe Abbildung unten). Es kann auch nur aus einem @-Zeichen und der Domäne bestehen. Die Domäne hinter dem @ muss aber in jedem Fall dem Wert im folgenden d-Tag entsprechen.
    dkim_i
  • d=news.optivo.de Die Domain der signierenden Stelle, auf der der öffentliche Schlüssel zur Signaturprüfung bereitgestellt wird, lautet news.optivo.de. Gemäß den neuen CSA-Regularien hat der Whois-Eintrag der Domäne auf den zertifizierten Versender – i. d. R. der Email Service Provider (ESP) – oder auf den Werbetreibenden zu zeigen, der die Dienste des ESP beansprucht. In der Praxis wird der Einfachheit halber - quasi per Mausklick - der ESP eingetragen. Wünschenswert ist aber das zuletzt genannte Szenario, d.h. die Domain ist diejenige des ESP-Kunden. Denn auf diese Weise kann der Werbetreibende effektiv seine eigene IP-unabhängige Domain-Reputation aufbauen und pflegen. Idealerweise ist die Domain auch gleichzeitig diejenige, die im Absendernamen auftaucht (sog. „Alignment“), sodass der Absender eindeutig seine Nachricht autorisiert.
  • s=mailing Als sogenannter Selektor fungiert für diese E-Mail “mailing”. Die Mailsoftware des Empfängers weiß durch die beiden Tags s= und d=, wie und wo sie den öffentlichen Schlüssel zur Signaturprüfung erhält. Nämlich per DNS-Abfrage des TXT-Eintrags unter ._domainkey.<domäne> - also „mailing._domainkey.news.optivo.de“. Die DKIM-DNS-Abfrage für den optivo-Newsletter können Sie bspw. auf mxtoolbox.com unter Eingabe von „TXT: mailing._domainkey.news.optivo.de“ leicht nachvollziehen:
    dkim_lookup
  • h=Message-ID:Date:From:Reply-To:To:Subject:MIME-Version:Content-Type:List-Id:X-CSA-Complaints:X-ulpe:Feedback-ID; In die Berechnung des Prüfsummen für die Kopfzeilen flossen die hier per Doppelpunkt getrennten Kopfzeilen (und die Kopfzeile „DKIM-Signature“ mit der vorübergehenden Angabe h=;) ein. In der Praxis fließen vornehmlich die folgenden Zeilen in die Berechnung ein:
    dkim_header
  • bh=3Y2uRDphT5xMDavqrSD8Nfem0rM= Der berechnete Prüfsumme für die Kopfzeile, der mit dem öffentlichen Schlüssel (siehe oben) durch den Empfänger überprüfbar ist.
  • b=HmzBwyG5VwO…………kv+9JMis= Der berechnete Prüfsumme für den E-Mail-Inhalt, der ebenfalls mit dem öffentlichen Schlüssel prüfbar ist.

 

Ein Wort zur DKIM-Sicherheit

Mit den Schlüsseln ist es wie mit Passwörtern. Damit DKIM sicher ist und bleibt, sollten die Schlüssel daher zum einen ausreichend groß sein. Empfohlen wird eine Stärke von mindestens 1014 Bit. Alles was darunter ist, behandelt Gmail als nicht signiert.

Wer den Schlüssel knackt, kann unter fremdem Namen signierte Phishingmails versenden. Und der Mathematiker Zachary Harris, der vor einiger Zeit von Google angeheuert wurde, um die (damals eigenen) Probleme schwacher Schlüssel zu ergründen, veranschaulicht die Gefahren sehr plastisch:

“A 384-bit key I can factor on my laptop in 24 hours. The 512-bit keys I can factor in about 72 hours using Amazon Web Services for . And I did do a number of those. Then there are the 768-bit keys. Those are not factorable by a normal person like me with my resources alone. But the government of Iran probably could, or a large group with sufficient computing resources could pull it off.”

Ferner sollten die Schlüssel wie Passwörter auch regelmäßig ausgetauscht werden. Nach Möglichkeit quartalsweise. Hierzu wird ein neues Schlüsselpaar generiert und ein neuer Selektor angelegt; der alte kann nach etwa einer Woche, wenn er nicht mehr zur Mailprüfung herangezogen wird, gelöscht werden. Bei Domains, die an den Dienstleister delegiert wurden, kümmert dieser sich um die Sicherheit.