Perché i tester usano una casella usa e getta
Quasi ogni applicazione invia email: conferme d'ordine, codici monouso, fatture, prenotazioni, avvisi e notifiche. Queste email fanno parte del prodotto, e si rompono più spesso di quanto si pensi. Il link punta all'ambiente di test. Il codice arriva quando è già scaduto. Il mittente appare come un nome di server grezzo tipo ip-10-0-3-17.internal. Nessuno se ne accorge finché un cliente vero non si lamenta.
Testare con la tua Gmail o Outlook non regge. Finisci gli alias con il "+", la casella si riempie di posta di test e non puoi passare facilmente l'indirizzo a un collega. Una casella usa e getta risolve tutto: apri la pagina, copia l'indirizzo, usalo nella tua applicazione e guarda l'email arrivare in tempo reale. Quando hai finito, non devi fare altro. Tutto si cancella da solo dopo 7 giorni.
Visto che è una casella vera su un dominio vero, la tua applicazione invia l'email con il normale SMTP, esattamente come a un cliente. Testi l'intero percorso, dal tuo codice al servizio di invio, al DNS fino alla consegna, e non un mock.
Come testare le email della tua applicazione in meno di un minuto
- Copia l'indirizzo in cima a questa pagina.
- Usalo nella tua applicazione (in locale, in test o in produzione) ovunque parta un'email: registrazione, ordine, prenotazione, pagamento, avviso.
- Tieni d'occhio la casella. L'email compare senza ricaricare, di solito in pochi secondi.
- Controlla l'email: mittente, oggetto, contenuto, ogni link e ogni codice.
- Clicca i link o usa il codice per arrivare in fondo al flusso e verificare che ogni passaggio funzioni.
Esempio: testare l'attivazione di un'offerta mobile con eSIM prima del rilascio
Immagina di lavorare nel QA di un operatore mobile, e che il rilascio della prossima settimana cambi il modo in cui i clienti attivano un'offerta online. Il cliente sceglie l'offerta, inserisce l'email, paga, e da lì quasi tutto passa via email. Ognuna di queste email deve essere giusta dal primo giorno, perché un link sbagliato significa un cliente che non riesce ad attivare la sua eSIM.
Con una casella usa e getta percorri tutto il viaggio come un nuovo cliente, in ambiente di test, prima di andare online:
- Attiva un'offerta in ambiente di test con l'indirizzo di questa pagina.
- Conferma l'indirizzo email con il codice ricevuto.
- Controlla la conferma d'ordine: l'offerta giusta, il costo mensile IVA inclusa, i giga e il numero d'ordine.
- Controlla l'email di riconoscimento (per esempio con SPID o documento): è chiaro cosa deve fare il cliente dopo?
- Controlla l'email della eSIM: il QR code si vede, ha un testo alternativo e il link di attivazione punta alla produzione, non a un server di test.
- Ripeti per ogni tipo di offerta (ricaricabile, abbonamento, offerta famiglia) in una nuova scheda, così ogni cliente di test ha la sua casella.
Lo stesso vale per qualsiasi settore in cui un'azione del cliente genera email: banche, assicurazioni, e-commerce, prenotazioni di viaggi o prove gratuite di SaaS. Testa ogni email che il cliente riceverà prima del rilascio, non dopo il primo reclamo.
Bug che trovi prima dei tuoi utenti
- Link di test nelle email di produzione. Un URL di base copiato dall'ambiente sbagliato. Comunissimo, e invisibile finché qualcuno non clicca.
- Codici che scadono troppo presto. L'email ci mette 40 secondi ad arrivare e il codice vale 30.
- Template rotti. Una variabile come
{{first_name}}non sostituita, o un oggetto vuoto. - Autenticazione mancante. Se le tue email finiscono nello spam, controlla SPF, DKIM e DMARC del mittente. Lo spieghiamo in SPF, DKIM e DMARC spiegati in modo semplice.
- Lingua o formato sbagliati. Un cliente italiano riceve il template in inglese, oppure data e prezzo sono nel formato sbagliato (23/10/2026, 9,99 €).
Testare con più utenti alla volta
Inviti, ruoli di team e flussi di approvazione richiedono più di una persona. Apri questa pagina in una nuova scheda o in una finestra in incognito e avrai una casella completamente separata. Una scheda per ogni utente di test è il modo più veloce: invita l'utente B dall'account di A, accetta dalla casella di B e controlla cosa vede A dopo. Approfondisci in test multiutente per il QA.
Quando non usare una casella usa e getta
Le caselle usa e getta servono per testare. Chiunque abbia il link può leggerla, e tutto viene cancellato dopo 7 giorni. Non usarla per account amministratore in produzione, per tutto ciò che riguarda i pagamenti o per account che potresti dover recuperare. Per quelli usa una casella vera gestita dal tuo team.
E non mettere indirizzi di clienti reali negli ambienti di test: oltre al rischio di mandare per errore un'email di test a un cliente, è contrario al GDPR. Un indirizzo di test evita il problema.
Domande frequenti
- È una casella vera o un mock?
- Una casella vera su un dominio vero. La tua applicazione invia con il normale SMTP, come a un cliente, quindi testi l'intero percorso: codice, servizio di invio, DNS e consegna.
- Le email HTML vengono mostrate?
- Sì. Le email HTML vengono mostrate come le vedranno i tuoi utenti.
- Per quanto tempo restano le email di test?
- Ogni email viene cancellata automaticamente 7 giorni dopo l'arrivo, e la casella scade 7 giorni dopo la creazione. Puoi anche cancellare tutto da solo quando vuoi.
- Posso testare con più utenti alla volta?
- Sì. Apri la pagina in una nuova scheda o in incognito e avrai un'altra casella. Una scheda per utente di test funziona bene per inviti, ruoli e approvazioni.
- Perché la mia email di test non è arrivata?
- Controlla prima che l'indirizzo sia giusto. Alcuni servizi bloccano i domini usa e getta noti, e alcuni provider ritardano di un paio di minuti la prima email di un nuovo mittente. Se a inviare è la tua applicazione, guarda i log e la dashboard del tuo servizio di invio.
- Posso usarla per account di produzione?
- No. Chiunque abbia il link può leggere la casella, e scade dopo 7 giorni. Usala per i test, mai per account che dovrai recuperare.