E-mail descartável em CI/CD: teste fluxos de OTP e cadastro no GitHub, GitLab e CircleCI
Conjuntos de testes automatizados falham assim que dependem de uma caixa de entrada real. Caixas de entrada compartilhadas ficam poluídas entre execuções paralelas, os códigos OTP expiram antes que as verificações sejam executadas e credenciais expostas nos logs transformam uma build bem-sucedida 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ê aprenderá a gerar caixas de entrada por build, consumir e-mails de verificação durante as etapas de teste, manter tokens fora dos logs e fazer a limpeza após cada execução. Seja para testar fluxos de cadastro, entrega de OTP ou notificações transacionais, os padrões apresentados escalam de um único fluxo de trabalho a um conjunto completo de testes paralelos.
Acesso rápido
Principais conclusões para equipes DevOps ocupadas
Se seus testes de CI/CD dependem de e-mails, você precisa de uma estratégia estruturada de e-mail descartável; caso contrário, acabará lançando bugs, vazando segredos ou fazendo as duas coisas.
- Os 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 organizada de e-mail descartável relaciona o ciclo de vida da caixa de entrada ao ciclo de vida do pipeline, mantendo os testes determinísticos e protegendo usuários reais e as caixas de correio dos funcionários.
- GitHub Actions, GitLab CI e CircleCI podem gerar, transmitir e usar endereços de e-mail temporário como variáveis de ambiente ou saídas de jobs.
- A segurança depende de regras rígidas: nenhum OTP ou token da caixa de entrada é registrado, a retenção é curta e caixas de entrada reutilizáveis só são permitidas quando o perfil de risco dá margem para isso.
- Com instrumentação básica, você pode monitorar o tempo de entrega do OTP, os padrões de falha e os 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 todos os problemas de caixa de entrada que você ignora no staging.
Onde o e-mail aparece nos 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 percorrer vários fluxos, incluindo cadastro de conta, verificação por OTP ou magic link, redefinição de senha, confirmação de alteração do endereço de e-mail, avisos de cobrança e alertas de uso.
Todos esses fluxos dependem da capacidade de receber uma mensagem rapidamente, analisar 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 no CI/CD.
Por que caixas de correio reais não escalam no QA
Em pequena escala, as equipes costumam executar testes em uma caixa de entrada compartilhada do Gmail ou Outlook e limpá-la manualmente de tempos em tempos. Essa abordagem deixa de funcionar assim que você tem jobs paralelos, vários ambientes ou implantações frequentes.
As 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, misturando dados de teste com comunicações pessoais e criando um pesadelo de auditoria.
Do ponto de vista do risco, é difícil justificar o uso de caixas de correio reais em testes automatizados quando há e-mail descartável e caixas de entrada temporárias disponíveis. O guia sobre como funcionam e-mails e correios temporários deixa claro que é possível separar o tráfego de teste das comunicações legítimas 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 de e-mail temporário, 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. O pipeline busca o conteúdo do e-mail por meio de uma API ou de 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á usam endereços de e-mail temporário em experimentos; o CI/CD é uma extensão natural dessa ideia.
Elabore uma estratégia organizada de caixa de entrada
Antes de mexer no YAML, decida de quantas caixas de entrada você precisa, por quanto tempo elas permanecerão ativas e quais riscos você se recusa a aceitar.
Caixas de entrada por build versus caixas de entrada de teste compartilhadas
Há dois padrões comuns. No padrão por build, cada execução do pipeline gera um endereço totalmente novo. Isso proporciona isolamento perfeito: não há e-mails antigos para filtrar, nem condições de corrida entre execuções simultâneas, e o modelo mental é fácil de entender. A desvantagem é que você precisa gerar e transmitir uma nova caixa de entrada a cada execução, e a depuração pode ser mais difícil depois que a caixa expira.
No padrão de caixa de entrada compartilhada, você aloca um endereço de e-mail descartável por branch, ambiente ou suíte de testes. O mesmo endereço é reutilizado entre as execuções, o que facilita a depuração e funciona bem para testes de notificações não críticos. Mas é preciso manter a caixa de correio sob controle rigoroso para que ela não se transforme em um depósito permanente.
Mapeando caixas de entrada para cenários de teste
Pense na alocação das caixas de entrada como parte do design dos dados de teste. Um endereço pode ser dedicado ao registro de contas, outro aos fluxos de redefinição de senha e um terceiro às notificações. Em ambientes multi-tenant ou baseados em regiões, você pode ir além e atribuir uma caixa de entrada por tenant ou por região para detectar desvios 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 as falhas até testes específicos quando algo dá errado.
Quando o e-mail temporário é a ferramenta errada
Opte por uma caixa de entrada de teste gerenciada ou por um serviço interno de captura de e-mails assim que sua asserção depender de algo que uma caixa de entrada descartável não possa oferecer: um anexo para abrir, um histórico de mensagens que sobreviva à execução por mais de um dia ou uma conta que ainda precise ser recuperável no próximo trimestre. Caixas de entrada descartáveis são ideais para fluxos sintéticos de cadastro, OTP e notificações. Elas são o recurso errado para contas regulamentadas, vinculadas a pagamentos ou pertencentes a pessoas — e escolhê-las nesses casos é como fazer um teste passar sem que ele prove nada.
Escolhendo um provedor de e-mail descartável para CI/CD
Os testes de e-mail em CI/CD exigem características um pouco diferentes das de um uso casual de e-mail descartável. A entrega rápida de OTP, uma infraestrutura MX estável e uma alta capacidade de entrega são muito mais importantes 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 recebimento pode determinar o sucesso ou o fracasso da sua automação.
Depois, verifique as limitações antes de usá-los como base, pois elas determinam o que você pode validar. Muitos serviços de e-mail temporário, incluindo o Tmailor, permitem apenas o recebimento e removem completamente os anexos recebidos — o corpo da mensagem chega, mas o arquivo não. Se um teste precisar abrir uma fatura em PDF ou um relatório gerado, uma caixa de entrada que remove anexos não poderá executar essa validação, e nenhuma quantidade de tentativas de consulta 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 compilação e inútil para uma análise posterior uma semana depois.
O acesso é outra lacuna que vale a pena mencionar desde o início. O Tmailor não publica uma API pública documentada, portanto não é um destino de consulta pronto para um executor de testes; se você precisa de recuperação programática, escolha um provedor que documente um endpoint de recebimento ou crie um pequeno serviço interno sob seu controle. Trate o token de recuperação de qualquer provedor como um segredo, independentemente de qualquer outra coisa.
Integrando o e-mail temporário ao GitHub Actions
O GitHub Actions facilita adicionar etapas preliminares que criam caixas de entrada descartáveis e as disponibilizam para os testes de integração como variáveis de ambiente.
Padrão: gerar uma caixa de entrada antes dos jobs de teste
Um fluxo de trabalho típico começa com um job leve que chama um script ou endpoint para criar um novo endereço de e-mail temporário. Esse job exporta o endereço como uma variável de saída ou o grava em um artefato. Os jobs seguintes do fluxo de trabalho leem esse valor e o usam na configuração da aplicação ou no código de teste.
Se sua equipe ainda não conhece endereços de e-mail temporários, primeiro percorra manualmente um fluxo usando o guia sobre como conseguir um e-mail temporário rapidamente. Quando todos entenderem como a caixa de entrada aparece e como as mensagens chegam, automatizar o processo no GitHub Actions se tornará muito menos misterioso.
Consumindo e-mails de verificação nas etapas de teste
No job de teste, a aplicação em teste é configurada para enviar e-mails ao endereço gerado. O 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 consistentes e mensagens de erro claras. Se um OTP não chegar dentro de um prazo razoável, o teste deverá falhar com uma mensagem que ajude a determinar se o problema está no provedor, na aplicação ou no próprio pipeline.
Limpando tudo após cada execução do fluxo de trabalho
Se o provedor usar caixas de entrada de curta duração com expiração automática, muitas vezes não será necessário fazer uma limpeza explícita. O endereço temporário desaparece após um período fixo, levando consigo os dados de teste. O que você deve evitar é despejar o conteúdo completo dos e-mails ou OTPs em logs de compilação que permanecem disponíveis por muito mais tempo 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.
Integrando 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, repassando endereços de e-mail para jobs posteriores sem expor segredos.
Projetando Estágios de Pipeline Cientes de E-mail
Um design limpo 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 são executados antes que a caixa de entrada esteja disponível.
Passando Detalhes da Caixa de Entrada Entre Jobs
Dependendo da sua postura de segurança, você pode passar os endereços das caixas de entrada entre jobs por meio de variáveis de CI, artefatos de jobs 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 compartilharem uma única caixa de entrada descartável, defina esse compartilhamento intencionalmente em vez de depender do reuso implícito, para não interpretar incorretamente e-mails de execuções anteriores.
Depurando Testes Instáveis Baseados em E-mail
Quando os testes de e-mail falharem de forma intermitente, comece distinguindo problemas de entrega de problemas na lógica dos testes. Verifique se outros testes de OTP ou de notificações falharam na mesma época. Padrões identificados em recursos como o checklist de risco OTP para QA podem orientar sua investigação.
Você também pode coletar cabeçalhos e metadados limitados de execuções com falha sem armazenar todo o corpo da mensagem. Isso geralmente é suficiente para determinar se o e-mail foi limitado, bloqueado ou atrasado, respeitando a privacidade e os princípios de minimização de dados.
Integrando o E-mail Temporário ao CircleCI
Os jobs e orbs do CircleCI podem encapsular todo o padrão "criar caixa de entrada → esperar pelo e-mail → extrair o token", para que as equipes possam reutilizá-lo com segurança.
Padrão de Job para Testes de E-mail
No CircleCI, um padrão típico consiste em ter uma etapa preliminar que chama seu provedor de e-mail temporário, salva o endereço gerado em uma variável de ambiente e, em seguida, executa os 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 dá continuidade ao cenário.
Usando Orbs e Comandos Reutilizáveis
À medida que sua plataforma amadurece, você pode encapsular os testes 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, depois 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.
Dimensionando Testes de E-mail em Jobs Paralelos
O CircleCI facilita um alto nível de 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 jobs ou IDs de contêineres para minimizar colisões. Monitore as taxas de erro e os limites de requisições no provedor de e-mail para identificar sinais de alerta precoces, antes que pipelines inteiros falhem.
Reduzindo Riscos nos Pipelines de Teste
Caixas de entrada descartáveis reduzem alguns riscos, mas criam outros, especialmente relacionados ao gerenciamento de segredos, aos logs e ao comportamento de recuperação de contas.
Mantendo Segredos e OTPs Fora dos Logs
Seus logs de pipeline geralmente são armazenados por meses, enviados para serviços externos de gerenciamento de logs e acessados por pessoas que não precisam ter acesso aos OTPs. Nunca imprima códigos de verificação, magic links ou tokens de caixas de entrada diretamente na saída padrão. Registre apenas que o valor foi recebido e usado com sucesso.
Para entender por que o tratamento de OTP exige cuidados especiais, o correio temporário para verificação de OTP é um complemento valioso. Trate seus testes como se usassem contas reais: não normalize más práticas apenas porque os dados são sintéticos.
Gerenciando Tokens e Caixas de Entrada Reutilizáveis com Segurança
Alguns provedores permitem que você retorne ao mesmo endereço posteriormente 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 sobre o que ele é, porque as equipes frequentemente entendem isso errado. É 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 outras pessoas acessem um endereço e, se você a perder, ninguém poderá restaurá-la para você. Portanto, armazene-a no mesmo cofre de segredos que suas chaves de API, partindo do princípio de que qualquer pessoa que a possua poderá 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 a caixa de correio. As mensagens que já expiraram desapareceram, portanto uma caixa de entrada reutilizável não é um arquivo.
Quando precisar de endereços de longa duração, siga as melhores 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 para revogar o 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 acidentalmente dados reais. Janelas curtas de retenção da caixa de entrada ajudam: as mensagens desaparecem após um período fixo, o que se alinha bem ao princípio da minimização de dados.
Documente uma política simples que explique por que o e-mail descartável é usado no CI/CD, quais dados são armazenados, onde e por quanto tempo são mantidos. Isso facilita muito as conversas com as equipes de segurança, risco e compliance.
Meça e ajuste os testes de e-mail
Para manter a confiabilidade dos testes baseados em e-mail a longo prazo, é necessária uma observabilidade básica do tempo de entrega, dos modos de falha e do comportamento do provedor.
Acompanhe o tempo de entrega do OTP e a taxa de sucesso
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ê perceberá uma distribuição: a maioria das mensagens chega rapidamente, 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 amenizar uma falha de entrega em um domínio específico. Seja claro, porém, sobre qual problema você está resolvendo: um endereço novo é uma opção válida quando um domínio específico não está recebendo mensagens, pois isso é uma falha de entrega. Se o serviço decidiu, por política, que não aceita e-mail descartável, alternar entre endereços até que um passe despercebido não é solução de problemas — use um endereço real sob seu controle.
Salvaguardas quando os fluxos de e-mail falham
Decida antecipadamente quando a ausência de um e-mail deve fazer todo o pipeline falhar e quando você prefere uma falha branda. Fluxos críticos de criação ou login de conta normalmente exigem falhas rígidas, enquanto notificações secundárias podem falhar sem bloquear a implantação. Regras explícitas evitam que os engenheiros de plantão tenham de adivinhar sob pressão.
Aperfeiçoando provedores, domínios e padrões
O comportamento dos e-mails muda com o tempo à medida que os filtros evoluem. Crie pequenos ciclos de feedback no seu processo monitorando tendências, realizando testes comparativos periódicos com vários domínios e refinando seus padrões. Conteúdos exploratórios, como os casos de uso inesperados de correspondência temporária, podem inspirar cenários adicionais para sua suíte de QA.
FAQ
Estas 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 essa decisão deve ser intencional. Reutilizar um endereço de e-mail 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 manter os dados de teste isolados e facilitar a análise.
Como posso evitar que códigos OTP vazem para os logs do CI/CD?
Mantenha o tratamento do OTP dentro do código de teste e nunca imprima os valores brutos. Registre eventos como "OTP recebido" ou "link de verificação aberto" em vez dos segredos propriamente ditos. Certifique-se de que suas bibliotecas de logging e os modos de depuração não estejam configurados para despejar corpos de requisições ou respostas que contenham tokens confidenciais.
É seguro armazenar tokens de caixas de entrada descartáveis em variáveis de CI?
Sim, desde que você os trate como outros segredos de nível de produção. Use variáveis criptografadas ou um gerenciador de segredos, restrinja o acesso a elas e evite exibi-las em scripts. Se algum token for exposto, faça sua rotação 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 é importante mantê-las separadas. No Tmailor, uma mensagem permanece visível por cerca de 24 horas após a chegada, e nenhuma configuração prolonga esse período. Um Access Token reabre o mesmo endereço posteriormente, mas restaura o endereço, não as mensagens que já expiraram — portanto, uma build que ultrapassa essa janela perde o e-mail, não a caixa de correio. A correção depende de você: 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 esperar até o fim de um job longo. Se um teste realmente precisa que as mensagens persistam por dias, uma caixa de entrada temporária é o armazenamento inadequado; nesse caso, use uma caixa de teste gerenciada.
Quantas caixas de entrada descartáveis devo criar para suítes de testes paralelos?
Uma regra prática simples é usar 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 simultaneamente. Se o provedor tiver limites rígidos, você pode reduzir essa quantidade, 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 ou causa bloqueios?
Pode causar. 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; portanto, meça em vez de presumir: acompanhe as taxas de rejeição, os atrasos na entrega e as mensagens que nunca chegam. Um limite é mais importante do que qualquer ajuste. Se os termos de um serviço não permitem e-mail descartável, 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 corrige um domínio que entrou em uma lista de bloqueio; não é uma forma de contornar uma regra.
Posso executar testes baseados em e-mail sem uma API pública de e-mail temporário?
Sim, e talvez seja necessário. O Tmailor não publica uma API pública documentada, então um executor de testes não tem nada oficial para consultar — ele foi projetado para uma pessoa ler uma caixa de entrada no navegador, não para um agente de build. 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 de 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 uso de e-mail descartável em pipelines para uma equipe de segurança ou compliance?
Apresente-o 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 e gerenciamento de segredos, além de consultar a documentação que descreve a infraestrutura de entrada utilizada.
Quando devo escolher uma caixa de correio temporária reutilizável em vez de uma caixa de entrada de uso único?
Caixas de correio 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ê deseja um endereço consistente. Elas são a escolha errada para fluxos de autenticação de alto risco ou experimentos sensíveis, nos quais 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 para 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 que diz respeito ao e-mail, os artigos complementares aqui se aprofundam mais 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.
Em resumo
O e-mail descartável não é apenas um recurso de conveniência para formulários de inscrição. Usado com cuidado, ele se torna um poderoso bloco de construção 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 para segredos e registros, você pode testar fluxos críticos de e-mail sem envolver caixas de entrada reais no processo.
Comece com um único cenário, meça os padrões de entrega e falha e, gradualmente, padronize uma abordagem que se adapte à 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.
