Warum Sie E-Mails nicht mit Regex validieren sollten

Ein Regex kann eine E-Mail-Adresse nicht validieren — er kann lediglich die grobe Form prüfen, und selbst das sorgfältigst konstruierte Muster wird sowohl legitime Adressen ablehnen als auch syntaktisch plausible akzeptieren, die niemals zugestellt werden. Der Grund liegt nicht darin, dass Sie noch nicht das richtige Muster gefunden haben; es liegt daran, dass die Frage „Ist diese E-Mail-Adresse gültig?” drei verschiedene Probleme vermischt, und ein Regex kann immer nur eines davon berühren — das am wenigsten nützliche. Dieser Artikel trennt diese drei Probleme voneinander, zitiert, was die Spezifikationen tatsächlich besagen (RFC 5321, RFC 5322, RFC 6531 und der WHATWG HTML Living Standard), zeigt genau, wo gängige Muster in beide Richtungen versagen, und liefert Ihnen pragmatischen JS/TS-Code, den Sie stattdessen verwenden können.

Die drei Ebenen der E-Mail-Validierung

E-Mail-Validierung hat drei unterschiedliche Ebenen: eine UX-Plausibilitätsprüfung (sieht es wie eine E-Mail aus?), syntaktische Validierung (entspricht es den Regeln von RFC 5321/5322?) und Existenzverifizierung (empfängt dieses Postfach tatsächlich E-Mails?). Nur die dritte Ebene beweist, dass die Adresse funktioniert, und nur eine Bestätigungs-E-Mail liefert diesen Beweis. Die Quellen, die Ihnen sagen, Sie sollten „aufhören, Regex zu verwenden”, haben Recht, aber sie vermischen diese Ebenen. Sie getrennt zu halten, zeigt Ihnen, welches Werkzeug wohin gehört.

• Ebene 1 — UX-Plausibilitätsprüfung. Eine schnelle, kostengünstige, clientseitige Prüfung, die offensichtliche Tippfehler erkennt (alicegmail.com, ein abschließendes Leerzeichen) und sofortiges Feedback gibt. Dies ist die einzige Ebene, auf der ein Regex seinen Platz hat, und selbst hier möchten Sie das kleinstmögliche Muster, das die Aufgabe erfüllt.
• Ebene 2 — Syntaktische Validierung. Entspricht der String der Grammatik in den E-Mail-RFCs? Dies ist weitaus schwieriger als es aussieht, überfordert handgeschriebene Regexes, und — entscheidend — beweist nichts über die Zustellbarkeit. Eine perfekt RFC-konforme Adresse kann auf eine Domain zeigen, die nicht existiert.
• Ebene 3 — Existenzverifizierung. Empfängt ein echtes Postfach E-Mails an dieser Adresse? Der einzige Beweis, dass eine E-Mail-Adresse funktioniert, ist eine erfolgreich zugestellte Nachricht; eine Bestätigungs-E-Mail erledigt in einem Schritt, was kein Regex überhaupt leisten kann.

Der Fehler, den nahezu jeder „ultimative E-Mail-Regex” macht, besteht darin, Ebene 2 perfekt abdecken zu wollen, obwohl Ebene 2 die Frage, die eigentlich relevant ist, nicht beantwortet. Die relevante Frage ist Ebene 3, und kein Muster erreicht sie.

Was „gültig” tatsächlich bedeutet

Eine gültige E-Mail-Adresse ist weit permissiver, als die meisten Regexes annehmen, da die Grammatik in RFC 5321 (SMTP) und RFC 5322 (das Nachrichtenformat) Konstrukte erlaubt, die fehlerhaft aussehen. Der Local Part — alles vor dem @ — kann eine lange Liste von Sonderzeichen enthalten und sogar ein quoted String sein.

Der unquoted Local Part wird aus atext aufgebaut, definiert in RFC 5322 §3.2.3, das neben Buchstaben und Ziffern folgende Zeichen erlaubt:

! # $ % & ' * + - / = ? ^ _ ` { | } ~

Das bedeutet, user+tag@example.com (Plus-Addressing) ist gültig — das + ist gewöhnliches atext gemäß RFC 5321 §4.1.2. Ob der empfangende Server das +tag als Subadresse behandelt, ist implementierungsspezifisch (RFC 5233), aber die Adresse selbst ist wohlgeformt. Der Local Part kann auch ein quoted String sein: "user name"@example.com ist gemäß RFC 5321 §4.1.2 und RFC 5322 §3.2.4 gültig — Leerzeichen inklusive. Die Domain kann ein IP-Adressliteral in eckigen Klammern sein — user@[192.168.1.1] ist gemäß RFC 5321 §4.1.3 gültig.

Es gibt eine Einschränkung, die sich kostengünstig durchsetzen lässt. RFC 5321 §4.5.3.1.3 begrenzt den Forward-Path auf 256 Oktette einschließlich der spitzen Klammern, was 254 Zeichen für die Adresse selbst übrig lässt; der Local Part ist separat auf 64 Oktette begrenzt (§4.5.3.1.1) und die Domain auf 255 (§4.5.3.1.2). Eine Längenprüfung ist die einzige Validierung, die ein String-Vergleich korrekt handhabt und für die ein Regex nicht benötigt wird.

Internationalisierte Adressen (EAI)

Internationalisierte E-Mail-Adressen, die in RFC 6531 definiert sind — wie 用户@例子.广告 — sind gültig und werden zunehmend häufiger; kein ASCII-only-Regex verarbeitet sie, und dies ist ein Problem für Bibliotheken, kein Regex-Problem. EAI (RFC 6531 §3.3) erweitert den Local Part um UTF-8-Unterstützung, und die Domain kann nicht-ASCII-Unicode sein. Dies unterscheidet sich von IDNA-Punycode-kodierten Domains (RFC 5891): EAI deckt auch den Local Part ab. Jedes Muster, das [a-zA-Z0-9] für den Local Part voraussetzt, ist für einen wachsenden Teil der Nutzer weltweit falsch, und es gibt keinen einzelnen Regex, der sowohl ASCII- als auch Unicode-Local-Parts korrekt akzeptiert, ohne dabei auch ungültige Eingaben durchzulassen.

Warum E-Mail-Validierungs-Regexes in beide Richtungen versagen

Ein handgeschriebener E-Mail-Regex versagt sowohl als Türsteher als auch als Filter: Er produziert False Negatives (lehnt zustellbare Adressen ab) und False Positives (akzeptiert Adressen, die der Grammatik entsprechen, aber niemals E-Mails empfangen werden). Beide Fehlermodi gelangen ständig in die Produktion, weil die Testsuite test@example.com verwendet, das jedes Muster besteht.

Nehmen Sie das kanonische Stack-Overflow-Copy-Paste — ein Muster, das eine 2- bis 4-stellige TLD erfordert:

// Ein häufig kopiertes Muster. Nicht verwenden.
const bad = /^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$/;

So verhält es sich bei echten Adressen:

Ein Regex, der name+filter@gmail.com (Plus-Addressing) oder user@studio.photography (eine gTLD, die im Rahmen des New gTLD Program von ICANN delegiert wurde, wobei .photography 2013 in den Root aufgenommen wurde) ablehnt, ist nicht streng — er ist schlicht falsch. Beide sind syntaktisch plausible Adressen, die gültige E-Mail-Funktionen verwenden. Die {2,4}-TLD-Beschränkung allein bricht .photography, .accountants, .engineering und Hunderte anderer gültiger Delegierungen.

Session Replays zeigen häufig Nutzer, die auf Validierungsfehler stoßen, ihre Eingabe mehrfach korrigieren und das Formular schließlich abbrechen. Studien zur Formular-Usability haben Validierungsreibung konsistent als Faktor für Abbrüche und reduzierte Konversionsraten identifiziert.

False Positives — Adressen, die den Regex bestehen, aber niemals zugestellt werden — sind ebenso real. someone@validformat.test besteht das obige Muster und die meisten anderen, aber .test ist eine reservierte TLD (RFC 2606), die niemals zustellen wird. Syntaktische Konformität und Zustellbarkeit sind unabhängige Eigenschaften, und ein Regex sieht immer nur die erste.

ReDoS: Wenn der Regex die Schwachstelle ist

Ein backtracking-anfälliger E-Mail-Regex, der serverseitig in Node.js ausgeführt wird, kann mit einer präparierten Eingabe ausgenutzt werden, um den Event Loop zu blockieren — ein Denial-of-Service-Angriffsvektor (CWE-1333: Inefficient Regular Expression Complexity sowie die OWASP-ReDoS-Referenz), der nichts mit E-Mail zu tun hat, aber alles mit katastrophalem Backtracking. Muster mit verschachtelten oder benachbarten Quantoren über überlappenden Zeichenklassen können bei Eingaben, die fast übereinstimmen, exponentiell viel Zeit benötigen.

Hier ist eine reproduzierbare Demonstration. Das (...)+ des Musters umschließt eine Gruppe, die dasselbe Zeichen auf mehrere Arten matchen kann, sodass eine lange Folge eines Zeichens gefolgt von einem nicht matchenden Zeichen die Engine zwingt, exponentiell viele Partitionen auszuprobieren, bevor sie scheitert:

// Node.js v24. Ausführen mit: node redos.js
// Ein absichtlich verwundbares, backtracking-anfälliges Muster.
const evil = /^([a-zA-Z0-9]+)*@example\.com$/;

// Eine präparierte Beinahe-Übereinstimmung: viele 'a's, dann ein Zeichen, das den Match bricht.
const attack = "a".repeat(40) + "!";

console.time("redos");
evil.test(attack); // blockiert den Event Loop
console.timeEnd("redos");

Bei einem aktuellen Node.js-Build wächst die Match-Zeit mit zunehmender Wiederholungsanzahl explosionsartig — jedes hinzugefügte Zeichen verdoppelt in etwa den Aufwand. Da die Regex-Engine von Node synchron auf dem Haupt-Thread läuft, blockiert eine einzige Anfrage mit dieser Eingabe den Event Loop und hält alle anderen laufenden Anfragen auf. Die Form (x+)* ist das Erkennungszeichen: Jede Gruppe, die dieselbe Teilzeichenkette auf mehr als eine Weise matchen kann, unter einem äußeren Quantor, ist ein Kandidat für katastrophales Backtracking. Die Lösung ist nicht ein clevereres Muster — es ist, diese Klasse von Mustern überhaupt nicht zu erstellen, was genau das ist, was die Delegation an die Plattform oder eine gepflegte Bibliothek Ihnen einbringt.

Syntax ist nicht Zustellbarkeit

Selbst eine perfekt RFC-konforme Adresse sagt nichts darüber aus, ob eine E-Mail ankommen wird. Ein Regex kann nicht prüfen, ob die Domain existiert, ob sie MX-Records hat, ob das Postfach eingerichtet ist oder ob die Adresse nicht eine Wegwerf-Adresse ist. Das sind Netzwerk- und Richtlinienfragen, keine Grammatikfragen. Eine Adresse wie realuser@gmail.com und ein Tippfehler wie realuser@gmial.com sind beide syntaktisch gültig; nur ein DNS-Lookup unterscheidet sie, und nur eine tatsächliche Zustellung unterscheidet ein aktives Postfach von einem inaktiven.

Wegwerf- und Temporär-E-Mail-Domains sind ein verwandtes, separates Anliegen: Adressen, die syntaktisch und operativ gültig sind, aber existieren, um Ihre Registrierung zu umgehen. Ihre Erkennung erfordert eine gepflegte Blockliste von Anbieter-Domains, kein Muster — die Domain-Liste ändert sich ständig, und jede Liste, die Sie fest einprogrammieren, wird veraltet. Behandeln Sie dies als Richtlinien-Ebene über der Validierung, nicht als Teil davon.

Was Sie stattdessen tun sollten

Verwenden Sie den geschichteten Ansatz: eine minimale Plausibilitätsprüfung für die UX, die eingebaute Validierung der Plattform für die Syntax, eine gepflegte Bibliothek nur wenn Sie mehr benötigen, und eine Bestätigungs-E-Mail für das Einzige, das wirklich zählt. Hier ist die Reihenfolge, von kostengünstig bis autoritativ.

1. Eine minimale Plausibilitätsprüfung

Für sofortiges clientseitiges Feedback ist das kleinste nützliche Muster dasjenige aus dem ursprünglichen „Hören Sie auf, mit Regex zu validieren”-Argument: Verlangen Sie etwas, ein @, etwas, einen Punkt und etwas. Kombinieren Sie es mit einer Längenprüfung.

/**
 * Ebene-1-Plausibilitätsprüfung: erkennt offensichtliche Tippfehler, nichts weiter.
 * Absichtlich permissiv — es ist KEIN Gültigkeitsbeweis.
 * @param value - der rohe Eingabe-String
 * @returns true, wenn der Wert die grobe Form einer E-Mail hat und <= 254 Zeichen lang ist
 */
export function looksLikeEmail(value: string): boolean {
  if (value.length > 254) return false; // RFC 5321 §4.5.3.1.3
  return /.+@.+\..+/.test(value);
}

Diese Plausibilitätsprüfung lehnt alicegmail.com und alice@localhost ab, akzeptiert Plus-Addressing und lange gTLDs und läuft in konstanter Zeit. Es ist nicht sicher, ihr true als „gültig” zu behandeln — sie ist ein Tippfehler-Erkenner.

2. Die Plattform bevorzugen: <input type="email">

Der beste Standard für syntaktische Validierung ist das eigene <input type="email"> des Browsers, und es lohnt sich zu wissen, was es genau tut. Das <input type="email"> des HTML Living Standard verwendet einen Regex, den die Spezifikation selbst als „willful violation of RFC 5322” bezeichnet — er ist absichtlich nicht RFC-vollständig und tauscht Spezifikationsgenauigkeit gegen Benutzerfreundlichkeit ein; er ist ein besserer Standard als jedes Muster, das Sie selbst schreiben werden. Die Spezifikation zitiert das genaue Muster:

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$

Klausel für Klausel gelesen:

• [a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+ — der Local Part, der die atext-Sonderzeichen erlaubt. Er unterstützt absichtlich keine quoted Local Parts ("user name"@…).
• @ — genau ein Trennzeichen.
• [a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])? — ein Domain-Label: beginnt und endet alphanumerisch, Bindestriche innen erlaubt, auf 63 Zeichen begrenzt. Er unterstützt absichtlich keine IP-Literal-Domains (user@[192.168.1.1]).
• (?:\.<label>)* — null oder mehr zusätzliche punktgetrennte Labels, sodass sowohl einstufige als auch mehrstufige Domains bestehen.

Die WHATWG dokumentiert den Kompromiss offen: Dieses Muster lehnt einige technisch gültige RFC-5322-Adressen (quoted Parts, IP-Literale) absichtlich ab, weil diese Formen bei echten Registrierungen verschwindend selten sind und ihre Unterstützung mehr Fehler verursacht, als sie verhindert. Das ist der richtige Kompromiss für ein Formularfeld, und deshalb sollte <input type="email"> Ihr Ebene-2-Ausgangspunkt sein — es hat keine Backtracking-Pathologie und entspricht dem, was Browser bereits durchsetzen.

3. Auf eine gepflegte Bibliothek zurückgreifen, nur wenn Sie mehr benötigen

Wenn Sie serverseitige syntaktische Validierung über das HTML5-Muster hinaus benötigen, verwenden Sie eine gepflegte, gut getestete Bibliothek, anstatt Ihre eigene zu schreiben. Das validator-Paket (npm validator, MIT-lizenziert) stellt eine isEmail-Funktion bereit, die quoted Local Parts unterstützt und Optionen für IP-Literal-Domains und Display Names bietet:

import isEmail from "validator/lib/isEmail";

/**
 * Ebene-2-syntaktische Validierung, serverseitig.
 * @param email - Kandidaten-Adresse (bereits auf Länge geprüft)
 * @returns true, wenn syntaktisch gültig gemäß den RFC-ausgerichteten Regeln von validator
 */
export function isSyntacticallyValid(email: string): boolean {
  return isEmail(email, { allow_utf8_local_part: true });
}

Bevorzugen Sie dies gegenüber dem älteren email-validator-Paket, das seit 2018 nicht mehr veröffentlicht wurde. Eine Bibliothek bietet Ihnen getestete Edge-Case-Behandlung und einen aktiven Maintainer, der die Fälle behebt, die Ihr handgeschriebenes Muster nie abdecken wird — einschließlich, mit den richtigen Optionen, EAI-Adressen.

4. Die eigentliche Antwort: Senden Sie eine Bestätigungs-E-Mail

Der einzige Schritt, der beweist, dass eine Adresse funktioniert, ist die Zustellung. Senden Sie eine Bestätigungsnachricht mit einem Einmal-Link; behandeln Sie die Adresse erst dann als verifiziert, wenn der Nutzer darauf klickt. Dies ist Double Opt-In, und es macht aufwändige vorgelagerte Validierung überflüssig — eine fehlerhafte oder nicht zustellbare Adresse wird schlicht nie bestätigt.

/**
 * Skizze des Verifizierungsablaufs. Storage und Mailer sind anwendungsspezifisch.
 * @param email - ein String, der bereits Längen- und Syntaxprüfungen bestanden hat
 */
async function startEmailVerification(email: string): Promise<void> {
  const token = crypto.randomUUID();
  await storePendingVerification(email, token); // läuft z.B. nach 24h ab
  const link = `https://app.example.com/verify?token=${token}`;
  await sendMail(email, "Bestätigen Sie Ihre E-Mail-Adresse", `Klicken Sie zur Bestätigung: ${link}`);
  // Konto erst als verifiziert markieren, wenn /verify mit einem gültigen Token aufgerufen wird.
}

Das Senden einer Bestätigungs-E-Mail ist die Lösung, zu der Quelle für Quelle letztendlich gelangt, aus demselben Grund: Es erledigt in einem Schritt, was kein Regex überhaupt leisten kann. Wie Jamie Zawinski es formulierte: „Some people, when confronted with a problem, think, ‘I know, I’ll use regular expressions.’ Now they have two problems.” Bei E-Mails ist das zweite Problem, dass der Regex die Frage immer noch nicht beantwortet hat.

Fazit

Hören Sie auf, die Adresse zu validieren, und beginnen Sie damit, das Postfach zu verifizieren. Verwenden Sie ein minimales Muster plus eine 254-Zeichen-Begrenzung für sofortiges UX-Feedback, setzen Sie auf <input type="email"> oder eine gepflegte Bibliothek wie validator für die Syntax, und sperren Sie jedes echte Konto hinter einer Bestätigungs-E-Mail — dieser letzte Schritt ist der einzige, der beweist, dass jemand zu Hause ist. Wenn das nächste Mal ein Anmeldeformular ein E-Mail-Feld benötigt, greifen Sie zur Plattform und zum Bestätigungsablauf, nicht zum Stack-Overflow-Muster.

FAQs

Was ist die maximale gültige Länge einer E-Mail-Adresse?

Eine E-Mail-Adresse ist auf 254 Zeichen begrenzt. Dies ergibt sich aus RFC 5321 Abschnitt 4.5.3.1.3, der den Forward-Path auf 256 Oktette einschließlich der umgebenden spitzen Klammern begrenzt, was 254 für die Adresse selbst übrig lässt. Der Local Part ist separat auf 64 Oktette und die Domain auf 255 Oktette begrenzt. Ein einfacher Längenvergleich setzt dies korrekt durch — das ist die einzige Validierung, die sich lohnt, vor der Ausführung eines Musters durchzuführen.

Validiert das HTML5-E-Mail-Input gegen die vollständige RFC-5322-Grammatik?

Nein. Der HTML Living Standard beschreibt seinen E-Mail-Input-Regex ausdrücklich als 'willful violation of RFC 5322'. Er lehnt absichtlich technisch gültige Formen wie quoted Local Parts ('user name'@example.com) und IP-Literal-Domains (user@[192.168.1.1]) ab, weil diese bei echten Registrierungen verschwindend selten sind. Der Kompromiss bevorzugt Benutzerfreundlichkeit gegenüber Spezifikationsvollständigkeit, was ihn zu einem sichereren Standard macht als ein handgeschriebenes Muster — er ist jedoch kein vollständiger RFC-Validator.

Wie kann ein E-Mail-Validierungs-Regex einen Denial-of-Service-Angriff verursachen?

Ein Regex mit verschachtelten oder benachbarten Quantoren über überlappenden Zeichenklassen, wie die Form ([a-zA-Z0-9]+)*, kann bei Eingaben, die fast übereinstimmen, exponentiell viel Zeit benötigen. Dies ist katastrophales Backtracking, klassifiziert als CWE-1333. Serverseitig in Node.js ausgeführt, wo die Regex-Engine synchron auf dem Haupt-Thread läuft, kann eine einzige präparierte Anfrage den Event Loop blockieren und alle anderen laufenden Anfragen aufhalten. Die Lösung besteht darin, diese Musterklasse vollständig zu vermeiden, nicht darin, ein clevereres Muster zu schreiben.

Kann ein Regex prüfen, ob eine E-Mail-Adresse tatsächlich existiert?

Nein. Ein Regex untersucht nur die Form des Strings; er kann nicht verifizieren, ob die Domain existiert, MX-Records hat oder ob das Postfach eingerichtet ist. Syntaktische Konformität und Zustellbarkeit sind unabhängige Eigenschaften. Eine Adresse wie realuser@gmial.com ist syntaktisch gültig, aber aufgrund eines Tippfehlers nicht zustellbar, und someone@validformat.test besteht die meisten Muster, verwendet aber eine reservierte TLD, die niemals zustellt. Nur eine erfolgreich zugestellte Bestätigungs-E-Mail beweist, dass eine Adresse E-Mails empfängt.

Warum lehnen E-Mail-Regexes gültige Adressen wie name+filter@gmail.com ab?

Plus-Addressing ist vollständig gültig, weil das Pluszeichen gemäß RFC 5322 Abschnitt 3.2.3 und RFC 5321 Abschnitt 4.1.2 gewöhnliches atext ist. Muster, die es ablehnen, ebenso wie Adressen auf langen gTLDs wie .photography oder internationalisierte Adressen gemäß RFC 6531, sind nicht streng — sie sind schlicht falsch. Diese False Negatives gelangen in die Produktion, weil Testsuites test@example.com verwenden, das jedes Muster besteht, sodass die Ablehnung echter Adressen in Tests nie auftaucht.