Quando o formulário de contacto diz «Obrigado», mas não chega nenhum e-mail
Um formulário de contacto pode avariar sem que ninguém veja um erro: o visitante recebe uma confirmação simpática, o leitor não recebe nada. Porque acontece e como dar por isso a tempo.
Imagine uma pequena clínica de fisioterapia. O seu sítio Web tem um formulário de contacto, e o formulário funciona – ou pelo menos parece funcionar. Os visitantes preenchem-no, clicam em «Enviar» e veem um simpático «Obrigado, entraremos em contacto em breve». O que ninguém vê: as mensagens deixaram de chegar à caixa de entrada da clínica há algum tempo. Não há erro, não há devolução na caixa de entrada de ninguém, não há nenhuma luz vermelha em lado nenhum. O formulário falha em silêncio.
Porque é que ninguém dá por isso
A página de «Obrigado» de um formulário significa normalmente uma única coisa: o sítio Web passou a mensagem adiante. Se um servidor de correio a aceita, a classifica como spam ou a rejeita pelo caminho acontece depois, fora do alcance do formulário. A função mail() do PHP, por exemplo, comunica êxito logo 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. O proprietário, entretanto, vê uma caixa de entrada vazia e assume que é apenas um mês calmo. Menos pedidos de contacto raramente são, por si só, alarmantes: férias, o tempo, a economia – há sempre uma explicação que parece mais plausível do que «o formulário está avariado».
- Dia 0Uma atualização de rotina de um plugin é executada durante a noite. O sítio parece exatamente igual ao que era.
- Dia 1Chega a última mensagem. Ninguém sabe que é a última.
- Dias 2–13Os visitantes continuam a submeter o formulário e a ver «Obrigado». Nada chega à caixa de entrada.
- Dia 14Alguém telefona e pergunta, ligeiramente irritado, porque é que ninguém respondeu ao seu pedido.
- Dia 15A causa é encontrada numa hora. As mensagens dessas duas semanas perderam-se – a menos que o formulário tenha guardado também uma cópia.
As causas habituais
- A palavra-passe SMTP ou o fornecedor de correio eletrónico mudou. O formulário continua a autenticar-se com as credenciais antigas e o servidor de correio recusa – em silêncio, pelo menos do ponto de vista do visitante.
- PHP mail() sem autenticação. O servidor Web envia o correio diretamente, sem se autenticar num servidor de correio adequado. Muitos servidores recetores tratam esse correio como suspeito: acaba no spam ou é rejeitado sem mais.
- SPF, DKIM e DMARC não estão alinhados. Muitos formulários colocam o endereço do visitante no campo From. A mensagem afirma então vir, por exemplo, de um endereço gmail.com, mas é enviada pelo seu servidor Web – exatamente o que o DMARC foi concebido para impedir.
- Uma atualização de plugin ou uma mudança de tema avaria o formulário ou o respetivo CAPTCHA. Um modelo alterado deixa cair um campo, um script deixa de ser carregado ou o widget do CAPTCHA aparece sem o seu script – e todas as submissões falham a validação.
- A caixa de correio de destino está cheia. O servidor de correio recusa novas mensagens, e a 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», os visitantes que recusam cookies podem receber um formulário que não pode ser submetido, ou cujas submissões são rejeitadas por falta de um token.
- Um certificado TLS ou um domínio expirado. Os visitantes veem um aviso do navegador e saem, ou o servidor de correio deixa de poder ser contactado de forma segura. Se o domínio da caixa de correio de destino expirar, o correio para ela simplesmente deixa de chegar.
- Uma camada de cache serve páginas desatualizadas. Uma cache de página completa pode entregar um formulário com um token de segurança expirado (um nonce ou token CSRF). O servidor rejeita a submissão e, consoante a configuração, o visitante não vê nenhum erro claro.
A armadilha do endereço From
A terceira causa merece uma análise mais atenta, porque muitas configurações de formulários a trazem incorporada por predefinição. O DMARC verifica se o domínio do endereço From visível corresponde a um domínio validado por SPF ou DKIM. Se o formulário enviar uma mensagem «a partir do» endereço do visitante, o seu servidor não está autorizado a enviar em nome desse domínio, pelo que a verificação falha. Consoante a política DMARC do domínio do visitante e o seu próprio fornecedor de correio eletrónico, a mensagem acaba no spam ou é rejeitada. A solução é simples: enviar a partir de um endereço do seu próprio domínio e colocar o endereço do visitante em Reply-To. Clicar em «Responder» continua a chegar ao visitante.
- From: o endereço do visitante
- Sem Reply-To
- PHP mail() diretamente a partir do servidor Web
- Sem SPF, DKIM nem DMARC para o domínio emissor
- A mensagem existe apenas como e-mail
- From: um endereço do seu próprio domínio, p. ex. formulario@oseudominio
- Reply-To: o endereço do visitante
- SMTP com autenticação ou um serviço de envio
- SPF, DKIM e DMARC configurados e alinhados
- É também guardada uma cópia na base de dados
O que fazer
- 1Envie regularmente uma mensagem de teste através do seu próprio formulário – pelo menos mensalmente e sempre após atualizações, mudanças de tema ou alterações às definições de correio. Identifique-a claramente como teste para que ninguém lhe responda.
- 2Conheça o 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 calmo.
- 3Envie por SMTP com autenticação – através do seu fornecedor de correio eletrónico ou de um serviço de envio dedicado – em vez de depender do PHP mail().
- 4Utilize o 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.
- 5Guarde uma cópia de cada submissão na base de dados. Muitos plugins de formulários oferecem esta opção, por vezes como extra. Se o correio falhar, os pedidos de contacto continuam lá.
- 6Verifique o formulário após cada atualização de plugin – incluindo o CAPTCHA, e também com os cookies recusados.
Verificações como estas são fáceis de esquecer, e é por isso que vale a pena automatizá-las. Com uma conta e um domínio verificado, a formexposed pode enviar uma submissão de teste claramente identificada e verificar se chega efetivamente (a verificação de entrega, apenas mediante ativação). Deteta também o 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, bem como a expiração do certificado TLS e do domínio. Só é alertado quando algo muda.
Se quiser apenas um primeiro olhar: uma verificação gratuita em formexposed.com não precisa de conta e não submete nada. Entre outras coisas, mostra se existe um CAPTCHA presente mas avariado – um widget sem o respetivo script, uma chave de teste pública, erros no navegador –, uma das formas mais silenciosas de um formulário deixar de funcionar. Se as mensagens chegam realmente só pode ser confirmado por uma mensagem de teste real, por isso envie uma hoje.