Wie man ein Test-E-Mail-Konto für QA auswählt

Was ist ein Test-E-Mail-Konto für QA?

Ein Test-E-Mail-Konto oder eine Test-E-Mail-Adresse für QA ist eine Adresse, die Ihr Team verwendet, um die E-Mails zu empfangen und zu prüfen, die Ihre eigene Anwendung versendet. Nutzen Sie einen temporären Posteingang für manuelle, nicht sensible Anmelde- und OTP-Prüfungen. Wählen Sie ein Firmenpostfach, wenn Nachrichten aufbewahrt, beantwortet oder mit Anhängen versehen werden sollen, und eine SMTP-Sandbox oder eine gehostete Postfach-API, wenn automatisierte Tests E-Mails ohne menschliches Zutun prüfen müssen.

Tmailor betreibt diesen Blog, daher passt er hier gut. Tmailor ist ein kostenloser temporärer E-Mail-Dienst, der nur empfangen kann, im Web, auf Android, iOS und als Telegram-Bot. Er eignet sich für den ersten Fall: Eine Person öffnet einen Posteingang, löst eine Anmeldung aus und liest, was ankommt. Für den letzten Fall ermöglicht die separate Tmailor Temp Mail API automatisierten Tests, reine Empfangsadressen zu erstellen und deren Nachrichten aus dem Code auszulesen. Nachrichten bleiben etwa 24 Stunden ab Ankunft erhalten, Anhänge werden nicht empfangen, und die Adresse kann weder senden noch antworten. Wenn Sie neu bei Wegwerf-Postfächern sind, beginnen Sie mit an, wie temporäre E-Mail funktioniert.

• Es muss keine E-Mail eingehen (Formularvalidierung, Fixtures, Unit-Tests): Verwenden Sie eine reservierte Beispiel-Domain.
• Eine Person liest die E-Mail und nichts darin ist sensibel: Ein temporärer Posteingang ist die schnellste Option.
• Sensible Daten, Antworten, Anhänge oder Nachweise, die Sie aufbewahren müssen: Verwenden Sie ein genehmigtes, vom Unternehmen kontrolliertes Postfach; fügen Sie Plus-Tags nur hinzu, wenn Ihr Mailsystem und Ihre Anwendung diese unterstützen.
• Niemand schaut zu Nutze einen SMTP-Catcher, wenn du die ausgehenden Mail-Einstellungen der App kontrollierst, oder eine gehostete Postfach-API, falls die App über ihren normalen Anbieter senden muss.

Manuelles vs. automatisiertes E-Mail-Testing: Ein Entscheidungsbaum

Vier Fragen entscheiden, welches Test-E-Mail-Konto eine Prüfung benötigt: ob überhaupt eine E-Mail ankommen muss, ob eine Person oder Code sie liest, ob sie sensible Daten enthält und ob Sie kontrollieren, wohin die Anwendung ihre ausgehenden E-Mails sendet.

1. Muss für den Test eine E-Mail ankommen? Formatprüfungen, UI-Zustände, Fixtures und Unit-Tests benötigen das meist nicht. Verwenden Sie Adressen bei example.com, example.org oder example.net. Diese Domains sind für Dokumentation und Beispiele reserviert, sodass nichts eine reale Person erreicht. Vermeiden Sie es, zufällige Domains zu erfinden, denn möglicherweise gehört sie jemandem.
2. Wird eine Person die Nachricht während des Tests lesen? Smoke-Tests, manuelles UAT, Demos und explorative Sitzungen haben einen Menschen im Ablauf. Regressionssuiten und CI-Jobs meist nicht.
3. Wenn eine Person sie liest, ist etwas darin sensibel? Echte Kundendaten, Zugangsdaten, regulierte Daten oder Nachrichten, die Sie als Prüfnachweis aufbewahren müssen, gehören nicht in einen temporären Posteingang. Verwenden Sie stattdessen ein Firmenpostfach. Wenn die Antwort nein ist, reicht ein temporärer Posteingang aus.
4. Wenn Code sie liest, kann die Testumgebung ihre E-Mails an einen Test-SMTP-Server senden? Wenn ja, erfasst ein SMTP-Catcher jede Nachricht, ohne sie zuzustellen. Wenn nein, weil die App über ihren normalen E-Mail-Anbieter senden muss, nutzen Sie einen gehosteten Posteingang, den Ihre Tests über eine API lesen.

Die Tabelle vergleicht die fünf Optionen nebeneinander.

Welche Adressen sollte ein E-Mail-Feld akzeptieren oder ablehnen?

Testen Sie die Formularvalidierung getrennt von der Nachrichtenzustellung. Verwenden Sie eine reservierte Adresse wie user@example.com für einen gültig aussehenden Fall, der nie zugestellt wird, fügen Sie eine Adresse mit Plus-Tag und eine mit einer Subdomain hinzu und ergänzen Sie fehlerhafte Fälle wie einen fehlenden lokalen Teil oder eine fehlende Domain. Halten Sie die erwarteten Ergebnisse mit dem Validator abgeglichen, den Ihr Produktionssystem tatsächlich verwendet.

Wann ein temporärer Posteingang ausreicht

Ein temporärer Posteingang eignet sich, wenn eine Person jeweils einen Ablauf prüft und die Nachricht nichts enthält, dessen Verlust nach einem Tag Ihnen etwas ausmachen würde. Das ist der klassische Einsatz einer Wegwerf-E-Mail für QA: Sie brauchen eine E-Mail-Adresse, um ein Formular manuell zu testen, kein langlebiges Konto. Typische Fälle sind ein Smoke-Test des Anmeldeformulars vor dem Release, ein manueller UAT-Durchlauf einer neuen Onboarding-E-Mail, eine Vertriebsdemo zur Kontoerstellung oder eine explorative Sitzung, in der Sie ungewöhnliche Eingaben ausprobieren und beobachten, was die App versendet.

Der Reiz liegt in der Geschwindigkeit. Es gibt kein Konto, das Sie bei der IT beantragen müssen, und kein gemeinsames Postfach, das aufgeräumt werden muss. Der Kompromiss ist die Kontrolle: Sie erhalten ein kurzes Zeitfenster für Nachrichten, keine Anhänge und einen Posteingang, den eine Person statt Code liest.

Wann Sie einen SMTP-Catcher oder eine gehostete Postfach-API benötigen

Sobald Tests unbeaufsichtigt laufen, muss der Posteingang per Code lesbar sein. Zwei Arten von Tools decken diesen Bedarf ab und lösen unterschiedliche Probleme.

SMTP-Catcher und Sandboxes ersetzen den ausgehenden Mailserver Ihrer App in einer Testumgebung und speichern jede Nachricht zur Inspektion, anstatt sie zuzustellen.

• Mailpit ist ein kostenloses Open-Source-Tool, das Sie selbst betreiben. Es fängt E-Mails standardmäßig ab und bietet eine Web-UI sowie eine REST-API für Integrationstests.
• MailHog funktioniert genauso, ist aber älter. Die Maintainer von Mailpit bezeichnen es als nicht mehr gepflegt, prüfen Sie daher seinen Status, bevor Sie es einsetzen.
• Mailtrap Email Sandbox ist eine gehostete Version derselben Idee mit SMTP- und API-Zugriff. Es ist getrennt von Mailtraps Produkt für den produktiven Versand.
• Ethereal ist ein kostenloser Fake-SMTP-Dienst, der hauptsächlich mit Nodemailer verwendet wird. Nachrichten werden zur Vorschau abgefangen und nie zugestellt.

Gehostete Inbox-APIs geben Tests echte Adressen auf den Domains des Anbieters, sodass deine App Mails über ihren normalen Anbieter sendet und der Test das Ergebnis über eine API liest. Tmailors eigene Temp Mail API funktioniert auf diese Weise, mit offiziellen SDKs für Python, Node.js und PHP.

• Mailosaur bietet Test-E-Mail-Adressen, eine API und Client-Bibliotheken, die mit Frameworks wie Cypress, Playwright und Selenium funktionieren. Es deckt auch SMS-Codes ab.
• MailSlurp erstellt Posteingänge auf Abruf über seine API und SDKs. Tests können auf eine Nachricht warten und dann Codes, Links und Anhänge herausziehen.

Anbieterfunktionen und -pläne ändern sich, prüfe daher die aktuellen Angaben auf jeder offiziellen Seite, bevor du eine Testsuite auf einen Anbieter festlegst.

Wann ein Firmenpostfach mit Plus-Tags die bessere Wahl ist

Plus-Tags ermöglichen es einem Firmenpostfach, viele Adressvarianten zu akzeptieren. Mails an qa+signup oder qa+reset auf deiner Firmendomain landen im qa-Postfach, wo du sie nach Tag filtern kannst. Google Workspace unterstützt das, und Microsoft dokumentiert, dass die Plus-Adressierung in Exchange Online standardmäßig aktiviert ist, es sei denn, ein Administrator schaltet sie ab.

Nutze diesen Weg, wenn ein Ablauf echte Kundendaten enthält, länger als einen Tag dauert, Antworten oder Anhänge benötigt oder Nachweise liefert, die ein Prüfer anfordern könnte. Behalte die Grenzen im Kopf. Tags sind Varianten eines Postfachs, keine separaten Posteingänge, sodass parallele Tests die Nachrichten der jeweils anderen lesen können. Einige Anmeldeformulare lehnen das Plus-Zeichen ab, und einige Apps behandeln getaggte Varianten als dasselbe Konto. Beide Verhaltensweisen sind einen eigenen Testfall wert.

So führst du einen manuellen Anmeldetest mit einem temporären Posteingang durch

Ein manueller Anmeldetest mit temporärer E-Mail für Tests braucht drei Dinge: eine frische Adresse, den Build, den du testest, und einen Ort außerhalb des Posteingangs, um festzuhalten, was angekommen ist. Führe ihn nur gegen Systeme aus, die dir gehören oder die du testen darfst.

1. Öffne einen Posteingang. Erstelle einen kostenlosen temporären Posteingang im Web, nutze die Tmailor-App oder den Telegram-Bot und kopiere die Adresse. Auf einem Desktop kann die Tmailor-Browsererweiterung das Formular sie auch in das E-Mail-Feld deines Test-Builds einfügen.
2. Melde dich in deinem Test-Build an. Verwende die Adresse in deiner Staging- oder QA-Umgebung und notiere die Uhrzeit, zu der du das Formular abgeschickt hast.
3. Achte auf die E-Mail. Prüfe, welche Nachricht angekommen ist, den Absendernamen und die From-Adresse, den Betreff und wie lange es gedauert hat.
4. Schließe den Schritt ab. Klicke auf den Link oder gib den Code ein. Bestätige, dass das Konto seinen Status nur einmal ändert und dass die erneute Verwendung desselben Links mit einer klaren Meldung fehlschlägt.
5. Halte die Nachweise anderswo fest. Kopiere den Link, den Code, die Zeitstempel und einen Screenshot in deinen Testfall. Nachrichten bleiben etwa 24 Stunden ab Ankunft erhalten, daher ist der Posteingang nicht dein Testprotokoll.
6. Speichere den Access Token, wenn du erneut testen willst. Der Token öffnet später dieselbe Adresse wieder, zum Beispiel um einen Passwort-Reset erneut durchzuführen. Er stellt keine bereits abgelaufenen Nachrichten wieder her, und ein verlorener Token kann nicht wiederhergestellt werden.

Wenn eine Sitzung mehrere Personas gleichzeitig benötigt, etwa einen kostenlosen Nutzer, einen Testnutzer und einen eingeladenen Teamkollegen, hält die Ansicht mehrerer Postfächer bis zu fünf Adressen nebeneinander in einem Browser-Tab bereit. Jede Persona erhält ihre eigene Adresse, sodass du sehen kannst, welche E-Mail zu welchem Konto gehört.

Diese Ansicht ist weiterhin manuell. Die Posteingänge werden von einer Person im Browser erstellt und nicht per Code bereitgestellt, sodass sie eine gehostete Inbox-API für parallele, unbeaufsichtigte Läufe nicht ersetzt.

Ein Posteingang oder eine Adresse pro Test?

Ein einzelner gemeinsamer Posteingang reicht für einen schnellen Smoke-Test aus, doch er wird schnell unübersichtlich. Sobald mehrere Tests gleichzeitig laufen, machen ähnliche Betreffzeilen es schwer zu erkennen, welche E-Mail zu welchem Skript gehört, und das Debugging wird zum Rätselraten.

Eine Adresse pro Testfall löst das. Protokolle, Screenshots und E-Mails passen zusammen, und eine fehlende Nachricht weist auf ein Szenario hin statt auf alle. Der Leitfaden zu Betrieb mehrerer temporärer Posteingänge behandelt diesen Workflow ausführlicher.

Manche Abläufe benötigen Tage später wieder dieselbe Adresse, etwa eine Testversion, die in ein Abo übergeht, oder ein Nutzer, der nach der Abwanderung zurückkehrt. Eine wiederverwendbare temporäre Mail-Adresse hält die Adresse über ihren Access Token verfügbar, nicht aber die Nachrichten. Speichere die Links und Codes, die du brauchst, während jeder Schritt läuft, und verlege jeden Schritt, der von älteren Nachrichten abhängt, in ein Firmenpostfach. Wenn sich ein Tester in einem kostenlosen Tmailor-Konto anmeldet, bevor er Persona-Adressen erstellt, wird jede davon unter „Created Emails“ gespeichert, sodass ein verlorener Token nicht mehr eine verlorene Adresse bedeutet.

Was in Anmelde- und Onboarding-E-Mails zu prüfen ist

Beginne mit einer Bestandsaufnahme aller E-Mails, die der Ablauf senden kann, und lege dann fest, was jeder Test prüfen soll. Teams entdecken zusätzliche E-Mails oft erst, wenn sie mitten im Test auftauchen, nachdem ein Wachstumsexperiment oder eine Sicherheitsänderung eine hinzugefügt hat, die niemand dokumentiert hatte.

E-Mails in einem typischen Anmeldeablauf

• Bestätigungslink oder Einmalcode
• Willkommens-E-Mail und jede Quick-Start-Sequenz
• Anmeldung per Magic Link
• Passwort zurücksetzen
• Änderung der E-Mail-Adresse, gesendet an die alte und die neue Adresse
• Sicherheitswarnung bei neuem Gerät oder neuem Standort
• Erinnerungen an Anmeldungen, die nie abgeschlossen wurden

Notiere für jede E-Mail den Auslöser, den erwarteten Zeitpunkt und die Bedingungen, die ihn verändern, etwa Tarif, Region oder Sprache. Lege das zulässige Zustellfenster anhand der dokumentierten Anforderung deines Produkts fest, statt eine allgemeingültige Schwelle anzunehmen; eine sofortige Bestätigungsnachricht und eine geplante Willkommenssequenz erfordern unterschiedliche Erwartungen. Sobald diese Erwartungen feststehen, hat jeder Test einen konkreten Maßstab zum Prüfen.

Was in jeder Test-E-Mail geprüft werden sollte

• Absender und Empfänger: Name und Adresse des Absenders, Reply-To und die genaue To-Adresse.
• Betreff und Text: sowohl die HTML- als auch die Klartextversion, mit korrekten Namen, Tarifdetails und Sprache.
• Links: das Ziel und ob es auf die richtige Umgebung zeigt. Eine Staging-E-Mail, die auf die Produktion verlinkt, ist ein echter Bug.
• Codes: Format, Länge, Hinweis zum Ablauf und ob der angegebene Ablauf mit dem übereinstimmt, was der Server durchsetzt.
• Timing: wie lange die Nachricht nach dem Auslöser gebraucht hat.
• Anhänge: Wenn ein Ablauf ein PDF oder eine Rechnung sendet, testen Sie dies in einem Firmenpostfach oder einem Testtool. Tmailor empfängt keine Anhänge.

Eine Warnung zum Rendering. Ein temporärer Posteingang zeigt, wie ein Webbrowser Ihr HTML darstellt. Er zeigt Ihnen nicht, wie dieselbe E-Mail in Gmail, Outlook, Apple Mail, im Dunkelmodus oder auf einem kleinen Handybildschirm aussieht. Planen Sie daher separate Rendering-Prüfungen, falls das relevant ist.

E-Mail-Änderung und Kontowiederherstellung

Wiederherstellungsabläufe gehen auf leisere Weise kaputt als die Anmeldung. Prüfen Sie, ob eine E-Mail-Änderung eine Bestätigung an die neue Adresse und einen Hinweis an die alte sendet, ob ein verwendeter Reset-Link nicht erneut verwendet werden kann, ob ein älterer Reset-Link nach dem Versand eines neueren nicht mehr funktioniert und ob ein auf einem zweiten Gerät geöffneter Link den Nutzer in einen sinnvollen Zustand bringt. OTP-Abläufe verdienen eine separate Risikoprüfung; der OTP-Risiko-Checkliste für QA und UAT behandelt Kennzahlen, Zeitfenster für erneutes Senden und Zuständigkeit.

Wie man OTP- und Verifizierungs-Randfälle testet

Testen Sie OTP- und Verifizierungsabläufe auf verzögerte Zustellung, erneutes Senden, abgelaufene und falsche Codes sowie Links, die auf einem anderen Gerät geöffnet werden. Jeder Fall sollte sowohl das Serverergebnis als auch die dem Nutzer angezeigte Nachricht prüfen. Führen Sie diese Tests nur auf Systemen durch, die Ihnen gehören oder die Sie testen dürfen. Gute OTP-Tests unterbrechen den Ablauf absichtlich:

• Langsame Zustellung: Warten Sie, bevor Sie den Posteingang prüfen, und bestätigen Sie, dass die Benutzeroberfläche erklärt, was passiert, und eine klare Möglichkeit zum erneuten Senden bietet.
• Verhalten beim erneuten Senden: Fordern Sie einen zweiten Code an und prüfen Sie, ob der erste ungültig wird oder weiterhin akzeptiert wird.
• Ablauf: Geben Sie einen Code nach Ablauf seiner angegebenen Lebensdauer ein und bestätigen Sie, dass die Fehlermeldung zum tatsächlichen Verhalten passt.
• Falscher Code: Bestätigen Sie, dass das Versuchslimit und der Hinweis zur Wartezeit für einen Menschen nachvollziehbar sind.
• Geräteübergreifende Magic-Links: Fordern Sie einen Link auf einem Laptop an, öffnen Sie ihn auf einem Handy und prüfen Sie, wo der Nutzer landet.

Für einen umfassenderen Überblick darüber, welche Codes einen temporären Posteingang erreichen und welche nicht, siehe diesen Leitfaden zu temporärer E-Mail für OTP-Codes.

Wenn Ihr Produkt Wegwerf-E-Mail-Domains bewusst ablehnt, testen Sie diesen Pfad direkt. Bestätigen Sie, dass die Ablehnungsmeldung klar ist und dass eine echte oder vom Unternehmen kontrollierte Adresse die Anmeldung weiterhin abschließen kann. Wechseln Sie nicht durch andere temporäre Domains, um die Sperre zu umgehen – weder bei Ihrem eigenen Produkt noch bei einem anderen. Zu bestätigen, dass die Sperre funktioniert, ist der Test; sie zu umgehen nicht. Diese Erklärung zu warum Websites temporäre Mail-Domains blockieren, behandelt die Gründe hinter diesen Filtern.

Was sich ändert, wenn E-Mail-Tests unbeaufsichtigt laufen

Wenn niemand zuschaut, braucht der Test einen Posteingang, den er per Code lesen kann. Das bedeutet eine API eines SMTP-Catchers oder eine gehostete Inbox-API. Der Tmailor-Web-Posteingang ist nicht dieses Werkzeug, die Tmailor Temp Mail API aber schon: Tests können reine Empfangsadressen erstellen, Nachrichten auflisten und lesen sowie den Einmalcode oder Verifizierungslink abrufen, den die API findet. Ein MCP-Server ermöglicht KI-Agenten wie Claude, Cursor oder VS Code Copilot, dasselbe für Anmeldeabläufe zu tun, die Ihnen gehören oder die Sie testen dürfen.

Ein paar Gewohnheiten halten unbeaufsichtigte E-Mail-Tests stabil, egal für welches Tool Sie sich entscheiden:

• Geben Sie jedem Testlauf eine eigene Adresse und eine Korrelations-ID, damit eine verspätete E-Mail aus einem früheren Lauf nicht die falsche Prüfung erfüllen kann.
• Verwenden Sie ein eigenes Warten auf die E-Mail-Ankunft mit sinnvollem Backoff, getrennt vom gesamten Test-Timeout, und protokollieren Sie, wie lange jede Nachricht gebraucht hat.
• Ordnen Sie die exakte Nachricht nach Empfänger und Betreff zu, statt „die neueste E-Mail“ zu lesen.
• Maskieren Sie Codes und Magic Links in CI-Logs, da Logs oft länger bestehen als der Posteingang.

Seien Sie sich auch darüber im Klaren, was ein bestandener Test beweist. „Die App hat die E-Mail erzeugt und übergeben“, „eine gehostete Testdomain hat sie über die öffentliche E-Mail-Infrastruktur empfangen“ und „Gmail hat sie im Posteingang abgelegt, nicht im Spam“ sind drei verschiedene Fakten. Ein SMTP-Catcher beweist den ersten, eine gehostete Inbox-API die ersten beiden, und keiner beweist den dritten. Zur Pipeline-Einrichtung auf GitHub Actions, GitLab CI und CircleCI siehe den Leitfaden zu E-Mail-Testing in CI/CD-Pipelines.

Testdaten sicher halten und die Regeln einhalten

Verwenden Sie synthetische Identitäten und nicht sensible Inhalte in temporären Testposteingängen und führen Sie Anmeldetests nur gegen Systeme durch, die Ihnen gehören oder die Sie bewerten dürfen. Halten Sie QA-Konten aus der Produktionsanalyse heraus, beachten Sie Ratenlimits und verlagern Sie regulierte Daten, Zugangsdaten, Anhänge und aufbewahrte Nachweise in genehmigte, vom Unternehmen kontrollierte Systeme.

• Keine echten Daten in einem temporären Posteingang. Leiten Sie niemals echte Kundendatensätze, Zugangsdaten, API-Schlüssel oder regulierte Daten an eine temporäre E-Mail-Adresse weiter. Verwenden Sie synthetische Nutzer mit offensichtlich falschen Namen.
• Testen Sie nur, was Sie testen dürfen. Führen Sie Anmeldetests gegen Ihr eigenes Produkt oder ein System durch, das Sie testen dürfen, und beachten Sie die Ratenlimits und Bedingungen dieses Dienstes. Verwenden Sie temporäre E-Mail nicht, um auf Websites Dritter massenhaft Konten zu erstellen. Volumen- und Lasttests gehören in Ihre eigene Staging-Umgebung, mit einem SMTP-Catcher oder einer gehosteten Inbox-API.
• Halten Sie QA-Traffic aus den Produktionszahlen heraus. Kennzeichnen Sie Testkonten klar und schließen Sie sie aus Analysen und Wachstums-Dashboards aus. Vermeiden Sie es, große Mengen an Testmails von Ihrer Produktions-Versanddomain zu senden, wo Bounces und Beschwerden deren Reputation schädigen können.
• Schreiben Sie die Richtlinie auf. Legen Sie fest, welche Abläufe einen temporären Posteingang nutzen dürfen, welche ein Firmenpostfach benötigen, wie lange Testdaten aufbewahrt werden und wer Zugriff hat. Sicherheits- und Compliance-Prüfungen laufen schneller, wenn die Grenzen bereits schriftlich festgehalten sind.

Wenn die Sicherheitsabteilung fragt, wie ein Anbieter mit Daten umgeht, prüfen Sie, was er erfasst, wie lange er Nachrichten speichert und wie der Zugriff funktioniert. Dieser Überblick zu temporäre E-Mail und Online-Privatsphäre behandelt diese Fragen aus Nutzersicht. Die Entscheidung, welche Abläufe Wegwerf-Posteingänge nutzen dürfen, liegt weiterhin bei Ihren eigenen Rechts-, Datenschutz- und Sicherheitsteams.

Grenzen, die Sie einplanen sollten

Der Tmailor-Web-Posteingang eignet sich für kurze manuelle Prüfungen nicht sensibler eingehender E-Mails (für die Automatisierung ist die Temp Mail API da). Bevor Sie sich dafür entscheiden, klären Sie, ob der Workflow ausgehende Aktionen, Anhänge, langfristig aufbewahrte Nachweise oder eine dauerhafte Wiederherstellung der Adresse erfordert. Jede dieser Anforderungen verlangt ein vom Unternehmen kontrolliertes Postfach oder ein spezialisiertes Testwerkzeug; die folgende Checkliste erklärt, warum.

• Tmailor ist reiner Empfang. Es kann eingehende Anmelde-, Verifizierungs- und OTP-Mails prüfen, aber keine Antwortabläufe oder irgendetwas, das von der Adresse aus versendet wird.
• Tmailor empfängt keine Anhänge, daher benötigen E-Mails zu Rechnungen, Verträgen oder Dokumentenzustellungen ein Firmenpostfach oder ein Testwerkzeug.
• Nachrichten bleiben etwa 24 Stunden ab Ankunft erhalten. Exportieren Sie die Links, Codes und Zeitstempel, die eine längere Untersuchung benötigt.
• Ein Access Token öffnet eine Adresse erneut, jedoch keine abgelaufenen Nachrichten, und ein verlorenes Token kann nicht wiederhergestellt werden.
• Der Web-Posteingang wird von einer Person gelesen. Für unbeaufsichtigtes Lesen des Posteingangs braucht man einen SMTP-Catcher oder eine gehostete Postfach-API, etwa die Tmailor Temp Mail API.
• Einige Dienste blockieren Wegwerf-E-Mail-Domains. Wenn ein von dir getesteter Flow dies absichtlich tut, prüfe ihn mit einer echten oder firmenkontrollierten Adresse.

Den richtigen Testposteingang auswählen

Wähle den Posteingang danach, was der Test beweisen muss. Verwende eine reservierte Beispieldomain, wenn keine Zustellung nötig ist, einen temporären Posteingang für manuelle, nicht sensible Prüfungen, ein Firmenpostfach für aufzubewahrende oder sensible Abläufe, einen SMTP-Catcher, wenn du die Einstellungen für ausgehende E-Mails kontrollierst, und eine gehostete Postfach-API für unbeaufsichtigte End-to-End-Tests.

Für die manuellen Fälle öffne einen temporären Posteingang und beginne mit dem Anmeldeablauf, den du als Nächstes auslieferst. Temporäre E-Mail bietet auch viele praktische Anwendungen über QA hinaus.