O parâmetro o:testmode faz o Mailgun aceitar uma mensagem para teste sem enviá-la ao destinatário. Colocar um endereço LDM nessa requisição não produz uma observação real de pasta. Para medir Inbox Placement, prepare um envio permitido pela rota efetivamente utilizada, envie o original aos destinatários fornecidos pelo LDM e compare os registros de envio com as pastas observadas.
Antes de investigar uma cópia ausente, determine se a requisição deveria entregar alguma mensagem. Uma proteção de desenvolvimento pode ser confundida com problema de reputação quando essa distinção fica escondida. O procedimento abaixo usa destinatários de teste e não pressupõe integração nativa Mailgun–LDM.
Não encontrar uma cópia após uma busca concluída é diferente de uma caixa indisponível ou de uma verificação pendente.
O significado de o:testmode
O guia oficial de test mode informa que definir o:testmode como yes ou true faz o Mailgun aceitar a mensagem sem enviá-la. A documentação também informa que mensagens nesse modo são cobradas. Portanto, não presuma gratuidade apenas porque não há entrega externa.
A ausência de uma cópia no destinatário é esperada nessa configuração. Alterar o campo to para um endereço LDM não modifica o comportamento de uma requisição que continua com test mode ativado.
Use essa etapa para examinar a construção da requisição e o tratamento da resposta pela aplicação. Registre o resultado como teste de processamento. A observação de pasta exige outra mensagem, habilitada para entrega real.
Preserve o caminho utilizado pelo Mailgun
A referência da API Messages documenta o envio de componentes individuais para o Mailgun montar a mensagem e o envio de uma mensagem MIME existente. SMTP é outra rota suportada.
Se a aplicação produz MIME com cabeçalhos e anexos próprios, um exemplo curto de API não representa necessariamente esse conteúdo. Se utiliza um modelo armazenado e dados individuais, HTML avulso não valida o resultado daquele modelo.
Anote domínio de envio, endereço From visível, método de submissão, versão do modelo e opções efetivas. Registre também o rastreamento: a API oferece controles por mensagem. Primeiro mantenha uma referência correspondente ao envio planejado; depois compare alterações opcionais.
Como executar um teste controlado
1. Escolha a mensagem e prepare os dados
Selecione uma comunicação concreta, como recibo de compra ou atualização de produto enviada com permissão. Defina se a pergunta envolve um modelo novo, uma mudança de rota ou a configuração atual.
Use dados fictícios realistas, sem informações confidenciais. Revise assunto, HTML, texto simples, links e anexos. Preserve os mecanismos obrigatórios de descadastro e registre a versão, evitando alterações silenciosas durante a comparação.
2. Examine a configuração efetiva
Confira o que a aplicação realmente submete, incluindo opções acrescentadas por componentes auxiliares, tarefas de fila ou variáveis do ambiente. Em HTTP, procure o:testmode ativado. Em SMTP, examine os controles suportados pela implementação; um parâmetro HTTP não deve ser tratado como configuração SMTP.
Verifique também se existe um horário futuro de envio. Uma mensagem ainda agendada não deve ser diagnosticada como falha de observação. Exclua credenciais dos registros capturados.
3. Conclua o teste sem entrega
Se test mode faz parte do desenvolvimento, execute essa etapa e confira o tratamento da resposta. Mantenha seu registro separado do envio real posterior.
Um identificador retornado nesse processamento não comprova que uma caixa externa recebeu o e-mail. Salve o modo utilizado junto com o identificador para que outra pessoa consiga interpretar o registro.
4. Obtenha os destinatários do LDM
Informe o remetente no LDM Inbox Placement e obtenha os endereços atuais. A interface do teste também está disponível em português.
Use destinatários temporários em uma tarefa limitada. Não os acrescente a warmup, listas permanentes ou eventos recorrentes. Confirme as permissões da conta e do domínio. Restrições ou supressões precisam ser investigadas, não contornadas para forçar o teste.
5. Envie um novo original pela rota real
Prepare uma tarefa separada para o envio real. No fluxo HTTP, retire a opção test mode daquela requisição e confira a configuração final antes da submissão. Preserve as proteções das demais tarefas de homologação.
Gere o conteúdo pelo caminho normal da aplicação e envie diretamente aos destinatários LDM. Não encaminhe uma cópia recebida. Mantenha cabeçalhos e descadastro obrigatório; guarde horário, referência da tarefa, resposta Mailgun e identificador disponível da mensagem.
6. Compare evidências diferentes
Consulte os registros de envio e aplique a metodologia LDM. Missing ou unknown não demonstram Spam. Promoções e outras categorias são locais de recebimento diferentes da caixa principal e de Spam.
A janela de 24 horas acompanha a mesma cópia recebida, sem novos envios periódicos. Preserve os horários confirmados. Uma falha de observação posterior não apaga um achado anterior nem comprova a localização atual da cópia.
Exemplo hipotético: test mode acrescentado por outro componente
Imagine que um desenvolvedor substitua os destinatários pelos endereços de teste e receba uma resposta de aceitação. Nenhuma cópia aparece. Como o código visível não menciona test mode, a equipe suspeita dos novos links do modelo.
Ao examinar a requisição efetiva, encontra um componente de desenvolvimento que acrescenta o:testmode=yes. Neste exemplo hipotético, a configuração sem entrega explica a ausência. Não existe evidência de que os links tenham causado uma decisão de filtragem.
Após corrigir apenas a tarefa isolada, a equipe envia um original novo. Suponha que uma cópia apareça em Spam e outra permaneça desconhecida porque a caixa não pôde ser lida. Registre os dois estados separadamente e investigue a cópia recebida sem transformar a falta de observação no mesmo diagnóstico.
Prepare uma comparação interpretável
Se a referência mostrar um problema, escolha uma pergunta específica. Você pode comparar uma alteração opcional no rastreamento de cliques, mantendo remetente, conteúdo e rota estáveis. Preserve o descadastro obrigatório em ambas as versões.
Uma diferença orienta a investigação; um par de envios não demonstra uma regra universal sobre rastreamento ou plataforma. Horário e condições dos destinatários também podem variar. Relate a mudança observada e os limites do experimento, sem prometer melhora para toda a audiência.
Perguntas frequentes
Um identificador Mailgun prova que a mensagem foi entregue?
Não. Interprete o identificador junto com o modo da requisição e os eventos posteriores. Ele permite rastrear a mensagem, mas não certifica recebimento externo ou uma pasta específica.
Posso manter test mode ativado e mudar somente o destinatário?
Não. A configuração de entrega também precisa corresponder ao experimento. Prepare uma requisição real separada, permitida e limitada, verificando os valores efetivos antes de enviá-la.
Devo trocar SMTP por HTTP para testar?
Somente se HTTP for a rota que você deseja avaliar. Caso contrário, preserve o caminho SMTP e a geração de conteúdo. Identifique explicitamente uma comparação entre rotas, sem presumir equivalência.
O LDM substitui os registros de envio do Mailgun?
Não. Os registros ajudam a explicar o que a aplicação submeteu e os eventos de entrega. A observação da caixa acrescenta evidências sobre cópias específicas. Use as duas fontes em conjunto.
Todo resultado fora da caixa principal deve ser contado como Spam?
Não. Categoria secundária, Spam confirmado, busca concluída sem encontrar a cópia e impossibilidade de observar a caixa são situações diferentes. Preserve a classificação efetivamente sustentada pelos dados.
Observe uma mensagem real
Crie um teste LDM e faça um envio limitado pela rota real do Mailgun. Mantenha modo, identidade da mensagem e pastas observadas no mesmo registro de diagnóstico.