O Mailtrap Email Sandbox captura mensagens para inspeção durante o desenvolvimento. O Email API/SMTP de envio real entrega a destinatários externos. Um endereço de teste no campo To de uma captura não comprova recebimento naquela caixa. Para verificar Inbox Placement com o LDM, gere um original pela rota real da aplicação e avalie as pastas separadamente das prévias do Sandbox.
Essas etapas se complementam. O Sandbox ajuda a detectar um modelo quebrado antes do envio externo; a observação de pasta examina o que aconteceu depois que a mensagem percorreu a rota planejada. O procedimento é iniciado por você e não pressupõe integração nativa nem alterações feitas pelo LDM na conta Mailtrap.
Transporte, pasta e interação são observações diferentes.
Para que serve o Email Sandbox
O Mailtrap descreve o Sandbox como um ambiente que captura mensagens para inspeção. Ele oferece prévias de HTML e texto, análise de cabeçalhos, anexos e pontuação de spam. Consulte a visão geral oficial.
Verifique o conteúdo construído pela aplicação: os campos foram preenchidos? O assunto corresponde ao evento? A versão em texto contém a informação essencial? Os cabeçalhos e anexos previstos estão presentes? Essas verificações encontram defeitos sem medir uma caixa externa.
A captura confirma que o Sandbox recebeu aquela submissão. O destinatário exibido faz parte do conteúdo inspecionado; não é um comprovante de recebimento externo. Da mesma forma, uma pontuação favorável de análise não estabelece a pasta escolhida por um provedor.
O envio real exige outra configuração
O guia de Email API/SMTP documenta o envio real e exige um domínio verificado. Conclua as etapas de configuração e aprovação aplicáveis à conta. Enquanto o envio externo não estiver disponível, continue as verificações de desenvolvimento no Sandbox.
O destino da conexão importa. A documentação identifica sandbox.smtp.mailtrap.io como host SMTP do Sandbox. Para API direta, distingue esse ambiente do endpoint transacional real, https://send.api.mailtrap.io/api/send, e do endpoint de envio em massa, https://bulk.api.mailtrap.io/api/send.
Mudar somente o destinatário não faz essa transição. Em SMTP, confira host e credenciais efetivos. Em um SDK, confira a configuração de sandbox documentada para a biblioteca instalada. Na API, examine o endpoint. Preserve a rota apropriada à comunicação avaliada.
Etapas para verificar a pasta de destino
1. Prepare uma referência de conteúdo no Sandbox
Acione o evento correspondente com dados fictícios realistas, sem informações confidenciais. Inspecione a captura e corrija problemas evidentes de conteúdo ou personalização. Registre a versão do modelo e da aplicação para reutilizar a mesma lógica na etapa seguinte.
Preserve assunto, HTML, texto simples, links e anexos previstos. Mantenha os cabeçalhos e mecanismos obrigatórios de descadastro: removê-los torna a amostra menos representativa da comunicação real.
2. Delimite o experimento real
Escolha uma pergunta concreta, como: “Em quais pastas este recibo final aparece pela rota transacional configurada?” Registre remetente, rota e versão do modelo.
Crie uma tarefa com destinatários explícitos e quantidade limitada. Mantenha o tráfego comum de homologação no Sandbox. Não é necessário transformar todos os eventos de desenvolvimento em envios externos para realizar essa verificação.
3. Confirme que a rota está pronta
Confira as configurações de envio real e o estado do domínio. Use os dados de integração da conta; não reutilize credenciais do Sandbox nem presuma que um exemplo genérico reproduz sua configuração.
Registre o uso de SMTP, API direta ou SDK. Preserve a geração de conteúdo e os cabeçalhos relevantes. Exclua tokens e senhas de capturas de tela, registros de configuração e relatórios.
4. Obtenha os endereços atuais do LDM
Crie um teste no LDM Inbox Placement com o remetente real e use os destinatários fornecidos. A interface do teste também está disponível em português.
Respeite o fluxo permitido pela plataforma. Não inclua os endereços em warmup, públicos permanentes ou eventos recorrentes. Registros temporários da aplicação não devem acionar mensagens futuras. Preserve as restrições existentes de destinatários.
5. Gere e envie um novo original
Faça a aplicação montar e enviar a mensagem diretamente pela rota real. Não encaminhe a captura do Sandbox ou uma cópia recebida por um funcionário ao LDM. O encaminhamento introduz outro contexto e pode utilizar outro caminho, sem reproduzir o envio original da aplicação.
Guarde resultado da submissão, horário, referência da mensagem e identificador da tarefa. Consulte os registros de envio antes de concluir que uma cópia ausente chegou ao provedor destinatário.
6. Interprete a observação
Siga a metodologia LDM. Missing e unknown não significam Spam. Promoções e outras categorias são locais de recebimento, distintos da caixa principal e de Spam.
As 24 horas acompanham a mesma cópia recebida, sem reenviar a mensagem em cada verificação. Registre pasta e horário juntos. Se modificar o modelo e enviar novamente, trate isso como outro experimento, não como nova observação da cópia anterior.
Exemplo hipotético: captura confundida com entrega
Imagine que um desenvolvedor use destinatários LDM nos dados de um recibo de compra. A mensagem aparece no Sandbox, está visualmente correta e passa nas verificações de conteúdo. Como o LDM não confirma recebimento, alguém sugere alterar o domínio.
Neste exemplo hipotético, a aplicação ainda utiliza o host SMTP do Sandbox. A captura confirma a submissão de desenvolvimento, não a entrega externa. Ainda não existe evidência de avaliação pelo filtro do destinatário.
O desenvolvedor mantém a homologação isolada e prepara uma tarefa limitada pela rota real verificada. Suponha que os resultados incluam caixa principal, categoria secundária e uma observação desconhecida. Preserve os três estados: desconhecido não é Spam, e categoria secundária não deve ser apresentada como falha de entrega.
O que comparar após o primeiro envio
Associe a captura do Sandbox e o registro real à mesma versão do modelo. Se houver diferenças inesperadas, investigue dados de teste, blocos condicionais, tratamento de links, cabeçalhos e rota. Essa comparação ajuda a localizar a etapa em que o conteúdo mudou.
Para outro experimento, preserve a referência e documente uma alteração específica. Se vários componentes mudarem juntos, descreva o resultado como avaliação da nova configuração. Mesmo um conjunto totalmente observado não prevê as regras e o comportamento de todos os clientes.
Perguntas frequentes
Basta colocar endereços de teste em uma mensagem do Sandbox?
Não. O campo de destinatário não comprova recebimento externo. Confirme que a tarefa isolada utiliza a rota de envio real e depois examine as observações das caixas externas.
Uma pontuação baixa de spam no Sandbox garante Inbox?
Não. Análise de conteúdo e localização na caixa são medições distintas. A pontuação pode orientar uma revisão, mas não demonstra como um provedor classificou uma cópia recebida.
Posso encaminhar a captura em vez de gerar outro original?
O encaminhamento pode ajudar alguém a inspecionar conteúdo, mas não reproduz o caminho original da aplicação ao destinatário. Para este teste, gere um novo original pela rota avaliada.
Devo trocar toda a homologação para envio real?
Não. Mantenha o desenvolvimento comum isolado. Use uma tarefa limitada, com destinatários explícitos e rota documentada, evitando incluir eventos não relacionados no experimento.
E se meu domínio ainda não puder fazer envios reais?
Continue as verificações de conteúdo e aplicação disponíveis no Sandbox. Conclua os requisitos aplicáveis do Mailtrap antes da observação externa. Uma rota ainda indisponível não é evidência de Spam.
Acrescente a observação externa
Inicie um teste LDM quando a mensagem final e a rota permitida estiverem prontas. Relacione inspeção de conteúdo, registros de envio e pastas observadas em um único registro verificável.