Hoe kies je een test-e-mailaccount voor QA

Wat is een test-e-mailaccount voor QA?

Een test-e-mailaccount, of test-e-mailadres voor QA, is een adres dat je team gebruikt om de e-mails die je eigen applicatie verstuurt te ontvangen en te inspecteren. Gebruik een tijdelijke inbox voor handmatige, niet-gevoelige aanmeldings- en OTP-controles. Kies een bedrijfsmailbox voor bewaarde berichten, antwoorden of bijlagen, en een SMTP-sandbox of gehoste inbox-API wanneer geautomatiseerde tests e-mail moeten inspecteren zonder dat er een persoon aan te pas komt.

Tmailor beheert deze blog, dus dit is waar het past. Tmailor is een gratis tijdelijke e-maildienst die alleen kan ontvangen, op het web, Android, iOS en via een Telegram-bot. Het past bij het eerste geval: iemand opent een inbox, start een aanmelding en leest wat er binnenkomt. Voor het laatste geval laat de aparte Tmailor Temp Mail API geautomatiseerde tests alleen-ontvangende adressen aanmaken en hun berichten vanuit code lezen. Berichten blijven ongeveer 24 uur na aankomst staan, bijlagen worden niet ontvangen en het adres kan niet verzenden of beantwoorden. Als je nieuw bent met wegwerp-inboxen, begin dan met hoe tijdelijke e-mail werkt.

• Er hoeft geen e-mail aan te komen (formuliervalidatie, fixtures, unit tests): gebruik een gereserveerd voorbeelddomein.
• Een persoon leest de e-mail en er staat niets gevoeligs in: een tijdelijke inbox is de snelste optie.
• Gevoelige gegevens, antwoorden, bijlagen of bewijs dat je moet bewaren: gebruik een goedgekeurde mailbox die door het bedrijf wordt beheerd; voeg alleen plus-tags toe als je e-mailsysteem en applicatie ze ondersteunen.
• Niemand kijkt mee: gebruik een SMTP-catcher als je de instellingen voor uitgaande e-mail van de app beheert, of een gehoste inbox-API als de app via de normale provider moet verzenden.

Handmatig versus geautomatiseerd e-mailtesten: een beslisboom

Vier vragen bepalen welk test-e-mailaccount een controle nodig heeft: of er überhaupt een e-mail moet aankomen, of een persoon of code die leest, of die gevoelige gegevens bevat, en of jij bepaalt waar de applicatie haar uitgaande e-mail naartoe stuurt.

1. Moet er voor de test een e-mail aankomen? Formaatcontroles, UI-statussen, fixtures en unit tests meestal niet. Gebruik adressen op example.com, example.org of example.net. Die domeinen zijn gereserveerd voor documentatie en voorbeelden, dus niets bereikt een echt persoon. Vermijd het verzinnen van willekeurige domeinen, want iemand anders kan ze bezitten.
2. Leest een persoon het bericht tijdens de test? Smoke tests, handmatige UAT, demo's en verkennende sessies hebben een mens in de loop. Regressiesuites en CI-jobs meestal niet.
3. Als een persoon het leest, staat er dan iets gevoeligs in? Echte klantgegevens, inloggegevens, gereguleerde gegevens of berichten die je als auditbewijs moet bewaren, horen niet in een tijdelijke inbox. Gebruik in plaats daarvan een bedrijfsmailbox. Als het antwoord nee is, is een tijdelijke inbox voldoende.
4. Als code het leest, kan de testomgeving haar e-mail dan naar een test-SMTP-server sturen? Zo ja, dan vangt een SMTP-catcher elk bericht op zonder het te bezorgen. Zo niet, omdat de app via haar normale e-mailprovider moet verzenden, gebruik dan een gehoste inbox die je tests via een API lezen.

De tabel vergelijkt de vijf opties naast elkaar.

Welke adressen moet een e-mailveld accepteren of weigeren?

Test formuliervalidatie los van berichtaflevering. Gebruik een gereserveerd adres zoals user@example.com voor een geldig ogend geval dat nooit wordt afgeleverd, voeg een adres met een plus-tag en een met een subdomein toe, en voeg ongeldige gevallen toe zoals een ontbrekend lokaal deel of een ontbrekend domein. Houd de verwachte resultaten in lijn met de validator die je productiesysteem daadwerkelijk gebruikt.

Wanneer een tijdelijke inbox genoeg is

Een tijdelijke inbox werkt wanneer iemand één flow tegelijk controleert en het bericht niets bevat dat je na een dag kwijt zou willen zijn. Dat is het klassieke gebruik van een wegwerp-e-mail voor QA: je hebt een e-mailadres nodig om een formulier handmatig te testen, niet een langdurig account. Typische gevallen zijn een rooktest van het aanmeldformulier vóór de release, een handmatige UAT-ronde van een nieuwe onboarding-e-mail, een verkoopdemo van accountaanmaak, of een verkennende sessie waarin je vreemde invoer probeert en kijkt wat de app verstuurt.

Het voordeel is snelheid. Je hoeft geen account bij IT aan te vragen en er is geen gedeelde mailbox om op te ruimen. De keerzijde is controle: je krijgt een kort berichtvenster, geen bijlagen en een inbox die een persoon leest in plaats van code.

Wanneer je een SMTP-catcher of een gehoste inbox-API nodig hebt

Zodra tests onbeheerd draaien, moet de inbox door code leesbaar zijn. Twee soorten tools dekken die behoefte, en ze lossen verschillende problemen op.

SMTP-catchers en sandboxes vervangen de uitgaande mailserver van je app in een testomgeving en bewaren elk bericht ter inspectie in plaats van het af te leveren.

• Mailpit is een gratis, opensource-tool die je zelf draait. Het vangt standaard e-mail op en biedt een webinterface en een REST API voor integratietests.
• MailHog werkt op dezelfde manier, maar is ouder. De beheerders van Mailpit beschrijven het als niet langer onderhouden, dus controleer de status voordat je het in gebruik neemt.
• Mailtrap Email Sandbox is een gehoste versie van hetzelfde idee, met SMTP- en API-toegang. Het staat los van het productieproduct van Mailtrap voor het verzenden van e-mail.
• Ethereal is een gratis nep-SMTP-dienst die vooral met Nodemailer wordt gebruikt. Berichten worden opgevangen om ze te bekijken en worden nooit afgeleverd.

Gehoste inbox-API's geven tests echte adressen op de domeinen van de leverancier, zodat je app e-mail via de normale provider verstuurt en de test het resultaat via een API uitleest. Tmailors eigen Temp Mail API werkt op deze manier, met officiële SDK's voor Python, Node.js en PHP.

• Mailosaur biedt test-e-mailadressen, een API en clientbibliotheken die werken met frameworks zoals Cypress, Playwright en Selenium. Het ondersteunt ook sms-codes.
• MailSlurp maakt inboxen op aanvraag aan via zijn API en SDK's. Tests kunnen op een bericht wachten en vervolgens codes, links en bijlagen eruit halen.

Functies en abonnementen van leveranciers veranderen, dus controleer de actuele gegevens op elke officiële site voordat je een testsuite aan één leverancier vastlegt.

Wanneer een bedrijfsmailbox met plustags de betere keuze is

Met plustags kan één bedrijfsmailbox veel adresvariaties accepteren. E-mail naar qa+signup of qa+reset op je bedrijfsdomein komt aan in de qa-mailbox, waar je deze op tag kunt filteren. Google Workspace ondersteunt dit, en Microsoft documenteert dat plusadressering in Exchange Online standaard aan staat, tenzij een beheerder het uitschakelt.

Gebruik deze route wanneer een flow echte klantgegevens bevat, langer dan een dag duurt, antwoorden of bijlagen nodig heeft, of bewijs oplevert waar een auditor om kan vragen. Houd de beperkingen in gedachten. Tags zijn variaties van één mailbox, geen aparte inboxen, dus parallelle tests kunnen elkaars berichten lezen. Sommige aanmeldformulieren weigeren het plusteken, en sommige apps behandelen getagde varianten als hetzelfde account. Beide gedragingen zijn een eigen testcase waard.

Hoe voer je een handmatige aanmeldtest uit met een tijdelijke inbox

Een handmatige aanmeldtest met tijdelijke e-mail voor tests vereist drie dingen: een nieuw adres, de build die je test, en een plek buiten de inbox om vast te leggen wat er is aangekomen. Voer de test alleen uit op systemen die je bezit of waarvoor je toestemming hebt om te testen.

1. Open een inbox. Maak een gratis tijdelijke inbox op het web, of gebruik de Tmailor-app of Telegram-bot en kopieer het adres. Op een desktop kan de Tmailor-browserextensie het ook invullen in het e-mailveld van je testbuild.
2. Meld je aan op je testbuild. Gebruik het adres in je staging- of QA-omgeving en noteer het tijdstip waarop je het formulier hebt ingediend.
3. Let op de e-mail. Controleer welk bericht is aangekomen, de naam van de afzender en het Van-adres, het onderwerp en hoe lang het duurde.
4. Voltooi de stap. Klik op de link of voer de code in. Bevestig dat het account één keer van status verandert en dat het hergebruiken van dezelfde link mislukt met een duidelijke melding.
5. Leg het bewijs elders vast. Kopieer de link, code, tijdstempels en een screenshot naar je testcase. Berichten blijven ongeveer 24 uur na aankomst bewaard, dus de inbox is niet je testregistratie.
6. Bewaar de access token als je opnieuw wilt testen. De token opent later hetzelfde adres weer, bijvoorbeeld om een wachtwoordreset opnieuw uit te voeren. Het herstelt geen berichten die al zijn verlopen, en een verloren token kan niet worden hersteld.

Wanneer een sessie meerdere persona's tegelijk nodig heeft, zoals een gratis gebruiker, een proefgebruiker en een uitgenodigde teamgenoot, houdt de weergave van meerdere inboxen tot vijf adressen naast elkaar in één browsertabblad. Elke persona krijgt een eigen adres, zodat je kunt zien welke e-mail bij welk account hoort.

Deze weergave is nog steeds handmatig. De inboxen worden door een persoon in een browser aangemaakt, niet via code ingericht, dus het vervangt geen gehoste inbox-API voor parallelle onbewaakte runs.

Eén inbox of één adres per test?

Eén gedeelde inbox is prima voor een snelle rooktest, maar wordt al snel rommelig. Zodra er meerdere tests tegelijk lopen, maken vergelijkbare onderwerpregels het lastig te bepalen welke e-mail bij welk script hoort, en wordt debuggen giswerk.

Eén adres per testcase lost dat op. Logs, screenshots en e-mails sluiten op elkaar aan, en een ontbrekend bericht wijst naar één scenario in plaats van naar allemaal. De gids voor het beheren van meerdere tijdelijke mailinboxen behandelt die workflow in meer detail.

Sommige journeys hebben hetzelfde adres dagen later weer nodig, zoals een proefperiode die overgaat in een betaald abonnement of een gebruiker die terugkomt na churn. Een herbruikbaar tijdelijk mailadres houdt het adres beschikbaar via het Access Token, maar niet de e-mail. Sla de links en codes die je nodig hebt op terwijl elke stap loopt, en verplaats elke stap die afhankelijk is van oudere berichten naar een bedrijfsmailbox. Als een tester inlogt bij een gratis Tmailor-account voordat hij persona-adressen aanmaakt, wordt elk adres opgeslagen onder Created Emails, dus een verloren token betekent niet langer een verloren adres.

Wat je moet controleren in aanmeld- en onboarding-e-mails

Begin met een inventarisatie van elke e-mail die de journey kan versturen en bepaal vervolgens wat elke test moet controleren. Teams ontdekken vaak pas extra e-mails wanneer ze midden in een test opduiken, na een groeiexperiment of een beveiligingswijziging die niemand had vastgelegd.

E-mails in een typische aanmeldingsjourney

• Verificatielink of eenmalige code
• Welkomstmail en een eventuele quickstart-reeks
• Inloggen met magic link
• Wachtwoord opnieuw instellen
• Wijziging van e-mailadres, verzonden naar zowel het oude als het nieuwe adres
• Beveiligingsmelding bij nieuw apparaat of nieuwe locatie
• Herinneringen voor aanmeldingen die nooit zijn afgerond

Noteer voor elk daarvan de trigger, de verwachte timing en de omstandigheden die die veranderen, zoals abonnement, regio of taal. Stel het toegestane leveringsvenster in op basis van de gedocumenteerde eis van je product in plaats van een universele drempel aan te nemen; een directe verificatiemelding en een geplande welkomstreeks vragen om verschillende verwachtingen. Zodra die verwachtingen er zijn, heeft elke test iets concreets om tegen te controleren.

Wat je in elke testmail moet controleren

• Afzender en ontvanger: de naam en het adres van de afzender, de Reply-To en het exacte adres van de ontvanger.
• Onderwerp en berichttekst: zowel de HTML- als de platte tekstversie, met correcte namen, abonnementsgegevens en taal.
• Links: de bestemming en of deze naar de juiste omgeving verwijst. Een staging-e-mail die naar productie linkt, is een echte bug.
• Codes: het formaat, de lengte, de tekst over de vervaldatum en of de opgegeven vervaldatum overeenkomt met wat de server afdwingt.
• Timing: hoe lang het duurde voordat het bericht na de trigger aankwam.
• Bijlagen: als een flow een PDF of factuur verstuurt, test dit dan in een bedrijfsmailbox of een testtool. Tmailor ontvangt geen bijlagen.

Eén waarschuwing over weergave. Een tijdelijke inbox laat zien hoe één webviewer je HTML weergeeft. Het zegt niets over hoe dezelfde e-mail eruitziet in Gmail, Outlook, Apple Mail, donkere modus of op een klein telefoonscherm, dus plan aparte weergavecontroles als dat belangrijk is.

E-mailwijziging en accountherstel

Herstelstromen gaan op subtielere manieren mis dan aanmelden. Controleer of een e-mailwijziging een bevestiging naar het nieuwe adres en een melding naar het oude adres stuurt, of een gebruikte resetlink niet opnieuw kan worden gebruikt, of een oudere resetlink stopt met werken nadat een nieuwere is verzonden, en of een link die op een tweede apparaat wordt geopend de gebruiker in een logische toestand brengt. OTP-flows verdienen een aparte risicobeoordeling; de OTP-risicochecklist voor QA en UAT behandelt statistieken, termijnen voor opnieuw verzenden en eigenaarschap.

Hoe je OTP- en verificatie-randgevallen test

Test OTP- en verificatieflows op vertraagde levering, opnieuw verzenden, verlopen en onjuiste codes, en links die op een ander apparaat worden geopend. Bij elke case moet je zowel het serverresultaat als het bericht dat de gebruiker te zien krijgt controleren. Voer deze tests alleen uit op systemen die je bezit of waarvoor je bevoegd bent om te testen. Goede OTP-tests doorbreken de flow bewust:

• Trage aankomst: wacht voordat je de inbox controleert en bevestig dat de interface uitlegt wat er gebeurt en een duidelijke manier biedt om opnieuw te verzenden.
• Gedrag bij opnieuw verzenden: vraag een tweede code aan en controleer of de eerste ongeldig wordt of nog steeds wordt geaccepteerd.
• Vervaldatum: voer een code in na de opgegeven levensduur en bevestig dat de foutmelding overeenkomt met wat er is gebeurd.
• Verkeerde code: bevestig dat de poginglimiet en de tekst over de cooldown logisch zijn voor een gebruiker.
• Magische links op meerdere apparaten: vraag een link aan op een laptop, open deze op een telefoon en controleer waar de gebruiker terechtkomt.

Voor een breder beeld van welke codes een tijdelijke inbox wel en niet bereiken, zie deze gids over tijdelijke e-mail voor OTP-codes.

Als je product wegwerp-e-maildomeinen bewust afwijst, test dan dat pad direct. Controleer of de afwijzingsmelding duidelijk is en of een echt of door het bedrijf beheerd adres de aanmelding nog steeds kan afronden. Ga niet langs andere tijdelijke domeinen om de blokkade te omzeilen, niet bij je eigen product en niet bij dat van iemand anders. Bevestigen dat de blokkade werkt is de test; haar omzeilen is dat niet. Deze uitleg over waarom websites tijdelijke maildomeinen blokkeren, behandelt de redenen achter die filters.

Wat verandert er wanneer e-mailtests onbeheerd worden uitgevoerd

Wanneer niemand meekijkt, heeft de test een inbox nodig die hij via code kan uitlezen. Dat betekent een API van een SMTP-catcher of een API van een gehoste inbox. De webinbox van Tmailor is dat hulpmiddel niet, maar de Tmailor Temp Mail API wel: tests kunnen alleen-ontvangen adressen aanmaken, berichten opvragen en lezen, en de eenmalige code of verificatielink ophalen die de API vindt. Een MCP-server laat AI-agenten zoals Claude, Cursor of VS Code Copilot hetzelfde doen voor aanmeldingsstromen die je bezit of mag testen.

Een paar gewoonten houden onbeheerde e-mailtests stabiel, ongeacht welk hulpmiddel je kiest:

• Geef elke testrun een eigen adres en een correlatie-ID, zodat een late e-mail van een eerdere run niet aan de verkeerde assertie kan voldoen.
• Gebruik een aparte wachttijd op de aankomst van e-mail met een verstandige backoff, los van de algehele testtimeout, en log hoe lang elk bericht erover deed.
• Koppel het exacte bericht aan ontvanger en onderwerp in plaats van "de laatste e-mail" te lezen.
• Maskeer codes en magic links in CI-logs, omdat logs vaak langer bewaard blijven dan de inbox.

Wees ook duidelijk over wat een geslaagde test bewijst. "De app heeft de e-mail gegenereerd en overgedragen", "een gehost testdomein heeft hem ontvangen via de openbare e-mailinfrastructuur" en "Gmail heeft hem in de inbox geplaatst, niet in spam" zijn drie verschillende feiten. Een SMTP-catcher bewijst het eerste, een API van een gehoste inbox bewijst de eerste twee, en geen van beide bewijst het derde. Voor het opzetten van een pipeline op GitHub Actions, GitLab CI en CircleCI, zie de gids over e-mailtesten in CI/CD-pipelines.

Houd testgegevens veilig en blijf binnen de regels

Gebruik synthetische identiteiten en niet-gevoelige inhoud in tijdelijke testinboxen, en voer aanmeldingstests alleen uit op systemen die je bezit of waarvoor je bevoegd bent ze te beoordelen. Houd QA-accounts buiten productieanalyses, respecteer snelheidslimieten en verplaats gereguleerde gegevens, inloggegevens, bijlagen en bewaard bewijs naar goedgekeurde, door het bedrijf beheerde systemen.

• Geen echte gegevens in een tijdelijke inbox. Stuur nooit echte klantgegevens, inloggegevens, API-sleutels of gereguleerde gegevens naar een tijdelijk e-mailadres. Gebruik synthetische gebruikers met overduidelijk verzonnen namen.
• Test alleen wat je mag testen. Voer aanmeldingstests uit op je eigen product of een systeem dat je bevoegd bent te testen, en respecteer de snelheidslimieten en voorwaarden van die dienst. Gebruik tijdelijke e-mail niet om in bulk accounts aan te maken op sites van derden. Volume- en belastingstests horen thuis in je eigen staging-omgeving, met een SMTP-catcher of een API van een gehoste inbox.
• Houd QA-verkeer buiten de productiecijfers. Label testaccounts duidelijk en sluit ze uit van analytics- en groeidashboards. Vermijd het versturen van grote hoeveelheden testmail vanaf je productiedomein, waar bounces en klachten de reputatie kunnen schaden.
• Leg het beleid vast. Geef aan welke stromen een tijdelijke inbox mogen gebruiken, welke een bedrijfsmailbox nodig hebben, hoe lang testgegevens worden bewaard en wie toegang heeft. Beveiligings- en compliancebeoordelingen verlopen sneller wanneer de grenzen al op papier staan.

Wanneer beveiliging vraagt hoe een provider met gegevens omgaat, kijk dan naar wat hij verzamelt, hoe lang berichten worden bewaard en hoe toegang werkt. Dit overzicht van tijdelijke e-mail en online privacy behandelt die vragen vanuit het perspectief van de gebruiker. De beslissing over welke stromen wegwerpinboxen mogen gebruiken, blijft bij je eigen juridische, privacy- en beveiligingsteams.

Beperkingen om rekening mee te houden

De webinbox van Tmailor is geschikt voor korte handmatige controles van niet-gevoelige inkomende e-mail (voor automatisering is de Temp Mail API bedoeld). Bepaal voordat je ervoor kiest of de workflow uitgaande acties, bijlagen, langdurig bewaard bewijs of duurzaam herstel van het adres nodig heeft. Elk van die vereisten vraagt om een door het bedrijf beheerde mailbox of een gespecialiseerd testhulpmiddel; de onderstaande checklist legt uit waarom.

• Tmailor is alleen-ontvangen. Het kan inkomende aanmeldings-, verificatie- en OTP-mail controleren, maar geen antwoordstromen of iets dat vanaf het adres wordt verzonden.
• Tmailor ontvangt geen bijlagen, dus e-mails met facturen, contracten of documenten hebben een bedrijfsmailbox of een testhulpmiddel nodig.
• Berichten blijven ongeveer 24 uur na aankomst bewaard. Exporteer de links, codes en tijdstempels die een langer onderzoek nodig heeft.
• Een access token heropent een adres, niet verlopen berichten, en een verloren token kan niet worden hersteld.
• De webinbox wordt door een persoon gelezen. Voor onbewaakt inbox-lezen is een SMTP-catcher of een gehoste inbox-API nodig, zoals de Tmailor Temp Mail API.
• Sommige diensten blokkeren domeinen voor wegwerp-e-mail. Als een flow die je test dit expres doet, valideer het dan met een echt of door het bedrijf beheerd adres.

De juiste testinbox kiezen

Kies de inbox op basis van wat de test moet bewijzen. Gebruik een gereserveerd voorbeelddomein wanneer levering niet nodig is, een tijdelijke inbox voor handmatige niet-gevoelige controles, een bedrijfsmailbox voor trajecten die bewaard moeten blijven of gevoelig zijn, een SMTP-catcher wanneer je de uitgaande instellingen beheert, en een gehoste inbox-API voor onbewaakte end-to-end tests.

Voor de handmatige gevallen open je een tijdelijke inbox en begin je met de aanmeldingsflow die je als volgende uitbrengt. Tijdelijke e-mail heeft ook volop praktische toepassingen naast QA.