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

Magento 2 não envia e-mails de pedidos, redefinição de senha, cadastro ou formulário de contato? O problema pode estar na geração da mensagem, no cron, no transporte utilizado pelo servidor ou na entrega ao destinatário. Reenviar notificações indiscriminadamente pode duplicar mensagens e confundir clientes, enquanto trocar configurações sem registrar o estado inicial dificulta o diagnóstico.

Antes de limpar caches ou instalar outro módulo SMTP, escolha um evento afetado e anote horário, loja, destinatário, tipo de e-mail e entidade relacionada, como pedido ou cliente. Os nove testes abaixo ajudam a descobrir em qual etapa a mensagem parou.

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

Confirme se a falha atinge todos os e-mails ou apenas um fluxo. Uma notificação de pedido envolve condições diferentes de uma redefinição de senha, mensagem do formulário de contato ou alerta de produto. Também verifique se o defeito ocorre em todos os sites e visões de loja.

Use uma matriz simples para registrar os testes:

• tipo da mensagem e evento que deveria gerá-la;
• horário aproximado da ação;
• endereço remetente e destinatário;
• site e visão de loja envolvidos;
• resultado no frontend e no Admin;
• presença da mensagem nos logs do servidor ou provedor;
• pasta de spam, quarentena e rejeições.

Se o pagamento foi confirmado, mas o pedido nem sequer existe no Admin, o e-mail pode ser apenas uma consequência de uma falha anterior. Nesse cenário, siga o diagnóstico de pagamento aprovado sem pedido no Magento 2 antes de investigar exclusivamente o envio.

9 testes para descobrir por que o Magento 2 não envia e-mails

1. Confirme se o evento realmente foi concluído

Abra a entidade associada à mensagem. Em vendas, confirme se o pedido foi criado e se o estado alcançado permite aquela notificação. Em recuperação de senha, verifique se a solicitação terminou sem erro. No formulário de contato, observe a resposta apresentada após o envio.

Uma falha na criação do pedido, uma exceção durante o salvamento ou uma integração interrompida pode impedir que o processo chegue à etapa de notificação. Não use a ausência do e-mail como prova de que o único defeito está no servidor de correio.

2. Verifique se as comunicações por e-mail estão habilitadas

No Admin, revise a configuração de envio em Lojas > Configuração > Avançado > Sistema > Configurações de envio de e-mail. Observe o escopo selecionado: uma configuração correta no padrão global pode ter sido sobrescrita em um site ou visão de loja.

Em um terminal autorizado, a configuração efetiva pode ser consultada sem alterá-la:

bin/magento config:show system/smtp/disable
bin/magento config:show system/smtp/host
bin/magento config:show system/smtp/port

O primeiro caminho merece atenção especial porque uma opção de desativação habilitada bloqueia o envio. Não publique credenciais, tokens ou configurações sensíveis em chamados e capturas de tela.

3. Revise remetentes, destinatários e escopo da loja

Confira as identidades de e-mail configuradas para vendas, suporte e contato. Endereços inexistentes, domínios digitados incorretamente e remetentes não autorizados pelo transporte podem causar rejeição. Verifique também o destinatário do formulário de contato e as opções específicas de e-mails de vendas.

Faça o teste com caixas de domínios diferentes, preferencialmente controladas pela equipe. Se apenas um provedor não recebe, a aplicação pode estar enviando normalmente e o problema pode pertencer à reputação, autenticação do domínio, política do destinatário ou quarentena.

4. Descubra se o envio de vendas está configurado como assíncrono

Notificações de vendas podem ser processadas de forma assíncrona, conforme a configuração da instalação. Consulte o valor efetivo:

bin/magento config:show sales_email/general/async_sending

Quando o envio assíncrono está habilitado, o pedido pode ser criado normalmente enquanto a mensagem aguarda processamento posterior. Nessa situação, a investigação deve incluir cron e registros pendentes. Desativar a opção em produção apenas para “fazer funcionar” pode esconder o gargalo e alterar o comportamento operacional da loja.

5. Confirme se o cron executa e conclui os trabalhos

Execute o cron manualmente em uma janela controlada e observe a saída:

bin/magento cron:run

Uma execução manual bem-sucedida não comprova que o agendamento do sistema está funcionando continuamente. Confirme a crontab do usuário correto, permissões, caminho do PHP e diretório da aplicação. Também procure mensagens como Could not acquire lock, exceções de banco e falta de memória.

Se o cron deixa de avançar junto com páginas lentas, consumo elevado ou filas acumuladas, investigue o gargalo antes de aumentar recursos. O roteiro para diagnosticar um Magento 2 lento ajuda a separar aplicação, banco, busca, cache e integrações.

6. Examine o histórico do cron sem apagar evidências

Com acesso somente de leitura ao banco, consulte as execuções recentes relacionadas a e-mail:

SELECT job_code, status, messages, scheduled_at, executed_at, finished_at
FROM cron_schedule
WHERE job_code LIKE '%email%'
ORDER BY schedule_id DESC
LIMIT 50;

Procure tarefas permanentemente pendentes, execuções perdidas e erros repetidos. Compare horários considerando o fuso usado pelo banco e pela aplicação. Não apague a tabela cron_schedule como primeira tentativa: isso remove informações úteis e não corrige a causa de um processo que continua falhando.

7. Correlacione logs da aplicação, PHP e servidor

Consulte os arquivos em var/log, principalmente system.log, exception.log e logs adicionados por módulos de SMTP ou pagamento. Relacione as entradas ao horário exato do teste. Depois, verifique os registros de PHP-FPM, servidor web, serviço de e-mail ou relay externo.

grep -RiE "mail|smtp|transport|connection|timeout" var/log/

Restrinja a pesquisa quando os arquivos forem grandes. Erros de conexão, autenticação, certificado, resolução de DNS e limite de tempo apontam para camadas diferentes. Caso a indisponibilidade alcance outras rotas, confira também se há um erro 503 no Magento 2 afetando cron, PHP-FPM ou serviços de infraestrutura.

8. Teste o transporte sem confundir aplicação com entrega

O Magento pode entregar a mensagem ao transporte e, ainda assim, o destinatário não recebê-la. Consulte os logs ou o painel do serviço responsável e procure pelo destinatário, horário e identificador da mensagem. Classifique o resultado como aceito, adiado, rejeitado, devolvido ou entregue.

Um teste isolado com a função de e-mail do PHP não reproduz necessariamente o mesmo caminho usado pela loja, especialmente quando existe extensão SMTP. Faça a validação pelo próprio fluxo afetado e em ambiente controlado. Se houver módulo de terceiros, confirme se ele está habilitado no escopo correto e se não existe mais de uma extensão tentando substituir o transporte.

9. Valide autenticação do domínio e entrega ao destinatário

Se o provedor aceitou a mensagem, examine a camada de entrega. Confirme a coerência de SPF, DKIM e DMARC com o serviço utilizado, além do domínio do remetente e das políticas de alinhamento. Essas verificações devem ser feitas no DNS e no painel do transporte, sem publicar chaves ou registros privados.

Peça ao destinatário que consulte spam, quarentena e regras automáticas. Teste uma caixa corporativa e outra externa. Diferenças entre provedores ajudam a identificar bloqueios de reputação ou política, enquanto falhas para todos os domínios sugerem problema anterior no transporte.

O que homologar depois da correção

Após corrigir a causa, teste mais do que a mensagem inicialmente afetada. Use pedidos e contas de homologação para validar:

• confirmação de pedido para cliente e cópias configuradas;
• fatura, envio, cancelamento e reembolso, quando aplicáveis;
• criação de conta e redefinição de senha;
• formulário de contato;
• conteúdo, idioma, moeda, links e dados da visão de loja;
• remetente, assunto e respostas ao endereço correto;
• processamento contínuo do cron após o teste manual.

Evite reenviar em massa as mensagens acumuladas antes de verificar quantidade, destinatários e impacto comercial. Notificações antigas podem gerar dúvidas sobre pedidos já concluídos ou cancelados.

Conclusão

Quando o Magento 2 não envia e-mails, a correção começa pela identificação da etapa interrompida: evento, configuração, processamento assíncrono, cron, transporte ou entrega. Registrar horários e comparar os logs entre essas camadas costuma ser mais eficiente do que limpar cache, reiniciar todos os serviços ou instalar outra extensão.

Se a falha continua, uma análise técnica do ambiente pode preservar as evidências, corrigir a origem e homologar os fluxos de vendas sem transformar a produção em laboratório. A equipe do SuporteMagento.com.br pode apoiar esse diagnóstico.

Perguntas frequentes

Por que o pedido aparece no Admin, mas o cliente não recebe o e-mail?

O pedido pode ter sido criado antes de uma falha no processamento da notificação. Verifique se o envio assíncrono está habilitado, se o cron avança e se o transporte aceitou ou rejeitou a mensagem.

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

Normalmente, não. O cache pode interferir na leitura de uma configuração recém-alterada, mas não corrige cron parado, autenticação SMTP, rejeição do provedor ou falha de entrega.

É seguro executar bin/magento cron:run manualmente?

O comando é útil para diagnóstico quando executado por um usuário autorizado e com acompanhamento de logs. Porém, ele não substitui a correção do agendamento do sistema nem comprova que todas as tarefas terminaram corretamente.

Instalar uma extensão SMTP resolve o problema?

Não necessariamente. Uma extensão pode oferecer transporte autenticado e registros adicionais, mas não resolve eventos que não foram gerados, cron interrompido, configuração por escopo ou políticas incorretas do domínio.

Como saber se a falha está no Magento ou no provedor de e-mail?

Correlacione o horário do evento com os logs da aplicação e do transporte. Se nenhuma tentativa chegou ao provedor, investigue Magento, cron e conexão. Se a mensagem foi aceita ou rejeitada pelo provedor, prossiga pela resposta registrada e pela camada de entrega.