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, umfasst Hunderte bis Tausende von Zeichen 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.

Kein Muster kann eine vertippte Domain wie gmial.com erkennen; dafür braucht es einen Abgleich mit bekannten Anbietern. Siehe die häufigsten Tippfehler in E-Mail-Adressen, oder probieren Sie den kostenlosen E-Mail-Tippfehler-Checker.

Die Adressen, die strenge Regexe fälschlich ablehnen#

Strenge Muster scheitern in die andere Richtung. Dieses typische, „strengere" Muster lehnt jede gültige Adresse in der folgenden Tabelle ab:

const STRICT = /^[\w.-]+@\w+\.[a-z]{2,4}$/i;

Jede Ablehnung ist ein echter Mensch, der bei der Anmeldung abgewiesen wird, und keine davon taucht in Ihren Bounce-Logs auf. Deshalb überleben zu strenge Muster jahrelang. Die Syntaxprüfung weiter unten akzeptiert alle fünf.

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: Hunderte bis 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.

Längenbegrenzungen: 64, 255 und 254#

RFC 5321, der SMTP-Standard, begrenzt den lokalen Teil (vor dem @) auf 64 Oktette, die Domain auf 255 und den gesamten Pfad auf 256, einschließlich der spitzen Klammern um die Adresse (<jane@example.com>). Damit bleibt eine tatsächliche Obergrenze von 254 Zeichen für die Adresse selbst.

Einige unserer Sprachleitfäden prüfen stattdessen length <= 320 (64 + 1 + 255). Das ist großzügig, aber harmlos: Alles, was diese Prüfung ablehnt, ist tatsächlich zu lang, und jede Adresse über 254 Zeichen, die sie durchlässt, muss trotzdem die DNS- und SMTP-Prüfungen bestehen.

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. Sie zu beantworten ist Aufgabe der E-Mail-Verifizierung, die das Netzwerk befragt statt der Zeichenfolge.

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. Der Nachweis, dass die Adresse der Person gehört, ist eine eigene Aufgabe: die einer Double-Opt-in-Mail.

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@.]+)+$/;

function isPlausibleEmail(email) {
  return (
    email.length <= 254 &&      // RFC 5321 path limit
    email.indexOf("@") <= 64 && // local part limit
    SYNTAX.test(email)
  );
}

isPlausibleEmail("jane@example.com");             // true
isPlausibleEmail("jane+news@mail.example.co.uk"); // true
isPlausibleEmail("not-an-email");                 // false
isPlausibleEmail("a@@b.com");                     // false
isPlausibleEmail("a..b@x.com");                   // false: consecutive dots
isPlausibleEmail(".a@x.com");                     // false: leading dot
isPlausibleEmail("a.@x.com");                     // false: trailing dot

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".

Der Punkt fehlt in der Zeichenklasse des lokalen Teils, daher kann er nur zwischen Zeichen stehen. Das lehnt die drei Punktfehler ab, akzeptiert alle fünf Adressen aus der Tabelle zu strengen Regexen und hält das Muster schnell. Die Browserprüfung ist eine Bequemlichkeit, keine Schranke: Jeder kann direkt an Ihren Endpunkt senden, wiederholen Sie die Prüfung also auf dem Server.

ReDoS: wenn der E-Mail-Regex die Schwachstelle ist#

Ein ungünstig gebautes Muster kann auch Ihren Dienst lahmlegen. Die eingebauten Engines von JavaScript und Python arbeiten mit Backtracking: Scheitert ein Treffer, probieren sie jede andere Art aus, wie das Muster die Eingabe aufteilen könnte. Kann eine wiederholte Gruppe dieselben Zeichen erfassen wie der Teil davor, wächst die Zahl der Aufteilungen exponentiell.

Frühere Versionen dieser Seite empfahlen genau diese Form, [^\s@"]+(?:\.[^\s@"]+)*, bei der der Punkt sowohl in die Klasse als auch auf das Trennzeichen der Gruppe passt. Bei einer Zeichenfolge aus wiederholtem a. ohne @ verdoppelte jeder zusätzliche Punkt in unserem eigenen kurzen Test in Node ungefähr die Laufzeit, und eine Eingabe unter 60 Zeichen blockierte den Prozess sekundenlang. Das ist ReDoS (CWE-1333). Falls Sie das alte Muster übernommen haben, ersetzen Sie es durch das obige.

Drei Abhilfen:

• Nicht überlappende Klassen. Ohne den Punkt in den Klassen gibt es für jede Eingabe nur eine Lesart, daher läuft das obige Muster in linearer Zeit.
• Eine Engine mit linearer Laufzeit. Das Go-Paket regexp garantiert sie, und RE2-Bindings bringen sie nach Node und Python.
• Ein Parser statt eines Musters, etwa net/mail.ParseAddress aus Go. Halten Sie Go aktuell: Versionen vor 1.24.8 und 1.25.2 parsen sehr lange Domain-Literale langsam.

Eine Längenbegrenzung rettet Sie nicht: Diese Form hängt schon weit unter 254 Zeichen. Um den Fehler zu testen, messen Sie die Zeit für eine nicht passende Zeichenfolge wie "a.".repeat(25) + "!": Ein anfälliges Muster braucht einen spürbaren Bruchteil einer Sekunde, ein sicheres antwortet sofort.

Syntaxprüfungen nach Sprache#

Die meisten Stacks bringen eine Syntaxprüfung mit, daher brauchen Sie selten ein eigenes Muster. Jeder Leitfaden behandelt alle drei Schichten; diese Tabelle zeigt nur Schicht 1.

Die eingebauten Prüfungen sind sich in Grenzfällen uneinig, etwa bei Anzeigenamen (Jane <jane@example.com>); jeder Leitfaden behandelt die Eigenheiten seines Stacks.

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.

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. Ohne Konto fügen Sie typo@gmial.com in den kostenlosen E-Mail-Checker ein: Jeder Regex auf dieser Seite akzeptiert die Adresse, und der Checker schlägt gmail.com vor. Die API-Referenz enthält Copy-and-Paste-Beispiele in sieben Sprachen.