Varför testare använder en tillfällig inkorg
Nästan alla applikationer skickar mejl: orderbekräftelser, engångskoder, fakturor, bokningar, påminnelser och aviseringar. Mejlen är en del av produkten, och de går sönder oftare än man tror. Länken pekar mot testmiljön. Koden kommer först när den redan har gått ut. Avsändaren visas som ett rått servernamn som ip-10-0-3-17.internal. Ingen märker något förrän en riktig kund hör av sig.
Att testa med din egen Gmail eller Outlook håller inte i längden. Plus-adresserna tar slut, inkorgen fylls av testskräp och det är krångligt att ge adressen till en kollega. En tillfällig inkorg löser det: öppna sidan, kopiera adressen, använd den i din applikation och se mejlet komma i realtid. När du är klar behöver du inte göra något mer. Allt raderas automatiskt efter 7 dagar.
Eftersom det är en riktig inkorg på en riktig domän skickar din applikation mejlet med vanlig SMTP, precis som till en kund. Du testar hela vägen, från din kod via din e-posttjänst och DNS till leveransen, och ingen mock.
Så testar du din applikations mejl på under en minut
- Kopiera adressen högst upp på sidan.
- Använd den i din applikation (lokalt, i test eller i produktion) där ett mejl skickas: registrering, beställning, bokning, betalning, avisering.
- Håll koll på inkorgen. Mejlet dyker upp utan att du behöver ladda om, oftast inom några sekunder.
- Kontrollera mejlet: avsändare, ämnesrad, innehåll, varje länk och varje kod.
- Klicka på länkarna eller använd koden för att gå igenom hela flödet och se att varje steg fungerar.
Exempel: testa ett mobilabonnemang med eSIM före release
Säg att du jobbar med QA hos en mobiloperatör och att nästa veckas release ändrar hur kunder tecknar abonnemang på nätet. Kunden väljer abonnemang, fyller i sin e-postadress, betalar, och därefter sker nästan allt via mejl. Varje mejl måste stämma från dag ett, för en felaktig länk betyder en kund som inte kan aktivera sitt eSIM.
Med en tillfällig inkorg går du igenom hela kundresan som ny kund, i testmiljön, innan det går live:
- Teckna ett abonnemang i testmiljön med adressen från den här sidan.
- Bekräfta e-postadressen med koden i mejlet.
- Kontrollera orderbekräftelsen: rätt abonnemang, månadspris inklusive moms, bindningstid och ordernummer.
- Kontrollera mejlet efter identifieringen med BankID: står det tydligt vad kunden ska göra härnäst?
- Kontrollera eSIM-mejlet: QR-koden syns, har alt-text, och aktiveringslänken pekar mot produktion, inte mot en testserver.
- Upprepa för varje abonnemangstyp (kontantkort, abonnemang, familjeabonnemang) i en ny flik, så att varje testkund får en egen inkorg.
Samma sak gäller i alla branscher där en kundhandling följs av mejl: banker, försäkringsbolag, e-handel, resebokningar och provperioder för SaaS. Testa varje mejl kunden kommer att få före release, inte efter det första klagomålet.
Buggar du hittar före dina användare
- Testlänkar i produktionsmejl. En bas-URL från fel miljö. Mycket vanligt, och osynligt tills någon klickar.
- Koder som går ut för snabbt. Mejlet tar 40 sekunder att komma fram och koden gäller i 30.
- Trasiga mallar. En variabel som
{{first_name}}som inte ersätts, eller en tom ämnesrad. - Saknad autentisering. Hamnar dina mejl i skräpposten, kontrollera avsändarens SPF, DKIM och DMARC. Vi förklarar det i SPF, DKIM och DMARC förklarat.
- Fel språk eller format. En svensk kund får den engelska mallen, eller datum och belopp står i fel format (2026-10-23, 199 kr).
Testa med flera användare samtidigt
Inbjudningar, teamroller och godkännandeflöden kräver mer än en person. Öppna sidan i en ny flik eller ett privat fönster så får du en helt separat inkorg. En flik per testanvändare är snabbast: bjud in användare B från A:s konto, acceptera i B:s inkorg och se vad A får veta efteråt. Läs mer i fleranvändartester för QA.
När du inte ska använda en tillfällig inkorg
Tillfälliga inkorgar är till för att testa. Alla som har länken kan läsa inkorgen, och allt raderas efter 7 dagar. Använd den alltså inte för administratörskonton i produktion, något som rör betalningar eller konton du kan behöva återställa. Använd då en riktig brevlåda som ditt team styr över.
Lägg inte heller in riktiga kunders adresser i testmiljön: utöver risken att en kund får testmejl av misstag går det emot GDPR. En testadress löser problemet.
Vanliga frågor
- Är det en riktig inkorg eller en mock?
- En riktig inkorg på en riktig domän. Din applikation skickar med vanlig SMTP, precis som till en kund, så du testar hela vägen: kod, e-posttjänst, DNS och leverans.
- Visas HTML-mejl?
- Ja. HTML-mejl visas som dina användare kommer att se dem.
- Hur länge sparas testmejlen?
- Varje mejl raderas automatiskt 7 dagar efter att det kommit, och inkorgen löper ut 7 dagar efter att den skapades. Du kan också radera allt själv när du vill.
- Kan jag testa med flera användare samtidigt?
- Ja. Öppna sidan i en ny flik eller ett privat fönster så får du en egen inkorg. En flik per testanvändare fungerar bra för inbjudningar, roller och godkännanden.
- Varför kom inte mitt testmejl fram?
- Kontrollera först att adressen är rätt. Vissa tjänster blockerar kända engångsdomäner, och vissa leverantörer fördröjer det första mejlet från en ny avsändare en minut eller två. Om det är din egen applikation som skickar, titta i dess loggar och i e-posttjänstens panel.
- Kan jag använda det för produktionskonton?
- Nej. Alla med länken kan läsa inkorgen, och den löper ut efter 7 dagar. Använd den för tester, aldrig för konton du behöver återställa senare.