Quando o formulário diz “Obrigado”, mas nenhum e-mail chega

Imagine uma pequena clínica de fisioterapia. Seu site tem um formulário de contato, e ele funciona — ou pelo menos parece funcionar. Os visitantes o preenchem, clicam em “Enviar” e veem um simpático “Obrigado, entraremos em contato em breve”. O que ninguém vê: as mensagens pararam de chegar à caixa de entrada da clínica há algum tempo. Não há erro, mensagem devolvida na caixa de ninguém nem luz vermelha em lugar algum. O formulário falha silenciosamente.

Por que ninguém percebe

A página de “Obrigado” de um formulário geralmente significa apenas uma coisa: o site repassou a mensagem. Se um servidor de e-mail a aceita, a classifica como spam ou a rejeita pelo caminho é algo que acontece depois, fora da vista do formulário. A função mail() do PHP, por exemplo, informa sucesso assim que o sistema local aceita a mensagem para entrega — não quando ela chega a alguém. Assim, o visitante recebe uma confirmação e segue em frente. Enquanto isso, o responsável vê uma caixa de entrada vazia e presume que é apenas um mês tranquilo. Menos solicitações raramente alarmam por si só: férias, clima, economia — sempre há uma explicação que parece mais plausível que “o formulário está com defeito”.

As causas comuns

• A senha SMTP ou o provedor de e-mail mudou. O formulário continua tentando entrar com as credenciais antigas, e o servidor de e-mail recusa — silenciosamente, pelo que o visitante consegue perceber.
• PHP mail() sem autenticação. O servidor web envia e-mails diretamente, sem entrar em um servidor de e-mail adequado. Muitos servidores destinatários tratam essas mensagens como suspeitas: elas caem no spam ou são rejeitadas de imediato.
• SPF, DKIM e DMARC não se alinham. Muitos formulários colocam o endereço do visitante no campo From. A mensagem então afirma vir, por exemplo, de um endereço gmail.com, mas é enviada pelo seu servidor web — exatamente o que DMARC foi concebido para impedir.
• Uma atualização de plugin ou troca de tema quebra o formulário ou seu CAPTCHA. Um modelo alterado perde um campo, um script deixa de carregar ou o widget de CAPTCHA aparece sem seu script — e todos os envios falham na validação.
• A caixa de correio destinatária está cheia. O servidor recusa novas mensagens, e o aviso de devolução vai para um endereço que ninguém lê.
• O banner de cookies bloqueia o script do formulário. Se a ferramenta de consentimento classificar o CAPTCHA ou o script do formulário como “marketing”, visitantes que recusam cookies podem receber um formulário que não pode ser enviado ou cujos envios são rejeitados por falta de token.
• Um certificado TLS ou domínio expirado. Visitantes veem um aviso do navegador e saem, ou o servidor de e-mail deixa de poder ser acessado com segurança. Se o domínio da caixa de correio destinatária expirar, o envio de e-mails para ela simplesmente para.
• Uma camada de cache fornece páginas antigas. Um cache de página inteira pode entregar um formulário com token de segurança expirado (nonce ou token CSRF). O servidor rejeita o envio e, dependendo da configuração, o visitante não vê um erro claro.

A armadilha do endereço From

A terceira causa merece atenção porque muitas configurações de formulário já a incluem por padrão. DMARC verifica se o domínio no endereço From visível corresponde a um domínio autenticado por SPF ou DKIM. Se o formulário enviar uma mensagem “do” endereço do visitante, seu servidor não estará autorizado a enviar por esse domínio, e a verificação falhará. Conforme a política DMARC do domínio do visitante e seu próprio provedor de e-mail, a mensagem cairá no spam ou será rejeitada. A correção é simples: enviar de um endereço do seu próprio domínio e colocar o endereço do visitante em Reply-To. Clicar em “Responder” continuará alcançando o visitante.

O que fazer

1. 1Envie regularmente uma mensagem de teste pelo seu próprio formulário — pelo menos mensalmente e sempre após atualizações, trocas de tema ou mudanças nas configurações de e-mail. Identifique-a claramente como teste para ninguém responder.
2. 2Conheça seu ritmo normal. Se o formulário costuma trazer algumas mensagens por semana, duas semanas de silêncio são motivo para verificar, não um mês tranquilo.
3. 3Envie por SMTP com autenticação — pelo seu provedor de e-mail ou serviço dedicado de envio — em vez de depender de PHP mail().
4. 4Use seu próprio domínio em From e o endereço do visitante em Reply-To. Depois configure SPF, DKIM e DMARC para esse domínio para que as mensagens passem nas verificações.
5. 5Mantenha uma cópia de cada envio no banco de dados. Muitos plugins de formulário oferecem isso, às vezes como complemento. Se o e-mail falhar, as solicitações continuarão ali.
6. 6Confira o formulário após cada atualização de plugin — incluindo o CAPTCHA e também com cookies recusados.

É fácil esquecer essas verificações, por isso vale automatizá-las. Com uma conta e um domínio verificado, formexposed pode fazer um envio de teste claramente identificado e verificar se ele realmente chega (a verificação de entrega, somente mediante ativação). Também detecta silêncio — um formulário que normalmente recebe mensagens e de repente deixa de receber — e verifica SPF, DKIM e DMARC dos e-mails de notificação, além da expiração do certificado TLS e do domínio. Você só recebe alertas quando algo muda.

Se quiser apenas uma primeira visão: uma verificação gratuita em formexposed.com não exige conta nem envia nada. Entre outras coisas, mostra se um CAPTCHA está presente, mas com falha — widget sem seu script, chave pública de teste, erros no navegador —, uma das formas mais silenciosas de um formulário parar de funcionar. Se as mensagens realmente chegam só pode ser confirmado por uma mensagem real de teste, então envie uma hoje.