Quando um formulário aceita o pedido mas o email não chega, siga o percurso da mensagem: evento da aplicação, chamada a wp_mail(), transporte, fornecedor de envio e servidor do destinatário. Uma indicação de sucesso no formulário não comprova a recepção. Faça um teste controlado, registe a hora e procure a primeira etapa sem confirmação antes de alterar plugins ou registos DNS.
Como saber se o problema está no formulário ou no envio de email
Identifique a operação afectada. Um pedido de contacto, a recuperação de palavra-passe e a confirmação de uma encomenda podem ter configurações diferentes na mesma instalação. Se só as confirmações de encomenda falham, substituir o transporte global pode interromper mensagens que funcionam sem corrigir a acção do WooCommerce que nunca foi executada. Comece pelo evento concreto que deveria produzir a notificação.
Registe o destinatário de teste, a hora com fuso horário, o tipo de mensagem e o último envio bem sucedido. Num alojamento com vários sites, inclua a instalação e o ambiente. Estes dados permitem relacionar o pedido com os registos do fornecedor. Um relato sem hora nem destinatário obriga a procurar entre mensagens diferentes e dificulta distinguir uma falha nova de um problema antigo.
Verifique se o formulário tem uma acção de envio activa e se o estado da encomenda corresponde ao email configurado. O botão de teste de um plugin SMTP testa o transporte, mas não reproduz todos os passos do formulário ou do pagamento. Compare esse teste com uma operação real numa conta autorizada. Se o transporte funciona e o fluxo não gera mensagem, investigue a configuração e os hooks da aplicação.
A documentação de wp_mail() distingue o resultado da função da entrega ao destinatário. Uma devolução positiva não garante que a mensagem entrou na caixa de correio. No relatório técnico, separe geração, aceitação pelo fornecedor e recepção. Esta distinção evita encerrar o incidente quando apenas a primeira ligação da cadeia foi confirmada.
Que plugin SMTP e serviço de email escolher para WordPress
FluentSMTP e WP Mail SMTP são exemplos de plugins que ligam WordPress a um serviço de email. O plugin não fornece automaticamente uma caixa de correio nem um limite gratuito de mensagens por mês. As quotas, os domínios autorizados e a política de retenção pertencem à conta do fornecedor. Confirme a integração disponível na versão instalada e o método de autenticação suportado pelo serviço contratado.
Mantenha um único componente responsável pelo transporte. Dois plugins podem modificar PHPMailer ou interceptar wp_mail() e substituir definições um do outro. Procure também código no tema, plugins obrigatórios e personalizações do alojamento. Antes de desligar uma integração, guarde a configuração e confirme se algum fluxo específico depende dela. Uma alteração global deve ter um caminho de reversão conhecido.
SMTP autenticado pode servir mensagens transaccionais. Uma API HTTP pode facilitar a leitura de respostas estruturadas e dos identificadores de evento. Nenhuma das opções garante colocação na caixa de entrada, nem uma API é automaticamente instantânea. Compare os registos disponíveis, a rotação de credenciais, os limites e a gestão de erros. A escolha deve permitir explicar o destino de uma mensagem concreta quando alguém comunica uma falha.
Como configurar a porta SMTP, o TLS e as credenciais no WordPress
Obtenha do fornecedor o servidor, a porta, o modo de encriptação e a autenticação. A porta 465 costuma usar TLS desde o início; a porta 587 costuma usar STARTTLS. Siga a combinação indicada pelo serviço, em vez de experimentar opções até aparecer uma indicação verde. Um erro de certificado exige corrigir o nome do servidor ou a cadeia de confiança, não desactivar a verificação TLS.
Use credenciais destinadas ao site quando o fornecedor permite restringir permissões. Evite partilhar a palavra-passe habitual de um colaborador entre produção e testes. Se o plugin suporta configuração de segredos fora da base de dados, utilize o mecanismo documentado. Não invente constantes de PHP a partir de exemplos de outro plugin: um nome plausível não significa que a integração o lê.
As cópias de segurança e exportações de configuração podem conter credenciais ou conteúdos das mensagens. Restrinja o acesso administrativo, oculte segredos em capturas de ecrã e confirme o que entra num pacote de suporte. Se uma chave ficou num repositório ou num pedido de assistência partilhado, substitua-a. Apagar a cópia visível não invalida uma credencial que alguém já pode ter obtido.
O ambiente de testes precisa de uma política de envio própria. Use uma conta separada ou um serviço de captura de mensagens e impeça notificações para clientes copiados da produção. Depois de publicar alterações, confirme de onde vêm o remetente e a credencial. Uma importação da base de dados de testes pode substituir a conta de envio sem alterar qualquer registo DNS.
Qual a diferença entre remetente, Return-Path e endereço de resposta
O endereço visível em From, o remetente do envelope que recebe devoluções e o domínio da assinatura DKIM são identidades diferentes. SPF avalia a autorização do servidor para o domínio do envelope. DKIM verifica a assinatura da mensagem. DMARC exige alinhamento do domínio visível com um resultado válido de SPF ou DKIM. Basta um mecanismo válido e alinhado; a falha de um deles não implica, por si só, falha de DMARC.
Utilize um remetente de um domínio controlado pela organização e verificado pelo fornecedor. Num formulário, coloque o endereço validado do visitante em Reply-To. Não use esse endereço como remetente, porque o site não controla a política de autenticação do domínio do visitante. Além de prejudicar a entrega, essa configuração torna cada submissão dependente de um domínio diferente.
No Contact Form 7, confirme as etiquetas do formulário na configuração de email. O campo que recolhe o endereço tem de corresponder à etiqueta usada no cabeçalho de resposta. Teste a notificação interna e a confirmação para o visitante separadamente. Uma pode funcionar enquanto a outra aponta para uma etiqueta inexistente ou para um destinatário incorrecto.
Como configurar SPF, DKIM e DMARC para WordPress
Antes de editar SPF, inventarie o site, o correio dos colaboradores, a facturação e os serviços de campanhas que enviam pelo mesmo domínio. Publique apenas um registo SPF por nome de domínio relevante. Combine os mecanismos autorizados conforme as instruções dos fornecedores. Acrescentar um segundo registo v=spf1 não é uma forma de juntar autorizações e pode invalidar a avaliação.
A especificação SPF limita a avaliação que depende de consultas DNS. Por isso, acrescentar includes indefinidamente pode causar erros mesmo quando cada serviço parece legítimo. Peça ao responsável pelo domínio para rever a composição e eliminar serviços já desactivados. Não copie um include de exemplo que pertence a outro alojamento ou a outra organização.
Para DKIM, copie os nomes e valores fornecidos pelo serviço. Podem ser registos TXT ou CNAME para chaves geridas pelo fornecedor. O selector não tem de se chamar default. Alguns painéis acrescentam o domínio ao nome automaticamente; outros esperam o nome completo. Confirme o nome publicado, porque duplicar o sufixo do domínio cria um registo que os destinatários não encontram.
Comece DMARC em modo de observação quando ainda não conhece todos os emissores legítimos. Leia os relatórios agregados e confirme alinhamento antes de aplicar quarentena ou rejeição. A mudança afecta também facturas e correio de colaboradores. A especificação DMARC explica a relação entre autenticação, alinhamento e política. Um painel do fornecedor ajuda na leitura, mas não substitui a verificação dos registos publicados.
Quando o SPF e o DKIM indicam pass e o DMARC falha mesmo assim, as verificações foram aprovadas para domínios diferentes do remetente visível. Abra o código-fonte de uma mensagem recebida (no Gmail: Mostrar original) e compare os domínios no cabeçalho Authentication-Results: smtp.mailfrom para o SPF, header.i ou header.d para o DKIM e header.from para o endereço que o destinatário vê. Se nenhum dos dois primeiros partilhar o domínio organizacional de header.from, o DMARC não tem nenhum resultado alinhado para aceitar. O guia da Mailfully SPF, DKIM and DMARC setup, step by step, de outubro de 2026, acrescenta duas verificações a fazer ao mesmo tempo. Na Cloudflare, mantenha os registos CNAME do DKIM em DNS only (nuvem cinzenta): a documentação da Cloudflare sobre o estado do proxy inclui os registos de email entre os que o proxy HTTP não suporta. Um subdomínio de envio sem registo _dmarc próprio recorre ao registo do domínio organizacional, que pode definir uma política para subdomínios com sp= (RFC 7489, secção 6.6.3). Verifique o que o subdomínio já herda antes de publicar um p=none mais permissivo.
Guarde o valor anterior, o novo valor, o responsável e o resultado da verificação. Os caches DNS significam que a alteração no painel pode ainda não estar visível noutros resolvers. Consulte os servidores autoritativos e repita o teste depois da propagação. Uma mudança sem registo dificulta perceber se uma rejeição posterior vem da configuração antiga ou da nova.
Atualização de . As diretrizes do Google para remetentes de email exigem que quem envia mais de 5000 mensagens por dia para contas Gmail suporte o cancelamento da subscrição com um clique nas mensagens de marketing e subscritas. Um aviso de reposição de stock ou um lembrete de carrinho abandonado enviado por wp_mail() está mais perto desse grupo do que uma confirmação de encomenda. O RFC 8058 define o mecanismo: um cabeçalho List-Unsubscribe com um endereço HTTPS e List-Unsubscribe-Post: List-Unsubscribe=One-Click. Ambos têm de estar cobertos pela assinatura DKIM: verifique a etiqueta h=. O RFC refere ainda que o software antispam abre muitas vezes todas as ligações dos cabeçalhos. Na versão 1.1.0 do nosso plugin Waitlist acrescentámos os dois cabeçalhos e uma ligação “Leave this waitlist” que funciona sem sessão iniciada. Abrir a ligação apenas pede confirmação, por isso um programa que abre ligações não remove ninguém. A ligação é assinada para cada inscrição e tem limite de pedidos, e uma ligação inválida ou já usada nunca revela se um endereço está inscrito. O aviso é também um email do WooCommerce, em HTML e texto simples, editável em WooCommerce > Configurações > Emails.
O que significam os erros SMTP no WordPress e onde procurar a causa
| Resultado observado | Primeira verificação |
|---|---|
| A aplicação não gera mensagem | Acção do formulário, estado da encomenda, hooks |
| A ligação expira | Firewall de saída, servidor, porta, disponibilidade |
| A autenticação é recusada | Credencial, método permitido, estado da conta |
| O fornecedor aceita mas não chega | Evento de entrega, devolução, supressão, filtros |
| A mensagem chega com problemas | Modelo, codificação, ligações, anexos |
Um timeout acontece antes da filtragem da caixa de correio. Teste a ligação no ambiente que executa WordPress; conseguir ligar a partir de um portátil não demonstra que o alojamento permite a mesma porta. Registe o código de erro e o tempo decorrido sem guardar a troca de autenticação. Se a rede é a primeira etapa com falha, confirme as regras de saída com o operador do alojamento.
Uma recusa de autenticação exige verificar a conta do fornecedor. A chave pode ter sido substituída, a política pode exigir OAuth ou a conta pode estar limitada. Repetir o mesmo pedido com uma credencial inválida apenas acrescenta ruído. Corrija a causa, faça um teste controlado e depois volte ao fluxo original. Não combine alterações de credencial, DNS e template sem saber qual delas resolveu o problema.
Se o fornecedor aceitou a mensagem, procure o identificador de entrega ou devolução. A mensagem pode ser adiada, rejeitada ou suprimida depois da aceitação inicial. Um evento de entrega costuma confirmar que o servidor destinatário a aceitou, não que uma pessoa a leu. Quando a mensagem aparece, examine os cabeçalhos recebidos e os resultados de autenticação.
Como reenviar notificações falhadas sem duplicar encomendas
Separe erros temporários de erros permanentes usando os códigos documentados pelo fornecedor. Uma indisponibilidade temporária pode justificar novas tentativas limitadas. Um endereço inválido ou uma supressão por devolução definitiva exige correcção. Defina um limite de tentativas e um alerta quando uma mensagem continua por enviar, em vez de criar uma fila que insiste indefinidamente.
Um timeout pode deixar o estado incerto: o serviço pode ter aceite a mensagem antes de o site perder a resposta. Reenviar imediatamente pode criar duplicados. Relacione cada tentativa com a operação de negócio, guarde o identificador do fornecedor e confirme se a API oferece idempotência. Trocar de plugin não elimina mensagens que já ficaram na fila anterior.
Numa loja WooCommerce, a encomenda é a referência para o processamento comercial. A ausência de email não deve apagar a encomenda, e repetir uma notificação não deve repetir o pagamento. Durante a recuperação, confirme o estado, o destinatário e o tipo de mensagem antes de reenviar. Esta separação permite resolver a comunicação sem alterar o historial da transacção.
Se o envio usa tarefas em segundo plano, monitorize também a fila. Uma ligação SMTP funcional não resolve uma tarefa que nunca é executada. Verifique o agendador, os trabalhos bloqueados e o processo responsável por os correr. Antes de substituir o envio síncrono por uma fila própria, defina retenção, novas tentativas e observabilidade; a fila passa a ser mais um componente operacional.
O que guardar nos registos de email e quem deve receber os alertas
Guarde tipo de fluxo, identificador da operação, hora, identificador do fornecedor e estado. O conteúdo completo raramente é necessário para demonstrar entrega. Ligações de recuperação de palavra-passe, moradas e detalhes de encomendas exigem acesso e retenção mais restritos. Confirme que a política de eliminação cobre os logs e as respectivas cópias de segurança.
Um alerta útil indica erros repetidos de autenticação ou um fluxo crítico parado. Um teste sintético periódico detecta problemas de transporte, mas não cobre todos os estados de encomenda nem todas as configurações de formulário. Atribua um responsável ao alerta e use um canal independente do transporte que está a testar. Uma notificação enviada pelo mesmo serviço avariado pode nunca chegar à equipa.
Quando Gmail é um destino relevante, consulte as orientações para remetentes. Existem diferenças entre remetentes comuns e remetentes em volume, e as mensagens promocionais têm requisitos adicionais. Não trate uma confirmação transaccional como uma newsletter, nem suponha que autenticar o domínio obriga o destinatário a aceitar qualquer conteúdo.
Porque é que os pedidos do formulário não chegam, embora o email seja enviado
A configuração SMTP pode estar impecável e, mesmo assim, os pedidos perdem-se. Em julho de 2026, um criador de sites descreveu no fórum r/Wordpress como perdeu um cliente por causa das notificações de um formulário. Depois do telefonema de uma pessoa cuja mensagem não tinha chegado, verificou os pedidos guardados, o registo do formulário, o registo do plugin SMTP e o painel do serviço de envio: tudo tinha sido enviado e entregue. A causa era outra:
Foi então que descobri que o funcionário que recebia esses emails tinha saído há três meses.
(tradução própria, r/Wordpress, tópico de 24 de julho de 2026)
No mesmo tópico, acrescentou que nenhuma medida do lado do DNS teria ajudado, porque os pedidos chegavam, só que a uma caixa de correio que já não existia (tradução própria, r/Wordpress).
Para que endereço devem ir as mensagens do formulário de contacto
O conselho mais repetido no tópico é um endereço da empresa e não de uma pessoa, por exemplo um grupo ou um alias com pelo menos dois destinatários, gerido pelo próprio cliente (tradução própria, r/Wordpress). Outra agência acrescenta uma segunda notificação para uma caixa partilhada a que várias pessoas têm acesso, como reserva para mudanças na equipa (tradução própria, r/Wordpress). No WordPress, isto significa dois endereços nas definições de notificação do formulário em vez de um.
Como verificar se o formulário de contacto do WordPress funciona
O registo do plugin SMTP só confirma que a mensagem saiu do servidor. O percurso completo verifica-se com um envio de teste pelo formulário a intervalos fixos, por exemplo uma vez por semana, embora, como nota o autor desse conselho, esse teste não diga se alguém leu o pedido verdadeiro (tradução própria, r/Wordpress). O segundo método do tópico é um resumo mensal de todos os envios do formulário, comparado com o mês anterior e enviado ao cliente (tradução própria, r/Wordpress). O resumo mostra pedidos que entraram, mas a que ninguém respondeu.
Bastam SPF, DKIM e DMARC para que os emails do formulário cheguem
Não. Os registos DNS descritos acima decidem se a caixa do destinatário aceita a mensagem, mas não sabem se alguém lê essa caixa. Os participantes do tópico apontam as duas causas lado a lado: filtros anti-spam cada vez mais rigorosos e mudanças, do lado do cliente, em quem deve receber os emails (tradução própria, r/Wordpress).
O que fazer quando sai o funcionário que recebia os pedidos
Inclua o endereço que recebe as notificações na lista de verificação para a saída de um colaborador, junto das contas, palavras-passe e acessos. Na passagem do site, convém registar quem recebe os pedidos, quem é o substituto e quem deve avisar o responsável pelo site quando alguma dessas pessoas sai (tradução própria, r/Wordpress). Se o formulário guardar os pedidos na base de dados, verifique depois dessa mudança se há pedidos por tratar das últimas semanas à espera no painel.
Como testar o envio de email do WordPress depois da reparação
Teste o transporte, submeta o formulário, peça uma recuperação de palavra-passe com uma conta de teste e crie uma encomenda autorizada quando existir comércio electrónico. Inclua o domínio que falhava e outro destino independente. Para cada mensagem, registe geração, aceitação e recepção. Verifique ainda resposta, apresentação em telemóvel, ligações e anexos.
Retire instrumentação temporária, revogue credenciais de diagnóstico e guarde um procedimento com responsáveis pelo fornecedor e pelo DNS. Repita a verificação depois de migrar alojamento, mudar o domínio remetente ou rodar credenciais. Para configuração e manutenção de WordPress, envie por email o fluxo afectado, a hora aproximada e o erro sem dados pessoais nem segredos.
