Fake-E-Mail-Adresse zum Testen: sichere Adressen für Anmeldeformulare
Wenn Sie Websites bauen oder testen, tippen Sie ständig E-Mail-Adressen in Formulare. Das Einzige, was nie passieren darf: dass eine Testnachricht im echten Postfach eines Fremden landet. Diese Seite zeigt, welche Fake-E-Mail-Adresse Sie für welchen Test nehmen — und wann die Nachricht wirklich ankommen muss.
Entscheiden Sie zuerst, ob die Mail ankommen muss
Diese eine Frage entscheidet alles, und es lohnt sich, sie ausdrücklich zu stellen — die Antwort ist öfter „nein“, als man denkt.
| Was Sie testen | Muss die Mail ankommen? | Nehmen Sie |
|---|---|---|
| Prüfung, Speicherung, Anzeige einer Adresse | nein | eine reservierte Domain — siehe unten |
| Den Bestätigungsablauf, von Hand | ja | ein Postfach hier |
| Den Bestätigungsablauf, automatisiert | ja, per Code lesbar | einen Dienst mit API |
| Last- oder Volumentests | nein — und sie darf nicht | immer eine reservierte Domain |
Wenn die Mail nicht ankommen darf: reservierte Namen nehmen
Es gibt Domains, die genau dafür existieren und garantiert nie jemandem gehören: example.com und seine Geschwister example.net und example.org, reserviert durch RFC 2606, dazu die gesamte Endung .test.
Adressen darauf sind die richtige Wahl für Beispieldaten, Startdaten und Lasttests. Nichts, was Sie senden, kann einen Menschen erreichen, weil dort niemand ist — per internationaler Vereinbarung, nicht durch Glück.
test@mycompanytest.com ist oft genug die echte Domain von jemandem, und ein Lasttest dagegen ist von einem Angriff nicht zu unterscheiden. Die reservierten Namen kosten nichts und beseitigen diese ganze Art von Unfall.Wenn die Mail ankommen muss, von Hand
Nehmen Sie hier eine Adresse, lassen Sie den Ablauf laufen und lesen Sie, was Ihre Anwendung wirklich verschickt hat — Kopfzeilen, Links und wie die Nachricht aussieht, wenn nicht Ihr eigenes Mailprogramm sie anzeigt. Zwei Dinge, die das aufdeckt und ein lokaler Mail-Fänger nicht:
- Echte Zustellung. Die Nachricht nimmt einen echten Mailweg, also scheitern falsch eingerichtete Absender hier und nicht im Livebetrieb.
- Wie ein Fremder sie sieht. Links, die nur in Ihrer Sitzung funktionieren, Bilder, die nie laden, ein Abmeldelink, der auf localhost zeigt — alles sofort sichtbar.
Achten Sie auch auf die Anhang-Warnungen, wenn Ihre Anwendung Dateien verschickt: Es sind dieselben Warnungen, die Ihre Nutzer sehen.
Wenn es automatisiert sein muss
Die Seite stattdessen auszulesen ist selbst dann ein schlechter Tausch, wenn es klappt: brüchig, undokumentiert und genau das Verkehrsmuster, das irgendwann gesperrt wird.
Ablehnungspfade testen
Die interessanten Fehler sind nicht „eine gültige Adresse funktioniert“. Abdecken sollten Sie:
- Eine Adresse auf einer Domain ohne MX-Eintrag — die Zustellung scheitert, obwohl die Adresse richtig geschrieben ist. Ihr Code sollte das eine vom anderen unterscheiden. Prüfen Sie, was was ist.
- Eine internationalisierte Domain, sowohl in Unicode als auch in der
xn---Form. Die meisten Prüfer lehnen eine ab und nehmen die andere an, und meist falschherum — Konverter. - Gmail-Varianten mit Punkt und Plus. Vergleicht Ihre Eindeutigkeitsprüfung rohe Zeichenketten, kann eine Person unbegrenzt viele Konten anlegen. Erst normalisieren — diese Seite tut genau das, was Ihre Prüfung tun sollte.
- Ein sehr langer lokaler Teil. Der Standard erlaubt 64 Zeichen; viele Formulare schneiden still bei 20 ab und speichern etwas, das nirgendwo mehr hinführt.
Etwas zum Bauen, nicht zum Testen
Wenn Ihr Produkt Fake-E-Mail-Adressen ablehnt, dann tun Sie es klar. „Ungültige E-Mail“ für eine völlig gültige Adresse ist der verwirrendste Fehler dieser Art: Der Nutzer prüft die Schreibweise, tippt neu und bekommt dieselbe Meldung. „Wir akzeptieren keine Fake-E-Mail-Adressen“ braucht genauso viel Platz und beendet die Verwirrung.