Magento 2 não envia e-mails? 9 testes para achar a falha antes de reenviar

Magento 2 não envia e-mails de pedidos, faturas, recuperação de senha ou formulários de contato? Antes de reenviar mensagens manualmente ou trocar o módulo SMTP, é preciso descobrir se o e-mail não foi gerado, ficou aguardando processamento, foi recusado pelo servidor de saída ou acabou filtrado pelo destinatário.

Esses cenários produzem sintomas parecidos, mas exigem correções diferentes. Os testes a seguir ajudam a localizar a interrupção sem alterar várias configurações ao mesmo tempo e sem transformar clientes reais em destinatários de testes.

Primeiro, descubra quais e-mails deixaram de chegar

Comece delimitando o alcance do problema. Registre o tipo de mensagem, horário da tentativa, loja ou website envolvido, endereço do destinatário e evento que deveria ter iniciado o envio.

• Nenhum e-mail é enviado: investigue configuração global, transporte de e-mail, credenciais, rede e cron.
• Somente mensagens de vendas falham: verifique configurações de pedidos, faturas, remessas e envio assíncrono.
• Apenas um website ou store view é afetado: compare o escopo das configurações e as identidades de remetente.
• Somente um domínio não recebe: procure rejeição, bloqueio ou filtragem no destino.
• O e-mail chega com atraso: verifique cron, filas no provedor e limites do serviço de saída.

Também confirme se o evento realmente ocorreu. Se o pagamento foi aprovado fora da plataforma, mas o pedido não foi criado, não existe necessariamente uma mensagem de confirmação para enviar. Nesse caso, siga o diagnóstico de pagamento aprovado sem pedido no Magento 2 antes de investigar apenas o e-mail.

Magento 2 não envia e-mails: faça estes 9 testes

1. Confirme se o envio está habilitado

No painel administrativo, revise as opções em Lojas > Configuração > Avançado > Sistema > Configurações de envio de e-mail. A nomenclatura pode variar conforme a versão, o idioma e as extensões instaladas.

Verifique principalmente se a comunicação por e-mail está desabilitada. Pela linha de comando, uma consulta útil é:

bin/magento config:show system/smtp/disable

Considere o escopo da configuração. Um valor correto no nível padrão pode ser sobrescrito para determinado website ou loja. Não altere esse parâmetro em produção antes de entender por que ele foi definido — ambientes clonados ou de homologação costumam manter o envio bloqueado intencionalmente.

2. Revise as configurações de cada e-mail de vendas

Pedidos, faturas, remessas e notas de crédito possuem configurações próprias. Em Lojas > Configuração > Vendas > E-mails de vendas, confirme se o tipo afetado está habilitado, qual identidade aparece como remetente e qual template foi selecionado.

Faça a conferência no escopo da store view que originou a venda. Uma loja pode usar a configuração padrão enquanto outra contém um template removido, um remetente incompleto ou o envio desativado.

3. Verifique se o envio assíncrono depende de um cron parado

Quando o envio assíncrono de mensagens comerciais está habilitado, o checkout não precisa concluir toda a entrega do e-mail durante a mesma requisição. A mensagem fica dependente do processamento agendado. Assim, pedidos podem ser criados normalmente enquanto as confirmações chegam com atraso ou não são processadas.

Consulte o estado geral do cron e execute-o manualmente com o mesmo usuário responsável pela aplicação:

bin/magento cron:run

Uma execução manual sem erro não comprova que o agendamento do sistema operacional está funcionando continuamente. Verifique também a crontab, o usuário, o binário do PHP e os registros da tabela cron_schedule. Se houver outros sintomas de tarefas acumuladas, use estas verificações para corrigir o cron do Magento 2.

4. Procure exceções nos logs do Magento

Analise os registros próximos ao horário exato da tentativa. Os arquivos mais comuns para iniciar a investigação são:

var/log/system.log
var/log/exception.log

Dependendo da extensão de SMTP ou do provedor, pode existir um arquivo específico. Procure mensagens relacionadas a autenticação, conexão, destinatário, template, endereço inválido e transporte de e-mail. Evite publicar logs completos em chamados ou ferramentas externas: eles podem conter dados pessoais, identificadores de pedidos e detalhes da infraestrutura.

5. Teste a conexão com o serviço de saída

Se a loja utiliza SMTP, API transacional ou relay do provedor de hospedagem, confirme host, porta, criptografia, usuário e segredo. Verifique ainda se houve mudança de credencial, restrição de IP, bloqueio de porta ou expiração de token.

O teste deve partir do mesmo ambiente e da mesma rede usados pelo PHP da loja. Uma credencial funcionar no computador do desenvolvedor não comprova que o servidor de produção consegue alcançar o serviço. Não desative TLS nem abra portas indiscriminadamente para contornar uma falha de conexão.

6. Valide remetente e domínio de envio

Confira as identidades configuradas em Lojas > Configuração > Geral > Endereços de e-mail da loja. Um endereço inexistente, digitado incorretamente ou não autorizado pelo provedor pode provocar rejeição.

Também vale solicitar à equipe responsável pelo domínio a revisão de SPF, DKIM e DMARC. Essas políticas não são corrigidas limpando o cache do Magento e devem ser ajustadas no DNS e no serviço de e-mail por quem administra o domínio. Evite mudar registros em produção sem conhecer os demais sistemas autorizados a enviar mensagens.

7. Troque temporariamente o template em homologação

Templates personalizados podem conter variáveis inválidas, diretivas incompatíveis ou blocos que falham durante a renderização. Em um ambiente de homologação, compare o comportamento com um template padrão compatível com a instalação.

Se a mensagem padrão funciona e a personalizada falha, revise a customização e os logs. Não faça o teste diretamente com a base de clientes: use destinatários controlados e um capturador de e-mails que impeça entregas externas no ambiente de testes.

8. Verifique módulos SMTP e plugins que interceptam o envio

Extensões de SMTP, marketing, antifraude, atendimento e personalização podem substituir ou interceptar o transporte de e-mail. Liste mudanças recentes de código e configuração, mas não desative módulos aleatoriamente em produção.

Reproduza o problema em staging, compare a configuração efetiva e consulte os logs da extensão. Se a falha começou após um deploy, revise também dependências, compilação e arquivos de configuração. O objetivo é isolar o componente sem apagar as evidências do erro.

9. Confirme entrega, rejeição e filtragem no destinatário

O Magento pode concluir o envio sem garantir que a mensagem aparecerá na caixa de entrada. Consulte os eventos do provedor para saber se houve aceitação, rejeição, bounce, bloqueio ou entrega. Depois, teste endereços controlados em domínios diferentes.

Peça ao destinatário que verifique spam, quarentena corporativa, regras automáticas e caixa cheia. Se apenas um domínio rejeita as mensagens, reúna o código e a justificativa da recusa antes de alterar a aplicação.

Como testar sem disparar e-mails para clientes

Em homologação, bloqueie a entrega externa e direcione as mensagens para uma caixa de captura ou destinatários autorizados. Ao clonar produção, remova ou substitua credenciais reais antes de executar cron, integrações e rotinas de vendas.

Um teste controlado deve registrar:

• evento que iniciou o envio;
• store view e tipo de e-mail;
• horário da tentativa;
• resultado no Magento e no serviço de saída;
• template e identidade utilizados;
• eventual mensagem de erro ou rejeição.

Depois da correção, valide pelo menos pedidos, faturas, remessas, recuperação de senha e formulários relevantes. Não presuma que o sucesso de um único template comprova todo o fluxo.

O que evitar durante o diagnóstico

• Reenviar confirmações em massa antes de saber quais mensagens foram entregues.
• Trocar módulo SMTP, cron e DNS simultaneamente.
• Expor senhas, tokens ou dados de clientes em logs compartilhados.
• Desabilitar criptografia para contornar erros de conexão.
• Testar produção usando pedidos e endereços de clientes reais.
• Limpar todos os caches sem relacionar a ação ao sintoma.

Perguntas frequentes

Por que o pedido é criado, mas o cliente não recebe a confirmação?

O pedido e o e-mail são etapas diferentes. A mensagem pode estar desabilitada, aguardando o cron, falhar no template ou ser recusada pelo serviço de saída mesmo com o pedido salvo corretamente.

Limpar o cache faz o Magento voltar a enviar e-mails?

Normalmente, não. A limpeza pode ser pertinente após uma mudança específica de configuração ou template, mas não corrige cron parado, credenciais inválidas, bloqueios de rede, DNS ou rejeições do destinatário.

Como saber se o problema está no Magento ou no SMTP?

Compare os logs do Magento com os eventos do provedor. Se não há tentativa de conexão ou geração da mensagem, investigue configuração, evento, cron e template. Se o provedor recebeu a tentativa, analise autenticação, rejeição e entrega.

É seguro executar bin/magento cron:run?

O comando é apropriado para diagnóstico quando executado pelo usuário correto da aplicação. Entretanto, ele pode processar tarefas pendentes. Em uma loja com grande acúmulo, avalie o impacto e preserve os logs antes da execução.

Conclusão

Quando o Magento 2 não envia e-mails, a correção começa separando geração, processamento, transporte e entrega. Confirme o escopo, revise o cron, consulte logs e valide o serviço de saída antes de reenviar mensagens ou substituir extensões.

Se a falha afeta vendas ou recuperação de acesso e não há evidência suficiente para localizar a origem, uma análise técnica controlada pode reduzir o risco de mensagens duplicadas e alterações desnecessárias. A equipe do SuporteMagento.com.br pode auxiliar no diagnóstico da aplicação, cron, templates e integração de e-mail.