Nutze diese RFC-konforme Checkliste zur E-Mail-Syntax-Validierung, um Parsing-Randfälle wie zitierte Strings, Plus-Addressing und knifflige Subdomains vor dem Launch abzufangen.
Verwende wenn möglich einen dedizierten Parser. Regexes übersehen oft Randfälle wie zitierte lokale Teile, Plus-Tags und Domains mit mehreren Labels, sodass sie entweder echte Nutzer ablehnen oder kaputte Eingaben akzeptieren.
Syntax fragt: „Ist das als E-Mail-String korrekt formatiert?“ Policy fragt: „Wollen wir das in unserem Produkt zulassen?“ Halte beides getrennt, damit du nicht versehentlich gültige Adressen blockierst, während du riskante Anmeldungen reduzieren willst.
Nein. „RFC-konform“ bedeutet hauptsächlich, dass der String als E-Mail geparst werden kann. Es beweist nicht, dass die Domain existiert, MX-Einträge hat oder die Mailbox E-Mails empfangen kann.
Zuerst führst du Trim für führende und abschließende Leerzeichen durch, dann lehne Steuerzeichen wie Tabs und neue Zeilen ab. Normalisiere nicht, indem du interne Zeichen entfernst — das kann die vom Benutzer eingegebene Adresse verändern.
Erlaube sie standardmäßig. [email protected] ist ein normales, weit verbreitetes Format und das Blockieren schafft unnötige Reibung bei der Anmeldung, ohne allein die Sicherheit zu erhöhen.
Ja. Subdomains sind üblich, und Domains können mehrere Punkte enthalten wie sub.example.co.uk. Ein Validator, der „nur einen Punkt“ annimmt, wird viele echte Adressen ablehnen.
Erzwinge „genau ein @“, mit mindestens einem Zeichen auf jeder Seite. Teile nicht einfach am ersten @ und ignoriere den Rest, und akzeptiere keine Eingaben mit mehreren @-Zeichen unverändert.
Treffe die Entscheidung bewusst. Sie sind standardkonform, aber selten und können nachgelagerte Systeme stören, die ein einfacheres Format erwarten. Wenn du sie ablehnst, erkläre das als Policy-Entscheidung und gib eine klare Fehlermeldung.
Sie fangen missbräuchliche oder gefährliche Eingaben ab und reduzieren seltsame Randfälle. Gängige praktische Limits sind 254 Zeichen insgesamt, 64 für den lokalen Teil, 253 für die Domain und 63 pro Domain-Label.
Verwende Fehlercodes, die spezifische Fehler abbilden, z. B. CONTROL_CHAR, PARSE_FAIL, LENGTH oder DOMAIN_LABEL. Das macht Support-Tickets und Debugging deutlich einfacher als ein generisches „ungültig“.
E-Mail-Adressen sehen einfach aus, bis man versucht, sie zu validieren. Viele Produktionsfehler entstehen dadurch, dass eine E-Mail als „einfach Buchstaben, ein @ und ein Punkt“ behandelt und dann auf ein schnelles Regex vertraut wird. Reale Adressen erlauben mehr Variationen, als viele Formulare erwarten, und kleine Parsing-Entscheidungen können eine gültige Adresse in einen „ungültig“-Fehler verwandeln.
Eine häufige Verwechslung ist, zwei verschiedene Fragen durcheinanderzubringen:
Wenn du riskante Anmeldungen reduzieren willst, blockierst du vielleicht bestimmte Muster. Wenn dein Ziel ist, echte Nutzer nicht abzuweisen, musst du zuerst die Syntax korrekt prüfen und dann darüber deine Policy anwenden. Diese Trennung ist der Unterschied zwischen einem Validator, dem du vertrauen kannst, und einem, der leise Anmeldungen verliert.
Gültige E-Mails abzulehnen bricht reale Dinge. Jemand gibt eine völlig gültige Adresse mit Plus-Addressing oder einer Subdomain ein, dein Formular sagt „ungültig“ und die Person geht. Du verlierst die Anmeldung und hast nicht einmal genug Daten, um zu debuggen, was schiefging.
Ungültige E-Mails zu akzeptieren bricht andere Dinge. Ungültige Adressen erhöhen Bounces, was deine Sender-Reputation und Zustellbarkeit schädigen kann. Sie locken außerdem minderwertige Anmeldungen und Betrug an, wenn Angreifer Formulare mit Müll übersäen.
Die meisten Ausfälle in Produktion lassen sich auf einige Muster zurückführen: Regexes, die zu restriktiv (oder zu locker) sind, fehlerhaftes Splitten um @, über-aggressives Trimmen oder „Normalisieren“ und das Vermischen von Syntaxprüfungen mit Zustellbarkeitsprüfungen.
Beispiel: Jemand meldet sich mit [email protected] an. Ein vereinfachter Validator lehnt ab, weil er nur einen Punkt in der Domain erwartet. Die Adresse kann völlig in Ordnung sein, aber der Nutzer erreicht nie die Bestätigung.
Dieser Beitrag konzentriert sich auf die Syntax: ob eine Adresse in einem gültigen Format geschrieben ist. Er beweist nicht, dass das Postfach existiert oder die Domain Mails empfangen kann. Diese Prüfungen gehören in spätere Schichten.
„RFC-konform“ betrifft hauptsächlich die Syntax: Lässt sich dieser String nach den Regeln von RFC 5322 als E-Mail-Adresse parsen? Das ist nützlich, aber es ist nur das erste Tor. Eine syntaktisch gültige Adresse kann trotzdem nicht zustellbar, unsicher oder von geringer Qualität sein.
Denk an die Validierung in Schichten:
Eine praktische Pipeline sieht so aus: Syntax parsen, grundlegende Domain-Prüfungen, dann deine Policy anwenden (bekannte Einweg-Domains, Spam-Traps und andere Risikosignale blockieren). Syntax alleine sollte niemals so tun, als garantiere sie Zustellbarkeit.
Für Signup-Formulare bedeutet „RFC-konform“ meist, dass du gängige reale Formate akzeptierst (Plus-Tags, Subdomains, längere TLDs) und vermeidest, gültige Adressen abzulehnen, nur weil sie ungewohnt aussehen.
Einige Teams schärfen die Regeln bewusst. Das kann vernünftig sein, sollte aber eine bewusste Policy-Entscheidung sein, dokumentiert und getestet. Zum Beispiel könntest du weiterhin ablehnen:
@ oder fehlender lokaler Teil bzw. DomainSzenario: [email protected] kann syntaktisch gültig sein. Wenn die Domain keine MX-Einträge hat, fängst du das in der Domain-Schicht ab. Wenn es ein bekannter Einweg-Anbieter ist, ist das Policy.
Die meisten Validierungsfehler passieren, weil der Validator rät. Bevor du nach Regex greifst, halte die Struktur klar: ein lokaler Teil, genau ein @ und ein Domain-Teil.
@. Hier leben die kniffligen Fälle: Plus-Tags, Punkte und manchmal zitierte Strings.@. Er folgt den Regeln für Domain-Labels und kann internationalisiert sein.Diese Teile getrennt zu halten macht die Logik leichter nachvollziehbar und viel einfacher zu testen.
Reale Adressen können nicht-ASCII-Zeichen im lokalen Teil (EAI) und nicht-ASCII-Domains (IDN) enthalten. Entscheide vorher, was du unterstützt.
Wenn du nur ASCII akzeptierst, lehne nicht-ASCII früh mit einer klaren Meldung ab. Wenn du IDNs akzeptierst, validierst du die Domain meist intern in ihrer ASCII-kompatiblen Form (Punycode).
Längenlimits helfen, Randfälle zu vermeiden und deine Formulare vor Missbrauch zu schützen. Übliche Limits in der Praxis:
Führe vor dem Parsen eine Grundbereinigung durch: Trim führender und abschließender Whitespaces und lehne Adressen mit internen Leerzeichen ab, es sei denn, du unterstützt absichtlich zitierte lokale Teile. Lowercase den lokalen Teil nicht (er kann case-sensitiv sein), aber die Domain zu kleinschreiben ist in der Regel sicher.
Plus-Addressing ist, wenn jemand ein Tag nach einem Plus hinzufügt, z. B. [email protected]. Leute nutzen das, um Mails zu filtern und Anmeldungen nachzuverfolgen, daher schafft das Ablehnen unnötige Reibung.
Behandle + als normales Zeichen im lokalen Teil (außer in zitierten Strings). Auch wenn einige Provider das Tag bei der Zustellung ignorieren, ist es dennoch Teil der geschriebenen Adresse.
Viele Teams akzeptieren eine „sichere Untermenge“ im lokalen Teil (Buchstaben, Ziffern und ein paar Separatoren wie ., _, -, +). Das deckt die meisten realen Adressen ab und vereinfacht die Implementierung.
RFC-Regeln erlauben mehr Satzzeichen, aber die Ausweitung deiner akzeptierten Menge hilft nur, wenn du es korrekt machst und solide Tests dafür hast.
In der üblichen unzitierten Form sind Punkte im lokalen Teil erlaubt, aber nicht überall:
[email protected] ist ungültig[email protected] ist ungültigBaue kein provider-spezifisches Verhalten in die Syntax ein. Manche Provider behandeln firstlast und first.last als dasselbe Postfach, aber das ist keine Syntaxregel.
Ein paar schnelle Fälle, die du testen solltest:
[email protected] (Plus-Tag)[email protected] (Punkt)[email protected] (führender Punkt)[email protected] (doppelter Punkt)[email protected] (Plus-Tag mit Subdomain)Zitierte Strings existieren, weil die E-Mail-Regeln ältere Systeme und ungewöhnliche Mailbox-Namen abdecken mussten. Sie erscheinen im lokalen Teil, wenn die Adresse Zeichen benötigt, die sonst illegal oder mehrdeutig wären.
Ein zitierter lokaler Teil ist in doppelte Anführungszeichen eingeschlossen, zum Beispiel \"john smith\"@example.com. Innerhalb der Anführungszeichen sind Leerzeichen erlaubt. Wenn du ein wirkliches doppeltes Anführungszeichen oder einen Backslash innerhalb der Anführungszeichen benötigst, muss es mit einem Backslash escaped werden.
Das Verwirrende ist, dass die Regeln innerhalb der Anführungszeichen anders sind. Zwei aufeinanderfolgende Punkte sind normalerweise im unzitierten lokalen Teil ungültig, aber sie sind in einem zitierten String erlaubt. Das bedeutet, \"a..b\"@example.com kann gültig sein, obwohl [email protected] abgelehnt werden sollte.
Für Signups hast du eine echte Wahl:
Beides ist vertretbar. Was Bugs verursacht, ist, sie versehentlich mit einem Regex abzulehnen, auf den du dich nicht verlassen wolltest.
Testfälle, die syntaktisch gültig sind:
\"john smith\"@example.com\"a..b\"@example.com\"john\\\"smith\"@example.com\"back\\\\slash\"@example.com\"weird()[],:;\u003c\u003e@\"@example.comZitierte Strings betreffen nur den lokalen Teil. Die Domain musst du weiterhin separat validieren.
Viele Validatoren machen bei der Domain Fehler. Subdomains sind normal und häufig. [email protected] sollte deinen Parser nicht überraschen.
Ein einfacher Ansatz ist, die Domain als Labels zu validieren, die durch Punkte getrennt sind, und dann ein paar einfache Regeln anzuwenden.
Für die meisten Consumer-Signups funktionieren diese Regeln gut:
„Mindestens ein Punkt“ zu verlangen ist oft ein guter Tippfehlerfilter für öffentliche Adressen, kann aber eine Policy-Entscheidung sein, wenn du interne Domains unterstützt.
Die Platzierung von Punkten ist ein häufiger Fehlerort. Das sollte harte Ablehnungen sein:
[email protected][email protected], [email protected].[email protected][email protected], [email protected]a@sub_domain.exampleDie meisten „ungültige E-Mail“-Fehler kommen von Validatoren, die Annahmen treffen statt konsistente Regeln anzuwenden.
Whitespace ist ein großes Thema. Copy/Paste kann führende Spaces, abschließende Spaces, Tabs, geschützte Leerzeichen oder eine versteckte Newline hinzufügen. Wenn du validierst, bevor du trimmst, lehnst du eine gültige Adresse ab. Wenn du zu aggressiv normalisierst (z. B. alle Leerzeichen überall entfernst), kannst du die Bedeutung einer Adresse verändern.
Ein weiterer Stolperstein ist naives Splitten um @. Du brauchst eine klare Regel: genau ein @-Trenner, mit mindestens einem Zeichen auf jeder Seite. Akzeptiere nicht einfach Müll, indem du am ersten @ teilst und den Rest ignorierst, und stürze nicht ab oder erzeuge verwirrende Fehler, indem du an jedem @ teilst.
Einige Bibliotheken unterstützen auch teilweise RFC-Features wie Kommentare (z. B. john.smith(comment)@example.com). Teilweise Unterstützung kann schlimmer sein als konsequente Ablehnung, weil sie Unterschiede zwischen Frontend und Backend erzeugt.
Alarmzeichen, auf die du achten solltest:
@ teilen, ohne „genau eins“ durchzusetzenUnicode-Ähnlichkeiten sind knifflig. Selbst wenn du internationalisierte Adressen unterstützt, hilft es, verdächtige Fälle zu protokollieren und eine klare Fehlermeldung anzuzeigen, wenn etwas merkwürdig aussieht.
Ein vertrauenswürdiger Validator ist kein cleveres Einzelmuster. Es ist eine kleine Menge von Regeln, die in der richtigen Reihenfolge angewendet werden.
Trimme führende und abschließende Whitespaces und lehne Steuerzeichen (Tabs, Newlines, Null-Bytes) ab. Entscheide, wie du nicht-ASCII-Whitespaces und andere ungewöhnliche Unicode-Spaces behandelst. Sei explizit, ob du Nicht-ASCII unterstützt.
Ein reiner Regex-Ansatz lehnt oft gültige Adressen ab oder akzeptiert kaputte. Verwende einen Parser, der lokalen Teil und Domain unterscheidet und weiß, wie zitierte Strings zu handhaben sind, falls du sie unterstützen möchtest.
Halte Parsen getrennt von Policy. Parsen beantwortet „ist das syntaktisch gültig?“, Policy beantwortet „dürfen wir das in unserem Produkt zulassen?"
Nach dem Parsen wendest du harte Limits und grundlegende Domain-Sanity-Checks an (Längenlimits, keine leeren Labels, keine führenden oder abschließenden Bindestriche, Subdomains erlaubt, wenn korrekt formatiert). Das fängt Eingaben ab, die zwar technisch parsen, aber später Probleme verursachen würden.
Triff bewusste Entscheidungen zu Randfällen wie zitierten lokalen Teilen. Wenn du sie blockierst, schreibe es auf und zeige eine klare Meldung. Wenn du sie erlaubst, füge Tests für escapte Zeichen und Leerzeichen hinzu.
Am wichtigsten ist, dieselben Regeln auf Web, Mobile und Backend anzuwenden, damit Nutzer keine inkonsistenten Fehler sehen.
Wenn der Support fragt, warum eine E-Mail abgelehnt wurde, ist „ungültig“ nicht hilfreich. Protokolliere eine kleine Menge an Grundcodes (z. B. CONTROL_CHAR, PARSE_FAIL, LENGTH, DOMAIN_LABEL). Das macht Auffälligkeiten leichter diagnostizierbar und hilft, Probleme wie eine iOS-Tastatur zu finden, die eine versteckte Newline einfügt.
Ein Validator ist nur so gut wie die Tests, die sein Verhalten festlegen. Halte eine kleine „must pass“-Menge basierend auf realen Anmeldungen, eine „must fail“-Menge für universelle Ablehnungen und eine Randfall-Menge für Parserfallen.
Must pass Beispiele:
Must fail Beispiele:
plainaddress (fehlendes @)alex@ (fehlende Domain)@example.com (fehlender lokaler Teil)[email protected] (doppelter Punkt im lokalen Teil)Wenn du dich entscheidest, zitierte Strings zu unterstützen, füge explizite Tests wie \"john..doe\"@example.com und \"john\\\"doe\"@example.com hinzu. Wenn du sie nicht unterstützen willst, behalte die Tests trotzdem, markiere sie aber als Policy-Ablehnungen, damit die Entscheidung sichtbar bleibt.
Höre nicht bei Bestehen/Nicht-Bestehen auf. Speichere erwartete Grundcodes, damit Fehler handhabbar sind.
{ \"input\": \"[email protected]\", \"expected\": \"fail\", \"reason\": \"LOCALPART_DOT_SEQUENCE\" }
Führe dieselbe Suite überall aus, wo du validierst: Web, Mobile, Backend und jeden Drittanbieter-Auth-Flow. Dort treten die meisten Abweichungen auf.
Wenn du weniger Signup-Bugs und weniger „warum funktioniert diese E-Mail nicht?“-Tickets willst, halte deine Syntaxregeln kurz und konsistent. Eine praktische Mindestanforderung sieht so aus:
@, mit mindestens einem Zeichen auf jeder SeiteTriff früh eine „einmal entscheiden, dokumentieren“-Entscheidung: ob du zitierte lokale Teile wie \"john smith\"@example.com akzeptierst. Sie sind nach RFC 5322 gültig, aber selten bei Signups und werden oft von nachgelagerten Systemen falsch behandelt.
Nach der Syntax füge die Prüfungen hinzu, die Syntax nicht abdecken kann: verifiziere, dass die Domain existiert, prüfe MX-Einträge und filtere Einweg-E-Mail-Anbieter und bekannte Spam-Traps. Wenn du diese Schichten nicht selbst pflegen willst, ist Verimail (verimail.co) eine E-Mail-Validierungs-API, die Syntaxprüfungen zusammen mit Domain-Verifikation, MX-Lookup und Einweg- sowie Blocklistenabgleich ausführt, damit du deine Signup-Logik konsistent halten kannst, ohne alles in ein Regex zu packen.