E-Mail-Validierung richtig gemacht: Warum es den perfekten Regex nicht gibt (und was stattdessen hilft)

Irgendwo in jeder Codebasis lauert ein E-Mail-Validierungs-Regex. Manchmal ist er fünf Zeichen lang, manchmal ein 6000-Byte-Monster, das aus einem Standarddokument kopiert wurde. Beide sind in entgegengesetzte Richtungen falsch, und die Geschichte des Warum ist eine der besten Illustrationen der Softwaretechnik für die Lücke zwischen Spezifikation und Realität. Diese Anleitung behandelt, was die E-Mail-Spezifikation tatsächlich zulässt, warum Regexes daran immer wieder scheitern und auf welche geschichtete Validierungsstrategie echte Systeme sich schließlich einigen.

Was die Spezifikation tatsächlich erlaubt (Überraschung inklusive)

E-Mail-Adressen sind primär durch RFC 5322 definiert. Das Format ist local-part@domain, und die Regeln für den lokalen Teil sind weit großzügiger, als die meisten Entwickler erwarten. All das ist technisch gültig:

"John Doe"@example.com — zitierte Zeichenketten dürfen Leerzeichen enthalten
user+newsletter@gmail.com — Plus-Adressierung (Gmail-Nutzer verlassen sich täglich darauf)
user.name+tag@sub.domain.co.uk — Punkte und mehrstufige Domains
very.unusual."@".unusual.com@example.com — ein @-Zeichen innerhalb von Anführungszeichen als Inhalt des lokalen Teils
user@[192.168.1.1] — ein IP-Literal statt eines Domainnamens
用户@example.com — nicht-ASCII-lokale Teile unter der Erweiterung für internationalisierte E-Mail (RFC 6531)

Und die Regeln haben auch in die andere Richtung Zähne: Punkte dürfen im nicht zitierten lokalen Teil nicht am Anfang, am Ende oder aufeinanderfolgend stehen; der lokale Teil ist auf 64 Zeichen begrenzt, die gesamte Adresse auf 254; Domains müssen gültige Hostnamen sein.

Die Erkenntnis: Die Menge der „gültigen“ Adressen ist groß und seltsam, und die Menge der „ungültigen“ hat Randfälle, die normal aussehen. Jeder Regex, der einfach genug zum Pflegen ist, weist echte Adressen zurück oder akzeptiert Unsinn — meist beides.

Warum der Regex immer enttäuscht

Drei strukturelle Probleme besiegeln die reine Regex-Validierung:

Die Grammatik ist kontextlastig. Ob " oder . zulässig ist, hängt von Position und Zitierzustand ab. Reguläre Ausdrücke sind bekanntermaßen schlecht bei verschachtelten, zustandsbehafteten Regeln — die vollständige RFC-5322-Grammatik als Regex umfasst Tausende Zeichen und ist unlesbar, unprüfbar und unpflegbar.
Gültig ≠ zustellbar. correct@format-but-fake-domain.xyz besteht jede Syntaxprüfung. Dass die Adresse wohlgeformt ist, sagt nichts darüber, ob ein Postfach existiert — und genau darum geht es Ihnen meist.
Standards driften. Internationalisierte Adressen, neue TLDs (.museum, .technology) und anbieterspezifische Eigenheiten lassen jedes fest kodierte Muster altern. In alte Regexes eingebackene TLD-Längenlimits ({2,4}) weisen seit über einem Jahrzehnt einwandfreie Adressen zurück.

Die ehrliche Einordnung: Ein Regex kann die Form prüfen, mehr nicht. Für eine schnelle Formprüfung — in einem Formularfeld, einer Log-Analyse, einem Datenbereinigungsskript — ist ein Validator wie der E-Mail-Validator genau das richtige Werkzeug. Verwechseln Sie nur „besteht die Formprüfung“ nicht mit „ist ein echtes Postfach“.

Die Strategie, die wirklich funktioniert: Schichten

Echte Systeme validieren E-Mail in drei von günstig bis teuer gestaffelten Schichten und stoppen, sobald eine scheitert:

Schicht 1 — Syntax (clientseitig, sofort). Eine bewusst großzügige Prüfung: Sieht es aus wie etwas@etwas.etwas? Das eingebaute <input type="email"> des Browsers oder ein kurzes Muster wie ^[^\s@]+@[^\s@]+\.[^\s@]+$ fängt Tippfehler — die 95 % der Fälle —, ohne exotische, aber echte Adressen abzulehnen. Widerstehen Sie dem Drang, es strenger zu machen. Ihr Ziel ist hier, Nutzern zu helfen, john@gmail,com zu korrigieren, nicht den RFC durchzusetzen.

Schicht 2 — Domain (serverseitig, Millisekunden). Prüfen Sie per DNS, ob die Domain MX- (oder A-)Einträge hat. Das tötet john@gmal.com und ganze Kategorien gefälschter Anmeldungen ohne jede Reibung für den Nutzer. Blocklisten für Wegwerf-Adressen können sich dieser Schicht anschließen, wenn Missbrauch ein Problem ist.

Schicht 3 — Postfach (die einzige maßgebliche Prüfung). Senden Sie eine Bestätigungs-E-Mail mit Link oder Code. Das ist die einzige Technik, die beweist, dass die Adresse existiert und vom Nutzer kontrolliert wird. Jeder ernsthafte Registrierungsablauf endet hier, weshalb Over-Engineering der Schichten 1 und 2 verschwendete Mühe ist — Schicht 3 ist ohnehin die Quelle der Wahrheit.

Praktische Faustregeln

Validieren Sie auf Tippfehler, nicht auf Konformität: großzügig bei der Form, strikt bei der Absicht.
Lehnen Sie niemals + im lokalen Teil ab. Plus-Adressierung ist legitim und bei Power-Usern beliebt; sie zu blockieren blockiert die Filter-Workflows Ihrer engagiertesten Nutzer.
Trimmen Sie Leerraum, schreiben Sie die Domain klein (Domains sind groß-/kleinschreibungsunabhängig), lassen Sie die Schreibweise des lokalen Teils aber unangetastet — technisch kann er groß-/kleinschreibungssensitiv sein.
Weisen Sie Wegwerf-Domains nur ab oder markieren sie, wenn Spam/Missbrauch Ihnen tatsächlich schadet; legitime Nutzer verwenden sie durchaus für Privatsphäre.
Bauen Sie beim Testen Ihrer Validierungslogik Ihre Testfälle aus den obigen Listen „seltsam-gültig“ und „normal-aussehend-ungültig“, nicht aus Ihrem Bauchgefühl. Der Regex-Tester ist praktisch, um das Muster der Schicht 1 gegen eine Reihe solcher Fälle zu iterieren, und die Regex-Referenz deckt die Syntax ab, falls das Muster erweitert werden muss.

Kurzreferenz

E-Mail = local-part@domain; lokal ≤ 64 Zeichen, gesamte Adresse ≤ 254.
Gültig-aber-seltsam: zitierte Zeichenketten, +tag, IP-Literal-Domains, internationalisierte Namen.
Regex prüft nur die Form — nie die Zustellbarkeit.
Der funktionierende Stapel: großzügige Syntaxprüfung → DNS/MX-Prüfung → Bestätigungs-E-Mail.
Die Bestätigungs-E-Mail ist der einzige Beweis für ein echtes, nutzerkontrolliertes Postfach.
Blockieren Sie kein +, erzwingen Sie keine TLD-Längenlimits, schreiben Sie den lokalen Teil nicht klein.