Por que testadores usam um e-mail descartável
Quase toda aplicação envia e-mails: confirmação de pedido, códigos de verificação, notas fiscais, reservas, avisos e notificações. Esses e-mails fazem parte do produto, e quebram com mais frequência do que parece. O link aponta para homologação. O código chega quando já expirou. O remetente aparece como um nome de servidor do tipo ip-10-0-3-17.internal. Ninguém percebe até um cliente de verdade reclamar.
Testar com o seu próprio Gmail ou Outlook não escala. Os aliases com "+" acabam, a caixa de entrada enche de lixo de teste e fica difícil passar o endereço para um colega. Uma caixa descartável resolve: abra a página, copie o endereço, use na sua aplicação e veja o e-mail chegar em tempo real. Quando terminar, pode esquecer. Tudo é apagado sozinho depois de 7 dias.
Como é uma caixa de entrada real em um domínio real, sua aplicação envia o e-mail por SMTP normal, igualzinho a um cliente. Você testa o caminho inteiro, do seu código ao provedor de e-mail, DNS e entrega, e não um mock.
Como testar os e-mails da sua aplicação em menos de um minuto
- Copie o endereço no topo desta página.
- Use na sua aplicação (local, homologação ou produção) em qualquer ponto que envie e-mail: cadastro, pedido, reserva, pagamento, aviso.
- Acompanhe a caixa de entrada. O e-mail aparece sem recarregar a página, normalmente em poucos segundos.
- Confira o e-mail: remetente, assunto, conteúdo, cada link e qualquer código.
- Clique nos links ou use o código para concluir o fluxo e garantir que cada etapa funciona.
Exemplo: testar a contratação de um plano de celular com eSIM antes do release
Imagine que você trabalha com QA em uma operadora, e o release da semana que vem muda a forma como o cliente contrata um plano pela internet. O cliente escolhe o plano, informa o e-mail, paga, e daí em diante quase tudo acontece por e-mail. Cada um desses e-mails precisa estar certo desde o primeiro dia, porque um link errado significa um cliente que não consegue ativar o eSIM.
Com uma caixa descartável, você percorre a jornada inteira como um cliente novo, em homologação, antes de ir para produção:
- Contrate um plano no ambiente de homologação com o endereço desta página.
- Confirme o e-mail com o código que chega por e-mail.
- Confira a confirmação do pedido: nome do plano, valor mensal, franquia de internet e número do pedido.
- Confira o e-mail de pagamento: se o pagamento via Pix ou boleto foi confirmado e se o valor bate com o pedido.
- Confira o e-mail do eSIM: se a imagem do QR code aparece, se tem texto alternativo e se o link de ativação aponta para produção, e não para um servidor de homologação.
- Repita para cada tipo de plano (pré-pago, controle, pós-pago) em uma aba nova, para que cada cliente de teste tenha sua própria caixa de entrada.
A mesma ideia vale para qualquer setor em que uma ação do cliente gera e-mails: bancos, seguros, e-commerce, reservas de viagem ou testes grátis de SaaS. Teste cada e-mail que o cliente vai receber antes do release, e não depois da primeira reclamação.
Bugs que você encontra antes dos seus usuários
- Links de homologação em e-mails de produção. Uma URL base copiada do ambiente errado. Muito comum, e invisível até alguém clicar.
- Códigos que expiram rápido demais. O e-mail leva 40 segundos para chegar e o código vale 30.
- Templates quebrados. Uma variável como
{{first_name}}sem substituir, ou um assunto vazio. - Falta de autenticação. Se seus e-mails caem no spam, confira o SPF, DKIM e DMARC do remetente. Explicamos em SPF, DKIM e DMARC explicados em linguagem simples.
- Idioma ou formato errado. Um cliente brasileiro recebe o template em inglês, ou datas e valores saem no formato errado (23/10/2026, R$ 49,90).
Testar com vários usuários ao mesmo tempo
Convites, papéis de equipe e fluxos de aprovação precisam de mais de uma pessoa. Abra esta página em uma aba nova ou em uma janela anônima e você ganha uma caixa de entrada totalmente separada. Uma aba por usuário de teste é o jeito mais rápido: convide o usuário B pela conta do A, aceite pela caixa do B e veja o que o A recebe depois. Mais detalhes em testes multiusuário para QA.
Quando não usar um e-mail descartável
Caixas descartáveis são para testes. Qualquer pessoa com o link da caixa pode ler, e tudo é apagado depois de 7 dias. Não use para contas de administração em produção, nada ligado a pagamentos ou contas que você precise recuperar depois. Para isso, use uma caixa de e-mail real controlada pela sua equipe.
E não coloque e-mails de clientes reais em homologação: além do risco de mandar um e-mail de teste para um cliente por engano, isso vai contra a LGPD. Um endereço de teste evita o problema.
Perguntas frequentes
- É uma caixa de entrada real ou um mock?
- É uma caixa real em um domínio real. Sua aplicação envia por SMTP normal, igual a um cliente, então você testa o caminho inteiro: código, provedor de e-mail, DNS e entrega.
- E-mails em HTML aparecem?
- Sim. E-mails em HTML aparecem do jeito que seus usuários vão ver.
- Por quanto tempo os e-mails de teste ficam guardados?
- Cada e-mail é apagado automaticamente 7 dias depois de chegar, e a caixa expira 7 dias depois de criada. Você também pode apagar tudo quando quiser.
- Dá para testar com vários usuários ao mesmo tempo?
- Sim. Abra a página em uma aba nova ou em uma janela anônima e você ganha outra caixa de entrada. Uma aba por usuário de teste funciona muito bem para convites, papéis e aprovações.
- Por que meu e-mail de teste não chegou?
- Primeiro confira se o endereço está certo. Alguns serviços bloqueiam domínios descartáveis conhecidos, e alguns provedores atrasam em um ou dois minutos o primeiro e-mail de um remetente novo. Se é a sua aplicação que envia, veja os logs e o painel do seu provedor de e-mail.
- Posso usar para contas de produção?
- Não. Qualquer pessoa com o link pode ler a caixa, e ela expira em 7 dias. Use para testes, nunca para contas que você precise recuperar depois.