Du har öppnat en tillfällig inkorg, fått det du behövde, och nu undrar du — vad händer egentligen när de 14 dagarna ä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å 14 dagar är ett medvetet tekniskt val som balanserar din integritet mot praktisk 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 14 dagar mer än tillräckligt. Det är faktiskt generöst. De flesta av dessa uppgifter tar minuter, inte dagar. Tidsfönstret finns för att ge dig bekväm marginal — tid att komma tillbaka för en sen bekräftelse eller ett uppföljningsmeddelande — inte för att spara dina uppgifter i all oändlighet.
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:
- Du besöker TempEmail.ai — en ny session skapas med en unik e-postadress och en utgångstidsstämpel, satt till 14 dagar efter skapandet, som sparas i databasen.
- Under de 14 dagarna kommer e-post in i realtid via en aktiv WebSocket-anslutning. Du ser dem direkt i webbläsaren utan att uppdatera sidan. Varje mejl får en egen utgångstid: 14 dagar efter att det kom in.
- Efter 14 dagar markeras sessionen och inkorgen som utgångna i databasen. Ingen ny e-post kan levereras till adressen.
- En städtjänst i bakgrunden körs automatiskt. Vid varje körning raderar den permanent varje mejl vars 14 dagar har passerat, samt alla utgångna sessioner och e-postadresser som inte längre har några meddelanden kopplade till sig.
- När även ditt sista meddelande har passerat sina 14 dagar och städningen har körts ä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.
Det finns alltså två klockor. Inkorgen lever i 14 dagar från det att den skapas, och varje mejl lever i 14 dagar från det att det kommer in. Ett meddelande som anländer på inkorgens sista dag sparas därför lite längre än själva inkorgen — men aldrig mer än 14 dagar efter att det kom in — och tas bort av städtjänsten när den tiden har passerat.
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 mejlen fram som vanligt, så länge de skickas inom inkorgens 14 dagar. Bara meddelanden som skickas efter att adressen har gått ut studsar. Om ditt test kräver att du tar emot e-post efter det fönstret — säg en påminnelse tre veckor efter registreringen — behöver du öppna en ny inkorg för den senare testfasen eller anpassa tidsplanen så att allt ryms inom de 14 dagarna.
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. Den fasta gränsen på 14 dagar ä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 din inkorg fortfarande är aktiv och du 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 14 dagar efter skapandet.
Behöver du en adress längre — till exempel för ett test eller en tjänst som fortsätter att skicka meddelanden i flera veckor — är den enkla lösningen att öppna en ny tillfällig inkorg när den gamla går ut. Varje ny session får 14 nya dagar 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 när som helst under dess 14 dagar. 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 med en fast, begränsad livslängd som 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?
Varje mejl som kom in under din session sparas i 14 dagar från att det anlände och raderas sedan permanent av städtjänsten — tillsammans med själva sessionen när inkorgen har gått ut. Det finns inget sätt att hämta det 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 inkorgen går ut. 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 14 dagar 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å 14 dagar:
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: 14 dagar räcker för nästan alla realistiska sekvenser, från ett "välkommen"-mejl 30 minuter efter registrering till en uppföljning en vecka senare. Planera dina tester så att de blir klara inom det fönstret, 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 mycket sent mejl (till exempel ett återaktiveringsmejl tre veckor efter registrering) kommer det först efter att inkorgen har gått ut — förkorta hellre den fördröjningen i din testkonfiguration.
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 14-dagarsgrä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.
Sammanfattningen
Livscykeln på 14 dagar ä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 14 dagar är den principen tagen på allvar. När de 14 dagarna är slut är uppgifterna borta. Det är ingen begränsning — det är hela poängen.