DKIM2, der geplante Nachfolger von DKIM, dem Standard, der E-Mails signiert und verifiziert, hat den nächsten öffentlichen Meilenstein erreicht. Die IETF-Arbeitsgruppe, die den Standard neu schreibt, hat die aktuelle Fassung des Spezifikationsentwurfs am 17. Mai 2026 veröffentlicht und ist auf Kurs, den Standard in den nächsten 12 bis 18 Monaten der formalen Verabschiedung näherzubringen. Dieser Artikel erklärt, was DKIM2 am E-Mail-Signaturverfahren ändert, warum die IETF den Standard jetzt neu aufbaut und was die Änderung (falls überhaupt) von Domain-Inhabern verlangt, die heute DMARC betreiben.
DKIM (DomainKeys Identified Mail) sagt einem empfangenden Mailbox-Anbieter, ob eine Nachricht, die angeblich von Ihrer Domain stammt, unterwegs verändert oder gefälscht wurde. DKIM ist eine der beiden kryptografischen Prüfungen, auf die sich DMARC stützt (die andere ist SPF). DKIM ist seit 2007 der Signaturstandard der E-Mail-Branche. Die IETF schlägt offen etwas Ehrgeizigeres vor als einen Patch: einen vollständigen Neuentwurf, der drei Probleme angeht, die DKIM aus eigener Kraft nie lösen konnte.
DKIM (DomainKeys Identified Mail, definiert in RFC 6376) hängt jeder ausgehenden E-Mail eine kryptografische Signatur an. Die sendende Domain veröffentlicht einen öffentlichen Schlüssel im DNS, und der empfangende Server verwendet diesen öffentlichen Schlüssel, um die Signatur zu prüfen. Stimmt die Signatur überein, kann der Empfänger zwei Dinge vertrauen: dass die Nachricht von jemandem mit Zugriff auf den privaten Schlüssel der Domain gesendet wurde und dass der Nachrichtentext und ausgewählte Header unterwegs nicht verändert wurden.
Der Mechanismus hat drei bekannte Schwachpunkte, und die IETF-DKIM-Arbeitsgruppe hat alle drei im DKIM2-Motivationsentwurf dokumentiert (draft-ietf-dkim-dkim2-motivation):
Diese Schwachpunkte zeigen sich in echten Authentifizierungsdaten. Im DMARCeye-Branchenbericht Q1 2026 liegen die DKIM-Fehlerquoten bei großen Mailbox-Anbietern und Unternehmens-Mailsystemen hoch: 19,6 % bei Microsoft, 11,1 % bei Google, 26,3 % bei Proofpoint, 22,9 % bei Mailgun. Die transaktionalen Top-Sender im selben Datensatz (Bird, Amazon SES, SendGrid) verzeichnen DKIM-Fehlerquoten unter 1 %. Der Abstand zwischen beiden Gruppen ist die operative Realität, für die DKIM2 entwickelt wird.
Wie der Q1-Bericht selbst feststellt, sind hohe Fehlerquoten bei großen Mailbox-Anbietern fast immer ein Konfigurationsproblem auf Kundenseite und kein Mangel am Anbieter selbst. Ausgehende Mails, die durch einen Microsoft-365- oder Google-Workspace-Tenant laufen, gehen durch Weiterleiter, Mailinglisten, Drittanbieter-Relays und ältere On-Premises-Gateways. Jede einzelne dieser Stationen kann die DKIM-Signatur zerstören, ohne dass der Kunde es bemerkt.
Eine plausible Hypothese lautet, dass die spezialisierten transaktionalen Sender die saubersten Zahlen vorweisen, weil ihr gesamtes Geschäft darin besteht, einen einzigen Mail-Typ durch eine einzige Signatur-Pipeline zu schicken. Allgemeine Mailbox-Anbieter dagegen verarbeiten eine deutlich breitere Vielfalt an Mail-Flüssen, für deren Erhalt die ursprüngliche DKIM-Spezifikation nie gedacht war. Eine detaillierte Aufschlüsselung der Compliance-Raten nach ESP beschreibt dasselbe Muster aus Sicht der Sender.
DKIM2 behält die Grundidee bei - jede ausgehende E-Mail zu signieren, damit der Empfänger prüfen kann, dass sie wirklich von Ihrer Domain stammt - baut aber das Signieren von Grund auf neu auf. Der aktuelle Spezifikationsentwurf (draft-ietf-dkim-dkim2-spec-02, veröffentlicht am 17. Mai 2026, auf dem Standards-Track) führt vier substanzielle Änderungen ein.
Jeder Server in der Zustellkette signiert die Nachricht. Wenn Sie heute eine E-Mail versenden, signiert nur Ihr Sendeserver die Nachricht. Berührt etwas in der Mitte der Zustellkette die Nachricht - ein unternehmensinterner Auto-Forwarder, eine Mailingliste, die ein Betreff-Präfix anhängt, ein E-Mail-Security-Gateway, das Header verändert - bricht die ursprüngliche Signatur, und der empfangende Posteingang kann nicht erkennen, was sich geändert hat oder wer es geändert hat. DKIM2 ändert das. Jeder Mailserver, der die Nachricht bearbeitet, fügt seine eigene Signatur hinzu, sodass der Empfänger am Ende eine verifizierbare Kette in der Hand hat, die zeigt, welche Domains die Nachricht in welcher Reihenfolge berührt haben. Die Idee einer Chain-of-Custody wurde bereits vom Authenticated-Received-Chain-Protokoll (ARC, definiert in RFC 8617) vorweggenommen, einer experimentellen Ergänzung, die jetzt zugunsten von DKIM2 zurückgezogen wird.
Die Signatur wird an die tatsächlichen Empfänger der Nachricht gebunden. DKIM signiert heute den Inhalt der Mail (den Nachrichtentext und einen ausgewählten Satz von Headern), schließt aber nicht ein, an wen die Mail gesendet wird. Genau deshalb kann ein Spammer, der eine einzige signierte Nachricht abfängt, sie an Millionen anderer Personen weiterversenden, und jede Kopie besteht weiterhin die Signaturprüfung. DKIM2 behebt das, indem auch der Routing-Umschlag mitsigniert wird: die MAIL-FROM-Adresse (der Absender) und die RCPT-TO-Adressen (die Empfänger), an die die Nachricht gesendet wurde. Eine abgefangene, DKIM2-signierte Nachricht, die an eine andere Empfängerliste weitergeschickt wird, fällt sofort durch die Verifizierung, weil die Empfängeradressen im Umschlag nicht mehr zu dem passen, was der ursprüngliche Signierer signiert hat.
Jeder Server, der die Nachricht unterwegs verändert, hinterlässt einen schriftlichen Eintrag, was er verändert hat. Wenn eine Mailingliste heute ein "[list-name]"-Präfix in Ihrer Betreffzeile ergänzt oder eine Fußzeile an Ihren Nachrichtentext anhängt, bricht sie damit stillschweigend die ursprüngliche DKIM-Signatur, und der Empfänger hat keine Möglichkeit zu erkennen, ob die Änderung eine harmlose Bearbeitung oder eine feindliche Manipulation war. DKIM2 erlaubt dem ändernden Server, eine kleine, maschinenlesbare Notiz anzuhängen, die beschreibt, was er verändert hat. Die Empfänger-Software macht jede erfasste Änderung rückgängig, rekonstruiert die ursprüngliche Nachricht und prüft die ursprüngliche Signatur gegen die Rekonstruktion. Das Format dieser Änderungsnotizen ist in einem separaten Begleitentwurf festgelegt.
Auch Bounce-Nachrichten werden signiert und können daher nicht mehr gefälscht werden. Wenn Sie schon einmal eine Bounce-Benachrichtigung für eine E-Mail erhalten haben, die Sie nie gesendet haben, haben Sie "Backscatter" gesehen: Ein Spammer hat Ihre Absenderadresse gefälscht, der empfangende Server hat versucht, die Nachricht zuzustellen, konnte es nicht und hat sie an Sie zurückgesendet statt an den Spammer. DKIM2 verhindert das, indem Bounce-Nachrichten selbst kryptografisch vom empfangenden Server signiert werden müssen. Ein Bounce kann nur von einer Domain stammen, die die Nachricht ursprünglich empfangen hat, und kann nur eine Domain erreichen, die ursprünglich eine Nachricht gesendet hat.
Die DKIM-Arbeitsgruppe spricht den Grund offen aus: Der frühere Versuch, eine Chain-of-Custody-Behandlung oberhalb von DKIM nachzurüsten, hat nicht die Verbreitung erreicht, die für Zuverlässigkeit nötig wäre. ARC, 2019 als RFC 8617 veröffentlicht, war die erste Antwort der IETF auf das Mailinglisten- und Weiterleiter-Problem. ARC ließ Zwischenstationen bestätigen, in welchem Authentifizierungszustand sich eine Nachricht in dem Moment befand, in dem sie diese verarbeitet haben, sodass nachgelagerte Empfänger der Kette in der Theorie auch dann vertrauen konnten, wenn DKIM unterwegs gebrochen war.
In der Praxis blieb ARC eine experimentelle Spezifikation mit lückenhafter Verbreitung. Der DKIM2-Motivationsentwurf sagt ausdrücklich, dass der neue Standard "auf Grundlage der Erfahrungen aus dem ARC-Experiment" entwickelt wird. ARC ist in einem separaten IETF-Entwurf zur Umstufung auf Historic vorgesehen. DKIM2 ist die konsolidierte, produktionsreife Version derselben Chain-of-Custody-Idee, neu konzipiert, um als Kernersatz für DKIM einsetzbar zu sein und nicht als optionale Ergänzung.
Die DKIM-Arbeitsgruppe betreibt dieselbe Art von Generationsarbeit, die die DMARC-Arbeitsgruppe mit DMARCbis, der geplanten Aktualisierung von DMARC selbst, leistet. Beide Standards entstammen der E-Mail-Authentifizierungs-Ära von 2007 bis 2015, beide haben mehr als ein Jahrzehnt operative Erfahrung gesammelt, die zeigt, wo die ursprünglichen Spezifikationen zu kurz gegriffen haben, und beide werden jetzt mit dieser Erfahrung im Rücken neu geschrieben.
Wie auch immer DKIM2 am Ende aussieht: Der DKIM-Eintrag, den Sie heute veröffentlichen, muss trotzdem korrekt sein. Ein falsch konfigurierter DKIM-Eintrag ist der häufigste Grund, warum Mails legitimer Sender an der Authentifizierung scheitern, und (laut den Q1-2026-Daten oben) liegen die Fehlerquoten bei den großen Mailbox-Anbietern höher, als die meisten Domain-Inhaber annehmen.
Geben Sie unten Ihre Domain ein, um zu prüfen, wie Ihr veröffentlichter DKIM-Eintrag aussieht und ob er korrekt eingerichtet ist.
Wie sehr DKIM2 Sie betrifft, hängt von Ihrer Rolle im E-Mail-Ökosystem ab.
Wenn Sie eine einzelne Domain betreiben oder ein kleines Unternehmen führen: Für Sie ändert sich heute nichts. Ihr DKIM-Eintrag funktioniert weiter. Mailbox-Anbieter werden DKIM1-Signaturen noch jahrelang nach der Veröffentlichung von DKIM2 prüfen, und von Ihrer Domain wird erst dann erwartet, DKIM2-Einträge zu veröffentlichen, wenn die großen Anbieter signalisieren, dass sie nach ihnen suchen. Konzentrieren Sie sich darauf, Ihr aktuelles DKIM richtig aufzusetzen: ein Schlüssel pro Sendequelle, Schlüsselrotation nach Plan und Ausrichtung an Ihrer DMARC-Policy.
Wenn Sie einen E-Commerce-Shop betreiben und darauf angewiesen sind, dass transaktionale Mails den Posteingang erreichen, sind die Q1-2026-Fehlerquoten oben die dringendere Sorge. DKIM ist die Authentifizierungsmethode, die bei den Mailbox-Anbietern Ihrer Kunden am ehesten scheitert, und die Fehler entstehen durch operative Details (Weiterleiter, Mailinglisten, Lücken bei der Schlüsselrotation), die mit dem DKIM2-Standard nichts zu tun haben. Wenn Sie noch kein DKIM-Monitoring im Einsatz haben, deckt der kostenlose Plan von DMARCeye eine Domain mit vollständiger Berichtsverarbeitung ab, und das reicht aus, um zu sehen, ob Ihr DKIM zuverlässig signiert.
Wenn Sie eine Agentur oder ein MSP sind und Domains für Kunden verwalten: DKIM2 ist ein Mandantenwechsel, der irgendwann über Ihr gesamtes Portfolio koordiniert werden muss. DMARCeye trennt jedes Kundenkonto strikt voneinander, auch für die Model-Context-Protocol-Integration, mit der Sie den Authentifizierungsstand programmatisch abfragen können. Ihr Team kann die DKIM-Lage über viele Kundendomains hinweg aus einer einzigen Konsole überwachen, während jeder Kunde nur seine eigenen Daten sieht. Die Sichtbarkeitsinfrastruktur, die Sie heute aufbauen, ist die, die den Umstieg trägt, wenn er kommt.
Wenn Sie eine Unternehmens-Mailinfrastruktur betreiben: Behalten Sie den Deployment-Profile-Entwurf im Blick (draft-moccia-dkim2-deployment-profile, veröffentlicht im April 2026). Der Deployment-Profile-Entwurf beschreibt, wie DKIM2 über die bestehende Milter-Schnittstelle umgesetzt werden kann, die die meisten Mail Transfer Agents bereits unterstützen, ohne den MTA-Kern zu verändern. Das bedeutet, dass DKIM2 so entworfen wird, dass es sich in bestehende Mail-Stacks einfügt, statt einen vollständigen Umbau zu erzwingen. Erstellen Sie jetzt eine Bestandsaufnahme Ihrer Schlüssel und legen Sie fest, welche Sendewege Sie zuerst migrieren würden.
DKIM2 ist kein veröffentlichter RFC, und davon ist er auch nicht knapp entfernt. Die Hauptspezifikation befindet sich Stand 17. Mai 2026 in Revision 02. IETF-Internet-Drafts verfallen nach sechs Monaten, also muss die aktuelle Revision vor November 2026 entweder weitergeführt oder neu veröffentlicht werden. Mehrere Begleitentwürfe (Motivation, DNS-Spezifikation, Best Current Practices, Deployment-Profile) bewegen sich parallel weiter.
Selbst bei einem ambitionierten Zeitplan dauert die RFC-Veröffentlichung üblicherweise 12 bis 18 Monate ab einer stabilen Spezifikationsfassung. Bis zur Annahme durch Mailbox-Anbieter vergehen dann weitere Jahre: DMARC selbst wurde 2015 als RFC 7489 veröffentlicht und ist bis heute nicht flächendeckend durchgesetzt. Realistisch wird DKIM2 frühestens Ende der 2020er-Jahre der Standard für ausgehende Mails sein.
Die Arbeit, die sich 2026 lohnt, besteht darin, DKIM1 für jede Domain, die Ihnen wichtig ist, korrekt zu konfigurieren. Daran ändert die neue Spezifikation nichts.
DKIM2 ist ein ehrlicher Neuaufbau der E-Mail-Signatur, der die Lücken bei Replay, Nachvollziehbarkeit und Änderungen durch Zwischenstationen schließt, die die IETF über die fast 20-jährige Geschichte des Standards dokumentiert hat. DKIM2 trägt weiter, was an ARC funktioniert hat, lässt fallen, was nicht funktioniert hat, und ist so konzipiert, dass es in bestehenden Mail-Stacks eingesetzt werden kann. Nichts davon verlangt Domain-Inhabern heute etwas ab, aber die Sichtbarkeitsinfrastruktur, die Sie jetzt aufbauen, ist die, die Sie durch den späteren Umstieg trägt.
Wenn Sie bereits DMARC-Monitoring betreiben, ist das, was Sie heute tun können, zu prüfen, ob Ihre DKIM-Signaturen zuverlässig bestehen und ob Ihr Eintrag korrekt eingerichtet ist. DMARCeye liest die DMARC-Berichte aus, die Ihre Domain erhält, und zeigt Ihnen in klarer Sprache, wo DKIM besteht, wo es scheitert und was die Fehler verursacht, ohne dass Sie das rohe XML selbst lesen müssen.