Internationalisierte E‑Mail‑Adressen können bei der Anmeldung wegen IDNs, Unicode‑Normalisierung und Lücken in SMTPUTF8 fehlschlagen. Lernen Sie sichere Validierungsschritte kennen.
Eine Regex kann nur die Form des Texts beurteilen, nicht aber, ob die Domain Mail empfangen kann oder ob Ihr Mail‑Stack an dem Ziel zustellbar ist. Regexes sind außerdem oft entweder zu streng und blockieren gültige internationalisierte Domains, oder zu locker und akzeptieren Eingaben, die später bouncen oder fehlschlagen.
Wenn Sie ein globales Publikum haben, ist es in der Regel unproblematisch, Unicode in der Domain‑Part zuzulassen, weil diese für DNS‑Prüfungen in eine ASCII‑Form konvertiert werden kann. Unicode im Local‑Part ist dagegen eine größere Entscheidung: Sie müssen sicherstellen, dass Ihr kompletter Auslieferungsweg SMTPUTF8 unterstützt, sonst riskieren Sie Anmeldungen, die keine Verifizierungs‑ oder Zurücksetz‑Mails empfangen können.
Behalten Sie die vom Nutzer eingegebene Form zur Anzeige bei, konvertieren Sie die Domain aber vor DNS‑ oder MX‑Prüfungen in ihre ASCII‑Form. Das Speichern der ASCII‑Form neben dem Original hilft beim Dedupe und verhindert Inkonsistenzen zwischen Bibliotheken, die IDNs unterschiedlich handhaben.
Normalisieren Sie frühzeitig, idealerweise bevor Sie validieren, vergleichen oder auf Einzigartigkeit prüfen, damit sich visuell identische Eingaben nicht zu unterschiedlichen Konten entwickeln. NFC ist ein praktikabler Standard, weil es „gleich‑aussehende“ Bytes‑Ungleichheiten reduziert, ohne so aggressiv Zeichen umzuwandeln wie Kompatibilitäts‑Normalisierung.
Lowercasen Sie die Domain, denn Domains werden praktisch immer case‑insensitiv behandelt und das verhindert Duplikate. Vermeiden Sie es, den Local‑Part standardmäßig zu lowercasen, denn das kann die Bedeutung ändern auf Systemen, die zwischen Groß‑ und Kleinschreibung unterscheiden, und bei nicht‑ASCII‑Zeichen Überraschungen erzeugen.
Speichern Sie sowohl die originale Eingabe als auch eine kanonische Form, die Sie für Vergleiche, Suche und Unique‑Constraints verwenden. Die kanonische Form wird typischerweise von umgebender Leerzeichen befreit, auf NFC normalisiert und die Domain wird kleingeschrieben und bei Bedarf in ASCII konvertiert, während die Anzeigeform benutzerfreundlich bleibt.
Machen Sie zuerst eine Syntaxprüfung, dann verifizieren Sie, ob die Domain auflösbar ist, und prüfen Sie MX‑Records mit der ASCII‑Version der Domain. Das fängt Tippfehler und tote Domains früh ab, beweist aber nicht, dass ein spezifischer Posteingang existiert — dafür brauchen Sie eine Eigentumsbestätigung per Verifizierungs‑E‑Mail.
Weil der Auslieferungsweg die Adresse ablehnen kann, nicht weil Ihre App sie akzeptiert hat. Ein häufiger Grund ist fehlende SMTPUTF8‑Unterstützung irgendwo zwischen Ihrer App, dem E‑Mail‑Provider und nachgelagerten Relays, wodurch Zustellungen an Unicode‑Local‑Parts fehlschlagen können, obwohl die Adresse formal zulässig ist.
Trimmen Sie offensichtliche umgebende Leerzeichen, seien Sie aber vorsichtig mit „Bereinigungen“, die unsichtbare Zeichen entfernen, da einige davon in Unicode Bedeutung haben können. Zusätzlich hilft es, auf versteckte Zeichen wie Zero‑Width‑Spaces zu prüfen und den Nutzer zu warnen oder die Eingabe zur Korrektur zurückzugeben, statt ihn still zu blockieren.
Nutzen Sie es, um fragile, inkonsistente Validierungslogik durch einen konsistenten API‑Aufruf zu ersetzen, der die Syntax RFC‑konform prüft, die Domain verifiziert, MX‑Records nachsieht und riskante Eingaben wie Wegwerf‑Provider markiert. Es ist besonders nützlich, wenn Sie schnelle, einheitliche Entscheidungen bei der Anmeldung wollen, ohne eine eigene mehrstufige Pipeline zu bauen und zu warten.
Eine E‑Mail‑Adresse kann normal aussehen und dennoch versagen, sobald sie ein echtes System erreicht. Der Hauptgrund ist, dass das, was Menschen als ein Zeichen sehen, als unterschiedliche Bytes gespeichert, von Bibliotheken verschieden behandelt oder von älteren Mail‑Servern abgelehnt werden kann.
Ein häufiges Beispiel ist søren@exämple.com. Das kann eine legitime Adresse sein, berührt aber mehrere heikle Punkte auf einmal: Unicode im Local‑Part, eine internationalisierte Domain und eine Mail‑Infrastruktur, die das eventuell nicht unterstützt.
Fehler zeigen sich oft weit entfernt vom Anmeldeformular. Sie akzeptieren die Adresse, senden dann aber kein Passwort‑Reset, weil Ihr E‑Mail‑Provider (oder ein Relay dazwischen) SMTPUTF8 nicht unterstützt. Oder Ihr Regex akzeptiert die Adresse, aber ein Schritt „lowercase und trim“ verwandelt sie in etwas anderes als das, was der Nutzer beabsichtigte.
Falsche Ablehnungen sind teuer, weil sie meist still passieren. Nutzer brechen Anmeldungen ab, probieren eine andere E‑Mail, oder eröffnen Support‑Tickets, die schwer nachzuvollziehen sind. Bei globaler Zielgruppe kann das Ablehnen internationalisierter E‑Mail‑Adressen außerdem so wirken, als unterstützten Sie ihre Sprache nicht.
Falsche Akzeptanzen kosten auf andere Weise: schlechte Adressen führen zu Bounces, niedrigerer Zustellbarkeit und unordentlichen Listen. Manche gültig aussehenden Eingaben sind absichtlich schädlich: Wegwerfdomains, Rollen‑Accounts für Missbrauch oder Spam‑Traps, die die Sender‑Reputation schädigen.
Das Ziel ist nicht „alles akzeptieren“ oder „alles blockieren“. Es geht darum, echte Nutzer zuzulassen und gleichzeitig offensichtlich schlechte Eingaben zu stoppen — mit Prüfungen, die zu dem passen, wie E‑Mail tatsächlich funktioniert: Anzeige von Speicherung trennen, Erreichbarkeit der Domain verifizieren (nicht nur das @) und aggressive Transformationen vermeiden, die stillschweigend das verändern, was der Nutzer eingegeben hat.
Eine E‑Mail‑Adresse hat zwei Teile, getrennt durch @: den Local‑Part (vor @) und die Domain (nach @). Internationalisierte E‑Mail‑Adressen können in beiden Teilen Unicode‑Zeichen enthalten, und die reale Unterstützung variiert je nachdem, welche Seite Unicode verwendet.
Der gebräuchlichste Fall sind internationalisierte Domain‑Namen (IDN). Der Nutzer sieht eine Domain in seiner Schrift, wie maria@bücher.example oder li@例子.公司. Unter der Haube konvertieren viele Systeme diese Domain in eine ASCII‑Form (oft Punycode), damit DNS‑Abfragen und MX‑Checks zuverlässig funktionieren.
Der kompliziertere Fall ist Unicode im Local‑Part, wie jó[email protected] oder ユーザー@domain.com. Das fällt unter Email Address Internationalization (EAI) und wird typischerweise über SMTPUTF8 zugestellt. Auch wenn die Adresse nach modernen Standards gültig ist, lehnen manche Mail‑Server, ältere Bibliotheken und nachgelagerte Tools sie weiterhin ab. Das heißt: Sie können sie bei der Anmeldung akzeptieren und später beim Versand scheitern.
Praktisch lässt sich die Unterstützung heute so einordnen:
Deshalb reicht ein einfaches Ja/Nein‑Regex nicht aus. Ein Regex kann legitime Nutzer ablehnen (z. B. indem er Nicht‑ASCII komplett blockiert) oder Adressen akzeptieren, die Sie praktisch nicht zustellen können.
Bessere Validierung behandelt beide Seiten getrennt. Für die Domain: normalisieren und zur ASCII‑Form für DNS‑Prüfungen konvertieren. Für den Local‑Part brauchen Sie eine Policy‑Entscheidung: unterstützen Sie SMTPUTF8 vollständig, erlauben Sie es mit Warnung, oder blocken Sie es, weil Ihr E‑Mail‑Stack es nicht zuverlässig zustellen kann?
Ein IDN (Internationalized Domain Name) ist eine Domain mit nicht‑ASCII‑Zeichen, etwa Akzente oder nicht‑lateinische Schriften. Nutzer sehen und tippen die Unicode‑Form, aber DNS ist auf ASCII ausgelegt. Diese Diskrepanz ist der Ort, an dem viele Produktionsfehler beginnen.
Um MX‑Records nachzusehen, eine Domain zu verifizieren oder auch nur eine einfache DNS‑Prüfung durchzuführen, brauchen Sie meist die ASCII‑Form der Domain. Diese Konversion erfolgt nach IDNA‑Regeln und erzeugt Punycode, der oft mit xn-- beginnt. Ein Nutzer könnte also eine Domain eingeben, die für ihn normal aussieht, während Ihre Logs, Datenbank oder ein Upstream‑Provider eine xn--...‑Version zeigen.
Punycode taucht an Stellen auf, die Sie erwarten und handhaben sollten:
Zwei häufige Fehler:
Es gibt auch eine Sicherheitsseite: Gemischte Schriftsysteme und ähnlich aussehende Zeichen können Domains erzeugen, die einer vertrauenswürdigen Marke visuell ähneln. Sie sollten nicht alle IDNs blocken, aber es ist vernünftig, sie in sensiblen Kontexten wie Zahlungen, Passwort‑Resets oder Admin‑Zugängen als höheres Risiko zu behandeln.
Ein praktischer Ansatz ist, die Eingabe des Nutzers zu akzeptieren und intern zu normalisieren:
Unicode macht es möglich, Namen und Wörter vieler Sprachen zu tippen, bedeutet aber auch, dass derselbe Buchstabe auf mehr als eine Weise kodiert werden kann. Vergleichen Sie Zeichen anhand roher Bytes oder speichern Sie eine Form und erhalten später eine andere, können Duplikate, fehlgeschlagene Logins und verwirrende „E‑Mail bereits in Gebrauch“‑Fehler entstehen.
Ein einfaches Beispiel sind Akzentbuchstaben. Der Buchstabe „é“ kann ein einzelner Codepunkt (U+00E9) sein oder aus zwei Codepunkten bestehen: „e“ (U+0065) plus ein kombinierender Akzent (U+0301). Für Menschen sehen sie identisch aus, aber Ihre Datenbank behandelt sie möglicherweise als unterschiedlich.
Normalisierung wandelt Text in eine konsistente Form um.
Für E‑Mail‑Verarbeitung ist NFC oft die sicherste Voreinstellung für „gleich machen“‑Vergleiche.
Die Regeln unterscheiden sich zwischen den beiden Seiten einer Adresse:
@): kann als case‑insensitiv behandelt werden. Lowercasen ist hier Standard.@): ist technisch gesehen case‑sensitiv, auch wenn viele Provider Groß‑/Kleinschreibung ignorieren. Ihn zu lowercasen kann auf einigen Systemen zwei unterschiedliche Adressen zusammenführen.Ein praxisorientierter Ansatz: lowercasen und normalisieren Sie die Domain; behalten Sie den Local‑Part so, wie der Nutzer ihn eingegeben hat, speichern Sie aber zusätzlich eine kanonische Form für Vergleiche.
Normalisieren Sie dort, wo Konsistenz zählt:
Selbst mit einem guten Validierungsdienst braucht Ihre App eine klare Normalisierungs‑ und Case‑Policy, damit legitime Nutzer nicht durch unsichtbare Zeichenunterschiede blockiert werden.
Die meisten Fehler bei internationalisierten E‑Mail‑Adressen treten an den Schnittstellen auf, wo ein System eine andere Annahme trifft als das nächste. Die Adresse sieht für den Nutzer in Ordnung aus, aber irgendetwas in der Kette ändert sie, lehnt sie ab oder behandelt zwei gleich aussehende Werte unterschiedlich.
Ein häufiger Fehler beginnt im Anmeldeformular. Frontend‑Regeln erlauben oft nur A‑Z, 0‑9 und ein paar Symbole. Mobile Tastaturen fügen „smarte“ Satzzeichen ein, und Autofill ergänzt ein unsichtbares Leerzeichen. Auto‑Lowercasing verhält sich außerhalb von ASCII ebenfalls eigenartig.
Auf dem Backend können kleine Bereinigungs‑Schritte zerstörerisch sein. Trimmen ist gut, aber das Entfernen „nicht druckbarer“ Zeichen kann gültige Unicode‑Marks löschen. Längenbegrenzungen sind ein weiteres stilles Problem: Internationalisierte Domains können bei der Umwandlung in Punycode länger werden und Limits erreichen, mit denen Sie nicht gerechnet haben.
Datenbanken bringen ihre eigenen Fallen mit. Kollation und Vergleichsregeln entscheiden, ob zwei Strings gleich sind. Wenn ein System eine komponierte Form speichert und ein anderes später eine dekomponierte Form sendet, können Unique‑Checks fehlschlagen. Das erzeugt doppelte Konten oder blockiert einen Nutzer, weil die Abfrage „bereits existiert“ nicht mit dem gespeicherten Wert übereinstimmt.
Probleme tauchen am häufigsten auf in:
Ausgehende Mails machen das Problem unausweichlich. Wenn Ihr Mail‑Server oder ein nachgelagerter Relay SMTPUTF8 nicht unterstützt, kann er sich weigern, an eine Mailbox mit Nicht‑ASCII‑Local‑Part zu senden. Nutzer können sich anmelden, aber nie eine Bestätigungs‑E‑Mail erhalten.
Eine realistische Fehlerkette sieht so aus: Ein Nutzer registriert sich mit einer Unicode‑Domain, Ihre App speichert sie, Ihr CRM normalisiert anders, und Ihr E‑Mail‑Provider lehnt SMTPUTF8 ab. Jetzt haben Sie einen Nutzer, zwei nicht übereinstimmende Strings und eine Willkommens‑Mail, die nie ankommt.
Ein sicherer Workflow trennt zwei Ziele: blockieren Sie keine echten Nutzer bei der Anmeldung und speichern Sie etwas, das Sie später vergleichen, senden und supporten können.
Bewahren Sie die Eingabe des Nutzers. Speichern Sie die Adresse genau so, wie sie eingegeben wurde, und entfernen Sie nur offensichtliche umgebende Leerzeichen. Vermeiden Sie „hilfreiche“ Änderungen wie Case‑Änderungen, Entfernen von Akzenten, Löschen von Punkten oder Entfernen von Plus‑Tags. Solche Änderungen können stillschweigend eine Adresse in eine andere verwandeln.
Führen Sie eine echte Syntaxprüfung durch. Fragen Sie „ist das strukturell möglich?“ und nicht „wird Mail definitiv funktionieren?“. Moderne Regeln sind weiter als die meisten Regexes, vor allem bei internationalen Zeichen.
Treffen Sie eine Entscheidung zu Normalisierung und Einzigartigkeit. Speichern Sie die rohe Adresse plus eine kanonische Form (oft NFC) für Gleichheitsprüfungen. Wenn E‑Mail ein eindeutiger Schlüssel in Ihrem System ist, legen Sie fest, ob visuell identische, aber unterschiedlich codierte Eingaben als derselbe Account zählen sollen.
Behandeln Sie die Domain korrekt. Normalisieren Sie die Domain und konvertieren Sie sie vor DNS‑Prüfungen in ASCII (Punycode). Prüfen Sie dann die Domain und suchen Sie nach MX‑Records (und ggf. Fallback auf A/AAAA, wenn Ihre Policy das vorsieht).
Legen Sie eine Policy für Unicode‑Local‑Parts fest. Wenn Ihr Outbound‑Provider SMTPUTF8 nicht zuverlässig zustellen kann, akzeptieren Sie die Anmeldung nur, wenn Sie einen Plan B haben (In‑App‑Verifikation, alternative Kontaktmethode oder eine klare Warnung, bevor Sie Zustellung versprechen).
Behalten Sie ein kleines Set von Logs zu Validierungsergebnissen, damit der Support Randfälle ohne Ratespiele debuggen kann.
Oft sagen Leute „E‑Mail‑Validierung“, wenn sie „wird meine Nachricht eine reale Person erreichen“ meinen. Das ist Zustellbarkeit, und die können Sie bei der Anmeldung nicht vollständig beweisen. Bei internationalisierten E‑Mail‑Adressen lässt sich „sieht gültig aus“ und „funktioniert überall“ noch leichter verwechseln.
Validierung kann trotzdem starke Signale liefern, bevor Sie eine Adresse speichern oder an sie senden:
Aber Validierung kann nicht garantieren, dass ein Postfach existiert oder Ihre Nachricht akzeptiert. Viele Provider blockieren Mailbox‑Probes, nehmen Mail für unbekannte Nutzer an und bouncen später oder ändern Richtlinien ohne Ankündigung.
Ein sichererer Weg ist zweistufig:
Bei „hochrisikigen“ Ergebnissen erzeugen harte Blockaden oft falsche Negative. Sanfte Reibung funktioniert meist besser: Zulassen der Anmeldung, Bestätigung vor wichtigen Aktionen verlangen, oder ein zusätzliches Signal nur bei hohem Risiko anfordern.
Der schnellste Weg, echte Anmeldungen zu verlieren, ist alles außerhalb von einfachem ASCII als ungültig zu behandeln. Viele legitime Provider unterstützen internationalisierte Domains, und manche Nutzer sind auf sie angewiesen.
Viel Produktcode geht noch davon aus, dass E‑Mail A‑Z, 0‑9, Punkte und eine kurze Liste von Symbolen bedeutet. Das bricht bei IDN‑Domains und garantiert falsche Ablehnungen in globalen Produkten.
Das Lowercasen der Domain ist in Ordnung. Das Lowercasen des Local‑Parts ist riskant.
Normalisieren hilft, aber unüberlegtes Anwenden kann Nutzer überraschen. Normalisieren Sie gezielt, bewahren Sie die Original‑Eingabe und testen Sie, wie sich Downstream‑Systeme verhalten.
Gängige „hilfreiche“ Transformationen, die nach hinten losgehen:
Ihr Backend braucht eventuell Punycode für DNS‑Prüfungen, aber die UI sollte die Domain meist in der Nutzerschrift anzeigen. xn--... in Bestätigungen oder Fehlermeldungen zu zeigen wirkt oft verdächtig, selbst wenn die Adresse korrekt ist.
Nur weil eine Adresse nach Spezifikation gültig ist, heißt das nicht, dass jeder Mail‑Server SMTPUTF8 unterstützt. Wenn Sie Unicode‑Local‑Parts akzeptieren, müssen Sie bereit sein, mit Zustellbarkeitsunterschieden zu leben.
Copy‑Paste fügt Non‑Breaking Spaces, Zero‑Width‑Chars und ungewollte Leerzeichen um @ herum ein. Nutzer sehen diese Probleme nicht, Ihre Validierung schon.
Beispiel: Ein Nutzer fügt name@пример.рф mit einem nachgestellten Leerzeichen ein. Wenn Sie validieren, bevor Sie trimmen, lehnen Sie ab. Wenn Sie überdesinfizieren, könnten Sie den Local‑Part verändern.
Internationalisierte E‑Mails können Ende‑zu‑Ende funktionieren, aber nur, wenn jede Schicht sich einig ist, was sie akzeptiert, speichert und sendet. Führen Sie vor dem Release Prüfungen durch, die das Produktionsverhalten abbilden, nicht nur Unit‑Tests.
Stellen Sie sicher, dass Logs und Admin‑Tools die nutzerfreundliche Version anzeigen, ohne Mojibake zu erzeugen oder Exporte zu zerstören. Bestätigen Sie außerdem, dass jedes System, das die Adresse berührt, damit umgehen kann: Analytics‑Events, CRM‑Sync, Webhook‑Payloads, CSV‑Exporte und Data‑Warehouse‑Ingestion. Viele Fehler passieren beim Export, nicht bei der Eingabe.
Ein konkreter Test: Führen Sie dieselbe Adresse durch Anmeldung, Login, Passwort‑Reset und Merge‑Flows. Wenn sie die Anmeldung besteht, aber später fehlschlägt, haben Sie eine Diskrepanz in Normalisierung, Speicherung oder Vergleichen.
Ein Nutzer meldet sich mit marta@bücher.example an. Es sieht normal aus, weil die Domain in Unicode geschrieben ist. Ihr System muss die Domain als IDN behandeln.
Auf der Domain‑Seite: Zeigen Sie die nutzerfreundliche Darstellung, validieren Sie aber die DNS‑sichere Form. Konvertieren Sie bücher.example in Punycode (xn--bcher-kva.example) bevor Sie MX‑Abfragen durchführen. Wenn Sie nur die Unicode‑Form prüfen, können manche DNS‑Bibliotheken fehlschlagen oder sich inkonsistent verhalten.
Jetzt der subtile Teil: Dieselbe E‑Mail kann auf mehrere Weisen eingegeben werden, die identisch aussehen. Angenommen, der Nutzer gibt márta@bücher.example ein — das „á“ kann als ein Zeichen oder als „a“ plus kombinierenden Akzent getippt werden. Wenn Sie nur Roh‑Eingaben speichern, kann derselbe Nutzer in Ihrer UI zwei Konten haben, die gleich aussehen.
Normalisierung behebt das. Normalisieren Sie auf NFC, bevor Sie vergleichen, speichern, ratenlimiten oder dedupen, und wenden Sie dieselben Schritte überall an, wo die Adresse berührt wird.
Der Local‑Part (alles vor @) ist der Bereich, in dem Sie eine klare Policy brauchen. SMTPUTF8 erlaubt Unicode‑Local‑Parts, aber nicht jeder Provider unterstützt das Ende‑zu‑Ende. Eine praktikable Policy für viele Produkte ist:
Wenn Sie eine einzelne Stelle für Syntaxprüfungen plus Domain‑ und MX‑Verifikation suchen (und Wegwerfprovider filtern möchten), kann eine E‑Mail‑Validierungs‑API wie Verimail diese Signale liefern, ohne dass Sie sich auf ein brüchiges Regex verlassen müssen.
Nächste Schritte, mit denen Sie sicher bleiben, ohne echte Nutzer abzulehnen: