Email-Verifikationsprotokoll: Was Chrome wirklich prüft und die 9 Fälle, in denen es sinnlos ist

Müssen Sie Ihr Anmeldeformular ändern, weil Chrome jetzt eine Gmail-Adresse mit einem Klick bestätigen kann? Google hat am 8. Juli 2026 den Origin Trial eines neuen Protokolls gestartet, das Email Verification Protocol (EVP): Der Aussteller bestätigt, dass beim E-Mail-Anbieter eine aktive Sitzung besteht, und der Browser überträgt den Nachweis, ohne dass eine Bestätigungs-E-Mail versendet wird. Konkret entfällt damit eine bestimmte Hürde, nämlich der Einmalcode oder der per E-Mail zugestellte Bestätigungslink, also genau der Schritt, an dem Ihr E-Mail-Tool alles grün anzeigt, während die hard bounce-Rate im Stillen steigt. Was das Protokoll beweist und vor allem was es nicht beweist, zeigt sich in einer Übersicht von 12 Erfassungssituationen.

Der Mechanismus des EVP-Protokolls in 6 Schritten

Das Protokoll unterscheidet 3 Rollen. Der Validator erfasst die E-Mail-Adresse in seinem Formular. Der E-Mail-Anbieter hostet das Postfach. Der Aussteller, bei einer Gmail-Adresse accounts.google.com, verwaltet die Kontositzung. Eine Adresse zu besitzen und beim eigenen Anbieter eine aktive Sitzung zu haben sind zwei unterschiedliche Dinge: Das Protokoll prüft ausschließlich Letzteres. Dafür müssen zwei Bedingungen erfüllt sein. Der Nutzer muss im selben Chrome-Profil bei seinem Postfach angemeldet sein. Zudem muss er seine Adresse aus der Autovervollständigung wählen statt sie manuell einzugeben. Ohne diese beiden Voraussetzungen wird kein Token erzeugt. Der Ablauf umfasst 6 Schritte.

1. Der Nutzer wählt seine Adresse aus der Autovervollständigung des Browsers, niemals durch manuelle Eingabe.
2. Chrome fragt den DNS-Eintrag _email-verification der Domain ab, um den zuständigen Aussteller zu ermitteln.
3. Der Aussteller bestätigt, dass für dieses Konto eine aktive Sitzung besteht, ohne weitere Informationen über den Nutzer preiszugeben.
4. Er erzeugt einen Email Verification Token im Format SD-JWT+KB, also ein Token mit selektiver Offenlegung, das an einen ephemeren öffentlichen Schlüssel gebunden und mit EdDSA oder ES256 signiert ist.
5. Der Token wird beim Absenden des Formulars über ein verstecktes Feld übertragen.
6. Der Server der Website führt 5 Prüfungen durch: Dekodierung des JWT, Überprüfung von email_verified, des Nonce und der Audience, Validierung des Key Binding, DNS-Abfrage sowie Signaturprüfung über den dafür vorgesehenen well-known-Endpunkt.

Der Mechanismus erinnert an BIMI, ein weiteres Protokoll, das auf einem DNS-Eintrag beruht und dessen Einführung anbieterweise erfolgt, nie von Anfang an universell. Schlägt eine Prüfung fehl oder fehlt der Token, greift die Website auf ihren gewohnten Ablauf zurück. Google nennt das eine progressive Verbesserung.

Die derzeitigen Verifizierungsmethoden zwingen den Nutzer, die Website zu verlassen, mit dem Risiko, dass er seine Sitzung abbricht, bevor er die Anmeldung abgeschlossen hat. Rowan Merewood, Staff Developer Relations Engineer bei Google, Chrome for Developers, 8. Juli 2026.

Die Übersicht: Wo das Protokoll greift, wo es nichts bringt

12 Erfassungssituationen, 12 unterschiedliche Antworten. Das Protokoll deckt nur einen schmalen Ausschnitt der Anmeldestrecke ab: den, in dem Chrome und Gmail zusammenwirken und die Autovervollständigung im selben Profil tatsächlich genutzt wird. Bei Safari verfügt Apple bereits über eine eigene Ebene mit E-Mail-Adresse verbergen, einem unabhängigen Mechanismus, der die Adressen in Ihren Listen neu verteilt und mit dem Chrome-Protokoll nichts zu tun hat.

Der kontraintuitivste Fall steckt in einer einzigen Tabellenzeile. Eine Wegwerfadresse, gehostet bei einem Anbieter, der irgendwann einen Aussteller einführen würde, würde die EVP-Prüfung mit einem einwandfrei gültigen Token bestehen. Der Token misst nichts anderes als eine aktive Sitzung zum Zeitpunkt T; er sagt nichts über die vorgesehene Lebensdauer des Postfachs aus, noch über die tatsächliche Absicht hinter der Anmeldung. Eine Yopmail- oder Mailinator-Adresse mit eigenem Aussteller würde einen ebenso sauberen Token signieren wie eine gewöhnliche Gmail-Adresse.

Der zweite blinde Fleck betrifft die Zeit. Der Token bestätigt einen Besitz zum Zeitpunkt der Anmeldung, niemals danach. Bei einer gerade erst erstellten Adresse bleibt die Abweichung zwischen dem, was das Protokoll behauptet, und der Realität des Postfachs gering. Nach einigen Monaten Inaktivität hingegen signalisiert nichts im Mechanismus, dass ein Postfach voll oder seit Monaten aufgegeben ist. EVP ist dafür auch gar nicht gedacht: Es beschränkt sich auf den Besitznachweis zum Zeitpunkt der Erfassung, eine Momentaufnahme, die verblasst, ohne sich je zu aktualisieren.

Ein dritter Unsicherheitsbereich betrifft geschäftliche Adressen. Google Workspace gab für das 4. Quartal 2025 mehr als 11 Millionen zahlende Kunden an, eine Zahl, die Sundar Pichai am 4. Februar 2026 verkündete, also ebenso viele Organisationen, deren Postfächer bei Google gehostet werden. Die Dokumentation sagt nicht, ob diese Domains den Eintrag _email-verification veröffentlichen und in die erste Spalte der Übersicht aufrücken können. Die betreffende Tabellenzeile bleibt an das Fehlen dieses Eintrags geknüpft, nie an den Adresstyp.

Kann der EVP-Token als DSGVO-Nachweis dienen?

Die Chrome-Dokumentation widmet dem Datenschutz keinen eigenen Abschnitt. Die DSGVO kommt darin nicht vor. Die Marketing-Einwilligung ebenso wenig, genauso wenig die vorgesehene Aufbewahrungsdauer des Tokens. Dieses Schweigen verlagert die Entscheidung auf den Verantwortlichen statt auf den Browser.

Auf Nutzerseite existiert dennoch eine Schutzvorkehrung. Chrome zeigt beim ersten Mal, wenn eine Adresse zur Validierung bereitgestellt wird, eine Freigabeaufforderung an; diese erscheint danach für dieselbe Adresse nicht mehr erneut. Die erste Validierung erfolgt also nicht ohne Wissen der angemeldeten Person. Für diese Adresse fragen die folgenden Male nichts mehr nach.

Der Token enthält konkrete personenbezogene Daten: den Aussteller (iss), die Adresse oder ihr Äquivalent (email), einen Gültigkeitsindikator (email_verified), einen Zeitstempel (iat), einen Bestätigungsschlüssel (cnf), den Ursprung der Website (aud), einen Nonce sowie einen Bestätigungshash (sd_hash). Ihn als Beleg zu speichern bedeutet, ein personenbezogenes Datum aufzubewahren, das den Grundsätzen der Datenminimierung und der Speicherbegrenzung unterliegt. Wie lange sollte man ihn aufheben? Die Dokumentation äußert sich dazu nicht. Das ist eine Frage, die Sie mit Ihrem Datenschutzbeauftragten klären sollten, nicht mit Ihrem technischen Dienstleister.

Ein Detail verändert die Lage bei der Datenminimierung: Der Claim email kann selektiv offengelegt werden. So konfiguriert, übermittelt er dem Validator einen Hash statt der Klartextadresse, eine Einstellung, die vor jeder Produktivsetzung zu prüfen ist.

Artikel 7 Absatz 1 der DSGVO verpflichtet den Verantwortlichen, die Einwilligung der betroffenen Person nachweisen zu können. Der Bestätigungsklick beim double opt-in erfüllt diese Rolle heute. Der EVP-Token ersetzt ihn nicht: Er bescheinigt einen technischen Besitz des Postfachs zum Zeitpunkt der Anmeldung, ohne etwas über die spätere Zustimmung zum Empfang von Nachrichten auszusagen. Er löst dafür ein anderes Problem, das double opt-in nur unvollständig abdeckt, nämlich den Einwand „diese Adresse habe nicht ich eingegeben“. Double opt-in beweist die Einwilligung, der Token beweist den Besitz des Postfachs zum Zeitpunkt der Anmeldung: Ein Formular, das beides kombiniert, schließt beide Flanken zugleich.

Zur Vertraulichkeit auf Ausstellerseite äußert sich Google eindeutig: „Der Aussteller sieht nur eine Anfrage zur Überprüfung der Existenz des Nutzers, er sieht nicht, welche Website die Anfrage ausgelöst hat.“ Die Architektur des Tokens macht diese Aussage glaubwürdig: Der Browser baut das Key-Binding-Token, das den Ursprung der Website und den Nonce enthält, erst nach Erhalt des Tokens vom Aussteller und signiert es mit dem ephemeren Schlüssel. Der Aussteller muss die empfangende Website also nie kennen, um seinen Teil des Tokens zu signieren.

Zwei Fragen bleiben in der aktuellen Dokumentation offen. Die genaue rechtliche Rolle des Ausstellers in der Kette ist nicht geklärt: Handelt er als Verantwortlicher oder als Auftragsverarbeiter? Übermittlungen außerhalb der Europäischen Union sind ebenfalls nicht dokumentiert: Der Aussteller ist der Anbieter, der das Postfach der Person bereits hostet. Die Dokumentation sagt jedoch nichts zur Verarbeitung des Tokens selbst oder zu seinem Speicherort.

Ihre tatsächliche Protokollabdeckung berechnen

Chrome hält im Mai 2026 weltweit einen Anteil von 65,23 % an den Browsersitzungen, ein Wert, der bei alleiniger Betrachtung von Desktop-Geräten auf 76,39 % steigt (StatCounter, Mai 2026). Dieser globale Anteil sagt nichts über Ihre tatsächliche EVP-Abdeckung aus, die einzig von Ihren eigenen Traffic- und Anmeldedaten abhängt. Bei der Messaging-Seite wird Gmail rund 1,8 Milliarden aktive Nutzer weltweit zugeschrieben, eine Statista-Schätzung vom November 2024, die die Branche mangels regelmäßiger Veröffentlichung durch Google übernimmt. Dieses Volumen setzt eine theoretische Obergrenze, niemals Ihren tatsächlichen Anteil: Eine Datenbank voller geschäftlicher Adressen und eine Datenbank voller Endkundenanmeldungen ergeben keineswegs denselben Prozentsatz.

3 Zahlen genügen. Der Chrome-Traffic-Anteil auf Ihrem Anmeldeformular, ablesbar in Google Analytics oder Matomo. Der Gmail-Adressanteil unter Ihren jüngsten Anmeldungen, indem Sie die Domain aus Ihrer ESP-Datenbank extrahieren. Und der Anteil dieser Anmeldungen, bei denen die Autovervollständigung das Feld tatsächlich ausgefüllt hat statt einer manuellen Eingabe, eine Zahl, die keine API nativ liefert und die Sie selbst instrumentieren müssen, etwa durch den Vergleich der im E-Mail-Feld ausgelösten input- und change-Events.

Die ersten beiden Zahlen zu multiplizieren ergibt eine obere Grenze. Die dritte, fast immer übersehen, drückt sie wieder nach unten.

Der dreistufige Aufbau, vom Token bis zum Versand

Der naheliegende Gedanke, sobald der Mechanismus verstanden ist: Wenn Chrome die Adresse bei der Anmeldung bereits validiert, wozu dann noch für eine Prüfung vor dem Versand bezahlen? Die Antwort liegt im Geltungsbereich des Tokens, der genau dort endet, wo die Übersicht es zeigt.

Der Token erlaubt es, bei Gmail-Anmeldungen über Chrome den Klick auf den Bestätigungslink zu überspringen. Double opt-in behält damit seine eigene, weiter oben beschriebene Rolle: den Nachweis einer aktiven Einwilligung, in der Praxis mit Zeitstempel versehen, um sie wie von Artikel 7 Absatz 1 der DSGVO gefordert belegen zu können. Ein EVP-Token ersetzt weder die angehakte Checkbox noch den zum Zeitpunkt der Einwilligung in der Datenbank gespeicherten Zeitstempel.

Google legt seit 2024 für Massenversand eine Schwelle für die Beschwerderate von 0,3 % fest, andernfalls werden Nachrichten bei Gmail als Spam markiert oder abgewiesen, ein Wert, der bereits in den Google Postmaster Tools pro Absenderdomain sichtbar ist. Eine Wegwerfadresse oder ein geschlossenes Postfach, das die Kampagne trotzdem erhält, treibt diese Rate nach oben, selbst mitten in der IP-Warmup-Phase, unabhängig davon, was der Token bei der Anmeldung anzeigte. Die Deliverability entscheidet sich beim Versand, wenn die Erfassung schon lange zurückliegt. Es ist nicht das erste technische Protokoll, das ein Glied der Kette neu gestaltet, ohne die anderen zu ersetzen: DKIM2 folgte bei der Authentifizierung von Nachrichten derselben Logik.

Die Prüfung, die Syntax, MX-Record und teils die Deliverability-Historie vor dem Versand kontrolliert, wie sie CaptainVerify durchführt, fügt sich folgerichtig zwischen Erfassung und Kampagne ein. Der einzige Weg herauszufinden, ob Ihre Datenbank diesen Filter braucht, ist ein Test an einer Stichprobe vor dem nächsten Versand.

Was Sie mindestens in der Datenbank behalten sollten: den DSGVO-Opt-in-Nachweis, den Status der letzten list hygiene-Prüfung und das Datum der letzten Kampagne, die ohne Bounce versendet wurde. Der EVP-Token hingegen ist nicht dafür vorgesehen, über die Anmeldesitzung hinaus gespeichert zu werden.

Gmail bleibt heute der einzige Aussteller für Privatnutzer. Die Chromium-Browser setzen das Protokoll um: Chrome seit Version 150, Edge über einen eigenen Origin Trial auf Microsoft-Seite. Sein Weg zur Standardisierung ist bereits vorgezeichnet: Ein von Dick Hardt und Sam Goto unterzeichneter Internet-Draft liegt der IETF seit dem 17. Juni 2026 vor, in einer auf den 4. Juli datierten Revision, als Einzeleinreichung, bisher ohne Arbeitsgruppe oder Freigabe. Validity schätzt in seiner Analyse vom Juli 2026, dass double opt-in beim Bestätigungsschritt 20 bis 35 % der Anmeldungen kostet, eine Hürde, die EVP auf Gmail-Seite tatsächlich verringern könnte. Führen Outlook oder Yahoo irgendwann einen eigenen Aussteller ein, erweitert sich die erste Spalte der Übersicht; ohne sie bleibt sie auf Gmail beschränkt.

Häufig gestellte Fragen zum Email Verification Protocol

Funktioniert das EVP-Protokoll auf Mobilgeräten oder in einer App?
Die Dokumentation klärt diesen Punkt nicht ausdrücklich. Das Protokoll braucht die Autovervollständigung des Browsers; fehlt sie, etwa in bestimmten In-App-Browsern, greift der Mechanismus nicht.

Welche Browser unterstützen EVP im Jahr 2026?
Chrome seit Version 150, über den am 8. Juli 2026 gestarteten Origin Trial. Edge folgt mit seinem eigenen Origin Trial, aufgeführt im Abschnitt Implementation Status des IETF-Drafts: derselbe Chromium-Mechanismus, mit einem bei Microsoft zu registrierenden Token, das sich von dem in Chrome unterscheidet. Bei Safari gibt es bislang keine Ankündigung.

Funktioniert das Protokoll mit Outlook oder Yahoo?
Noch nicht. Gmail ist zum Start der einzige E-Mail-Anbieter, der Tokens ausstellt. Die für andere E-Mail-Anbieter vorgesehene API befindet sich bei Google noch in der Entwicklung.

Sollte man den Origin Trial schon jetzt aktivieren?
Nur wenn Chrome und Gmail einen messbaren Anteil Ihrer Anmeldungen ausmachen. Der Trial bringt Traffic-Grenzen und einen bei Fehlschlag verpflichtenden Fallback auf die klassische Bestätigungs-E-Mail mit sich.