E-mails transacionais no WooCommerce: por que seus pedidos caem no spam e como resolver

Seus clientes reclamam que não receberam o e-mail de confirmação do pedido. Ou o e-mail chega, mas está na caixa de spam. Você verifica o WooCommerce, vê que o pedido foi registrado — mas o e-mail simplesmente não apareceu. Onde está o problema?

A resposta raramente é “o WordPress quebrou”. Na verdade, o problema pode estar em qualquer uma das três camadas por onde o e-mail transacional passa: geração (o WooCommerce criou o e-mail?), transporte (o servidor enviou?), ou aceitação (o servidor do destinatário aceitou?). Diagnosticar corretamente onde está o gargalo evita horas tentando corrigir o lugar errado.

Neste artigo, mostramos como identificar em qual camada está o problema e o que fazer em cada caso — sem precisar entender de infraestrutura ou configuração DNS.

Por que e-mails de pedido caem no spam (e não é culpa do WooCommerce)

Antes de tudo, uma distinção importante: quando um e-mail de pedido não chega, existem dois cenários bem diferentes.

“O e-mail foi gerado, mas não chegou.” O WooCommerce disparou o e-mail corretamente, o servidor o enviou, mas o servidor do destinatário rejeitou, classificou como spam ou simplesmente descartou. Esse é um problema de transporte ou aceitação.

“O e-mail nunca foi gerado.” O WooCommerce nem tentou enviar. Pode ser que a notificação esteja desativada, que o status do pedido não tenha acionado o gatilho, ou que um conflito entre plugins esteja impedindo o disparo. Esse é um problema de geração.

A confusão entre esses dois cenários faz muitos lojistas instalarem plugins de SMTP quando o problema real é uma configuração desligada no WooCommerce — ou vice-versa.

Camada 1 — O WooCommerce gerou o e-mail?

A primeira pergunta é: o WooCommerce tentou enviar o e-mail? A resposta está nos logs de e-mails transacionais.

Como verificar os logs

Desde a versão 10.9, o WooCommerce registra cada tentativa de envio de e-mail transacional diretamente no painel (documentação oficial). Acesse WooCommerce > Status > Logs e filtre pela fonte chamada transactional-emails. Cada entrada mostra o resultado:

• Sent (enviado): o WooCommerce entregou o e-mail ao sistema de envio do servidor. Isso não significa que o destinatário recebeu — apenas que o WooCommerce fez a parte dele.
• Failed (falhou): o WooCommerce tentou enviar, mas o processo de envio do servidor retornou um erro. O log geralmente inclui o motivo (credenciais SMTP incorretas, servidor indisponível, etc.).
• Disabled (desativado): o tipo de e-mail está desligado nas configurações.
• Skipped (ignorado): uma condição necessária estava faltando, como destinatário em branco.

Para e-mails de pedido, o WooCommerce também registra o resultado como nota privada no pedido. Você pode ver isso em WooCommerce > Pedidos > [pedido] > Notas do pedido.

Configurações que podem estar desligando os e-mails

Acesse WooCommerce > Settings > Emails. Cada tipo de notificação tem um botão Manage (Gerenciar) ao lado. Verifique:

• Enable/Disable — a caixa “Enable this email notification” está marcada? É comum desativar sem perceber algum tipo de e-mail e depois esquecer.
• Recipient(s) — o destinatário está correto? E-mails de admin (novo pedido, cancelado, falhado) usam por padrão o e-mail administrador definido em Settings > General. Se esse e-mail estiver errado ou inacessível, você não recebe a notificação mesmo que ela tenha sido enviada.
• From Address — o endereço de origem deve usar o domínio da sua loja (ex: loja@sualoja.com.br). Se estiver usando um e-mail pessoal (seunome@gmail.com), isso causa falha de autenticação e o e-mail tende a cair no spam ou ser rejeitado.

Uma mudança importante no WordPress 6.9

Em 2 de dezembro de 2025, o WordPress 6.9 alterou como o endereço de remetente é configurado no wp_mail() (dev note no core blog). A mudança visava corrigir um problema antigo onde o “Envelope-From” ficava inválido, causando rejeição em vários servidores. Porém, a alteração causou falhas em sites que funcionavam antes — especialmente em provedores como AWS SES, que exigem endereços verificados. A reversão veio na 6.9.1, em 3 de fevereiro de 2026. Se sua loja ainda roda na versão 6.9.0, atualize para a versão atual (WordPress 7.1) com backup e teste de compatibilidade — nosso guia de atualização segura explica como fazer isso sem quebrar nada.

Camada 2 — O servidor está enviando?

Se o log mostra “Sent”, o WooCommerce fez a parte dele. Agora o e-mail está nas mãos do servidor de hospedagem. É aqui que entra a segunda camada: como o e-mail está sendo enviado.

PHP mail vs SMTP vs API transacional

Existem três formas principais de enviar e-mails a partir de um site WordPress:

PHP mail() — é o método padrão. O WordPress usa a função wp_mail(), que internamente chama o mail() do PHP. Esse método depende de um servidor de correio local (MTA) na hospedagem. Em muitas hospedagens compartilhadas, esse servidor é básico, sem autenticação adequada, e os e-mails tendem a cair no spam ou ser rejeitados por provedores como Gmail e Outlook.

SMTP — configura o WordPress para enviar e-mails através de um servidor SMTP remoto (o mesmo que você usa no Outlook, por exemplo). Plugins como WP Mail SMTP fazem essa configuração. O e-mail passa por um servidor autenticado, o que melhora a reputação do remetente.

API transacional — em vez de SMTP, o plugin se comunica diretamente com a API de um serviço como SendGrid, Mailgun ou Postmark. Não depende de portas de e-mail (que podem estar bloqueadas na hospedagem) e a autenticação da conexão com o serviço é feita por API key ou credenciais fornecidas pelo provedor — o que não dispensa a configuração de SPF, DKIM e DMARC no DNS do seu domínio, que continuam sendo responsáveis pela autenticação do remetente na caixa do destinatário. Tanto API quanto SMTP podem ser transportes confiáveis quando configurados corretamente — a diferença prática é que a API costuma exigir menos ajustes manuais na hospedagem.

A documentação oficial do WordPress recomenda, para quem gerencia seu próprio servidor, configurar um MTA local que encaminhe e-mails para um serviço de terceiros — ou usar um plugin SMTP que aponte para um provedor confiável. Para hospedagens gerenciadas (compartilhadas, WordPress gerenciado), o envio geralmente funciona “de fábrica”, mas pode precisar de ajustes na autenticação.

O que o lojista deve perguntar à hospedagem

Se você não usa nenhum plugin de e-mail e os logs do WooCommerce mostram “Sent” mas os e-mails não chegam, pergunte ao suporte da hospedagem:

1. O servidor tem MTA configurado e funcionando?
2. As portas de envio de e-mail (587, 465) estão abertas?
3. Existe algum limite de envio de e-mails por hora/dia?
4. O servidor tem registro PTR (DNS reverso) configurado para o IP?

Se a hospedagem não souber responder ou o problema persistir, o caminho mais rápido é usar um serviço transacional dedicado.

Camada 3 — O servidor destinatário aceitou?

Mesmo que o WooCommerce tenha gerado o e-mail e o servidor tenha enviado, o e-mail ainda pode ser rejeitado ou colocado no spam pelo servidor do destinatário. Isso depende de autenticação e reputação.

SPF, DKIM e DMARC em linguagem simples

Esses três mecanismos são como uma “carteira de identidade” do seu domínio. Sem eles, o servidor do destinatário não confia que o e-mail realmente veio de você.

SPF (Sender Policy Framework) — é uma lista pública de quais servidores estão autorizados a enviar e-mails pelo seu domínio. Quando o Gmail recebe um e-mail dizendo que veio do seu domínio, ele verifica se o servidor que enviou está na sua lista SPF. Se não estiver, o e-mail pode ser marcado como spam. Para o lojista, o SPF é configurado no DNS do domínio — geralmente o provedor de e-mail transacional fornece o registro correto para colocar.

DKIM (DomainKeys Identified Mail) — é uma assinatura digital que o servidor de envio coloca no e-mail. O servidor do destinatário verifica essa assinatura usando uma chave pública que está no DNS do seu domínio. Se a assinatura for válida, significa que o e-mail não foi adulterado no caminho e que realmente veio de um servidor autorizado. Novamente, o provedor de e-mail fornece a chave pública para configurar no DNS.

DMARC (Domain-based Message Authentication, Reporting & Conformance) — é a camada de política. Ele diz ao servidor do destinatário o que fazer quando o SPF ou DKIM falham: ignorar (p=none), colocar no spam (p=quarantine) ou rejeitar (p=reject). Também envia relatórios sobre quem está enviando e-mails pelo seu domínio. Para lojas que enviam poucos e-mails, o ideal é começar com p=none para monitorar, depois migrar para p=quarantine quando tiver certeza de que tudo está autenticado.

Por que isso importa para lojas WooCommerce

Desde fevereiro de 2024, o Gmail (política de autenticação) e o Yahoo (melhores práticas) passaram a exigir SPF ou DKIM para todos os remetentes — independentemente do volume. Para quem envia mais de 5.000 e-mails por dia para contas Gmail, o Gmail exige SPF, DKIM e DMARC. O Yahoo não publicou um limite numérico semelhante para envio em massa, mas a exigência de autenticação se aplica a qualquer volume. Mesmo lojas pequenas são afetadas: sem autenticação, seus e-mails transacionais de pedido têm chance significativamente maior de cair no spam — e o cliente nunca vê a confirmação da compra.

A boa notícia é que a maioria dos serviços de e-mail transacional (SendGrid, Mailgun, Postmark, Brevo) configura SPF e DKIM automaticamente quando você aponta o DNS do seu domínio para eles. O DMARC geralmente precisa ser adicionado manualmente, mas o provedor fornece o registro exato.

Reputação do domínio e do IP

Autenticação não é tudo. Mesmo com SPF, DKIM e DMARC configurados, o e-mail pode ser filtrado se:

• O domínio ou IP de envio estiver em lista negra (blocklist).
• Muitos destinatários marcaram seus e-mails como spam.
• O domínio é novo e ainda não tem reputação.

Para verificar, ferramentas como MXToolbox permitem consultar listas negras gratuitamente. Se o problema for reputação, a solução é usar um serviço transacional que já tenha IPs com reputação estabelecida.

Roteiro de diagnóstico em 5 passos

Quando seus e-mails de pedido não chegam ou caem no spam, siga esta ordem — do menos arriscado ao mais técnico.

Passo 1 — Verifique se o e-mail foi gerado

Antes de tudo, verifique em WooCommerce > Status > Logs se o nível de registro está adequado para capturar eventos de e-mail (a seção Settings dos logs mostra a configuração atual). Depois, filtre por transactional-emails e procure a entrada correspondente ao pedido. Se não houver entrada, isso pode significar que o e-mail não foi gerado — mas também pode indicar que o nível de log não está capturando eventos desse tipo, ou que a retenção de logs já removeu registros anteriores. Confirme verificando se a notificação está ativa em WooCommerce > Settings > Emails e se o status do pedido deveria acionar o envio.

Passo 2 — Teste com um e-mail simples

Faça um pedido de teste (use o sandbox do gateway de pagamento, se disponível) e verifique se o e-mail de confirmação chega na sua caixa de entrada. Se usar um serviço transacional, verifique no painel dele se o e-mail aparece como “entregue” ou “rejeitado”.

Passo 3 — Converse com o destinatário

Peça ao cliente (ou use sua própria caixa) para verificar a pasta de spam, lixeira e “Promoções” do Gmail. Às vezes o e-mail chega, mas não na caixa principal. Peça também para verificar se o remetente está na lista de contatos — e-mails de contatos salvos têm menos chance de serem filtrados.

Passo 4 — Verifique a autenticação

Use um verificador de e-mail (como mail-tester.com) para enviar um e-mail de teste e receber uma pontuação. O relatório mostra se SPF, DKIM e DMARC estão passando. Se algum falhar, entre em contato com o provedor de e-mail para corrigir os registros DNS.

Passo 5 — Avalie o provedor de envio

Se tudo estiver autenticado mas os e-mails continuam no spam, o problema pode ser reputação. Considere migrar para um serviço transacional com boa reputação de entrega. Na seção abaixo, explicamos quando isso vale a pena.

Plugins de e-mail: o que mudam e o que não mudam

WP Mail SMTP e congêneres

Plugins como WP Mail SMTP, Post SMTP e FluentSMTP reconfiguram o wp_mail() do WordPress para usar um servidor SMTP ou API em vez do mail() padrão do PHP. São a solução mais comum para lojas que enfrentam problemas de entrega.

O WP Mail SMTP, por exemplo, integra-se com serviços como SendLayer, Brevo, Mailgun, SendGrid e Postmark. A configuração pode ser feita por um assistente visual, sem precisar editar arquivos. A documentação oficial do plugin lista os provedores suportados e os passos de configuração para cada um.

Plugins de SMTP resolvem o problema de transporte (Camada 2). Eles não resolvem problemas de geração (Camada 1) nem de autenticação DNS (Camada 3). Se o e-mail não foi gerado pelo WooCommerce, instalar um plugin SMTP não vai ajudar. Se a autenticação SPF/DKIM/DMARC não está configurada, o plugin pode até piorar a situação — porque agora os e-mails passam por um servidor autenticado, mas o domínio não está autorizado.

Quando vale a pena usar um serviço transacional

Um serviço transacional é recomendado quando:

• A hospedagem não oferece envio de e-mail confiável.
• Sua loja envia mais de algumas dezenas de e-mails por dia.
• Você precisa de relatórios de entrega (saber se o e-mail chegou ou não).
• O gateway de pagamento exige notificações confiáveis.
• Você quer separar o envio de e-mails do servidor web, reduzindo riscos de impacto na reputação do IP.

Para a maioria das lojas pequenas e médias, um serviço gratuito ou de baixo custo (com limite de envio mensal) é suficiente. A escolha do provedor depende do volume e do orçamento — não existe recomendação universal.

Quando chamar um especialista

Algumas situações vão além do que o lojista resolve sozinho:

• Os logs do WooCommerce não mostram nenhuma entrada e as configurações estão corretas — pode haver um conflito entre plugins impedindo o disparo.
• Os e-mails funcionam para alguns destinatários e não para outros — pode ser problema de reputação com provedores específicos.
• A hospedagem bloqueia portas SMTP e não oferece alternativa — pode ser necessário migrar de provedor.
• Os relatórios de autenticação mostram falhas que você não consegue resolver com o suporte da hospedagem.

Um diagnóstico profissional identifica exatamente onde está o gargalo — se é geração, transporte, autenticação ou reputação — e aplica a correção no ponto certo, sem tentativas aleatórias.

Perguntas frequentes

Por que o e-mail de confirmação do pedido não chega?

Verifique primeiro se o e-mail foi gerado: acesse WooCommerce > Status > Logs e confirme que o nível de registro na seção Settings está apto a capturar eventos de e-mail. Depois, filtre por transactional-emails. Se não houver entrada, o e-mail pode não ter sido gerado — mas verifique também se a notificação está ativa em WooCommerce > Settings > Emails e se o status do pedido deveria acionar o envio. Se a entrada existe e mostra “Sent”, o problema está na Camada 2 (transporte) ou 3 (aceitação/filtragem).

O log mostra “Sent” mas o cliente não recebeu. O que fazer?

O WooCommerce entregou o e-mail ao sistema de envio do servidor, mas isso não confirma que o destinatário recebeu. Verifique: (1) a pasta de spam/lixo do destinatário; (2) se o endereço de e-mail no pedido está correto; (3) se o provedor de e-mail tem logs de entrega; (4) se SPF/DKIM/DMARC estão configurados corretamente.

Preciso instalar um plugin SMTP?

Depende. Se sua hospedagem envia e-mails de forma confiável (eles chegam na caixa de entrada, não no spam), não precisa. Se os e-mails caem no spam ou não chegam, antes de instalar qualquer plugin confirme que o WooCommerce está gerando o e-mail (Camada 1). Depois, um plugin SMTP ou um serviço com API transacional que aponte para um provedor dedicado costuma ser o caminho mais direto para resolver o problema de transporte (provedores de e-mail transacional recomendados pelo WooCommerce). Plugins como WP Mail SMTP ajudam nessa etapa, mas a autenticação DNS (SPF/DKIM/DMARC) precisa estar configurada separadamente.

SPF, DKIM e DMARC são obrigatórios?

Desde 2024, o Gmail (política de autenticação) e o Yahoo (melhores práticas) exigem SPF ou DKIM para qualquer remetente. O Gmail exige SPF, DKIM e DMARC especificamente para quem envia mais de 5.000 e-mails por dia para contas Gmail — o Yahoo não publicou limite semelhante. Não existe dispensa para lojas pequenas: mesmo com baixo volume, a ausência de autenticação aumenta significativamente a chance de o e-mail cair no spam.

Como sei se meu domínio tem SPF configurado?

O registro SPF fica no DNS do domínio. Você pode verificar consultando o painel de DNS da sua hospedagem ou usando ferramentas como MXToolbox. Se não encontrar um registro TXT começando com v=spf1, o SPF não está configurado. Nesse caso, o provedor de e-mail transacional que você escolher fornece o registro correto para adicionar.

Posso usar o Gmail como servidor de e-mail da loja?

Tecnicamente, sim — plugins como WP Mail SMTP permitem configurar o Gmail como SMTP. Mas o Gmail não foi feito para envio transacional de e-commerce. Tem limites de envio, não oferece relatórios de entrega detalhados, e em muitos casos os e-mails podem exibir um aviso indicando que foram enviados por um servidor intermediário. Para uma loja profissional, um serviço transacional dedicado é mais adequado.

Próximos passos

Se seus e-mails transacionais continuam caindo no spam ou não chegam, o diagnóstico precisa ser feito na ordem certa: primeiro verificar se o WooCommerce gerou o e-mail, depois se o servidor enviou, e por último se a autenticação está correta. Pular etapas geralmente leva a soluções inúteis.

A Panacea realiza análise inicial gratuita para identificar exatamente onde está o problema na sua loja — sem compromisso, sem tentativas aleatórias. Se sua loja apresenta dificuldades com e-mails transacionais, fale com um especialista que resolve.