RFC-konforme Checkliste zur E-Mail-Syntax-Validierung für Registrierungen

Warum E-Mail-Syntax-Validierung so viele Fehler verursacht

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:

• Was die Standards erlauben (Syntaxregeln)
• Was dein Produkt akzeptieren möchte (deine Policy)

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.

Was RFC-konform bedeutet (und was nicht)

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

Syntax vs Domain-Prüfungen vs Postfach-Existenz

Denk an die Validierung in Schichten:

• Syntax: Ist die Adresse korrekt formatiert (Zeichen, Trenner, Zitierregeln)?
• Domain: Kann die Domain E-Mails empfangen (DNS, MX-Einträge)?
• Postfach-Existenz: Existiert genau dieses Postfach? Das ist die schwierigste Schicht, weil viele Mailserver das nicht bestätigen.

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.

Was „RFC-konform" in der Praxis bedeutet

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:

• Fehlendes @ oder fehlender lokaler Teil bzw. Domain
• Steuerzeichen, unsichtbare Whitespaces oder eingefügte Newlines
• Domain-Labels, die mit einem Bindestrich beginnen oder enden
• Unicode, das du nicht durchgängig unterstützt
• Extrem lange Eingaben (setze ein Maximum, um Missbrauch zu verhindern)

Szenario: [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.

Kenne die Teile einer E-Mail-Adresse, bevor du validierst

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.

• Der lokale Teil ist alles vor @. Hier leben die kniffligen Fälle: Plus-Tags, Punkte und manchmal zitierte Strings.
• Der Domain-Teil ist alles nach @. 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.

ASCII vs internationalisierte Adressen (auf hohem Niveau)

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

Zu durchsetzende Längenlimits

Längenlimits helfen, Randfälle zu vermeiden und deine Formulare vor Missbrauch zu schützen. Übliche Limits in der Praxis:

• Gesamtlänge: 254 Zeichen
• Lokaler Teil: 64 Zeichen
• Domain-Teil: 253 Zeichen
• Jedes Domain-Label: 63 Zeichen

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 und Punkte: gängige Fälle, die unterstützt werden sollten

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.

Zeichen im lokalen Teil: sichere Untermenge vs vollständige Menge

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.

Punkte: was die Syntax erlaubt (und was Provider tun)

In der üblichen unzitierten Form sind Punkte im lokalen Teil erlaubt, aber nicht überall:

• Kein führender Punkt: [email protected] ist ungültig
• Kein abschließender Punkt
• Keine aufeinanderfolgenden Punkte: [email protected] ist ungültig

Baue 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: der Randfall, den die meisten Parser übersehen

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:

• Unterstütze zitierte Strings vollständig (und teste sie gründlich), oder
• Lehne sie bewusst ab, weil sie selten sind und nachgelagerte Systeme stören können

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

Zitierte Strings betreffen nur den lokalen Teil. Die Domain musst du weiterhin separat validieren.

Domains und Subdomains: was erlaubt werden sollte und was zu blockieren ist

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.

Was zu erlauben ist (und warum)

Für die meisten Consumer-Signups funktionieren diese Regeln gut:

• Mehrere Labels (Subdomains) sind in Ordnung.
• Labels können Buchstaben und Ziffern enthalten und dürfen Bindestriche innen verwenden (nicht am Rand).
• Labels sind 1 bis 63 Zeichen lang, und die gesamte Domain ist nicht absurd lang (viele Systeme begrenzen auf 253).

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

Was zu blockieren ist (häufige „sieht gut aus“-Fehler)

Die Platzierung von Punkten ist ein häufiger Fehlerort. Das sollte harte Ablehnungen sein:

• Aufeinanderfolgende Punkte: [email protected]
• Führender oder abschließender Punkt: [email protected], [email protected].
• Leere Labels durch falsches Splitten: [email protected]
• Label beginnt oder endet mit Bindestrich: [email protected], [email protected]
• Ungültige Zeichen in einem Label (Unterstriche sind ein häufiger Fehler): a@sub_domain.example

Häufige Parsing-Fehler, die falsche Ablehnungen erzeugen

Die 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:

• Nur ASCII-Spaces trimmen, aber nicht Tabs, geschützte Leerzeichen oder abschließende Newlines
• Am @ teilen, ohne „genau eins“ durchzusetzen
• Mit einem permissiven Regex akzeptieren, dann später mit einer vagen Fehlermeldung scheitern
• Unterschiedliche Resultate zwischen Umgebungen (Web vs Mobile vs Backend)
• Unicode-Ähnlichkeiten ignorieren (z. B. ein kyrillisches „а“, das wie das lateinische „a“ aussieht)

Unicode-Ä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.

Schritt-für-Schritt: Baue einen Syntax-Validator, dem du vertrauen kannst

Ein vertrauenswürdiger Validator ist kein cleveres Einzelmuster. Es ist eine kleine Menge von Regeln, die in der richtigen Reihenfolge angewendet werden.

1) Bereinige die Eingabe

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.

2) Parse mit einem RFC-bewussten Parser (nicht nur mit Regex)

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

3) Durchsetze Limits und Domain-Label-Regeln

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.

4) Wähle deine Striktheits-Policy und dokumentiere sie

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.

5) Protokolliere Fehler mit Grundcodes

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.

Testfälle, die du in deine Validierungs-Suite aufnehmen solltest

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:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

Must fail Beispiele:

• `` (leerer String)
• 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.

Kurze Checkliste und nächste Schritte

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:

• Genau ein @, mit mindestens einem Zeichen auf jeder Seite
• Keine Spaces oder Steuerzeichen (es sei denn, du unterstützt bewusst zitierte lokale Teile)
• Längen innerhalb üblicher Limits (lokaler Teil bis 64, gesamte Adresse bis 254)
• Domain ist wohlgeformt (keine aufeinanderfolgenden Punkte, keine leeren Labels, kein führender oder abschließender Bindestrich in einem Label)
• Plus-Tags und Subdomains werden standardmäßig erlaubt

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