What is a temporary email address?

A temporary email address is a real, working inbox that receives emails like any normal address. It does not require an account or registration. The inbox automatically deletes itself after one hour.

Is TempEmail free to use?

Yes. TempEmail is completely free. There are no plans, no usage limits, and no credit card required.

How long does a temporary email inbox last?

The inbox stays active for one hour from when it was created. After that, the address and all emails in it are permanently deleted. You can bookmark the page URL to return to the same inbox within that window.

Can I choose my own temporary email address?

Not at the moment. Addresses are randomly generated each time you visit. Custom addresses are planned for a future update.

Can I send emails from a temporary email address?

No. TempEmail is a receive-only inbox. You can read emails sent to your temporary address but you cannot send emails from it.

What are legitimate uses for a temporary email address?

Common legitimate uses include testing your own application's email flows, signing up as a new user to test your product's onboarding experience, protecting your inbox while researching vendors or services, short-term project registrations, and maintaining privacy on public or shared computers.

Why didn't I receive the email I was expecting?

Some services actively block disposable or temporary email domains. If you did not receive an expected email, the sender may have rejected the address. This is the sender's decision and cannot be overridden.

Is my temporary email inbox private?

The inbox has no password, but the address is randomly generated and long enough that it cannot realistically be guessed. Do not use it for anything sensitive like banking or private communications.

Can I use TempEmail on my phone?

Yes. TempEmail works on any device with a browser, including mobile phones and tablets. Copy the address and emails will appear in real time just like on desktop.

Passwort-Reset-Flows testen als Entwickler

Warum das Testen des Passwort-Resets oft vernachlässigt wird

Der Passwort-Reset ist einer der am häufigsten angegriffenen — und paradoxerweise am wenigsten getesteten — Flows in jeder Webanwendung. Der Grund ist einfach: Entwickler verwenden ihre eigene E-Mail-Adresse während der Entwicklung. Nach dem dritten oder vierten Testlauf ist der Posteingang voll mit identisch aussehenden "Passwort zurücksetzen"-Nachrichten. Man verliert den Überblick, welcher Link zu welchem Testlauf gehört, und irgendwann wird das Testen zu mühsam. Man verlässt sich darauf, dass es funktioniert, weil es beim letzten Mal funktioniert hat. Genau diese Selbstgefälligkeit lässt schwere Bugs in die Produktion schlüpfen.

Was du im Passwort-Reset-Flow wirklich testen musst

Ein einfacher "Wird eine E-Mail gesendet?"-Test reicht nicht aus. Das OWASP Authentication Cheat Sheet beschreibt eine umfassende Liste von Anforderungen, die jede einzelne getestet werden muss:

E-Mail-Zustellung — kommt die Reset-E-Mail tatsächlich an, und kommt sie schnell an?
Link-Korrektheit — führt der Link in der E-Mail zur richtigen Seite mit dem richtigen Token?
Token-Ablauf — wenn du 25 Stunden wartest und dann auf den Link klickst, wird der abgelaufene Token korrekt abgelehnt?
Einmalige Token — kann derselbe Reset-Link zweimal verwendet werden? Das darf nicht möglich sein.
Token-Invalidierung bei erneutem Reset — wenn ein Nutzer zweimal einen Reset anfordert, wird der erste Token ungültig?
SSO-Konten — was passiert bei Nutzern, die sich über Google oder einen anderen OAuth-Anbieter registriert haben?
HTTPS-Erzwingung — ist der Reset-Link immer HTTPS?
Rate Limiting — kann jemand den Endpoint für eine bestimmte Adresse spammen?
E-Mail-Enumeration — unterscheidet sich die Antwort je nachdem, ob die E-Mail existiert? Das sollte nicht der Fall sein.

Der Temp-E-Mail-Ansatz — Schritt für Schritt

Die sauberste Lösung ist eine frische temporäre E-Mail-Adresse für jeden Testlauf. Öffne einen temporären Posteingang, kopiere die angezeigte Adresse, registriere damit ein Testkonto in deiner Anwendung und löse einen Passwort-Reset aus. Die E-Mail kommt in Echtzeit an — du kannst sie einsehen, auf den Link klicken und den gesamten Vorgang verifizieren, ohne deinen persönlichen Posteingang zu berühren. Für ein weiteres Testszenario öffnest du einfach einen neuen Browser-Tab und erhältst eine völlig unabhängige Inbox mit einer anderen Adresse. Keine Aufräumarbeit, keine Verwirrung, kein Risiko, den falschen Link aus einem vorherigen Testlauf zu klicken.

Meine persönliche Testroutine vor einem Release

Vor einem Release öffne ich fünf Browser-Tabs, jeder mit einer unabhängigen temporären Inbox. Tab eins: Happy Path — registrieren, Reset anfordern, Link innerhalb von zwei Minuten nutzen, Anmeldung bestätigen. Tab zwei: Abgelaufener Token — Reset anfordern, 25 Stunden warten, dann den Link versuchen. Tab drei: Doppelter Reset — Reset anfordern, sofort erneut anfordern, dann beide Links testen. Tab vier: Wiederverwendeter Link — Reset erfolgreich nutzen, dann denselben Link ein zweites Mal versuchen. Tab fünf: Rate Limiting — Resets schnell hintereinander auslösen. Jedes Szenario hat seine eigene saubere Inbox. Die gesamte Testsuite dauert unter 30 Minuten.

Hardcode niemals eine Test-E-Mail-Adresse in deiner Codebase. Nutze jedes Mal eine frische Temp-Mail-Inbox — damit testest du echte Zustellung und startest immer mit einem sauberen Zustand.

Die Token-Sicherheits-Checkliste

Passwort-Reset-Token sind eine häufige Angriffsfläche. Laut OWASP sollte eine sichere Implementierung folgendes erfüllen:

Mindestens 32 Zeichen, kryptografisch zufällig generiert
Läuft innerhalb von 24 Stunden ab, idealerweise innerhalb von 1 Stunde
Einmalig verwendbar — nach Einlösung sofort ungültig
Wird ungültig, wenn ein neuer Reset angefordert wird
Rate-limitiert pro E-Mail-Adresse
Niemals im Klartext in Logs gespeichert

Wie die Reset-E-Mail aussehen sollte

Eine gute Passwort-Reset-E-Mail ist schlicht und funktional: eine klare Betreffzeile ("Passwort zurücksetzen"), ein einzelner prominenter Button, eine klare Ablaufangabe ("Dieser Link läuft in 1 Stunde ab") und ein Hinweis, dass die E-Mail ignoriert werden kann, wenn der Nutzer keinen Reset angefordert hat. Kein Marketing-Text, keine Social-Media-Icons, kein Newsletter-Footer. Überprüfe die Konfiguration deiner Domain mit MXToolbox und lies den E-Mail-Authentifizierungsleitfaden, um sicherzustellen, dass deine E-Mails nicht im Spam-Ordner landen.

Passwort-Reset in die Regressionssuite aufnehmen

Der Passwort-Reset bricht oft still und heimlich, wenn Auth-Bibliotheken aktualisiert, E-Mail-Provider gewechselt oder API-Keys rotiert werden. Füge mindestens einen einfachen End-to-End-Test in deiner Staging-Umgebung hinzu: ein Testkonto programmatisch erstellen, einen Reset auslösen, die ausgehende E-Mail über die API deines Mail-Services abfangen und den Token verifizieren. Schon ein einziger automatisierter Check nach jedem Deployment fängt die häufigste Regressionsklasse ab. Für tiefergehende Einblicke in reale Passwort-Kompromittierungen ist Troy Hunts Blog eine unverzichtbare Ressource.