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.
Separar o problema do formulário do problema de transporte
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.
Escolher a integração de envio
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.
Configurar ligação e credenciais
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.
Configurar remetente 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.
Alterar DNS com inventário dos emissores
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.
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.
Interpretar os erros na etapa correcta
| 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.
Recuperar notificações sem duplicar operações
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.
Limitar registos e tornar alertas accionáveis
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.
Confirmar o resultado antes de fechar o incidente
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.
