Blog

Tips, guides, and privacy advice

← Back to Blog
Så fungerar det

Vad händer med din tillfälliga inkorg efter en timme?

25 februari 2026·5 min read

Du har öppnat en tillfällig inkorg, fått det du behövde, och nu undrar du — vad händer egentligen när timmen är slut? Kanske är du utvecklare och vill förstå systemet innan du använder det i tester. Kanske är du en integritetsmedveten användare som vill veta exakt vad utgången innebär. Oavsett vilket får du här det fullständiga, ärliga svaret.

Den korta versionen: allt raderas permanent. E-postadressen, sessionen, varje enskilt meddelande i inkorgen — allt tas bort från databasen när tiden går ut. Inte arkiverat. Inte anonymiserat och sparat för analys. Inte mjukraderat med en flagga som skulle kunna ångras. Raderat — i betydelsen att databasposterna är borta. Det finns ingen "papperskorg" och ingen backuplagring som skulle göra det möjligt för någon, inte heller oss, att hämta tillbaka de uppgifterna.

Om det var allt du behövde veta har du ditt svar. Men vill du förstå resonemanget bakom, den exakta tekniska tidslinjen och vad det innebär i praktiken för olika användningsfall — läs vidare.

Varför automatisk radering är en funktion, inte en begränsning

De flestas första instinkt är att se utgången som en inskränkning — något som tas ifrån dem. Det känns som en nedräkning till att förlora åtkomst. Men i själva verket är det den centrala designfunktionen i en tjänst för tillfällig e-post, och det är precis det som gör integritetsgarantin verklig i stället för teoretisk. Data som inte består kan inte läcka. Den kan inte säljas. Den kan inte begäras ut i en domstolsprocess. Den kan inte kommas åt av en missnöjd anställd eller en alltför nyfiken tredje part. Ingen kan använda den till något efter att sessionen är slut.

Jämför det med ett gammalt, oanvänt konto hos någon tjänst du registrerade dig hos för flera år sedan. Det kontot — och din e-postadress, din användningshistorik och vad de nu mer samlade in — förblir ett mål långt efter att du glömt att det finns. Varje dataintrång du läser om i nyheterna handlar om uppgifter som lagrades och aldrig raderades ordentligt. Troy Hunt, säkerhetsforskaren bakom Have I Been Pwned, har dokumenterat tusentals intrång genom åren som berört miljarder poster. Mönstret är alltid detsamma: företag samlade in data, behöll den betydligt längre än nödvändigt, och till slut exponerades den. TempEmail.ai:s arkitektur gör hela den problemkategorin strukturellt omöjlig för din tillfälliga inkorg — eftersom uppgifterna helt enkelt inte finns kvar att läcka.

Livslängden på en timme är ett medvetet tekniskt val som sätter din integritet före bekvämlighet. För de allra flesta användningsfall — ta emot ett verifieringsmejl, testa ett registreringsflöde, komma åt en nedladdningslänk, slutföra en registrering — är en timme mer än tillräckligt. Det är faktiskt generöst. De flesta av dessa uppgifter tar minuter, inte en timme. Tidsfönstret finns för att ge dig bekväm marginal, inte för att skynda på dig.

Den exakta tidslinjen

Så här går det till, steg för steg, från det ögonblick du öppnar en session till det ögonblick dina uppgifter är borta:

  1. Du besöker TempEmail.ai — en ny session skapas med en unik e-postadress och en utgångstidsstämpel på 60 minuter sparad i databasen.
  2. Under den timmen kommer e-post in i realtid via en aktiv WebSocket-anslutning. Du ser dem direkt i webbläsaren utan att uppdatera sidan.
  3. Vid 60-minutersgränsen markeras sessionen och inkorgen som utgångna i databasen. Ingen ny e-post kan levereras till adressen.
  4. En städtjänst i bakgrunden körs var 15:e minut. Vid varje körning raderar den permanent alla utgångna sessioner, e-postadresser och varje e-postmeddelande som hör till dem.
  5. Inom ett kort fönster efter utgången — högst 15 minuter — är alla spår av din inkorg helt borta från databasen.

"Permanent raderat" betyder i detta sammanhang att databasposterna tas bort helt. De mjukraderas inte med en flagga. De flyttas inte till en arkivtabell. De sparas inte i backuper i all evighet. Posterna tas bort från den aktiva databasen. Det är inte ett löfte vi ger motvilligt — det är hela poängen med systemets design.

Städcykeln på 15 minuter innebär att dina uppgifter i värsta fall består i cirka 75 minuter från att sessionen skapades (60 minuter aktiv session plus upp till 15 minuter innan nästa städkörning). I praktiken är det ofta kortare, eftersom städningen kan köra tidigare efter att din session gått ut.

Vad som händer med e-post som kommer efter utgången

Om någon — eller något automatiserat system — skickar ett mejl till din tillfälliga adress efter att den gått ut avvisas mejlet. Adressen finns inte längre i systemet, så det finns ingenstans att leverera det. Den sändande e-postservern får ett meddelande om leveransfel (ett bounce-meddelande), precis som om den hade skickat till vilken icke-existerande adress som helst på vilken e-postserver som helst i världen. Ur avsändarens perspektiv går det inte att skilja från att skicka till en adress som aldrig varit giltig.

Det är värt att notera i testsammanhang. Om du använder en temp mail-adress för att testa ett fördröjt aviseringsflöde — till exempel en applikation som skickar ett mejl flera timmar efter registrering, eller en drip-kampanj som skickar en uppföljning nästa dag — kommer de senare mejlen att bounca. Din tillfälliga adress finns bara under den enda timmen. Om ditt test kräver att du tar emot e-post efter det fönstret behöver du öppna en ny inkorg för varje testfas eller anpassa tidsplanen så att allt ryms inom timmen.

Kan du förlänga sessionen?

Nej. När en inkorg har gått ut kan den inte förlängas, förnyas eller återskapas. Uppgifterna är borta. Det är avsiktligt — om sessioner kunde förlängas i obegränsad tid skulle integritetsgarantin vara meningslös. Gränsen på en timme är just det som gör systemet pålitligt: du vet med säkerhet att dina uppgifter raderas, eftersom systemet inte tillåter undantag.

Om du fortfarande är inom timmen och oroar dig för att tiden ska ta slut är det viktiga att förstå att sessionstimern utgår från skapandetidpunkten, inte din senaste aktivitet. Klockan började ticka när du först besökte sidan och sessionen skapades. Att klicka runt i inkorgen, läsa e-post eller uppdatera sidan nollställer eller förlänger inte timern. Utgången ligger fast på exakt en timme efter skapandet.

Behöver du mer tid för en uppgift — till exempel en komplex utvecklingstestsession som kan pågå längre än en timme — är den enkla lösningen att öppna en ny tillfällig inkorg när den gamla går ut. Varje ny session får en färsk timme med en helt ny e-postadress. Kom ihåg att den nya inkorgen har en annan adress, så konton eller tjänster du registrerade med den gamla adressen följer inte automatiskt med. Planera dina testsessioner därefter.

GUID:en i din URL — vad den betyder efter utgången

Din session är knuten till en unik GUID (globalt unik identifierare) som lagras på två platser: i webbläsarens URL som en frågeparameter och i webbläsarens localStorage. Den GUID:en är det som låter dig återvända till samma inkorg inom timmen. Stäng fliken, öppna den igen, gå tillbaka till URL:en — så länge sessionen inte gått ut finns din inkorg kvar med all e-post.

Efter utgången blir GUID:en meningslös. Servern har ingen post kopplad till den längre. Om du försöker besöka URL:en känner systemet igen att sessions-GUID:en inte längre är giltig och erbjuder att skapa en ny session i stället. Om du delar URL:en med någon, eller om någon annan på något sätt får tag på den, finns ingenting där efter utgången — ingen inkorg, ingen e-post, inga sessionsdata. GUID:en är bara en slumpmässig sträng som pekade på något som inte längre finns.

Detta ligger i linje med de säkerhetsrekommendationer som OWASP ger: sessionsidentifierare bör ha begränsad livslängd och inte bestå längre än sitt syfte. En session som går ut snabbt och inte innehåller några personuppgifter utgör minimal risk även om URL:en på något sätt skulle läcka.

Hur är det med e-post som kom in före utgången?

All e-post som kom in under din aktiva session raderas tillsammans med själva sessionen när städningen körs. Det finns inget sätt att hämta den efteråt. E-posten vidarebefordras ingenstans, säkerhetskopieras inte och sparas inte i någon form. När sessionen försvinner försvinner allt som hör till den också.

Om du fick något viktigt under sessionen som du behöver behålla — ett bekräftelsenummer, kontouppgifter, en licensnyckel, en nedladdningslänk till ett dokument — bör du spara den informationen innan timmen är slut. Kopiera den relevanta texten till en anteckningsapp, vidarebefordra det väsentliga till din riktiga e-postadress, ta en skärmbild eller ladda ner eventuella bilagor. När inkorgen är borta kan innehållet inte återskapas av någon, inte heller av teamet bakom TempEmail.ai. Det är ingen begränsning vi skulle kunna åtgärda om vi ville — det är själva grunddesignen: raderad data är raderad.

Varför detta är bra för din integritet

Modellen med automatisk radering ger en verklig integritetsvinst som går långt utöver att bara städa upp efter din testsession. Eftersom TempEmail.ai raderar allt automatiskt finns ingen långsiktig databas över din användning att bekymra sig för. Ingen uppgift om vilka tjänster du registrerade dig hos med tillfälliga adresser. Ingen historik över vilken e-post du tog emot. Ingen profil som byggs utifrån dina användningsmönster. Ingen lista med e-postadresser som skulle kunna kopplas tillbaka till dig. Att dessa uppgifter saknas är inget förbiseende — det är produkten.

GDPR och liknande dataskyddsregler världen över ger användare rätt att få sina uppgifter raderade. Rätten till radering — ibland kallad "rätten att bli bortglömd" — är en av de viktigaste rättigheterna i modern dataskyddslagstiftning. TempEmail.ai:s arkitektur gör den rätten automatisk och universell: du behöver inte begära radering, eftersom radering sker genom design, för varje användare, varje gång. Den brittiska ICO-vägledningen om dataskydd betonar att lagringspolicyer bör vara proaktiva, inte reaktiva — och det är precis så detta system fungerar.

I en värld där dataintrång rapporteras varje vecka och företag rutinmässigt behåller uppgifter de inte har någon anledning att spara är en tjänst som verkligen raderar dina uppgifter efter en timme inte bara bekväm — den är ett principiellt ställningstagande om hur onlineverktyg borde fungera.

Praktisk vägledning för utvecklare

Om du använder tillfällig e-post för utveckling och QA-testning är det så här du arbetar effektivt med livscykeln på en timme:

För korta tester — registreringsflöden, e-postverifiering, lösenordsåterställning, kontobekräftelse: en session räcker mer än väl. Öppna en ny inkorg, trigga mejlet från din applikation, ta emot det, klicka på länken eller kopiera koden — klart. Sådana tester tar oftast under fem minuter. Du behöver inte tänka på timern över huvud taget.

För längre testsessioner — testning av aviseringssekvenser, e-posttiming, onboardingflöden i flera steg eller arbetsflöden som innebär att vänta på fördröjda mejl: planera dina tester så att de blir klara inom timmen, eller strukturera dem så att varje större testfas använder en ny inkorg. Anteckna vilken tillfällig adress du använde för vilket testscenario så att du kan följa resultaten. Om din applikation skickar ett fördröjt mejl (till exempel ett "välkommen"-mejl 30 minuter efter registrering) ska du starta testet tillräckligt tidigt i sessionen för att hinna ta emot det före utgången.

För automatiserad testning: hårdkoda aldrig en tillfällig e-postadress i dina testskript. Generera en ny adress för varje testkörning genom att skapa en ny session via API:et. Då startar varje test från ett verkligt rent läge — inga kvarglömda mejl från tidigare körningar, inget delat tillstånd mellan tester. Det är faktiskt bättre testpraxis oavsett timmesgränsen, eftersom det eliminerar en vanlig orsak till instabila tester: restdata från tidigare körningar som förorenar den aktuella. Att använda en temp mail-inkorg för varje testkörning är god praxis — det säkerställer att du testar från ett verkligt rent läge varje gång.

E-postinfrastrukturen bakom kulisserna

E-post som skickas till din tillfälliga adress går genom vanlig internet-e-postinfrastruktur — SMTP-servrar, DNS MX-uppslag, e-postroutning — allt styrt av RFC 5321, grundprotokollet för e-postöverföring. Ur den sändande e-postserverns perspektiv är din tillfälliga adress en helt vanlig e-postadress på en helt vanlig e-postserver. Mejlet levereras via de normala kanalerna, tas emot av TempEmail.ai:s infrastruktur, sparas i databasen och skickas till din webbläsare i realtid via WebSocket. Inkorgens tillfälliga natur är helt osynlig för alla som skickar till den — ända till adressen går ut och varje efterföljande leveransförsök bouncar.

Det innebär att e-post till din tillfälliga adress levereras med samma tillförlitlighet och hastighet som e-post till vilken annan adress som helst. Det finns ingen särskild routning, ingen fördröjning och ingen filtrering utöver vanligt skräppostskydd. Du får mejlet så snabbt som internets e-postinfrastruktur kan leverera det — vilket i de flesta fall är inom några sekunder.

Sätt en påminnelse eller håll ett öga på nedräkningen när du startar en testsession, särskilt om uppgiften kan komma nära timmesgränsen. Ett extra ögonblicks uppmärksamhet kan bespara dig att starta om ett helt testflöde från början bara för att inkorgen gick ut mitt i arbetet.

Sammanfattningen

Livscykeln på en timme är det som gör en tillfällig e-postadress genuint tillfällig — inte bara till namnet, utan i verkligheten. Det är ingen marknadsföringsetikett på ett system som i tysthet behåller dina uppgifter. Det är en hård teknisk begränsning inbyggd i systemets arkitektur. Data som raderas automatiskt är data som inte kan orsaka problem senare — varken för dig eller för någon annan.

Electronic Frontier Foundation har länge drivit principen om dataminimering — tanken att tjänster bara bör samla in och behålla de uppgifter de verkligen behöver, och bara så länge de behöver dem. Den automatiska raderingen efter en timme är den principen tagen på allvar. När timmen är slut är uppgifterna borta. Det är ingen begränsning — det är hela poängen.