E-mail descartável em CI/CD: teste OTP e fluxos de cadastro no GitHub, GitLab e CircleCI
Conjuntos de testes automatizados quebram no momento em que dependem de uma caixa de correio real. Caixas de entrada compartilhadas ficam poluídas entre execuções paralelas, códigos OTP expiram antes que as asserções sejam acionadas, e credenciais vazadas nos logs transformam uma build verde em um incidente de segurança. Este guia mostra como integrar o e-mail descartável ao GitHub Actions, GitLab CI/CD e CircleCI — passo a passo. Você vai aprender a gerar caixas de entrada por build, consumir e-mails de verificação dentro das etapas de teste, manter tokens fora dos logs e limpar tudo após cada execução. Seja testando fluxos de cadastro, entrega de OTP ou notificações transacionais, os padrões aqui escalam de um único workflow para um conjunto completo de testes paralelos.
Acesso rápido
Principais Pontos para Equipes DevOps Ocupadas
Se seus testes de CI/CD dependem de e-mails, você precisa de uma estratégia estruturada de caixa de entrada descartável; caso contrário, mais cedo ou mais tarde você vai entregar bugs, vazar segredos ou ambos.
- Pipelines de CI/CD frequentemente encontram fluxos de e-mail, como cadastro, OTP, redefinição de senha e notificações de cobrança, que não podem ser testados de forma confiável com caixas de entrada humanas compartilhadas.
- Uma estratégia limpa de caixa de entrada descartável associa o ciclo de vida da caixa de entrada ao ciclo de vida do pipeline, mantendo os testes determinísticos enquanto protege usuários reais e caixas de correio de funcionários.
- GitHub Actions, GitLab CI e CircleCI podem todos gerar, passar e consumir endereços de e-mail temporários como variáveis de ambiente ou saídas de job.
- A segurança decorre de regras rígidas: nenhum OTP ou token de caixa de entrada é registrado, a retenção é curta e caixas de entrada reutilizáveis só são permitidas quando o perfil de risco permite.
- Com instrumentação básica, você pode acompanhar o tempo de entrega do OTP, padrões de falha e problemas do provedor, tornando os testes baseados em e-mail mensuráveis e previsíveis.
Torne o CI/CD Seguro para E-mails
O e-mail é uma das partes mais complexas dos testes de ponta a ponta, e o CI/CD amplifica cada problema de caixa de entrada que você ignora no staging.
Onde o E-mail Aparece em Testes Automatizados
A maioria dos aplicativos modernos envia pelo menos alguns e-mails transacionais durante uma jornada normal do usuário. Seus testes automatizados em pipelines de CI/CD normalmente precisam passar por vários fluxos, incluindo cadastro de conta, verificação por OTP ou magic link, redefinição de senha, confirmação de alteração de endereço de e-mail, avisos de cobrança e alertas de uso.
Todos esses fluxos dependem da capacidade de receber uma mensagem rapidamente, extrair um token ou link e verificar se a ação correta ocorreu. Guias como o e-mail temporário para verificação OTP demonstram a importância crítica dessa etapa para usuários reais, e o mesmo se aplica aos seus usuários de teste dentro do CI/CD.
Por que caixas de correio reais não escalam em QA
Em pequena escala, as equipes frequentemente executam testes em uma caixa de entrada compartilhada do Gmail ou Outlook e a limpam manualmente de tempos em tempos. Essa abordagem quebra assim que você tem jobs paralelos, múltiplos ambientes ou implantações frequentes.
Caixas de entrada compartilhadas rapidamente se enchem de ruído, spam e mensagens de teste duplicadas. Os limites de taxa entram em ação. Os desenvolvedores passam mais tempo vasculhando pastas do que lendo logs de teste. Pior ainda, você pode acidentalmente usar a caixa de correio de um funcionário real, o que mistura dados de teste com comunicação pessoal e cria um pesadelo para auditorias.
Do ponto de vista do risco, usar caixas de correio reais para testes automatizados é difícil de justificar quando e-mails descartáveis e caixas de entrada temporárias estão disponíveis. O guia sobre como funcionam e-mails e correios temporários deixa claro que você pode separar o tráfego de teste da comunicação legítima sem perder a confiabilidade.
Como as caixas de entrada descartáveis se encaixam no CI/CD
A ideia central é simples: cada execução de CI/CD ou suíte de testes recebe seu próprio endereço descartável, vinculado apenas a usuários sintéticos e dados de curta duração. A aplicação em teste envia OTPs, links de verificação e notificações para esse endereço. Seu pipeline busca o conteúdo do e-mail por uma API ou um endpoint HTTP simples, extrai o que precisa e depois descarta a caixa de entrada.
Quando você adota um padrão estruturado, obtém testes determinísticos sem contaminar caixas de correio reais. Um guia temporário de e-mail para desenvolvedores mostra como os desenvolvedores já dependem de endereços descartáveis para experimentos; o CI/CD é uma extensão natural dessa ideia.
Elabore uma Estratégia de Caixa de Entrada Limpa
Antes de mexer no YAML, decida quantas caixas de entrada você precisa, por quanto tempo elas existem e quais riscos você se recusa a aceitar.
Caixas de entrada por build vs compartilhadas de teste
Existem dois padrões comuns. No padrão por build, cada execução de pipeline gera um endereço totalmente novo. Isso proporciona isolamento perfeito: sem e-mails antigos para filtrar, sem condições de corrida entre execuções simultâneas e um modelo mental fácil de entender. A desvantagem é que você precisa gerar e passar uma nova caixa de entrada toda vez, e depurar depois que a caixa expira pode ser mais difícil.
No padrão de caixa de entrada compartilhada, você aloca um endereço descartável por branch, ambiente ou suíte de testes. O endereço exato é reutilizado entre execuções, o que facilita a depuração e funciona bem para testes de notificação não críticos. Mas você deve manter a caixa de correio sob controle rigoroso para que ela não se torne um depósito de lixo a longo prazo.
Mapeando caixas de entrada para cenários de teste
Pense na alocação das suas caixas de entrada como design de dados de teste. Um endereço pode ser dedicado ao cadastro de conta, outro aos fluxos de redefinição de senha e um terceiro às notificações. Para ambientes multi-tenant ou baseados em região, você pode ir além e atribuir uma caixa de entrada por tenant ou por região para detectar divergências de configuração.
Use convenções de nomenclatura que codifiquem o cenário e o ambiente, como signup-us-east-@example-temp.com ou password-reset-staging-@example-temp.com. Isso facilita rastrear falhas até testes específicos quando algo dá errado.
Quando o e-mail temporário é a ferramenta errada
Recorra a uma caixa de entrada de teste gerenciada ou a um serviço interno de captura de e-mails no momento em que sua asserção depender de algo que uma caixa de entrada descartável não pode oferecer: um anexo para abrir, um histórico de mensagens que dure mais de um dia após a execução, ou uma conta que ainda precise ser recuperável no próximo trimestre. As caixas de entrada descartáveis dão o melhor de si em fluxos sintéticos de cadastro, OTP e notificação. Elas são a fixture errada para contas regulamentadas, vinculadas a pagamentos ou de propriedade humana — e escolhê-las nesses casos é como um teste que passa acaba não provando nada.
Escolhendo um provedor de e-mail descartável para CI/CD
Testes de e-mail em CI/CD exigem propriedades um pouco diferentes do uso casual e descartável. Entrega rápida de OTP, infraestrutura MX estável e alta entregabilidade importam muito mais do que interfaces sofisticadas. Artigos que explicam como a rotação de domínios melhora a confiabilidade do OTP mostram por que uma boa infraestrutura de entrada pode fazer ou quebrar sua automação.
Depois, verifique as restrições antes de construir sobre elas, porque são elas que decidem o que você pode afirmar. Muitos serviços de e-mail temporário, incluindo o Tmailor, são somente de recebimento e removem completamente os anexos recebidos — o corpo da mensagem chega, o arquivo não. Se um teste precisar abrir uma fatura em PDF ou um relatório gerado, uma caixa de entrada com anexos removidos não consegue executar essa asserção, e nenhuma quantidade de polling vai mudar isso. Verifique também a retenção: o Tmailor mantém uma mensagem visível por cerca de 24 horas, o que é suficiente para uma build e inútil para uma análise uma semana depois.
O acesso é outra questão a resolver cedo. O Tmailor agora publica uma API pública documentada de Temp Mail (REST, JSON) documentada que um executor de testes pode chamar diretamente: criar um endereço somente de recebimento, listar e ler suas mensagens e obter o código de uso único e os links que a API extrai de cada mensagem (melhor esforço). Existem SDKs oficiais para Python, Node.js e PHP, e o plano gratuito exige a inclusão de um IP de servidor na lista de permissões, então planeje de onde vêm as solicitações do seu runner. Use-a para testar seus próprios fluxos de cadastro, verificação e redefinição de senha. Trate o token de recuperação de qualquer provedor, e qualquer chave de API, como segredo em todos os casos.
Integrar o e-mail temporário ao GitHub Actions
O GitHub Actions facilita adicionar etapas prévias que criam caixas de entrada descartáveis e as injetam nos testes de integração como variáveis de ambiente.
Padrão: gerar a caixa de entrada antes dos jobs de teste
Um fluxo de trabalho típico começa com um job leve que invoca um script ou endpoint para criar um novo endereço de e-mail temporário. Esse job exporta o endereço como variável de saída ou o grava em um artefato. Os jobs seguintes do fluxo de trabalho leem o valor e o usam na configuração da aplicação ou no código de teste.
Se sua equipe é nova em endereços de e-mail temporários, primeiro faça um processo manual usando o guia de como conseguir um e-mail temporário rapidamente. Quando todos entenderem como a caixa de entrada aparece e como as mensagens chegam, automatizá-la no GitHub Actions se torna muito menos misterioso.
Consumindo e-mails de verificação nas etapas de teste
Dentro do seu job de teste, a aplicação em teste está configurada para enviar e-mails ao endereço gerado. Seu código de teste então consulta o endpoint da caixa de entrada descartável até encontrar o assunto correto, analisa o corpo do e-mail em busca de um OTP ou link de verificação e usa esse valor para concluir o fluxo.
Implemente timeouts e mensagens de erro claras de forma consistente. Se um OTP não chegar dentro de um prazo razoável, o teste deve falhar com uma mensagem que ajude a determinar se o problema está no seu provedor, na sua aplicação ou no próprio pipeline.
Limpando após cada execução do fluxo de trabalho
Se seu provedor usa caixas de entrada de curta duração com expiração automática, muitas vezes você não precisa de limpeza explícita. O endereço temporário desaparece após uma janela fixa, levando consigo os dados de teste. O que você deve evitar é despejar o conteúdo completo dos e-mails ou os OTPs em logs de build que duram muito mais do que a caixa de entrada.
Mantenha apenas metadados mínimos nos logs, incluindo qual cenário usou um e-mail temporário, se o e-mail foi recebido e métricas básicas de tempo. Quaisquer detalhes adicionais devem ser armazenados em artefatos seguros ou em ferramentas de observabilidade com controles de acesso adequados.
Integrar o e-mail temporário ao GitLab CI/CD
Os pipelines do GitLab podem tratar a criação de caixas de entrada descartáveis como uma etapa de primeira classe, alimentando os jobs seguintes com endereços de e-mail sem expor segredos.
Projetando etapas de pipeline cientes de e-mail
Um bom design no GitLab separa a criação da caixa de entrada, a execução dos testes e a coleta de artefatos em estágios distintos. O estágio inicial gera o endereço, armazena-o em uma variável mascarada ou em um arquivo seguro e só então aciona o estágio de testes de integração. Isso evita condições de corrida que ocorrem quando os testes rodam antes de a caixa de entrada estar disponível.
Passando Detalhes da Caixa de Entrada Entre Jobs
Dependendo da sua postura de segurança, você pode passar endereços de caixa de entrada entre jobs por meio de variáveis de CI, artefatos de job ou ambos. O endereço em si geralmente não é sensível, mas qualquer token que permita recuperar uma caixa de entrada reutilizável deve ser tratado como uma senha.
Mascare os valores sempre que possível e evite exibi-los em scripts. Se vários jobs compartilham uma única caixa de entrada descartável, defina o compartilhamento de forma intencional em vez de depender de reuso implícito, para não interpretar mal e-mails de execuções anteriores.
Depurando Testes Instáveis Baseados em E-mail
Quando os testes de e-mail falham de forma intermitente, comece distinguindo entre problemas de entrega e problemas de lógica de teste. Verifique se outros testes de OTP ou de notificação falharam na mesma época. Padrões de recursos como o checklist de risco OTP para QA podem orientar sua investigação.
Você também pode coletar cabeçalhos e metadados limitados das execuções com falha sem armazenar todo o corpo da mensagem. Isso geralmente basta para determinar se o e-mail foi limitado, bloqueado ou atrasado, respeitando a privacidade e os princípios de minimização de dados.
Integrar o E-mail Temporário ao CircleCI
Jobs e orbs do CircleCI podem encapsular todo o padrão "criar caixa de entrada → aguardar e-mail → extrair token", para que as equipes possam reutilizá-lo com segurança.
Padrão em Nível de Job para Testes de E-mail
No CircleCI, um padrão típico é ter uma etapa prévia que chama seu provedor de e-mail temporário, salva o endereço gerado em uma variável de ambiente e então executa seus testes de ponta a ponta. O código de teste se comporta exatamente como no GitHub Actions ou no GitLab CI: aguarda o e-mail, analisa o OTP ou o link e continua o cenário.
Usando Orbs e Comandos Reutilizáveis
À medida que sua plataforma amadurece, você pode encapsular o teste de e-mail em orbs ou comandos reutilizáveis. Esses componentes cuidam da criação da caixa de entrada, da consulta e da análise, e então retornam valores simples que os testes podem consumir. Isso reduz a necessidade de copiar e colar e facilita a aplicação das suas regras de segurança.
Escalando Testes de E-mail em Jobs Paralelos
O CircleCI facilita o alto paralelismo, o que pode amplificar problemas sutis de e-mail. Evite reutilizar a mesma caixa de entrada em muitos jobs paralelos. Em vez disso, distribua as caixas de entrada usando índices de job ou IDs de contêiner para minimizar colisões. Monitore as taxas de erro e os limites de taxa do lado do provedor de e-mail para identificar sinais de alerta precoce antes que pipelines inteiros falhem.
Reduzir Riscos nos Pipelines de Teste
As caixas de entrada descartáveis reduzem alguns riscos, mas criam novos, especialmente em relação ao tratamento de segredos, ao registro em logs e ao comportamento de recuperação de contas.
Mantendo Segredos e OTPs Fora dos Logs
Os logs do seu pipeline costumam ser armazenados por meses, enviados para gerenciamento externo de logs e acessados por pessoas que não precisam de acesso aos OTPs. Nunca imprima códigos de verificação, magic links ou tokens de caixa de entrada diretamente no stdout. Registre apenas que o valor foi recebido e usado com sucesso.
Para entender por que o tratamento de OTP exige cuidado especial, o correio temporário para verificação de OTP é um complemento valioso. Trate seus testes como se fossem contas reais: não normalize más práticas só porque os dados são sintéticos.
Tratando Tokens e Caixas de Entrada Reutilizáveis com Segurança
Alguns provedores permitem que você volte ao mesmo endereço mais tarde usando um token de recuperação — o Tmailor chama isso de Access Token —, o que é útil para ambientes de QA e UAT de longa duração. Seja preciso quanto ao que ele é, porque as equipes costumam errar nisso. É uma chave de recuperação, não uma senha nem uma fechadura: ela permite que você volte a um endereço, mas não impede que outra pessoa entre nele, e se você a perder para um endereço de convidado, ninguém poderá restaurá-la para você (endereços criados pela API Temp Mail permanecem na sua conta até você excluí-los). Portanto, guarde-a no mesmo cofre de segredos das suas chaves de API, partindo do princípio de que qualquer pessoa que a tenha pode acessar essa caixa de entrada — e não da crença equivocada de que ela protege a caixa de entrada. E observe o limite: ela recupera o endereço , não o correio. Mensagens que já envelheceram desapareceram, então uma caixa de entrada reutilizável não é um arquivo.
Quando você precisar de endereços de longa duração, siga as boas práticas do guia sobre como reutilizar um endereço temporário com segurança. Defina políticas de rotação, determine quem pode visualizar os tokens e documente o processo de revogação de acesso em caso de problema.
Conformidade e Retenção de Dados de Teste
Mesmo usuários sintéticos podem estar sujeitos a regras de privacidade e conformidade se você misturar dados reais por acidente. Janelas curtas de retenção na caixa de entrada ajudam: as mensagens desaparecem após um tempo fixo, o que está bem alinhado com o princípio da minimização de dados.
Documente uma política leve que explique por que o e-mail descartável é usado em CI/CD, quais dados são armazenados e onde, e por quanto tempo são mantidos. Isso facilita muito as conversas com as equipes de segurança, risco e compliance.
Medir e Ajustar os Testes de E-mail
Para manter os testes baseados em e-mail confiáveis a longo prazo, você precisa de observabilidade básica sobre o tempo de entrega, os modos de falha e o comportamento do provedor.
Acompanhe o Tempo de Entrega e a Taxa de Sucesso do OTP
Adicione métricas simples para registrar quanto tempo cada teste baseado em e-mail espera por um OTP ou link de verificação. Com o tempo, você vai notar uma distribuição: a maioria das mensagens chega rápido, mas algumas demoram mais ou nunca aparecem. Artigos que estudam como a rotação de domínios melhora a confiabilidade do OTP explicam por que isso acontece e como a rotação de domínios pode suavizar uma falha de entrega em um domínio específico. Mas seja claro sobre qual problema você está resolvendo: um endereço novo é válido quando um domínio específico não está recebendo, porque isso é uma falha de entrega. Se o serviço decidiu, por política, que não aceita e-mails descartáveis, alternar endereços até que um passe despercebido não é solução de problemas — use um endereço real que você controla.
Proteções para Quando os Fluxos de E-mail Falham
Decida com antecedência quando um e-mail ausente deve fazer todo o pipeline falhar e quando você prefere uma falha suave. Fluxos críticos de criação de conta ou login normalmente exigem falhas graves, enquanto notificações secundárias podem falhar sem bloquear a implantação. Regras explícitas impedem que os engenheiros de plantão tenham que adivinhar sob pressão.
Iterar sobre Provedores, Domínios e Padrões
O comportamento dos e-mails muda com o tempo conforme os filtros evoluem. Crie pequenos ciclos de feedback no seu processo monitorando tendências, executando testes de comparação periódicos em vários domínios e refinando seus padrões. Conteúdos exploratórios como o os casos de uso inesperados de e-mail temporário, podem inspirar cenários adicionais para sua suíte de QA.
Perguntas Frequentes
Essas respostas curtas ajudam sua equipe a adotar caixas de entrada descartáveis no CI/CD sem repetir as mesmas explicações em cada revisão de projeto.
Posso reutilizar a mesma caixa de entrada descartável em várias execuções de CI/CD?
Pode, mas você deve fazer isso de forma intencional. Reutilizar um endereço temporário por branch ou ambiente é aceitável para fluxos não críticos, desde que todos entendam que e-mails antigos ainda podem estar presentes. Para cenários de alto risco, como autenticação e faturamento, prefira uma caixa de entrada por execução, para que os dados de teste fiquem isolados e mais fáceis de raciocinar.
Como posso evitar que códigos OTP vazem para os logs de CI/CD?
Mantenha o tratamento do OTP dentro do código de teste e nunca imprima valores brutos. Registre eventos como "OTP recebido" ou "link de verificação aberto" em vez dos segredos reais. Certifique-se de que suas bibliotecas de log e modos de depuração não estejam configurados para despejar corpos de requisição ou resposta que contenham tokens sensíveis.
É seguro armazenar tokens de caixas de entrada descartáveis em variáveis de CI?
Sim, desde que você os trate como qualquer outro segredo de produção. Use variáveis criptografadas ou um gerenciador de segredos, restrinja o acesso a elas e evite exibi-las em scripts. Se um token for exposto, faça a rotação dele como faria com qualquer chave comprometida.
O que acontece se a caixa de entrada temporária expirar antes de meus testes terminarem?
Duas coisas expiram aqui, e vale a pena mantê-las separadas. No Tmailor, uma mensagem permanece visível por cerca de 24 horas após a chegada, e nenhuma configuração estende isso. Um Access Token reabre o mesmo endereço depois, mas restaura o endereço, não as mensagens que já passaram da janela — então uma build que ultrapassa a janela perde o e-mail, não a caixa de correio. A solução está do seu lado: execute as etapas de e-mail no início do pipeline, mantenha o cenário curto e valide a mensagem assim que ela chegar, em vez de no final de um job longo. Se um teste realmente precisa que o e-mail persista por dias, uma caixa de entrada temporária é o armazenamento errado, e uma caixa de teste gerenciada é a correta.
Quantas caixas de entrada descartáveis devo criar para suítes de testes paralelas?
Uma regra simples é uma caixa de entrada por worker paralelo para cada cenário central. Assim, você evita colisões e mensagens ambíguas quando muitos testes são executados ao mesmo tempo. Se o provedor tiver limites rígidos, você pode reduzir o número ao custo de uma lógica de análise um pouco mais complexa.
Usar endereços de e-mail temporários no CI/CD reduz a entregabilidade dos e-mails ou causa bloqueios?
Pode. A aceitação varia conforme o serviço de destino, o padrão de envio e a reputação do domínio, e pode mudar sem aviso, então meça em vez de presumir: acompanhe taxas de rejeição, atrasos na entrega e mensagens que nunca chegam. Um limite importa mais do que qualquer ajuste. Se os termos de um serviço não permitem e-mails descartáveis, isso é uma política, e a resposta não é alternar entre domínios até que um seja aceito — é usar um endereço de teste real e gerenciado. A rotação de domínios é uma solução para um domínio bloqueado, não uma forma de burlar uma regra.
Posso executar testes baseados em e-mail sem uma API pública de e-mail temporário?
Sim, mas com o Tmailor você não precisa mais disso. O Tmailor agora publica uma API pública documentada de e-mail temporário, com SDKs oficiais para Python, Node.js e PHP, para que um executor de testes possa criar um endereço, consultar a mensagem e ler o código ou link por um endpoint oficial. Quando um provedor documenta um endpoint de entrada, seu código de teste pode chamá-lo como qualquer outro serviço HTTP. Caso contrário, execute um pequeno serviço interno que faça a ponte entre o provedor e seu pipeline, expondo apenas os metadados que suas asserções realmente precisam.
Devo usar um e-mail descartável para dados semelhantes aos de produção ou apenas para usuários sintéticos de teste?
Limite as caixas de entrada descartáveis a usuários sintéticos criados exclusivamente para fins de teste. Contas de produção, dados reais de clientes e qualquer informação relacionada a dinheiro ou conformidade devem usar endereços de e-mail de longo prazo e devidamente gerenciados.
Como explico o e-mail descartável em pipelines para uma equipe de segurança ou de conformidade?
Apresente isso como uma forma de reduzir a exposição de endereços de e-mail confirmados e de PII durante os testes. Compartilhe políticas claras sobre retenção, registro em logs e gerenciamento de segredos, e faça referência à documentação que descreve a infraestrutura de entrada que você utiliza.
Quando devo escolher uma caixa de e-mail temporária reutilizável em vez de uma caixa de entrada de uso único?
Caixas de e-mail temporárias reutilizáveis fazem sentido para ambientes de QA de longa duração, sistemas de pré-produção ou testes exploratórios manuais em que você quer um endereço consistente. Elas são a escolha errada para fluxos de autenticação de alto risco ou experimentos sensíveis, em que o isolamento rigoroso é mais importante do que a conveniência.
Fontes e leituras adicionais
O comportamento das plataformas muda, então trate a documentação do fornecedor como autoridade sobre qualquer mecanismo específico: a documentação do GitHub sobre saídas de jobs e segredos mascarados, a do GitLab sobre variáveis mascaradas e arquivos seguros, e a do CircleCI sobre orbs e paralelismo. No lado do e-mail, os artigos complementares aqui vão mais fundo do que este guia consegue: o que funciona e falha com OTP, rotação de domínio e confiabilidade OTP, e o checklist de risco OTP para QA.
Conclusão
O e-mail descartável não é apenas um recurso de conveniência para formulários de cadastro. Usado com cuidado, ele se torna um bloco de construção poderoso dentro dos seus pipelines de CI/CD. Ao gerar caixas de entrada de curta duração, integrá-las ao GitHub Actions, ao GitLab CI e ao CircleCI, e aplicar regras rígidas sobre segredos e logs, você pode testar fluxos críticos de e-mail sem envolver caixas de entrada reais no processo.
Comece pequeno com um cenário, meça os padrões de entrega e de falha e, aos poucos, padronize uma abordagem que se encaixe na sua equipe. Com o tempo, uma estratégia intencional de e-mail descartável tornará seus pipelines mais confiáveis, suas auditorias mais fáceis e seus engenheiros menos receosos da palavra "email" nos planos de teste.
Marcus Lee writes Tmailor's step-by-step guides, signing up to apps and platforms with temp mail, using the mobile app and Telegram bot, custom domains, reusing addresses, and getting the most out of disposable email day to day.
