Warum die E-Mail-Validierung per Regex scheitert

Jede Codebasis hat einen: einen regulären Ausdruck, von Stack Overflow kopiert, der E-Mail-Adressen „validiert". Er fühlt sich wie eine Prüfung an, beantwortet aber eine Frage, die fast niemand tatsächlich stellt. Ein Regex kann Ihnen sagen, dass eine Zeichenfolge wie eine E-Mail-Adresse aussieht. Er kann Ihnen nicht sagen, ob die Adresse existiert, Mails annimmt oder Ihrer nächsten Kampagne keinen Hard-Bounce beschert — und nur das zählt.

Die kurze Antwort#

Regex validiert die Syntax, nicht die Zustellbarkeit. definitely-fake@gmail.com ist nach jedem jemals geschriebenen Regex eine völlig gültige E-Mail-Adresse, und sie erzeugt in dem Moment einen Bounce, in dem Sie an sie senden. Schlimmer noch: Die Regexe, zu denen die Leute greifen, weisen entweder echte Adressen zurück (zu streng) oder akzeptieren Unsinn (zu locker), und der eine, der technisch korrekt ist, ist Tausende von Zeichen lang und kann trotzdem kein Postfach bestätigen. Verwenden Sie eine einfache Syntaxprüfung, um Tippfehler direkt im Eingabefeld abzufangen, und prüfen Sie dann die Zustellbarkeit mit einer DNS- und SMTP-Prüfung — das ist ein Netzwerkproblem, kein Problem des Musterabgleichs.

Der Regex, den Sie kennen, und was er durchlässt#

Hier ist der Archetyp — irgendeine Variante davon lebt in den meisten Projekten:

const re = /^[^@\s]+@[^@\s]+\.[^@\s]+$/;
re.test("definitely-fake@gmail.com"); // true  ← will hard-bounce
re.test("typo@gmial.com");            // true  ← typo'd domain, bounces
re.test("info@company-that-folded.com"); // true  ← dead domain

Alle drei bestehen. Alle drei sind nicht zustellbar. Der Regex hat seine Aufgabe perfekt erledigt und Ihnen nichts Nützliches gesagt, denn Syntax und Zustellbarkeit sind verschiedene Fragen. Jede Adresse, die ein Regex sehen kann, ist eine Zeichenfolge; ob ein Mensch dort Mails liest, ist eine Tatsache über das Internet, nicht über die Zeichenfolge.

Das Kaninchenloch RFC 5322#

„Gut", lautet die Überlegung, „dann nehme ich eben einen korrekten Regex." Die formale Grammatik einer E-Mail-Adresse ist in RFC 5322 definiert, und ein Regex, der sie tatsächlich umsetzt, ist berüchtigt monströs — Tausende von Zeichen, und er erlaubt Dinge, die Sie niemals akzeptieren wollten, etwa in Anführungszeichen gesetzte lokale Teile mit Leerzeichen ("a b"@example.com) und Kommentare innerhalb der Adresse.

Daraus folgen zwei Probleme. Erstens akzeptiert der strenge Regex mehr, als Sie wollen, nicht weniger — er validiert gegen eine Spezifikation von 2008, nicht gegen „Adressen, an die echte Mailserver zustellen werden". Zweitens kann selbst ein tadelloser RFC-5322-Treffer Ihnen immer noch nicht sagen, ob die Domain einen Mailserver hat oder das Postfach existiert. Sie haben enormen Aufwand betrieben, um die einfache Frage mit mehr Präzision zu beantworten, während die schwierige Frage — wird die Mail ankommen? — vollkommen unberührt bleibt.

Die drei Dinge, die ein Regex grundsätzlich nicht kann#

Kein Muster, so clever es auch sei, reicht über das Netzwerk hinaus. Regex kann nicht:

• Prüfen, ob die Domain Mails empfangen kann. user@company-that-folded.com ist syntaktisch gültig auf einer Domain ohne MX-Einträge. Nur ein DNS-Lookup offenbart die tote Domain.
• Bestätigen, dass das Postfach existiert. noreply-9f2x@gmail.com ist syntaktisch gültig für ein Konto, das nie angelegt wurde. Nur ein SMTP-Dialog mit Gmail kann Ihnen sagen, dass es nicht existiert.
• Eine Catch-All-Domain erkennen. Ein Catch-All-Server akzeptiert jede Adresse, sodass selbst eine Live-SMTP-Prüfung ein bestimmtes Postfach nicht bestätigen kann — und ein Regex hat keine Ahnung, dass sich die Domain so verhält.

Das sind keine Lücken eines bestimmten Regex; sie liegen außerhalb dessen, was ein Regex überhaupt leisten kann, weil es Fragen über Server sind, nicht über Zeichenfolgen.

Was Sie tatsächlich tun sollten: in Schichten validieren#

Zustellbarkeit ist eine Pipeline aus zunehmend aufwendigen Prüfungen, und die Syntax ist nur die günstige erste Stufe (das vollständige Bild finden Sie unter wie E-Mail-Verifizierung funktioniert):

1. Syntax — eine einfache Prüfung am Eingabefeld, um offensichtliche Tippfehler abzufangen. Das ist die einzige Schicht, in die ein Regex gehört.
2. Domain und MX — ein DNS-Lookup, um überhaupt zu bestätigen, dass die Domain Mails empfangen kann. Werkfertigen Code finden Sie in den Leitfäden für Node.js und Python.
3. SMTP-Postfachprüfung — der Zustelldialog, der das Postfach tatsächlich bestätigt, plus Catch-All-Erkennung. Dafür braucht es einen Mailserver mit sauberer IP-Reputation und sorgfältige Ratenbegrenzung, weshalb die meisten Teams zu einer Verifizierungs-API greifen, statt es selbst zu bauen.

Die Syntaxprüfung, die es zu behalten lohnt#

Für Schicht 1 basteln Sie sich RFC 5322 nicht selbst zusammen. Der pragmatische Schritt ist das HTML5-E-Mail-Eingabefeld im Browser (das das Muster des WHATWG-Living-Standard kostenlos anwendet) und eine kurze, freizügige Prüfung auf dem Server:

// Pragmatic: rejects fat-finger errors, accepts the addresses real
// mail servers actually deliver to. Not a deliverability check.
const SYNTAX = /^[^\s@"]+(?:\.[^\s@"]+)*@[^\s@.]+(?:\.[^\s@.]+)+$/;

SYNTAX.test("jane@example.com"); // true
SYNTAX.test("not-an-email");     // false
SYNTAX.test("a@@b.com");         // false

Verwenden Sie sie, um am Eingabefeld sofortiges Feedback zu geben — mehr nicht. Behandeln Sie ein Bestehen als „lohnt eine ordentliche Prüfung", niemals als „gültig".

Den Rest des Weges gehen#

Sobald die Syntax besteht, ist die eigentliche Verifizierung eine Netzwerkaufgabe. Die DNS- und SMTP-Schichten können Sie selbst bauen — die Sprachleitfäden oben zeigen, wie weit Sie kommen —, aber das Bestätigen von Live-Postfächern in großem Maßstab stößt darauf, dass Port 25 auf den meisten Hosts blockiert ist, auf IP-Reputation und auf Greylisting, und genau hier verdient sich eine verwaltete API ihren Platz. Qualisends POST /verify durchläuft die gesamte Pipeline und liefert ein vierteiliges Urteil (deliverable | risky | undeliverable | unknown) mit einem Grund-Code, sodass Ihr Code danach handelt, ob das Postfach existiert, statt danach, ob die Zeichenfolge ein @ enthält.

Häufig gestellte Fragen#

Gibt es einen korrekten Regex für die E-Mail-Validierung?#

Nicht in dem Sinne, den sich die Leute wünschen. Es existiert ein Regex, der RFC 5322 umsetzt, aber er ist Tausende von Zeichen lang, akzeptiert exotische Formen, die Sie niemals haben wollten, und kann trotzdem nicht bestätigen, dass die Adresse zustellbar ist. Für den praktischen Einsatz ist ein kurzes, freizügiges Muster (oder das HTML5-Eingabefeld type="email") zum Abfangen von Tippfehlern genau das richtige Maß an Regex — der Rest ist ein DNS- und SMTP-Problem.

Warum weist mein Regex gültige E-Mail-Adressen zurück?#

Weil strenge Muster Annahmen codieren, die nicht stimmen — dass Top-Level-Domains 2–3 Buchstaben lang seien (sind sie nicht: .email, .io, .marketing), dass Pluszeichen oder Punkte im lokalen Teil nicht erlaubt seien (sind sie), oder dass es keine neuen gTLDs gebe. Ein zu strenger Regex ist eine häufige Ursache für verlorene Anmeldungen. Bleiben Sie bei der Syntax freizügig und prüfen Sie die Zustellbarkeit separat.

Prüft die HTML5-E-Mail-Validierung, ob die Adresse echt ist?#

Nein. Die type="email"-Validierung des Browsers ist eine Syntaxprüfung — eine freundlichere, standardisierte Variante desselben Musterabgleichs. Sie fängt fehlende @-Zeichen und offensichtliche Fehlformate direkt im Eingabefeld ab, kontaktiert aber niemals den Mailserver und kann Ihnen daher nicht sagen, ob die Domain oder das Postfach existiert.

Was sollte ich statt Regex zur Validierung von E-Mails verwenden?#

Bauen Sie es in Schichten auf: eine freizügige Syntaxprüfung für sofortiges Feedback, ein DNS-/MX-Lookup, um tote Domains auszuschließen, und eine SMTP-Postfachprüfung, um die Zustellung zu bestätigen. Die ersten beiden bauen Sie selbst; für die SMTP-Schicht nutzen Sie eine Verifizierungs-API, denn um das zuverlässig zu tun, braucht es Reputation der Sende-IP und eine Ratenbegrenzung, die ein Regex niemals bieten könnte.

Möchten Sie den Unterschied zwischen „gültige Syntax" und „wird tatsächlich zugestellt" sehen? Der kostenlose Tarif enthält 100 Verifizierungs-Credits, die die vollständige Pipeline durchlaufen — Syntax, DNS und die SMTP-Postfachprüfung —, sodass Sie zusehen können, wie eine per Regex freigegebene Adresse als undeliverable zurückkommt. Die API-Referenz enthält Copy-and-Paste-Beispiele in sieben Sprachen.