Temporäre E-Mail zum Testen: So prüfen Entwickler und QA-Teams Registrierungsabläufe

Ein manueller Testlauf, eine Checkliste mit 12 Punkten und die echten Grenzen eines öffentlichen Temp-Postfachs für QA, dazu Tools für Automatisierung und Geheimnisse.

PureTempMail-Team

Das Team, das PureTempMail entwickelt und betreibt

Veröffentlicht am 30. Oktober 2026

Kurz gesagt

Mit einer temporären E-Mail-Adresse prüfen Sie einen Registrierungsablauf schnell von Hand: Bestätigungs-, Passwort-Reset- und Willkommensmails kommen in Sekunden in einem echten Posteingang im öffentlichen Internet an, ohne dass jemandes privates Postfach berührt wird. Für automatisierte Tests, echte Kundendaten oder alles, was Geheimnisse enthält, nehmen Sie stattdessen einen lokalen Mail-Catcher oder eine Test-Sandbox.

Jedes Produkt, das E-Mails verschickt, braucht jemanden, der sich immer wieder mit einer frischen Adresse registriert. Entwickler greifen zu ihrem eigenen Gmail mit Plus-Zusatz, QA-Tester führen eine Tabelle mit Wegwerfkonten, und Produktmanager leihen sich den Posteingang eines Kollegen. Für eine bestimmte Aufgabe ist eine temporäre E-Mail-Adresse zum Testen schneller als all das: genau zu sehen, was ein neuer Nutzer von Ihrem Produktiv- oder Staging-Mailsystem erhält.

Wir betreiben die Mailserver von PureTempMail, die Grenzen unten sind also unsere echten Einstellungen und keine Vermutungen. Diese Anleitung zeigt, wo ein öffentliches Temp-Postfach in einen Testplan passt, einen manuellen Durchlauf in fünf Minuten, die Checkliste, die wir für unsere eigenen Registrierungsmails verwenden würden, und die Fälle, in denen Sie ein anderes Tool nehmen sollten.

Wo ein Temp-Postfach zwischen Ihren Testoptionen passt

Es gibt fünf gängige Wege, einem Testkonto eine Adresse zu geben. Die meisten Teams nutzen am Ende zwei oder drei davon in verschiedenen Phasen desselben Releases.

Optionen für E-Mail-Tests im Vergleich: wofür sie taugen und wo sie an Grenzen stoßen
Option	Am besten für	Echte Zustellung über das Internet	Automatisierung	Worauf Sie achten sollten
Öffentliches Temp-Postfach (etwa PureTempMail)	Manuelle Prüfung von Staging- oder Produktivmails, exploratives Testen, Demos	Ja	Keine von unserer Seite: Sie beobachten den Posteingang im Browser	Wer die Adresse kennt, kann die Post lesen, und sie läuft nach einer Stunde ab, wenn Sie nicht verlängern
Lokaler SMTP-Catcher (etwa Mailpit)	Entwicklungsrechner und CI, wo die App an einen Fake-SMTP-Server sendet	Nein: Die Post verlässt nie Ihren Rechner oder Ihr Netzwerk	Ja, über seine HTTP-API	Sagt nichts über DNS, SPF, DKIM oder darüber, wie echte Anbieter Ihre Post behandeln
Gehostete Test-Sandbox (etwa Mailtrap oder Mailosaur)	Staging-Umgebungen und End-to-End-Testsuiten	Je nach Produkt: per SMTP abgefangen oder auf der Testdomain des Anbieters empfangen	Ja, mit SDKs für gängige Sprachen	Kostenpflichtige Tarife für nennenswertes Volumen, und ein weiterer Anbieter hält Ihre Testdaten
Plus-Adressierung auf einem Team-Postfach	Langlebige Testkonten, in die Sie sich nächsten Monat wieder einloggen müssen	Ja	Nur über die API dieses Mailanbieters	Viele Registrierungsformulare lehnen das Pluszeichen ab, und jeder Test landet in einem gemeinsamen Posteingang
Eigene Catch-all-Testdomain	Große Mengen dauerhafter Testkonten unter Ihrer Kontrolle	Ja	Ja, wenn Sie das Postfach über IMAP oder eine API auslesen	DNS und Mail-Hosting müssen eingerichtet und gepflegt werden

Ein Temp-Postfach füllt eine Lücke, die die anderen offenlassen: eine echte Nachricht, verschickt von Ihrem echten Mailanbieter, die auf einer Domain landet, die Sie nicht kontrollieren, und in Sekunden im Browser zu sehen ist. Näher kommen Sie an das, was ein neuer Kunde sieht, nicht heran, ohne irgendwo noch ein weiteres Konto anzulegen.

Ein manueller Testlauf mit PureTempMail

Diesen Ablauf empfehlen wir, um einen Registrierungsablauf von Hand zu prüfen. Ein Durchgang dauert etwa fünf Minuten.

Für jeden Testnutzer ein frisches Postfach öffnen
Öffnen Sie PureTempMail in einem eigenen Browserfenster. Beim Laden wird eine neue Adresse erzeugt. Das Postfach wird pro Browser gespeichert. Drücken Sie also für jeden Testnutzer auf Neu, oder nutzen Sie ein privates Fenster, wenn sich zwei Tester einen Rechner teilen.
Die Adresse neben dem Testfall notieren
Fügen Sie die Adresse in Ihren Testfall oder Ihr Ticket ein, bevor Sie sie verwenden. Wenn ein Tester später fragt, warum die Reset-Mail nie kam, müssen Sie wissen, an welches Postfach sie ging.
Die Registrierung durchlaufen und jede mögliche E-Mail auslösen
Füllen Sie das Formular aus und fordern Sie dann die E-Mails an, die ein neuer Nutzer in seiner ersten Sitzung auslösen kann: Bestätigung erneut senden, Passwort vergessen, Anmeldung per Magic Link, Änderung der E-Mail-Adresse. Jede davon ist eine eigene Vorlage, die für sich kaputtgehen kann.
Den Posteingang beobachten, ohne neu zu laden
Neue Post wird über eine Live-Verbindung auf die Seite geschoben, sobald unser Server sie annimmt. Der Zeitpunkt, an dem eine Nachricht erscheint, liegt also nah an ihrer echten Zustellzeit. Notieren Sie, wie lange jede gebraucht hat. So funktioniert es erklärt den Zustellweg.
Jede Nachricht in beiden Ansichten öffnen
Lesen Sie sie in HTML und wechseln Sie dann zu Nur Text. Auf die Textansicht greifen manche Programme und Screenreader zurück, und dort fällt ein fehlender Textteil oder ein unlesbarer Code als Erstes auf. Klicken Sie jeden Link an und prüfen Sie, wo er landet.
Verlängern, wenn der Ablauf langsam ist
Drip-Sequenzen, verzögerte Freigaben und Erinnerungen am zweiten Tag brauchen mehr Zeit. Drücken Sie +1 Std., um den Timer auf eine volle Stunde zurückzusetzen. Das können Sie wiederholen, bis 24 Stunden seit dem Anlegen des Postfachs vergangen sind.
Ablaufen lassen, dann den Bounce testen
Nach dem Ablauf weist unser Server Post an diese Adresse schon in der SMTP-Phase mit dem dauerhaften Fehler "No such mailbox" ab. Schicken Sie noch eine E-Mail dorthin und prüfen Sie, ob Ihre App oder Ihr Mailanbieter einen Hard Bounce verbucht und diesen Nutzer nicht mehr anschreibt.

Die Checkliste für Registrierungsmails

Diese Prüfungen würden wir vor einem Release bei den Registrierungsmails jedes Produkts durchführen. Jede davon fällt in einem echten Posteingang leicht auf und wird in einem Code-Review leicht übersehen.

Bestätigungscode oder -link. Er kommt an, der Code ist im Textformat lesbar, der Link funktioniert einmal, und ein zweiter Klick liefert eine klare Meldung statt einer Fehlerseite.
Magic Links und Einmalcodes. Ein neuer Link macht den alten ungültig, ein abgelaufener Link erklärt, was als Nächstes zu tun ist, und das Öffnen in einem anderen Browser verhält sich so, wie Sie es beabsichtigen.
Passwort-Reset. Die E-Mail nennt das Konto, um das es geht, der Link läuft ab, und ein Reset für eine nicht registrierte Adresse verrät nicht, ob zu dieser Adresse ein Konto existiert.
Willkommens- und Drip-Mails. Die erste kommt nach der Bestätigung an, nicht davor, und spätere Schritte werden für Nutzer, die nie bestätigt haben, nicht ausgelöst.
HTML- und Textteil. Beide sind vorhanden, beide sagen dasselbe, und nichts Wichtiges steht nur in einem Bild. Externe Bilder werden in unserer HTML-Ansicht geladen. Sie können sie dort prüfen und mit Nur Text die Nachricht ohne sie ansehen.
Anhänge. Rechnungen und PDFs kommen mit sinnvollen Dateinamen und Inhaltstypen an. Halten Sie Testdateien unter 1 MB pro Nachricht, oder schicken Sie einen Download-Link, was echten Nutzern ohnehin entgegenkommt.
Linkziele. Kein Link in einer Produktivmail zeigt auf localhost, einen internen Hostnamen oder eine Staging-Domain, und Tracking-Weiterleitungen führen zur richtigen Seite.
Abmelde-Header. Marketing- und Drip-Mails enthalten einen funktionierenden Abmeldelink und, bei Massenversendern, den Ein-Klick-Header List-Unsubscribe nach RFC 8058, den die Absenderrichtlinien von Google von Massenversendern verlangen. Transaktionsmails wie Resets sollten durch eine Abmeldung nicht blockiert werden.
Zustellzeit. Bestätigungsmails, die länger als ein, zwei Minuten brauchen, kosten Nutzer. Ist eine langsam, prüfen Sie, ob Ihre App Mails hinter anderen Jobs einreiht oder ob der Anbieter neue Absender drosselt.
Ihre eigenen Ratenbegrenzungen. Hämmern Sie auf die Schaltfläche zum erneuten Senden. Die App sollte das begrenzen und den Nutzer bitten zu warten, statt zehn Codes zu verschicken oder stillschweigend zu scheitern.
Wiederverwendung einer Adresse. Registrieren Sie sich in einer Sitzung zweimal mit derselben Adresse und prüfen Sie den zweiten Versuch: ein klarer Weg für "bereits registriert" und kein zweites Konto.
Ihre Regel gegen Wegwerf-Domains. Wenn Ihr Produkt temporäre Adressen blockiert, prüfen Sie, ob die Fehlermeldung klar ist und nicht versehentlich auch echte Anbieter sperrt. Mehr dazu weiter unten.

Unsere Grenzen und was sie für einen Test bedeuten

Das sind die tatsächlichen Einstellungen auf unseren Servern. Planen Sie Testläufe danach.

Lebensdauer: Eine Stunde ab dem Anlegen. +1 Std. setzt sie auf eine volle Stunde zurück, bis 24 Stunden nach dem Anlegen. Genug für eine Sitzung, nicht für ein Testkonto, das Sie im nächsten Sprint wiederverwenden wollen.
Nachrichten: Bis zu 50 Nachrichten und 5 MB pro Postfach. Ist eine der beiden Grenzen erreicht, wird neue Post abgewiesen. Ein Lasttest gegen eine einzige Adresse hört also schnell auf zu zählen. Öffnen Sie pro Testnutzer ein neues Postfach.
Nachrichtengröße: Bis zu 1 MB pro E-Mail, Anhänge eingeschlossen. Nur die ersten 10 Anhänge werden behalten.
Nur Empfang: Die Adresse kann weder senden noch antworten. Abläufe, bei denen der Nutzer per E-Mail antworten muss, etwa Support-Ticket-Verläufe, lassen sich hier nicht durchgängig testen.
Domain: Eine Domain für alle Adressen. Wenn Ihr Produkt bekannte temporäre Domains blockiert, blockiert es auch unsere, was nützlich ist, wenn Sie genau dieses Verhalten testen wollen.
Neue Postfächer: Fünf neue Postfächer pro Minute von einer IP-Adresse. Ein QA-Team hinter einem gemeinsamen Büroanschluss teilt sich dieses Kontingent.
Löschung: Nach dem Ablauf löscht eine Bereinigung, die alle fünf Minuten läuft, das Postfach samt Nachrichten und Anhängen. Machen Sie Screenshots, bevor der Timer abläuft, wenn Sie Belege für einen Bugreport brauchen.
Automatisierung: Es gibt keine öffentliche API für den skriptgesteuerten Zugriff auf Postfächer. PureTempMail ist für einen Menschen vor dem Browser gebaut, deshalb gehören automatisierte Testsuiten auf die weiter unten genannten Tools.

SPF, DKIM und DMARC Ihrer Testmails prüfen

Eine Nachricht, die gut aussieht, kann trotzdem an der Authentifizierung scheitern und bei echten Nutzern im Spam landen. Schicken Sie zur Prüfung dieselbe E-Mail an ein Postfach, das den Rohquelltext zeigt, etwa über Original anzeigen in Gmail, und fügen Sie die Header in unsere E-Mail-Header-Analyse ein. Sie zeigt, ob SPF, DKIM und DMARC bestanden wurden, markiert ein Reply-To auf einer anderen Domain und zeigt, wo die Zustellung langsam war. Die Analyse läuft in Ihrem Browser, die Header werden also nicht an uns gesendet.

Die eigene Sperre für Wegwerf-Domains testen

Viele Teams bauen eine Prüfung auf Wegwerf-E-Mails in ihr Registrierungsformular ein und testen sie nie mit einer echten temporären Adresse. Ein Temp-Postfach ist die naheliegende Testeingabe.

Den Wortlaut prüfen. Die Ablehnung sollte sagen, was stattdessen zu verwenden ist, etwa "Bitte verwenden Sie eine private oder geschäftliche Adresse". Ein knappes "Ungültige E-Mail" schickt ehrliche Nutzer auf die Suche nach einem Tippfehler, den es nicht gibt.
Auf Fehlalarme prüfen. Probieren Sie Adressen bei kleinen regionalen Anbietern und auf eigenen Firmendomains. Sperrlisten, die nach Mustern filtern, erwischen sie manchmal.
Jeden Einstiegspunkt prüfen. Dieselbe Regel sollte für das Registrierungsformular, die Einstellung zum Ändern der E-Mail-Adresse, Einladungen und die API gelten, sonst nehmen die Leute einfach den Weg, den Sie vergessen haben.
Entscheiden, ob Sie die Sperre überhaupt brauchen. Unser Artikel Warum Websites Wegwerf-E-Mails blockieren behandelt die Kosten, die sie rechtfertigen, und die Fälle, in denen sie Sie nur ehrliche Nutzer kostet.

Wann ein öffentliches Temp-Postfach das falsche Tool ist

In diesen Fällen nehmen Sie etwas anderes.

Alles mit echten Geheimnissen oder Kundendaten. Produktiv-Tokens, echte Rechnungen, Admin-Einladungen. Nutzen Sie eine Sandbox, die nur Ihr Team lesen kann.
Automatisierte Tests und CI. Leiten Sie die App in Entwicklung und CI auf einen lokalen Catcher wie Mailpit um und auf eine gehostete Sandbox wie Mailtrap oder Mailosaur, wenn Tests gegen eine bereitgestellte Umgebung laufen müssen. MailHog, der ältere lokale Catcher, wird nicht mehr gepflegt, Mailpit ist der übliche Ersatz.
Staging-Umgebungen mit Kopien echter Nutzerdaten. Das Problem sind dort die kopierten Daten. Bereinigen Sie sie und leiten Sie Staging-Mails in einen Catcher, damit ein Test nie einem echten Kunden schreibt.
Testkonten, die Sie behalten müssen. Ein Demokonto für den Vertrieb oder ein Prüfkonto für einen App Store braucht eine Adresse, die nächsten Monat noch funktioniert. Nutzen Sie Plus-Adressierung auf einem Team-Postfach oder ein Catch-all auf einer eigenen Testdomain.
Fixtures, die nie zugestellt werden dürfen. Für Seed-Daten und Unit-Tests verwenden Sie die reservierten Domains wie example.com und die Top-Level-Domain .test, die in RFC 2606 dafür vorgesehen sind. Post an sie geht absichtlich nirgendwohin.

Fazit

Nutzen Sie eine temporäre E-Mail-Adresse zum Testen, wenn ein Mensch schnell und mit erfundenen Daten eine echte E-Mail von einem echten Absender sehen muss: Release-Checks, exploratives Testen und Demos. Automatisieren Sie mit einem Catcher oder einer Sandbox, halten Sie Geheimnisse aus öffentlichen Postfächern heraus, und sehen Sie sich unsere Seite mit weiteren Anwendungsfällen an, wenn Sie überlegen, wo eine Wegwerfadresse sonst noch passt. Was mit einer Nachricht passiert, nachdem sie bei uns ankommt, lesen Sie in So funktioniert ein Temp-Mail-Dienst von innen.

Quellen

Mailpit auf GitHub, das E-Mail-Testtool mit API für Entwickler, und seine Hinweise zum Ersatz von MailHog.
Dokumentation der Mailtrap Email Sandbox.
Mailosaur-Clientbibliotheken auf GitHub.
RFC 8058, Signaling One-Click Functionality for List Email Headers.
Google, Richtlinien für E-Mail-Absender.
RFC 2606, Reserved Top Level DNS Names.
Lebensdauer, Größen- und Mengengrenzen der Postfächer, Ratenbegrenzungen, die SMTP-Abweisung nach dem Ablauf und der Zeitplan der Bereinigung stammen aus der Serverkonfiguration von PureTempMail und sind auch in den FAQ zusammengefasst.