Magento 2 não envia e-mails? Ache a falha em 9 testes

Magento 2 não envia e-mails de pedidos, redefinição de senha ou cadastro? Antes de reenviar mensagens manualmente ou trocar o módulo SMTP, descubra se a falha ocorreu na geração, no processamento, no transporte ou na entrega ao destinatário.

Essas etapas são diferentes. O Magento pode registrar o pedido corretamente e não iniciar o envio, entregar a mensagem ao servidor SMTP e sofrer uma rejeição posterior ou concluir o processo sem que o e-mail passe pelos filtros do provedor do cliente. Os nove testes abaixo ajudam a isolar cada cenário sem criar mensagens duplicadas.

Magento 2 não envia e-mails: primeiro delimite o problema

Faça uma lista dos tipos de mensagem afetados. Teste, quando aplicável:

• confirmação de pedido;
• fatura, envio e reembolso;
• cadastro e redefinição de senha;
• formulário de contato;
• alertas de produto ou preço;
• mensagens geradas por extensões.

Se apenas os e-mails de vendas falham, a investigação deve priorizar a configuração de vendas e o cron. Se nenhuma mensagem sai, verifique a desativação global, o transporte e o servidor de e-mail. Já uma falha limitada a uma loja, idioma ou website costuma apontar para escopo de configuração, remetente ou template.

1. Confirme se o evento realmente aconteceu no Magento

Não use apenas o relato do cliente como evidência. Localize o pedido, usuário ou solicitação correspondente e confirme data, horário, loja e endereço do destinatário. Em pedidos, verifique também se a venda foi efetivamente criada, pois uma aprovação exibida pelo gateway não garante a persistência do pedido.

Quando houver cobrança sem venda registrada, siga um diagnóstico específico para pagamento aprovado sem pedido no Magento 2. Sem pedido, o sistema não terá a confirmação de venda normal para enviar.

Registre um identificador para acompanhar o teste de ponta a ponta: número do pedido, e-mail do cliente, horário e ID da mensagem no provedor SMTP, se disponível.

2. Verifique se o envio global está desativado

No Admin, revise as configurações de envio de e-mail no escopo correto. A opção que desativa as comunicações pode ter sido habilitada durante uma manutenção e permanecer ativa após a publicação. Também pode existir uma diferença entre configuração padrão, website e visão de loja.

Em instalações nas quais o caminho estiver disponível, a leitura por linha de comando ajuda a documentar o valor:

bin/magento config:show system/smtp/disable

Não altere o valor diretamente no banco. Faça a correção pela configuração administrável ou pelo processo de configuração adotado no projeto, valide o escopo e limpe somente os caches necessários.

3. Revise os e-mails de vendas e seus remetentes

Em Lojas > Configuração > Vendas > E-mails de vendas, confirme se o envio está habilitado para pedidos, faturas, remessas e reembolsos. Revise também o remetente selecionado, o template e os endereços usados para cópia.

Um template personalizado pode depender de variáveis removidas por uma extensão ou conter marcação inválida. Para separar template de infraestrutura, associe temporariamente um template padrão em homologação e execute uma compra controlada. Não faça esse teste diretamente com pedidos reais sem planejar quem receberá a mensagem.

Se a falha existir somente em uma visão de loja, compare os valores herdados e desmarque a herança apenas quando houver uma configuração intencional para aquele escopo.

4. Descubra se o envio assíncrono está habilitado

O Magento pode processar e-mails de vendas de forma assíncrona. Nesse cenário, a conclusão do checkout não significa que a mensagem será transmitida na mesma requisição: ela dependerá das rotinas agendadas.

Confira a opção de envio assíncrono no Admin. Em ambientes compatíveis, o valor também pode ser consultado com:

bin/magento config:show sales_email/general/async_sending

Se o envio assíncrono estiver ativo e o cron estiver parado, pedidos podem continuar entrando enquanto as confirmações ficam pendentes. Desabilitar a opção às pressas pode mudar o comportamento do checkout e não resolve a causa do agendamento interrompido.

5. Inspecione o cron sem apagar o histórico

Verifique se os processos de cron estão em execução e se existem tarefas com status de erro, perdidas ou acumuladas. Comece pelo status geral:

bin/magento cron:status
bin/magento cron:run

A segunda instrução deve ser usada de maneira controlada, pois executa tarefas elegíveis e pode aumentar a carga em uma instalação com grande backlog. Antes disso, consulte os registros do agendador e preserve as mensagens de falha.

SELECT job_code, status, scheduled_at, executed_at, finished_at, messages
FROM cron_schedule
WHERE job_code LIKE 'sales_send_%'
ORDER BY scheduled_at DESC
LIMIT 100;

Não apague toda a tabela cron_schedule para “destravar” o envio. Além de remover evidências, isso pode dificultar a identificação de problemas de PHP, permissões, bloqueios ou falta de recursos. Um acúmulo amplo de tarefas também pode contribuir para lentidão; nesse caso, use os testes de performance do Magento 2 para investigar a infraestrutura em conjunto.

6. Leia os logs do Magento e do transporte de e-mail

Correlacione o horário do teste com var/log/system.log, var/log/exception.log, logs específicos da extensão SMTP e registros do PHP ou servidor de aplicação. Busque termos relacionados ao endereço testado, ao pedido e ao transporte:

grep -RiE "mail|smtp|transport|[email protected]" var/log/

Substitua o endereço pelo destinatário controlado. Evite publicar os resultados em chamados abertos, pois os arquivos podem conter dados pessoais, tokens ou detalhes internos.

Erros de autenticação, conexão recusada, timeout, remetente não autorizado e limite do provedor exigem correções diferentes. Guarde a mensagem completa, o código retornado e o horário antes de reiniciar serviços.

7. Teste o SMTP fora do fluxo do pedido

Se houver uma extensão SMTP, use seu recurso de teste para verificar credenciais, host, porta, criptografia e remetente. Um teste bem-sucedido comprova apenas que aquela tentativa chegou ao transporte; ele não garante que o cron, o template do pedido e a entrega ao destinatário estejam funcionando.

Confirme no painel do provedor se a mensagem foi aceita, rejeitada, adiada ou bloqueada. Quando o problema começou depois de um deploy, compare arquivos de configuração, variáveis de ambiente e dependências publicadas. O roteiro para diagnosticar falhas após deploy no Magento 2 também ajuda a preservar evidências da mudança.

8. Separe processamento interno de entregabilidade

Quando o provedor aceita a mensagem, mas o destinatário não a vê, investigue entregabilidade. Confira spam, quarentena corporativa, bloqueios, reputação do remetente e alinhamento do domínio usado no campo de envio.

A equipe responsável pelo domínio deve revisar SPF, DKIM e DMARC no DNS. Essas verificações não são corrigidas com limpeza de cache do Magento. Peça ao provedor o identificador da mensagem e o motivo exato de qualquer rejeição, em vez de concluir que o cliente apenas não procurou na caixa de spam.

Teste endereços controlados em provedores diferentes. Se apenas um domínio rejeita as mensagens, o problema pode estar na política do destinatário ou na autenticação do remetente, não na criação do e-mail pelo Magento.

9. Evite reenvios e alterações diretas no banco

Antes de reenviar confirmações, descubra se o primeiro e-mail ainda está pendente ou se foi aceito pelo provedor. Executar repetidamente o cron, alterar indicadores de envio no banco ou acionar extensões de reenvio pode produzir várias mensagens para o mesmo pedido.

Use um pedido de teste em homologação ou uma compra controlada em produção, com valor e destinatário previamente definidos. Valide nesta ordem:

1. evento criado no Magento;
2. template renderizado;
3. tarefa processada;
4. transporte acionado;
5. mensagem aceita pelo provedor;
6. entrega confirmada na caixa de destino.

Depois da correção, monitore alguns ciclos do cron e diferentes tipos de e-mail. Documente a causa, a configuração alterada e a forma de detectar a recorrência.

Conclusão

Quando o Magento 2 não envia e-mails, trocar o SMTP ou reenviar pedidos sem diagnóstico pode ocultar a falha e duplicar comunicações. O caminho mais seguro é seguir a mensagem desde o evento de negócio até o provedor, verificando configuração, escopo, cron, logs, transporte e entregabilidade.

Se a loja continua sem enviar mensagens ou apresenta falhas intermitentes, a equipe do SuporteMagento.com.br pode ajudar a revisar o fluxo técnico e localizar o ponto de interrupção.

Perguntas frequentes

Por que o pedido aparece no Admin, mas o cliente não recebe a confirmação?

O envio de e-mails de vendas pode estar desabilitado, configurado como assíncrono com o cron parado, falhando no SMTP ou sendo rejeitado depois que sai do Magento. É necessário acompanhar um pedido específico em cada etapa.

Limpar o cache faz os e-mails pendentes serem enviados?

Normalmente, não. A limpeza pode ser necessária após uma mudança de configuração, mas não corrige cron interrompido, autenticação SMTP, template com erro ou rejeição do provedor.

Posso executar o cron manualmente para resolver?

Uma execução controlada ajuda no diagnóstico, mas pode processar muitas tarefas acumuladas. Consulte o histórico, preserve os erros e avalie a carga antes de usar o comando em produção.

O teste do módulo SMTP funcionou. Isso prova que o Magento está enviando pedidos?

Não. Ele comprova somente o caminho testado pelo módulo. O e-mail de pedido ainda depende da configuração de vendas, do template e, quando habilitado, do processamento assíncrono.

É seguro alterar o status de envio diretamente no banco?

Não é a primeira opção recomendada. A alteração pode gerar duplicidades, inconsistências e perda de evidências. Primeiro identifique onde a mensagem parou e utilize os mecanismos administrativos do projeto.