Quando o e-mail do Magento 2 não chega, o pedido pode ter sido criado corretamente e ainda assim o cliente ficar sem confirmação, atualização de envio, fatura ou recuperação de senha. O problema pode estar no agendamento do Magento, no transporte de e-mail, no provedor, no DNS do domínio ou apenas em um template específico.
Antes de reenviar mensagens ou trocar configurações em produção, registre um pedido de teste, o destinatário, o horário exato e o tipo de e-mail esperado. Essas evidências ajudam a localizar em qual etapa o envio foi interrompido e reduzem o risco de duplicidade.
Como o e-mail transacional percorre o Magento 2?
O Magento gera e-mails a partir de eventos comerciais e administrativos. Dependendo da configuração e do tipo de mensagem, o envio pode ocorrer durante a própria requisição ou ser adiado para uma rotina agendada. Depois disso, a aplicação entrega a mensagem ao mecanismo configurado, que pode envolver o serviço local do servidor, um relay SMTP, uma extensão ou um provedor externo.
Aceitar a mensagem não significa entregá-la na caixa de entrada. O servidor destinatário ainda pode rejeitar, colocar em quarentena, classificar como spam ou aceitar sem exibi-la na pasta principal. Por isso, o diagnóstico precisa separar quatro situações:
- o Magento não gerou a mensagem;
- a mensagem ficou pendente em uma rotina assíncrona;
- o transporte recusou ou não conseguiu encaminhar o e-mail;
- o provedor aceitou, mas houve problema de entrega ou classificação.
E-mail do Magento 2 não chega: faça estas 9 verificações
1. Descubra exatamente quais mensagens falham
Teste separadamente confirmação de pedido, fatura, envio, redefinição de senha e formulário de contato. Se apenas um modelo falha, a causa tende a estar no evento, na configuração daquela área ou em uma customização do template. Se nenhum e-mail sai, concentre a investigação no transporte, nas credenciais, no servidor e nas configurações globais.
Também compare destinatários de provedores diferentes. Uma falha restrita a um domínio pode indicar bloqueio, política antispam ou reputação, e não necessariamente um defeito no Magento.
2. Confirme se o evento comercial realmente aconteceu
Um e-mail de pedido não será gerado se o checkout não concluiu a criação do pedido. Da mesma forma, mensagens de fatura e envio dependem da existência dessas entidades e de seu estado. Consulte o painel administrativo e confirme número do pedido, status, histórico e endereço de e-mail associado.
Quando o gateway mostra aprovação, mas o pedido não está no painel, o problema ocorre antes da comunicação com o cliente. Nesse cenário, siga o diagnóstico de pagamento aprovado sem pedido visível no Magento 2 antes de insistir no envio.
3. Verifique se o envio assíncrono está habilitado
A configuração de envio assíncrono para e-mails de vendas pode ser consultada pela linha de comando, a partir da raiz da instalação:
php bin/magento config:show sales_email/general/async_sendingQuando o resultado indica envio assíncrono, confirmações de vendas dependem das rotinas agendadas. Isso explica por que pedidos podem ser criados normalmente enquanto as mensagens permanecem pendentes. Não desative essa opção às pressas em produção: primeiro descubra se o cron está funcionando e se há erros durante o processamento.
4. Confirme a execução do cron
Verifique o crontab do usuário correto, o PHP utilizado pela linha de comando e os registros da tabela cron_schedule. Uma consulta somente de leitura pode mostrar os trabalhos mais recentes relacionados a vendas e e-mail:
SELECT job_code, status, created_at, scheduled_at, executed_at, finished_at
FROM cron_schedule
WHERE job_code LIKE '%email%'
OR job_code LIKE '%sales%'
ORDER BY schedule_id DESC
LIMIT 50;Estados recorrentes como error, tarefas atrasadas ou ausência completa de novos agendamentos merecem investigação. Rodar o cron manualmente uma vez não corrige o agendamento do sistema operacional. Para analisar usuário, frequência, grupos e erros acumulados, consulte o guia sobre cron do Magento 2 que não executa.
5. Procure o erro nos logs certos
Reproduza a falha em um horário controlado e examine var/log/system.log, var/log/exception.log e os arquivos específicos da extensão SMTP, caso existam. Também verifique logs do PHP, do agente de transporte local e do provedor contratado.
Pesquise por termos relacionados a autenticação, conexão, timeout, remetente recusado, certificado TLS e limite de envio. Evite publicar logs completos em chamados ou canais abertos: eles podem conter endereços, identificadores, cabeçalhos e outras informações sensíveis.
6. Teste o transporte sem usar pedidos reais
Se uma extensão SMTP oferece teste de conexão, use um destinatário controlado e registre a resposta retornada. Um teste bem-sucedido confirma apenas que aquela configuração conseguiu autenticar e entregar uma mensagem ao relay; ele não comprova que todos os eventos e templates do Magento estão funcionando.
Em integrações externas, consulte o painel do provedor para identificar mensagens aceitas, rejeitadas, adiadas ou bloqueadas. Não altere simultaneamente porta, criptografia, host e credenciais. Mude um item por vez para preservar a causa do problema.
7. Valide remetente, credenciais e escopo da configuração
Confira as identidades de e-mail definidas para vendas, suporte e contato. Um endereço inexistente, domínio incorreto ou remetente não autorizado pelo relay pode provocar rejeição. Em instalações com vários websites e store views, verifique também o escopo: uma loja pode herdar a configuração global enquanto outra utiliza um valor específico e inválido.
Credenciais devem permanecer em recursos protegidos e nunca ser adicionadas ao repositório. Se houver suspeita de exposição, faça a rotação no provedor e atualize a aplicação por um processo controlado.
8. Revise SPF, DKIM, DMARC e o domínio de retorno
Quando o provedor registra o envio como aceito, examine a autenticação do domínio. SPF informa quais serviços podem enviar em nome dele; DKIM adiciona uma assinatura verificável; DMARC orienta o tratamento de mensagens que não passam nas validações e fornece alinhamento entre os domínios utilizados.
O objetivo não é apenas criar registros DNS, mas garantir que eles correspondam ao serviço que realmente envia. Registros SPF duplicados, chaves DKIM incorretas ou política DMARC incompatível podem prejudicar a entrega. Mudanças de DNS devem ser validadas com a equipe responsável pelo domínio e pelo provedor de e-mail.
9. Isole templates e extensões personalizadas
Se o transporte funciona e somente um tipo de mensagem falha, compare o template personalizado com o padrão em homologação. Procure diretivas inválidas, variáveis removidas, arquivos sobrescritos pelo tema e plugins que interceptam o envio. Uma extensão de checkout, ERP ou marketing também pode substituir observadores e impedir que o fluxo esperado termine.
Teste com dados simples e examine a exceção gerada durante a renderização. Se a falha começou após um deploy, compare módulos, templates e configurações alterados nessa publicação. Problemas ocorridos antes da criação do pedido devem ser tratados como falhas de checkout; nesse caso, veja os testes para um checkout Magento 2 que fica carregando.
O que evitar durante a correção
- Não reenvie em massa antes de descobrir quais destinatários já receberam a mensagem.
- Não edite tabelas de pedidos ou cron diretamente para “marcar” tarefas como concluídas.
- Não desative autenticação TLS apenas para contornar um erro de conexão.
- Não use clientes reais em testes repetitivos de produção.
- Não conclua que o Magento falhou apenas porque o e-mail caiu no spam.
Como validar a solução
Após a correção, execute uma matriz pequena, mas completa: pedido com cliente cadastrado, compra como convidado, redefinição de senha e pelo menos uma mensagem de fatura ou envio. Teste destinatários em domínios diferentes e confirme tanto o registro do provedor quanto o recebimento.
Monitore os próximos ciclos do cron e verifique se os logs permanecem sem novas exceções. Em lojas com grande volume, acompanhe também atrasos e rejeições no painel do serviço de e-mail, evitando depender apenas de testes manuais.
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 depender do cron, falhar durante a renderização do template, ser recusada pelo transporte ou ser classificada como spam pelo destinatário.
Executar o cron manualmente resolve os e-mails pendentes?
Pode processar tarefas em uma execução, mas não corrige necessariamente o agendamento. É preciso validar o crontab, o usuário, o PHP CLI, os grupos e os erros registrados.
Um teste SMTP bem-sucedido confirma que o Magento está normal?
Não. Ele confirma principalmente conexão e autenticação com o relay. Eventos, envio assíncrono, templates e configurações por escopo ainda podem apresentar falhas.
É seguro reenviar todas as confirmações de pedido?
Não sem identificar quais mensagens falharam. O reenvio indiscriminado pode gerar duplicidade, confundir clientes e aumentar reclamações. Use registros do Magento e do provedor para delimitar o período afetado.
Conclusão
Quando o e-mail do Magento 2 não chega, a correção mais confiável é acompanhar a mensagem desde o evento que deveria gerá-la até a resposta do servidor destinatário. Cron, templates, transporte, remetente e DNS precisam ser verificados separadamente.
Se a loja continua sem enviar mensagens ou não há visibilidade sobre o ponto da falha, uma análise técnica pode reduzir tentativas arriscadas e preservar as evidências. A equipe do SuporteMagento.com.br pode auxiliar no diagnóstico da aplicação, das rotinas agendadas e da integração de e-mail.
