Como escolher uma conta de e-mail de teste para QA

O que é uma conta de e-mail de teste para QA?

Uma conta de e-mail de teste, ou endereço de e-mail de teste para QA, é um endereço que sua equipe usa para receber e inspecionar os e-mails que sua própria aplicação envia. Use uma caixa de entrada temporária para verificações manuais e não sensíveis de cadastro e OTP. Escolha uma caixa de correio da empresa para mensagens que precisam ser mantidas, respostas ou anexos, e uma sandbox SMTP ou API de caixa de entrada hospedada quando testes automatizados precisarem inspecionar e-mails sem uma pessoa.

O Tmailor mantém este blog, então veja onde ele se encaixa. O Tmailor é um serviço gratuito de e-mail temporário somente para recebimento, disponível na web, Android, iOS e em um bot do Telegram. Ele atende ao primeiro caso: uma pessoa abre uma caixa de entrada, dispara um cadastro e lê o que chega. Para o último caso, a API separada Tmailor Temp Mail permite que testes automatizados criem endereços somente para recebimento e leiam suas mensagens a partir do código. As mensagens ficam cerca de 24 horas após a chegada, anexos não são recebidos e o endereço não pode enviar nem responder. Se você é novo em caixas de entrada descartáveis, comece por como funciona o correio temporário.

• Nenhum e-mail precisa chegar (validação de formulário, fixtures, testes unitários): use um domínio de exemplo reservado.
• Uma pessoa lê o e-mail e nada nele é sensível: uma caixa de entrada temporária é a opção mais rápida.
• Dados sensíveis, respostas, anexos ou evidências que você precisa manter: use uma caixa de correio aprovada e controlada pela empresa; adicione tags plus somente se seu sistema de e-mail e sua aplicação as suportarem.
• Ninguém acompanhando: use um SMTP catcher se você controlar as configurações de e-mail de saída do app, ou uma API de caixa de entrada hospedada se o app precisar enviar pelo provedor normal.

Teste manual vs. automatizado de e-mail: uma árvore de decisão

Quatro perguntas decidem qual conta de e-mail de teste uma verificação precisa: se um e-mail precisa chegar, se uma pessoa ou um código o lê, se ele carrega dados sensíveis e se você controla para onde a aplicação envia seus e-mails de saída.

1. O teste precisa que um e-mail chegue? Verificações de formato, estados da interface, fixtures e testes unitários geralmente não precisam. Use endereços em example.com, example.org ou example.net. Esses domínios são reservados para documentação e exemplos, então nada chega a uma pessoa real. Evite inventar domínios aleatórios, porque alguém pode ser dono deles.
2. Uma pessoa vai ler a mensagem durante o teste? Testes de fumaça, UAT manual, demonstrações e sessões exploratórias têm um humano no circuito. Suítes de regressão e jobs de CI geralmente não têm.
3. Se uma pessoa lê, há algo sensível na mensagem? Registros reais de clientes, credenciais, dados regulados ou mensagens que você precisa manter como evidência de auditoria não pertencem a uma caixa de entrada temporária. Use uma caixa de correio da empresa. Se a resposta for não, uma caixa de entrada temporária é suficiente.
4. Se o código lê, o ambiente de teste pode enviar seu e-mail para um servidor SMTP de teste? Se sim, um SMTP catcher captura todas as mensagens sem entregá-las. Se não, porque o app precisa enviar pelo provedor de e-mail normal, use uma caixa de entrada hospedada que seus testes leem por uma API.

A tabela compara as cinco opções lado a lado.

Quais endereços um campo de e-mail deve aceitar ou rejeitar?

Teste a validação do formulário separadamente da entrega da mensagem. Use um endereço reservado, como user@example.com, para um caso com aparência válida que nunca é entregue, inclua um endereço com tag plus e outro com subdomínio, e adicione casos malformados, como ausência da parte local ou do domínio. Mantenha os resultados esperados alinhados com o validador que seu sistema de produção realmente usa.

Quando uma caixa de entrada temporária é suficiente

Uma caixa de entrada temporária funciona quando uma pessoa está verificando um fluxo de cada vez e a mensagem não contém nada que você se importaria de perder depois de um dia. Esse é o uso clássico de um e-mail descartável para QA: você precisa de um endereço de e-mail para testar um formulário manualmente, não de uma conta duradoura. Casos típicos são um teste de fumaça pré-lançamento do formulário de cadastro, uma passagem manual de UAT em um novo e-mail de onboarding, uma demonstração de vendas de criação de conta ou uma sessão exploratória em que você tenta entradas estranhas e observa o que o app envia.

O atrativo é a velocidade. Não há conta para solicitar ao TI nem caixa de correio compartilhada para limpar. A contrapartida é o controle: você tem uma janela curta de mensagens, sem anexos, e uma caixa de entrada que uma pessoa lê em vez de o código.

Quando você precisa de um SMTP catcher ou de uma API de caixa de entrada hospedada

Quando os testes passam a rodar sem supervisão, a caixa de entrada precisa ser legível por código. Duas famílias de ferramentas atendem a essa necessidade, e elas resolvem problemas diferentes.

SMTP catchers e sandboxes substituem o servidor de e-mail de saída do seu app em um ambiente de teste e mantêm cada mensagem para inspeção em vez de entregá-la.

• O Mailpit é uma ferramenta gratuita e de código aberto que você mesmo executa. Ele captura e-mails por padrão e oferece uma interface web e uma API REST para testes de integração.
• O MailHog funciona da mesma forma, mas é mais antigo. Os mantenedores do Mailpit informam que ele não é mais mantido, então verifique seu status antes de adotá-lo.
• O Mailtrap Email Sandbox é uma versão hospedada da mesma ideia, com acesso via SMTP e API. Ele é separado do produto de envio de produção do Mailtrap.
• O Ethereal é um serviço SMTP falso gratuito usado principalmente com o Nodemailer. As mensagens são capturadas para pré-visualização e nunca são entregues.

APIs de caixas de entrada hospedadas fornecem aos testes endereços reais nos domínios do fornecedor, então seu app envia e-mails pelo provedor normal e o teste lê o resultado por meio de uma API. A própria API de e-mail temporário do Tmailor funciona assim, com SDKs oficiais para Python, Node.js e PHP.

• O Mailosaur oferece endereços de e-mail de teste, uma API e bibliotecas de cliente que funcionam com frameworks como Cypress, Playwright e Selenium. Ele também cobre códigos por SMS.
• O MailSlurp cria caixas de entrada sob demanda por meio de sua API e SDKs. Os testes podem aguardar uma mensagem e então extrair códigos, links e anexos.

Os recursos e planos dos fornecedores mudam, então confirme os detalhes atuais em cada site oficial antes de vincular um conjunto de testes a um deles.

Quando uma caixa de correio da empresa com etiquetas plus é a melhor escolha

As etiquetas plus permitem que uma única caixa de correio da empresa aceite muitas variações de endereço. E-mails enviados para qa+signup ou qa+reset no domínio da sua empresa chegam à caixa de correio de QA, onde você pode filtrá-los por etiqueta. O Google Workspace oferece suporte a isso, e a Microsoft documenta que o endereçamento plus no Exchange Online vem ativado por padrão, a menos que um administrador o desative.

Use esse caminho quando um fluxo envolve dados reais de clientes, dura mais de um dia, precisa de respostas ou anexos, ou produz evidências que um auditor pode solicitar. Lembre-se dos limites. As etiquetas são variações de uma única caixa de correio, não caixas de entrada separadas, então testes paralelos podem ler as mensagens uns dos outros. Alguns formulários de cadastro rejeitam o sinal de mais, e alguns apps tratam as variantes com etiqueta como a mesma conta. Ambos os comportamentos merecem um caso de teste próprio.

Como Executar um Teste Manual de Cadastro com uma Caixa de Entrada Temporária

Um teste manual de cadastro que usa e-mail temporário precisa de três coisas: um endereço novo, a build que você está testando e um local fora da caixa de entrada para registrar o que chegou. Execute-o apenas em sistemas que você possui ou está autorizado a testar.

1. Abra uma caixa de entrada. Crie uma caixa temporária gratuita na web, ou use o app Tmailor ou o bot do Telegram, e copie o endereço. No desktop, o extensão do navegador Tmailor também pode preenchê-lo no campo de e-mail da sua build de teste.
2. Cadastre-se na sua build de teste. Use o endereço no seu ambiente de staging ou QA e anote o horário em que enviou o formulário.
3. Fique de olho no e-mail. Verifique qual mensagem chegou, o nome do remetente e o endereço De, o assunto e quanto tempo levou.
4. Conclua a etapa. Clique no link ou insira o código. Confirme que a conta muda de estado uma única vez e que reutilizar o mesmo link falha com uma mensagem clara.
5. Registre as evidências em outro lugar. Copie o link, o código, os carimbos de data e hora e uma captura de tela para o seu caso de teste. As mensagens ficam disponíveis por cerca de 24 horas após a chegada, então a caixa de entrada não é o seu registro de teste.
6. Salve o access token se você for testar novamente. O token reabre o mesmo endereço mais tarde, por exemplo, para refazer uma redefinição de senha. Ele não restaura mensagens que já expiraram, e um token perdido não pode ser recuperado.

Quando uma sessão precisa de várias personas ao mesmo tempo, como um usuário gratuito, um usuário de teste e um colega convidado, a visualização de múltiplas caixas de entrada mantém até cinco endereços lado a lado em uma única aba do navegador. Cada persona recebe seu próprio endereço, então você consegue ver qual e-mail pertence a qual conta.

Essa visualização ainda é manual. As caixas de entrada são criadas por uma pessoa no navegador, não são provisionadas por código, então ela não substitui uma API de caixa de entrada hospedada para execuções paralelas sem supervisão.

Uma caixa de entrada ou um endereço por teste?

Uma caixa de entrada compartilhada é suficiente para uma verificação rápida, mas logo fica confusa. Quando vários testes rodam ao mesmo tempo, linhas de assunto parecidas dificultam saber a qual script cada e-mail pertence, e a depuração vira adivinhação.

Um endereço por caso de teste resolve isso. Logs, capturas de tela e e-mails ficam alinhados, e uma mensagem ausente aponta para um cenário em vez de todos. O guia sobre rodar múltiplas caixas de entrada temporárias aborda esse fluxo de trabalho com mais detalhes.

Algumas jornadas precisam do mesmo endereço novamente dias depois, como um teste gratuito que se converte em pago ou um usuário que retorna após cancelar. Um endereço temporário de e-mail reutilizável mantém o endereço disponível por meio do Access Token, mas não as mensagens. Armazene os links e códigos de que precisa conforme cada etapa é executada e transfira qualquer etapa que dependa de mensagens antigas para uma caixa de correio da empresa. Se um testador entrar em uma conta Tmailor gratuita antes de criar os endereços de persona, cada um é salvo em E-mails Criados, então um token perdido deixa de significar um endereço perdido.

O que verificar nos e-mails de cadastro e onboarding

Comece com um inventário de todos os e-mails que a jornada pode enviar e depois decida o que cada teste deve verificar. As equipes muitas vezes só descobrem e-mails extras quando eles aparecem no meio do teste, depois que um experimento de crescimento ou uma mudança de segurança acrescentou um que ninguém havia registrado.

E-mails em uma jornada típica de cadastro

• Link de verificação ou código de uso único
• E-mail de boas-vindas e qualquer sequência de início rápido
• Login por magic link
• Redefinição de senha
• Alteração de endereço de e-mail, enviada tanto para o endereço antigo quanto para o novo
• Alerta de segurança de novo dispositivo ou novo local
• Lembretes para cadastros que nunca foram concluídos

Para cada um, anote o gatilho, o momento esperado e as condições que o alteram, como plano, região ou idioma. Defina a janela de entrega permitida a partir do requisito documentado do seu produto, em vez de presumir um limite universal; uma mensagem de verificação imediata e uma sequência de boas-vindas agendada exigem expectativas diferentes. Uma vez que essas expectativas existam, cada teste tem algo concreto para verificar.

O que verificar em cada e-mail de teste

• Remetente e destinatário: nome e endereço do remetente, Reply-To e o endereço exato do destinatário.
• Assunto e corpo: tanto as versões HTML quanto em texto simples, com nomes, detalhes do plano e idioma corretos.
• Links: o destino e se ele aponta para o ambiente certo. Um e-mail de staging que leva à produção é um bug de verdade.
• Códigos: formato, comprimento, texto de expiração e se o prazo informado corresponde ao que o servidor aplica.
• Tempo: quanto tempo a mensagem levou para chegar após o gatilho.
• Anexos: se um fluxo envia um PDF ou fatura, teste em uma caixa de correio da empresa ou em uma ferramenta de teste. O Tmailor não recebe anexos.

Um alerta sobre a renderização. Uma caixa de entrada temporária mostra como um visualizador web exibe seu HTML. Ela não mostra como o mesmo e-mail aparece no Gmail, no Outlook, no Apple Mail, no modo escuro ou em uma tela pequena de celular, então planeje verificações de renderização separadas se isso for importante.

Fluxos de Alteração de E-mail e Recuperação de Conta

Os fluxos de recuperação falham de formas mais silenciosas do que o cadastro. Verifique se uma alteração de e-mail envia uma confirmação para o novo endereço e um aviso para o antigo, se um link de redefinição já usado não pode ser reutilizado, se um link de redefinição mais antigo deixa de funcionar depois que um mais novo é enviado e se um link aberto em um segundo dispositivo leva o usuário a um estado coerente. Os fluxos de OTP merecem uma análise de risco separada; o lista de verificação de risco do OTP para QA e UAT aborda métricas, janelas de reenvio e titularidade.

Como testar casos extremos de OTP e verificação

Teste fluxos de OTP e verificação quanto a entrega atrasada, reenvios, códigos expirados e incorretos e links abertos em outro dispositivo. Cada caso deve verificar tanto o resultado no servidor quanto a mensagem exibida ao usuário. Execute esses testes apenas em sistemas que você possui ou está autorizado a testar. Bons testes de OTP quebram o fluxo de propósito:

• Chegada lenta: espere antes de verificar a caixa de entrada e confirme se a interface explica o que está acontecendo e oferece uma forma clara de reenviar.
• Comportamento do reenvio: solicite um segundo código e verifique se o primeiro é invalidado ou ainda aceito.
• Expiração: insira um código após o tempo de vida informado e confirme se a mensagem de erro corresponde ao que aconteceu.
• Código errado: confirme se o limite de tentativas e o texto do cooldown fazem sentido para uma pessoa.
• Links mágicos entre dispositivos: solicite um link em um laptop, abra-o no celular e verifique onde o usuário acaba.

Para uma visão mais ampla de quais códigos chegam a uma caixa de entrada temporária e quais não, veja este guia sobre e-mail temporário para códigos OTP.

Se o seu produto rejeita domínios de e-mail descartável de propósito, teste esse caminho diretamente. Confirme que a mensagem de rejeição está clara e que um endereço real ou controlado pela empresa ainda conclui o cadastro. Não fique alternando entre outros domínios temporários para burlar o bloqueio, nem no seu próprio produto nem no de outra pessoa. Confirmar que o bloqueio funciona é o teste; contorná-lo não é. Esta explicação sobre por que os sites bloqueiam domínios de e-mail temporários aborda os motivos por trás desses filtros.

O que muda quando os testes de e-mail rodam sem supervisão

Quando ninguém está acompanhando, o teste precisa de uma caixa de entrada que ele consiga ler por código. Isso significa uma API de SMTP catcher ou uma API de caixa de entrada hospedada. A caixa de entrada web do Tmailor não é essa ferramenta, mas a API de E-mail Temporário do Tmailor é: os testes podem criar endereços somente de recebimento, listar e ler mensagens e obter o código de uso único ou o link de verificação que a API encontrar. Um servidor MCP permite que agentes de IA como Claude, Cursor ou VS Code Copilot façam o mesmo em fluxos de cadastro que você possui ou tem permissão para testar.

Alguns hábitos mantêm os testes de e-mail sem supervisão estáveis, seja qual for a ferramenta escolhida:

• Dê a cada execução de teste um endereço próprio e um ID de correlação, para que um e-mail atrasado de uma execução anterior não satisfaça a asserção errada.
• Use uma espera dedicada pela chegada do e-mail, com backoff adequado e separada do tempo limite geral do teste, e registre quanto tempo cada mensagem levou.
• Localize a mensagem exata pelo destinatário e pelo assunto, em vez de ler "o e-mail mais recente".
• Mascare códigos e magic links nos logs de CI, já que os logs costumam durar mais que a caixa de entrada.

Também deixe claro o que um teste aprovado comprova. "O aplicativo gerou e entregou o e-mail", "um domínio de teste hospedado o recebeu pela infraestrutura pública de e-mail" e "o Gmail o colocou na caixa de entrada, não no spam" são três fatos diferentes. Um SMTP catcher comprova o primeiro, uma API de caixa de entrada hospedada comprova os dois primeiros, e nenhum dos dois comprova o terceiro. Para configurar pipelines no GitHub Actions, GitLab CI e CircleCI, consulte o guia de testes de e-mail em pipelines CI/CD.

Mantenha os dados de teste seguros e respeite as regras

Use identidades sintéticas e conteúdo não sensível em caixas de entrada temporárias de teste, e execute testes de cadastro apenas em sistemas que você possui ou está autorizado a avaliar. Mantenha as contas de QA fora das análises de produção, respeite os limites de taxa e transfira dados regulados, credenciais, anexos e evidências retidas para sistemas aprovados e controlados pela empresa.

• Nenhum dado real em uma caixa de entrada temporária. Nunca encaminhe registros reais de clientes, credenciais, chaves de API ou dados regulados para um endereço de e-mail temporário. Use usuários sintéticos com nomes claramente falsos.
• Teste apenas o que você tem permissão para testar. Execute testes de cadastro no seu próprio produto ou em um sistema que você está autorizado a testar, e respeite os limites de taxa e os termos desse serviço. Não use e-mail temporário para criar contas em massa em sites de terceiros. Testes de volume e de carga pertencem ao seu próprio ambiente de staging, com um SMTP catcher ou uma API de caixa de entrada hospedada.
• Mantenha o tráfego de QA fora dos números de produção. Identifique claramente as contas de teste e exclua-as das análises e dos painéis de crescimento. Evite enviar grandes volumes de e-mails de teste a partir do seu domínio de envio de produção, onde rejeições e reclamações podem prejudicar sua reputação.
• Registre a política por escrito. Defina quais fluxos podem usar uma caixa de entrada temporária, quais precisam de uma caixa de correio da empresa, por quanto tempo os dados de teste são mantidos e quem tem acesso. As revisões de segurança e conformidade avançam mais rápido quando os limites já estão no papel.

Quando a segurança pergunta como um provedor trata os dados, observe o que ele coleta, por quanto tempo mantém as mensagens e como funciona o acesso. Esta visão geral sobre correio temporário e privacidade online aborda essas questões do ponto de vista do usuário. A decisão sobre quais fluxos podem usar caixas de entrada descartáveis continua sendo das suas equipes jurídica, de privacidade e de segurança.

Limites a considerar no planejamento

A caixa de entrada web do Tmailor serve para verificações manuais curtas de e-mails recebidos não sensíveis (para automação existe a API de E-mail Temporário). Antes de escolhê-la, decida se o fluxo de trabalho precisa de ações de envio, anexos, evidências de longo prazo ou recuperação durável do endereço. Qualquer um desses requisitos exige uma caixa de correio controlada pela empresa ou uma ferramenta especializada em testes; a lista abaixo explica o motivo.

• O Tmailor é somente de recebimento. Ele consegue verificar e-mails de cadastro, verificação e OTP recebidos, mas não fluxos de resposta nem qualquer coisa que envie a partir do endereço.
• O Tmailor não recebe anexos, então e-mails de fatura, contrato ou entrega de documentos precisam de uma caixa de correio da empresa ou de uma ferramenta de teste.
• As mensagens ficam cerca de 24 horas a partir da chegada. Exporte os links, códigos e carimbos de data e hora de que uma investigação mais longa vai precisar.
• Um access token reabre um endereço, mas não mensagens expiradas, e um token perdido não pode ser recuperado.
• A caixa de entrada web é lida por uma pessoa. A leitura de caixa de entrada sem supervisão exige um capturador SMTP ou uma API de caixa de entrada hospedada, como a API Tmailor Temp Mail.
• Alguns serviços bloqueiam domínios de e-mail descartável. Se um fluxo que você testa faz isso de propósito, valide-o com um endereço real ou controlado pela empresa.

Escolhendo a caixa de entrada de teste certa

Escolha a caixa de entrada de acordo com o que o teste precisa comprovar. Use um domínio de exemplo reservado quando a entrega não for necessária, uma caixa de entrada temporária para verificações manuais não sensíveis, uma caixa de correio da empresa para jornadas que exigem retenção ou dados sensíveis, um capturador SMTP quando você controla as configurações de saída e uma API de caixa de entrada hospedada para testes de ponta a ponta sem supervisão.

Para os casos manuais, abra uma caixa de entrada temporária e comece pelo fluxo de cadastro que você lançará em seguida. O e-mail temporário tem bastante usos práticos além do QA também.