O formulário de contacto do seu site diz «Enviado». Porque não recebeu o pedido?
Uma mensagem de sucesso no formulário confirma apenas parte do processo. Saiba como acompanhar um pedido de teste pelo site, pelo serviço de envio e pela caixa de correio, sem fazer alterações por tentativa e erro.

Uma mensagem «enviado» ou «obrigado» não prova que o pedido chegou à caixa de correio pretendida. Pode significar apenas que o site aceitou o envio do formulário sem detetar um erro imediato.
A forma mais segura de investigar é preservar e acompanhar um único envio de teste controlado ao longo de quatro etapas: o registo do site ou do formulário, o remetente ou serviço de envio, o servidor de correio do destinatário e a caixa de correio que recebe a mensagem. Investigue a primeira etapa que não consegue confirmar. Reative o registo nessa etapa ou corrija uma falha apenas quando as provas a confirmarem. Começar por alterar plugins ao acaso ou editar registos DNS pode ocultar a falha original e criar novos problemas.
O que confirma realmente a mensagem «enviado»?
Uma mensagem de um formulário de contacto passa por várias etapas distintas:
- Aceitação do formulário: o site aceita os dados e apresenta uma resposta de sucesso.
- Aceitação pelo remetente ou serviço: o site entrega a mensagem a um processo de correio local, a um serviço SMTP ou a uma API de email, que a aceita ou coloca em fila.
- Resposta do servidor de correio do destinatário: o servidor que recebe a mensagem aceita-a, adia-a ou rejeita-a.
- Entrega na caixa de correio: o sistema recetor entrega a mensagem aceite na caixa de entrada, na pasta de spam, em quarentena ou noutro local definido pelas suas regras.
Por exemplo, a documentação do WordPress explica que um resultado bem-sucedido de wp_mail() significa que o pedido foi processado sem erro, não que o destinatário recebeu o email. A mesma distinção pode aplicar-se noutras plataformas, mesmo que usem termos diferentes.
Como fazer um teste controlado ao formulário de contacto?
Envie uma única mensagem de teste pelo formulário público, tal como faria um visitante. Use uma referência única, que não possa ser confundida com uma mensagem anterior, por exemplo ENQUIRY-2026-10-06-1437. Inclua-a na mensagem e, se possível, no assunto ou no campo do nome.
Registe a hora exata do envio, incluindo o fuso horário, o URL da página, o endereço de destino que esperava que o formulário usasse e uma captura de ecrã da mensagem de sucesso. Use conteúdo realista, mas sem dados sensíveis. Evite enviar muitos testes seguidos: mensagens quase idênticas podem dificultar a leitura dos registos e acionar limites de envio ou filtros.
Depois, acompanhe essa referência pela ordem indicada:
- O site guarda um envio com a mesma referência e marca temporal?
- Existe um evento do remetente ou do serviço de envio que indique que a mensagem foi aceite, colocada em fila ou falhou?
- O servidor de correio do destinatário aceitou, adiou ou rejeitou a mensagem?
- O administrador da caixa de correio recetora consegue encontrar uma mensagem aceite no rastreio de mensagens, na quarentena, na pasta de spam ou nas regras de fluxo de correio?
Se o formulário não guardar qualquer registo, investigue a etapa de processamento do formulário. Se existir um registo, mas não houver um evento do remetente ou do serviço de envio, investigue a transferência do site para o remetente. Se o remetente aceitou ou colocou a mensagem em fila, mas não há resposta do servidor do destinatário, investigue a fila e os registos de entrega do remetente. Se o servidor do destinatário adiou ou rejeitou a mensagem, use essa resposta em vez de adivinhar. Se o servidor aceitou a mensagem, investigue os filtros, o encaminhamento, a quarentena e as regras da caixa de correio.
Que provas deve pedir a um fornecedor técnico?
Peça provas associadas à referência única e à marca temporal, não uma afirmação genérica de que o formulário «funciona». São úteis, por exemplo:
- o registo do envio guardado ou do processamento do formulário;
- o endereço do destinatário configurado no momento do teste;
- o evento de saída, o registo da fila ou o evento do serviço de envio;
- um ID de mensagem ou ID de evento do fornecedor;
- a resposta do servidor remoto, incluindo qualquer código de aceitação, rejeição ou adiamento;
- registos de devolução, supressão ou reclamação;
- o rastreio da caixa de correio recetora e qualquer resultado de quarentena ou encaminhamento.
Nem todas as configurações disponibilizam todos estes elementos. A falta de registos também é informação útil: mostra em que ponto o serviço atual não consegue confirmar o que aconteceu.
Que endereços From e Reply-To deve usar o formulário?
Em geral, o endereço de um visitante não deve ser usado como identidade do remetente da mensagem. Uma configuração mais segura é:
From: Website Enquiries <forms@example.com>
Reply-To: visitor@example.net
O endereço fixo em From identifica as mensagens enviadas pelo site, enquanto Reply-To permite que a equipa responda normalmente ao visitante. O servidor ou serviço de envio tem de estar autorizado para o domínio e a configuração de email em causa. Escolher apenas um endereço do domínio da empresa não concede essa autorização.
Este padrão também evita que o site pareça enviar mensagens em nome de domínios arbitrários dos visitantes. Os sistemas recetores verificam cada vez mais se o domínio visível do remetente está alinhado com um envio autenticado por SPF ou DKIM ao abrigo do DMARC.
A autenticação do email pode estar envolvida?
É possível, mas a autenticação é apenas uma das hipóteses a investigar. Consoante as provas, a causa pode ser, por exemplo, a validação do formulário, um destinatário incorreto, uma falha na transferência, um limite de envio, uma supressão pelo fornecedor, uma rejeição, a classificação como spam, a quarentena, um encaminhamento ou uma regra da caixa de correio.
Não altere registos DNS antes de inventariar todos os remetentes legítimos do domínio, incluindo o email da equipa, as mensagens do site, os sistemas de faturação, os boletins informativos e outros serviços. Substituir um registo SPF ou alterar o DKIM ou o DMARC sem esse inventário pode interromper mensagens que estão a funcionar. Qualquer alteração de DNS deve basear-se nas provas e ser verificada face aos requisitos dos serviços de envio efetivamente utilizados. As orientações para remetentes da Google e do Yahoo podem ajudar nessas verificações. O mesmo inventário de remetentes é importante ao mudar de fornecedor de email, pois as mensagens do site e os restantes sistemas automatizados têm de ser migrados ou continuar autorizados de forma deliberada.
O que deve guardar uma configuração fiável?
Uma configuração duradoura do formulário de contacto deve guardar os envios, com controlos adequados de acesso e retenção, usar um canal de envio autenticado, manter registos pesquisáveis de eventos ou entregas e emitir alertas para falhas, como rejeições repetidas ou limites de envio esgotados. Também deve ser testada periodicamente através do formulário público real, com envio para uma caixa de correio profissional monitorizada.
Um teste que chega a uma caixa de correio é um sinal positivo, mas não prova que a entrega será fiável para todos os fornecedores ou em qualquer momento futuro. Guarde os registos necessários para investigar a próxima mensagem sem ter de reconstruir o sucedido de memória.
Se quiser uma segunda opinião, podemos acompanhar um pedido de teste controlado, desde o envio até ao destinatário, e identificar a primeira etapa que não é possível confirmar.