| Sintoma | Causa raiz | Ação corretiva |
|---|---|---|
| Pedido cai no spam | From sem SPF/DKIM alinhado ao domínio de envio | Configurar SMTP autenticado e publicar SPF e DKIM |
| E-mail nunca chega | PHP mail() bloqueada no servidor compartilhado | Trocar por SMTP via WP Mail SMTP ou Amazon SES |
| Confirmação atrasa horas | WP-Cron só roda em pageview, loja com pouco tráfego | Ativar cron real do servidor a cada 5 minutos |
Legenda: a tela WooCommerce > Configurações > E-mails controla quais eventos disparam cada e-mail transacional.
--- ## Os 3 tipos de e-mail transacional que o WooCommerce dispara O WooCommerce dispara, por padrão, cerca de 11 modelos de e-mail transacional em três tipos por destinatário. O primeiro vai para o cliente (pedido pago, concluído, reembolsado). O segundo vai para o administrador (novo pedido, falha no pagamento). O terceiro é o e-mail de conta (senha, nova conta). Saber qual evento dispara qual mensagem importa porque o alinhamento de domínio precisa valer para todos os onze. Um SPF que cobre o e-mail do cliente mas não o do administrador deixa o lojista sem aviso de venda. Para o detalhe de cada modelo, o guia de e-mails do WooCommerce mostra como editar gatilho por gatilho. O ponto técnico é simples: o e-mail transacional não é um só, são onze modelos, e a autenticação por SPF e DKIM é única para todos eles, do recibo do cliente ao aviso interno de venda. --- ## Como configurar o e-mail transacional no WooCommerce em 5 passos Configurar o e-mail transacional no WooCommerce leva cerca de 30 minutos e segue 5 passos: instalar um plugin de SMTP, conectar um provedor de envio, publicar SPF e DKIM no DNS, validar o DMARC e substituir o WP-Cron por um cron real. A ordem importa: autenticar o domínio antes de ter provedor não faz sentido. ### Passo 1: Instale o plugin de SMTP Instale o WP Mail SMTP em WP-Admin > Plugins > Adicionar novo. Ele intercepta a função wp_mail() do WordPress e roteia cada e-mail transacional por um servidor SMTP autenticado em vez da PHP mail() nativa. Ative o registro de log para auditar entregas. O plugin é gratuito na versão base e cobre o roteamento que a maioria das lojas precisa. ### Passo 2: Conecte um provedor de envio Conecte um provedor de envio dedicado como Amazon SES, Brevo ou Mailgun. Esses serviços mantêm reputação de IP que um servidor compartilhado nunca terá. O Amazon SES, por exemplo, custa cerca de US$0,10 por mil e-mails e entrega com reputação de IP da AWS. Insira a chave de API no WP Mail SMTP e defina o endereço From no seu domínio próprio. ### Passo 3: Publique SPF e DKIM no DNS Publique os registros SPF e DKIM no DNS do seu domínio. O SPF autoriza o IP do provedor a enviar em nome do seu domínio; o DKIM assina cada e-mail transacional com uma chave criptográfica. Sem os dois, o Gmail trata o pedido como falsificação. A propagação leva até 24 horas. ### Passo 4: Valide o DMARC Valide a política DMARC publicando um registro TXT em _dmarc.seudominio.com com p=quarantine. O DMARC só passa se SPF ou DKIM estiverem alinhados ao domínio do From. Use o Google Postmaster Tools para monitorar a taxa de aprovação ao longo dos primeiros dias. ### Passo 5: Substitua o wp-cron por cron real Desative o WP-Cron pseudo adicionando define('DISABLE_WP_CRON', true) no wp-config.php e agende um cron real do servidor a cada 5 minutos. Assim o e-mail transacional dispara independente de visita à loja, e a confirmação de pedido sai em minutos, não horas. --- ## Por que o wp-cron atrasa o e-mail transacional O WP-Cron atrasa o e-mail transacional porque não é um cron de verdade: ele só executa quando uma página do site é carregada. Em loja WooCommerce com pouco tráfego, a confirmação de pedido fica parada na fila por horas até o próximo visitante abrir a home e disparar o agendador. O cliente que acabou de pagar fica sem recibo, abre um ticket e a percepção de golpe começa. A correção é desacoplar o disparo do tráfego. Ao definir DISABLE_WP_CRON como true no wp-config.php e criar um cron real no servidor rodando wp-cron.php a cada 5 minutos, o e-mail transacional passa a sair em janela previsível. A FULL vê no suporte que essa é a causa mais subestimada de pedido sem confirmação. O processamento via REST e tarefas agendadas do WordPress, descrito na REST API do WordPress, depende do mesmo agendador. Conserte o cron e metade dos relatos de e-mail transacional fantasma desaparece. --- ## Como testar a entrega do e-mail transacional Testar a entrega do e-mail transacional exige mais do que disparar um pedido de teste para o próprio Gmail. A ferramenta de referência é o Mail Tester, que dá uma nota de 0 a 10 e mostra quais checagens de SPF, DKIM e DMARC falharam. Faça o teste depois de cada um dos 5 passos. Uma nota abaixo de 8 indica que o e-mail transacional ainda corre risco de cair no spam, mesmo que chegue na sua caixa. Combine o Mail Tester com o Google Postmaster Tools para monitorar a reputação do domínio ao longo do tempo. O Postmaster mostra a taxa de spam reportada pelos próprios destinatários Gmail, que tende a ser o sinal mais honesto de entrega real. Dispare um pedido de ponta a ponta, do checkout ao e-mail de pedido concluído, e confirme que tanto o cliente quanto o administrador receberam. O checkout transparente do WooCommerce só converte se o e-mail transacional que o segue chegar. --- ## Quando vale ter a infraestrutura gerenciada pela FULL Configurar SMTP, DNS e cron real em cada loja é viável para um site, mas vira gargalo para quem mantém vários. O plano PRO da FULL sai por R$849 e cobre até 10 sites, o que dá R$85 por site com o bundle de plugins incluído, entre eles o WP Mail SMTP e o WP-Optimize. A gente vê no suporte da FULL que padronizar a stack de e-mail transacional entre lojas reduz o número de tickets de pedido sem confirmação. Conheça os planos da FULL para entender o que entra em cada nível. Para agências, R$85 por site com a infraestrutura de envio resolvida costuma pagar o plano já no primeiro pedido recuperado, e a confirmação de pedido por e-mail transacional deixa de ser um ponto cego da operação da loja. --- --- ---Porque o From não tem SPF e DKIM alinhados ao domínio de envio. O Gmail trata uma mensagem sem assinatura criptográfica como possível falsificação, ainda mais quando sai de um IP compartilhado já marcado. Publicar SPF, DKIM e uma política DMARC com p=quarantine resolve a maior parte dos casos e tira o pedido da pasta de spam.
É possível pela função PHP mail() nativa, mas não é recomendado. Em servidor compartilhado, a PHP mail() costuma estar bloqueada ou enviar de um IP sem reputação, e o e-mail transacional não chega. Um plugin como o WP Mail SMTP roteia por um servidor autenticado e eleva a taxa de entrega de forma consistente, por isso é o padrão para qualquer loja séria.
O e-mail transacional responde a uma ação individual do cliente, como um pedido pago ou uma senha redefinida, e tem expectativa imediata de entrega. O e-mail de marketing é enviado em massa para uma lista e aceita atraso. Por isso o transacional precisa de SMTP dedicado e DNS autenticado, enquanto a newsletter pode rodar por uma ferramenta de envio em lote separada.
Com WP-Cron padrão, o e-mail transacional pode levar de minutos a horas, porque o disparo só acontece quando alguém abre uma página da loja. Em lojas de baixo tráfego, o atraso é grande. Com um cron real do servidor rodando a cada 5 minutos, a confirmação de pedido sai em até 5 minutos, independente de visita ao site.
São três registros de DNS que autenticam o e-mail transacional. O SPF lista quais IPs podem enviar pelo seu domínio; o DKIM assina cada mensagem com uma chave criptográfica; o DMARC define o que o destinatário faz quando SPF ou DKIM falham. Juntos, eles provam ao Gmail que o e-mail de pedido é legítimo e veio mesmo da sua loja.