Behandle Plus-Adressierung bei Anmeldungen korrekt: sichere Normalisierung für Dedupe, Speicherrichtlinien und Validierungsprüfungen, ohne echte Nutzer auszuschließen.
Ja. Viele echte Nutzer verwenden Plus-Adressierung wie [email protected], und viele Mailprovider liefern sie in dasselbe Postfach wie [email protected]. Behandle das als normale Formatwahl, nicht als Warnsignal.
Nutzer verwenden Tags, um E-Mails in Ordner zu filtern, nachzuverfolgen, wo eine Adresse verwendet wurde, und verschiedene Anmeldungen zu trennen. Das Blockieren von + lehnt oft sorgfältige, legitime Kunden ab.
Die sicherste Standardregel ist, die E-Mail genau so zu speichern und an diese genaue Zeichenkette zu senden, wie sie der Nutzer eingegeben hat. Änderungen können Inbox-Regeln zerstören, Nutzer verwirren und später Support-Probleme verursachen.
Dedupe nicht, indem du +tag im Haupt-E-Mail-Feld entfernst. Wenn du Duplikate erkennen musst, erstelle einen separaten internen Vergleichs-„Key“ und behalte die ursprüngliche Adresse unverändert für Versand und Anzeige.
Verlange als primären Login-Bezeichner die exakt beim Signup verwendete E-Mail. Wenn jemand eine andere Variation eingibt, die nur über einen normalisierten Key passt, fordere eine Eigentumsbestätigung an, statt sie stillschweigend einzuloggen.
Normalisiere konservativ: Kürze umgebende Leerzeichen, lehne Steuerzeichen ab und lagere die Domain kleingeschrieben. Lokale-Teil-Regeln wie das Entfernen von +tag solltest du nur für Domains anwenden, die du explizit auf einer Allowlist hast und deren Verhalten du kennst. Halte diese Logik im separaten Dedupe-Key.
Eine zu strenge Pattern stimmt oft nicht mit der Realität überein. Ein selbstgebautes Regex, das nur Buchstaben, Zahlen und Punkte vor dem @ erlaubt, ist eine häufige Ursache. Nutze RFC-konforme Syntaxprüfungen und vermeide hausgemachte Regex-Regeln, die + als ungültig behandeln.
Nein, das hängt von der Konfiguration der empfangenden Domain ab, nicht nur vom Provider-Namen. Gehe davon aus, dass es funktionieren kann, prüfe Zustellsignale und vermeide harte Regeln wie „+ funktioniert immer“ oder „+ funktioniert nie“.
Ein +tag ist meist ein Signal für ein normales Postfach, kann aber verwendet werden, um viele „einzigartig aussehende“ Adressen für dasselbe Postfach zu erzeugen. Geh dieses Problem mit Produktregeln und Verhaltenschecks (Verifizierung, Rate-Limits, Risiko-Scoring) an, nicht durch ein Verbot von +.
Validiere auf Erreichbarkeit und Risiko: Syntax, Domain-Checks, MX-Einträge und Disposable-Erkennung, und akzeptiere dennoch getaggte Adressen. Bewahre Validierungsergebnisse (Status, Grund, Zeitstempel) getrennt von der gespeicherten E-Mail auf, damit du nicht die vom Nutzer eingegebene Zeichenkette überschreibst.
Viele echte Nutzer verwenden E-Mails wie [email protected]. Der +tag-Teil ist ein Tag (auch Subaddress genannt). Viele Provider liefern solche Nachrichten an dasselbe Postfach wie [email protected], aber das Tag erlaubt dem Nutzer, den Verwendungszweck zu kennzeichnen.
Nutzer verwenden Tags aus praktischen Gründen: Filterregeln (die Nachrichten in Ordner verschieben), Tracking (um zu sehen, welche Seite eine Adresse weitergegeben hat), und um Anmeldungen getrennt zu halten (so dass jedes Konto eine optisch unterschiedliche E-Mail hat). Das ist besonders verbreitet bei Gmail- und Fastmail-Nutzern.
Probleme entstehen, wenn ein Anmeldeformular + als ungültig oder verdächtig behandelt. Das sperrt sorgfältige, legitime Kunden aus. Ein weiterer häufiger Fehler ist, das Tag zu entfernen und nur die Basisadresse zu speichern. Dann können mehrere Anmeldungen auf ein Konto zusammenfallen und später zu verwirrenden Login- und Wiederherstellungsproblemen führen.
Häufige Fehlerfälle:
+, obwohl sie E-Mails empfangen können.name+billing@... und name+personal@... zu einem Nutzer zusammenführt.Behandle Plus-Adressierung als Formatwahl, nicht als Betrugsbeweis. Akzeptiere Adressen, die E-Mails empfangen können, und dedupe nur, wenn es wirklich sicher ist. Die einfachste Regel, die die meisten Probleme verhindert: speichere die originale E-Mail genau so, wie der Nutzer sie eingegeben hat, und erstelle — falls nötig — einen separaten Vergleichs-Key, der nur für Abgleiche verwendet wird.
Wenn du eine E-Mail-Validierung verwendest (zum Beispiel über einen Anbieter wie Verimail), sollte die Validierung auf Zustellbarkeit und Risiko-Signalen fokussieren, nicht darauf, legitime +tags zu bestrafen, auf die viele Nutzer angewiesen sind.
Plus-Adressierung ist eine Möglichkeit, ein Tag zur lokalen Adresse hinzuzufügen, ohne ein neues Postfach anzulegen. Das übliche Muster ist [email protected], wobei der Teil nach + dem Nutzer hilft, zu kennzeichnen, wo die Adresse verwendet wurde.
Eine E-Mail-Adresse hat zwei Hauptteile: den lokalen Teil und die Domain. Bei [email protected] ist name+tag der lokale Teil und example.com die Domain.
Drei Ideen werden oft durcheinandergebracht:
+.sales@ und hello@), verwaltet vom Provider oder Domain-Inhaber.Was als „dieselbe Inbox" zählt, hängt vom empfangenden Provider und der Domain-Konfiguration ab. Technisch sind [email protected] und [email protected] verschiedene Strings. Einige Provider liefern beide in dasselbe Postfach, aber nicht alle tun das, und das Verhalten kann je nach Domain variieren.
Deshalb ist der sicherste Standard, die vollständige Adresse so zu behandeln, wie der Nutzer sie eingegeben hat. Wenn sich jemand mit [email protected] anmeldet, erwartet er möglicherweise, dass zukünftige Nachrichten weiterhin in den gefilterten Ordner gelangen, den er eingerichtet hat.
Beispiel: Ein Kunde verwendet [email protected] für Newsletter und [email protected] für Rechnungen. Wenn deine App +news und +billing entfernt, kannst du zwei unterschiedliche Absichten zu einem account zusammenführen und später Verwirrung (und Supporttickets) erzeugen.
Plus-Adressierung ist verbreitet, aber nicht universell. Viele große Postfächer akzeptieren Adressen wie [email protected] und liefern sie an dasselbe Postfach wie [email protected]. Andere behandeln den +-Teil anders oder unterstützen ihn nicht.
Eine Detailfrage ist wichtiger als der Markenname: Die Regel wird durch die empfangende Domain gesetzt. Selbst innerhalb eines Unternehmens können unterschiedliche Domains unterschiedliche Mail-Routing-Einstellungen haben. Ein hart kodiertes „+ funktioniert immer“ oder „+ funktioniert nie“ blockiert früher oder später echte Nutzer.
Einige Domains unterstützen +tags nur für bestimmte Postfächer. Manche erlauben andere Trennzeichen. Einige Setups leiten Mail über Systeme weiter, die Teile der lokalen Adresse entfernen oder umschreiben. Betrachte Subaddressing als „vielleicht“-Feature, es sei denn, du kannst es verifizieren.
Was du nicht für alle Domains annehmen solltest:
jane.doe vs janedoe), es sei denn, du weißt, dass die Domain so funktioniert.+tags nicht für Zustellentscheidungen (Senden an den Nutzer).Ein sicherer Default ist einfach: Akzeptiere die E-Mail, die der Nutzer eingegeben hat, validiere sie und behalte sie genau so für Nachrichten. Falls du dedupen musst, speichere einen zweiten, „für Dedupe normalisierten" Wert separat.
Wenn sich jemand als [email protected] anmeldet, weil er Onboarding-Mails filtern will, verlieren du einen echten Kunden, wenn du das ablehnst. Ihn auf [email protected] zu ändern kann ebenso schaden, weil du dann nicht mehr an die Adresse sendest, die er erwartet.
Eine praktikable Vorgehensweise ist: Adresse akzeptieren, dann Syntax und Domain-Einrichtung prüfen (inkl. MX-Einträge) und schließlich Disposable- und Risiko-Checks anwenden. Eine E-Mail-Validierungs-API wie Verimail kann bestätigen, dass die Adresse wohlgeformt ist und die Domain so konfiguriert ist, dass sie Mail empfangen kann, während du die originale Adresse für den Versand unangetastet lässt.
Speichere, was der Nutzer eingegeben hat, und sende genau an diese Adresse. Leute nutzen Tags aus echten Gründen (Belege filtern, Arbeit und Privat trennen), und das Umschreiben der Adresse kann Zustellung kaputtmachen oder den Support erschweren, wenn ein Nutzer sagt: „Ich habe mich mit [email protected] angemeldet."
Gleichzeitig möchten viele Produkte einen zweiten Wert, der hilft, Duplikate zu erkennen und Konten ordentlich zu halten. Genau dafür gehört Normalisierung: in einem getrennten internen Key, nicht in der E-Mail, an die du sendest.
Ein praktisches Datenmodell hat zwei Felder mit unterschiedlichen Aufgaben:
Halte Verifizierungsinformationen getrennt von beiden. Validierung ist keine Eigenschaft der Adresse selbst, sondern ein Zustand zu einem Zeitpunkt. Speichere Status (valid, risky, invalid), einen Grund (z. B. Domain ohne MX) und einen Zeitstempel.
Normalisierung sollte konservativ sein. Die Domain kleingeschrieben zu speichern ist in der Regel sicher. Den lokalen Teil komplett zu lowercasen ist in der Praxis oft unproblematisch, aber sei konsistent und vermeide Überraschungen. Vor allem: entferne +tag nicht, es sei denn, es wird ausschließlich für einen internen Key verwendet und du bist sicher, dass du dadurch keine verschiedenen Personen zusammenführst.
Konkretes Beispiel: Speichere [email protected] als originale E-Mail, aber behalte als Key z. B. [email protected] für Abgleiche — jedoch nur, wenn du sicher bist, dass die Domain dieses Verhalten unterstützt. Ansonsten nutze [email protected] auch im Key.
Wenn du eine Validierungs-API wie Verimail einsetzt, validiere zuerst, dann normalisiere. Diese Reihenfolge hilft dir, zu vermeiden, dass du eine fehlerhafte Adresse „reparierst", sodass sie valid aussieht, aber nicht zustellbar ist.
Akzeptiere reale Adressen (einschließlich Plus-Adressierung) und erkenne trotzdem Duplikate, indem du einen separaten Dedupe-Key erstellst — nicht, indem du das eingegebene Feld umschreibst.
Eine praktische Vorgehensweise:
Eingabe trimmen und säubern. Entferne führende und folgende Leerzeichen. Lehne Steuerzeichen (Tabs, neue Zeilen, Nullbytes) ab, die eine andere Adresse verbergen oder Logs und Mails kaputtmachen können.
Führe grundlegende Syntaxprüfungen durch, aber banne + nicht. Ein gültiger lokaler Teil kann + und andere Zeichen enthalten. Achte auf offensichtliche Probleme wie fehlendes @, leere Teile oder illegale Leerzeichen.
Normalisiere die Domain vorsichtig. Speichere die Domain kleingeschrieben und normalisiere konsistent. Unterstützt du internationalisierte Domains, konvertiere sie standardisiert, damit exämple.com und seine ASCII-Form auf dieselbe Domain abgebildet werden.
Wende Regeln für den lokalen Teil nur an, wenn du das Risiko kontrollierst. Entferne +tag nicht global. Wenn du [email protected] mit [email protected] dedupen willst, tue das nur für Domains, die du explizit allowlistet und deren Verhalten du verifiziert hast.
Erzeuge einen stabilen Dedupe-Key, lasse das Original unangetastet. Speichere beide Werte: das Original zum Versenden und Anzeigen, und den normalisierten Key zum Abgleich.
Beispiel: Meldet sich jemand als [email protected] an, speichere [email protected] als Kontakt-E-Mail. Baue einen Dedupe-Key wie [email protected] nur, wenn example.com auf einer Allowlist steht. Andernfalls halte den Key näher am Original wie [email protected].
Wenn du eine Validierungs-API wie Verimail nutzt, validiere zuerst, dann normalisiere. So vermeidest du, eine schlechte Adresse in etwas zu verwandeln, das zwar syntaktisch korrekt aussieht, aber nicht zustellbar ist.
Behandle die vom Nutzer eingegebene E-Mail als sein Identitätslabel, nicht als etwas, das du beliebig umschreiben kannst. Bei Plus-Adressierung können zwei Strings an dasselbe Postfach routen, aber aus Nutzersicht sind sie nicht immer dasselbe Konto.
Bei der Anmeldung akzeptiere +tags und zeige die Adresse genau so zurück, wie sie eingegeben wurde (inklusive des +-Teils). Das beruhigt Nutzer, dass du ihre E-Mail nicht „korrigiert" hast.
Für den Login gilt eine einfache Regel: Allow logins with the exact email used at signup. Wenn jemand eine andere Variation (z. B. ohne Tag) eingibt und die einzige Übereinstimmung über einen normalisierten Key entsteht, logge ihn nicht stillschweigend ein — fordere stattdessen Eigentumsnachweis, z. B. durch den regulären Login oder eine E-Mail-Verifizierung.
Zusammenführungen sollten Nachweise verlangen, nicht nur "diese normalisieren auf denselben String". Sichere Optionen sind z. B.:
Beispiel: Alex registriert sich als [email protected] für einen Newsletter. Monate später tippt ein Kollege auf einem geteilten Gerät [email protected] ein. Ein automatisches Zusammenführen nur auf Basis von Normalisierung kann einem falschen Nutzer Zugriff geben.
Lege vorher fest, ob +tags als eigene Identitäten zählen sollen. Manche Teams behandeln jede eingeladene Adresse als einzigartig fürs Tracking, erlauben aber nicht mehrere Konten ohne bestätigte E-Mail.
Wenn du E-Mails während der Anmeldung validierst, halte die Grenze klar: Validierung hilft bei Zustellbarkeit und Risiko, Entscheidungen zur Identität (Login, Merge, Einladungen) sollten explizite Produktregeln folgen.
Der schnellste Weg, gute Anmeldungen zu verlieren, ist, eine gültige Adresse als „komisch" zu behandeln. Plus-Adressierung ist normal für Leute, die Mails filtern, sehen wollen, wo eine Adresse verwendet wurde, oder Anmeldungen getrennt halten.
Ein häufiger Bug ist ein Regex, das vor dem @ nur Buchstaben, Zahlen, Punkte und Bindestriche erlaubt. Das blockiert [email protected], obwohl es für viele Provider gültig ist. Wenn deine Validierungsregeln alt sind, ist das oft die Ursache.
Ein weiterer Fehler ist, das +tag zu entfernen und dann die abgespeckte Version für den Versand zu verwenden. Wenn sich der Nutzer mit [email protected] anmeldet, solltest du genau das Speichern und Senden. Entfernen kann auch Inbox-Regeln zerstören, die auf dem Tag basieren.
Die Handhabung von Punkten ist besonders riskant. Manche Dienste ignorieren Punkte im lokalen Teil (sam.smith@... vs samsmith@...), aber viele tun das nicht. Zu vermuten, dass Punkte überall gleich sind, kann unterschiedliche Postfächer zusammenführen.
Ein subtileres Problem sind inkonsistente Regeln über Systeme hinweg. Wenn dein Signup-Flow [email protected] akzeptiert, dein Billing-Tool das Tag jedoch entfernt und dein Marketing-Tool es behält, kann dieselbe Person als mehrere Kontakte auftauchen oder falsch zusammengeführt werden.
Schnelle "tu das nicht"-Checks:
+ im lokalen Teil nicht ab.Normalisierung ist keine Verifikation. Nutze Normalisierung nur für vorsichtiges Dedupe. Nutze einen echten Validator (z. B. Verimail), um Tippfehler, ungültige Domains und Disposable-Adressen zu erkennen, ohne legitime +tag-Nutzer zu blockieren.
Ein +tag ist meist ein Zeichen für einen vorsichtigen Nutzer, nicht für einen Angreifer. Leute nutzen Tags, um Mails zu filtern oder zu sehen, welche Seite ihre Adresse weitergegeben hat.
Angreifer können trotzdem Aliase missbrauchen, um viele Konten zu erstellen, weil einige Provider [email protected] als dasselbe Postfach behandeln. Das kann „ein Konto pro E-Mail“-Regeln umgehen, wenn dein System jede +tag als neue Identität behandelt.
Die Lösung ist nicht, +tags zu verbieten. Das sperrt echte Nutzer und stoppt nicht Missbrauch bei Providern, die andere Alias-Styles unterstützen (Punkte, Domain-Aliase, Catch-Alls). Entscheide, was du schützen willst: Account-Erstellung, Promotionen oder Identität.
Lege Reibung auf Verhalten, nicht auf Format. Z. B.: Rate-Limits bei verdächtigen Anmelde-Bursts, E-Mail-Verifizierung für risikoreichere Anmeldungen und Monitoring, wenn viele Anmeldungen kurzfristig auf dasselbe Postfach mapen.
Wenn du Identität von Kontaktmethode trennen musst, mache E-Mail nicht zum einzigen Schlüssel. Behandle das Konto als eigenes Record und E-Mails als Kontaktpunkte, die hinzugefügt, verifiziert und entfernt werden können. Das macht geteilte Postfächer, Rollenadressen und legitime E-Mail-Änderungen einfacher zu unterstützen.
Die Erkennung von Disposable-E-Mails ist wichtiger als das Verbot von +tags. Ein Disposable-Postfach ist für Wegwerf-Anmeldungen gedacht; ein +tag ist meist ein normales Postfach. Tools wie Verimail helfen, bekannte Disposable-Provider, Spamtraps und ungültige Adressen zu erkennen und gleichzeitig legitime getaggte Adressen zu akzeptieren.
Die meisten realen Probleme mit Plus-Adressierung sind selbstverschuldet: ein zu strenges Regex oder eine Dedupe-Regel, die stillschweigend Konten zusammenführt, die getrennt bleiben sollten.
Beginne mit Annahme. Dein Validator sollte + im lokalen Teil erlauben (vor @). Vermeide Regex-Abkürzungen, die nur Buchstaben, Zahlen, Punkte und Unterstriche erlauben. Wenn du eine Bibliothek nutzt, bestätige, dass sie RFC-konform ist statt einer selbstgebauten Lösung.
Trenne Zustellung von Dedupe. Speichere immer die originale E-Mail unverändert; sende niemals an eine modifizierte Version. Wenn du einen normalisierten Dedupe-Key erstellst, halte ihn getrennt und dokumentiere die Regeln, damit Support und Engineering dieselben Entscheidungen treffen.
Eine kurze Pre-Ship-Checklist:
+ im lokalen Teil.Für Domain- und Postfach-Erreichbarkeit: validiere, bevor du Nutzer in Schritte wie „verifiziere deine E-Mail, um fortzufahren“ zwingst. Ein Validator hilft, echte Nutzer nicht wegen Tippfehlern oder toten Domains zu blockieren.
Führe abschließend einen einfachen Testsatz aus: [email protected], [email protected] und [email protected]. Bestätige, dass sie sich anmelden, einloggen, Passwörter zurücksetzen und Nachrichten empfangen können, ohne Überraschungen.
Ein häufiger Fall: Eine B2B-App bietet kostenlose Testphasen. Ein Admin bei Acme probiert das Produkt für verschiedene Kunden und nutzt Tags wie [email protected], [email protected] und [email protected], um Inbox-Regeln sauber zu halten. Das ist normales Plus-Adressierungs-Verhalten, und Nachrichten liefern trotzdem ins gleiche Postfach.
Probleme entstehen, wenn Dedupe zu aggressiv ist. Wenn du alles nach + entfernst und alle diese Anmeldungen als denselben Nutzer behandelst, kannst du Leute aussperren. Der Admin versucht eine zweite Testphase, aber deine App denkt, das Konto existiert bereits und blockiert die Anmeldung. Ein Passwort-Reset geht dann an das erste Testkonto, nicht an das, das er gerade sieht.
Eine sichere Herangehensweise trennt „Zustell-Identität" von „Account-Identität". Speichere die originale E-Mail exakt so, wie sie eingegeben wurde. Nutze eine normalisierte Form nur als Hilfsmittel für Matching, Review oder Analytics. Dann:
[email protected], aber mache die Testphase erst nach E-Mail-Bestätigung aktiv.Für den Support ist es hilfreich, beide Felder im Nutzerprofil und in Logs zu zeigen: „Eingegebene E-Mail" und „Normalisiert für Dedupe". Das erleichtert das Erklären und schnelle Beheben von Problemen.
Wenn du +tags akzeptierst, sie aber in Signup, Login und internen Tools unterschiedlich behandelst, erzeugst du weiterhin Duplikate und verwirrte Nutzer. Die schnellste Korrektur ist, deine Regeln aufzuschreiben und überall dort anzuwenden, wo das E-Mail-Feld auftaucht.
Eine einfache Policy reicht für die meisten Teams: Speichere die E-Mail exakt wie eingegeben und verwende nur einen separaten normalisierten Wert für Matching und Reporting. So kannst du dedupen, ohne Zustellung zu zerstören oder Nutzer zu überraschen.
Rollout-Checklist:
Wenn du eine Implementierung möchtest, die sich auf Erreichbarkeit und Risiko-Signale konzentriert (ohne legitime +tags abzulehnen), bietet Verimail (verimail.co) eine einzelne E-Mail-Validierungs-API, die Syntax-Checks, Domain- und MX-Verifizierung sowie Disposable- und Blocklist-Abgleich kombiniert.
Sobald Änderungen live sind, messe die Ergebnisse, um Regressionen zu erkennen und Regeln zu optimieren. Verfolge die Ablehnungsrate bei Anmeldungen und die Gründe, Bestätigungs-Bounce-Rate, die Duplikatsrate basierend auf deinem normalisierten Key und Support-Tickets wegen doppelter Konten oder fehlschlagender Anmeldungen. Bewahre eine kleine, redigierte Stichprobe abgelehnter Adressen auf und prüfe sie. Wenn viele reale Domains blockiert werden, sind deine Validierungs- oder Normalisierungsregeln zu aggressiv.