Porque o seu formulário de contacto é o seu maior risco de spam

O problema é mais antigo do que pensa

Os formulários de contacto são um vetor de spam desde o início dos anos 2000, mas o problema agravou-se à medida que os fornecedores de email apertaram os seus requisitos de autenticação. A maioria dos formulários de contacto continua a ser construída da mesma forma: o utilizador preenche um formulário, o seu servidor envia um email usando o endereço do utilizador no cabeçalho From, e fica à espera de respostas.

Isto é uma vulnerabilidade clássica de falsificação de email. Os spammers podem usar o seu formulário para enviar email que parece vir de qualquer endereço que queiram, encaminhado através do IP do seu servidor. Se sair spam suficiente desta forma, o seu domínio é sinalizado e os seus emails transacionais legítimos deixam de chegar às caixas de entrada.

A correção é simples, mas a maioria dos tutoriais continua a fazê-la mal.

O que torna os formulários de contacto tão exploráveis

Um formulário de contacto típico aceita três campos: nome, email e mensagem. O handler do lado do servidor pega nesse endereço de email e coloca-o diretamente no cabeçalho From de uma mensagem SMTP de saída. Isto é conveniente para respostas — basta carregar em "responder" na sua caixa de entrada — mas também é um presente para spammers.

Eis o que acontece quando um spammer encontra o seu formulário:

1. Submete o formulário com o endereço de email de uma vítima no campo "from"
2. O seu servidor envia obedientemente um email com o endereço dessa vítima no cabeçalho From
3. O servidor de email da vítima vê um email que afirma vir do seu domínio, mas que tem origem no seu IP
4. Se o seu domínio não tiver registos SPF/DKIM/DMARC adequados (ou mesmo que os tenha), o email pode ainda assim passar porque muitos servidores são permissivos com tráfego de formulários de contacto
5. A vítima recebe spam que parece vir do seu próprio endereço, ou o seu domínio é sinalizado por falsificação

Isto não é um ataque teórico. Acontece constantemente. Se tem um formulário de contacto e nunca verificou os logs do seu servidor de email, provavelmente já está a ser usado desta forma.

A forma correta de enviar email de formulários de contacto

A correção é nunca colocar entrada do utilizador no cabeçalho From. Em vez disso:

• From: [email protected] (ou qualquer endereço que controle)
• Reply-To: O endereço de email submetido pelo utilizador
• Subject: Inclua o nome do utilizador se quiser, mas nunca o email
• Body: Inclua todos os dados do formulário, claramente identificados

Desta forma, o seu servidor só envia email a partir de endereços que possui e que autenticou corretamente. Quando carrega em "responder" na sua caixa de entrada, a resposta continua a ir para o utilizador — é isso que Reply-To faz. Mas os spammers não podem usar o seu formulário para se fazerem passar por endereços arbitrários.

A maioria das bibliotecas de email suporta isto de raiz. Em PHP's PHPMailer:

$mail->setFrom('[email protected]', 'Contact Form');
$mail->addReplyTo($_POST['email'], $_POST['name']);

Em Python's smtplib com email.mime:

msg['From'] = '[email protected]'
msg['Reply-To'] = form_data['email']

Em Node.js com Nodemailer:

const mailOptions = {
  from: '[email protected]',
  replyTo: req.body.email,
  // ...
};

Se o seu formulário de contacto atualmente coloca entrada do utilizador no cabeçalho From, isto é uma correção de uma linha. Faça-a hoje.

A limitação de taxa não é opcional

Mesmo com uma higiene de cabeçalhos adequada, um formulário de contacto desprotegido continua a ser um vetor de spam. Os spammers irão submeter o seu formulário centenas de vezes com corpos de mensagem diferentes, e a sua caixa de entrada ficará cheia de lixo.

Precisa de limitação de taxa em vários níveis:

• Por IP: Não mais de 5 submissões por hora a partir do mesmo IP
• Por email: Não mais de 3 submissões por dia a partir do mesmo endereço de email
• Global: Não mais de 50 submissões por hora entre todos os utilizadores (ajuste com base no seu tráfego)

A limitação de taxa pertence ao código da sua aplicação, não apenas à configuração do seu servidor web. A limitação de taxa do Nginx e do Apache pode ajudar, mas opera ao nível do pedido e não sabe nada sobre endereços de email nem padrões de abuso específicos de formulários.

Se usa uma framework, provavelmente existe um middleware de limitação de taxa que pode integrar. Se está a construir do zero, um contador simples em Redis com chaves que expiram funciona bem:

key = f"contact_form:{ip_address}"
count = redis.incr(key)
if count == 1:
    redis.expire(key, 3600)  # 1 hour
if count > 5:
    return error("Rate limit exceeded")

Isto não é à prova de bala — os spammers podem alternar IPs — mas aumenta significativamente o custo do abuso.

CAPTCHAs são uma troca, não uma solução

O reCAPTCHA v3 da Google é invisível e pontua os utilizadores com base no comportamento, o que parece ideal. Na prática, bloqueia utilizadores legítimos com mais frequência do que seria de esperar, especialmente utilizadores em VPNs, Tor ou redes empresariais partilhadas.

O reCAPTCHA v2 (a caixa de seleção "I'm not a robot") é mais fiável, mas acrescenta fricção. Campos honeypot — inputs de formulário ocultos que humanos não preenchem, mas bots sim — apanham bots pouco sofisticados sem impacto para o utilizador, mas são triviais de contornar para qualquer spammer sério.

A melhor abordagem é em camadas:

1. Cabeçalhos de email adequados (não negociável)
2. Limitação de taxa (não negociável)
3. Campo honeypot (ganho fácil, sem desvantagens)
4. CAPTCHA apenas se ainda estiver a receber spam significativo depois do anterior

Se adicionar um CAPTCHA, use reCAPTCHA v3 com um limiar baixo (0,5 ou inferior) e um fallback para v2 para utilizadores com pontuação fraca. Isto mantém a fricção baixa para a maioria dos utilizadores, ao mesmo tempo que continua a bloquear bots.

Quando usar um serviço de formulários de terceiros

Se gere um site pequeno e não quer manter infraestrutura de formulários, serviços de terceiros como Formspree, Tally ou Netlify Forms tratam de tudo isto por si. Aplicam limitação de taxa, validam e enviam email a partir dos seus próprios domínios, para que a sua reputação se mantenha limpa.

A contrapartida é que está a enviar dados de utilizadores para terceiros, o que pode entrar em conflito com a sua política de privacidade ou obrigações do GDPR. Processar dados do lado do cliente é uma tendência crescente para equipas preocupadas com privacidade, mas os formulários de contacto exigem inerentemente processamento do lado do servidor — não é possível enviar email a partir do browser sem expor credenciais.

Se está a lidar com pedidos sensíveis (jurídicos, médicos, financeiros), provavelmente precisa de gerir a sua própria infraestrutura de formulários. Para tudo o resto, um serviço de terceiros é uma escolha razoável.

O problema do DMARC

Mesmo que corrija os cabeçalhos do seu formulário de contacto, não está seguro se o seu domínio não tiver uma política DMARC. O DMARC diz aos servidores de email recetores o que fazer com emails que falham as verificações SPF ou DKIM. Sem ele, os spammers continuam a poder enviar email que parece vir do seu domínio, mesmo que não estejam a usar os seus servidores.

Configurar DMARC está fora do âmbito deste artigo, mas, se leva a sério a reputação de email, é inegociável. Comece com uma política apenas de monitorização (p=none) e avance gradualmente para p=quarantine ou p=reject à medida que verifica que o seu email legítimo está corretamente autenticado.

E quanto a Consentimento de cookies e monitorização de formulários?

Se o seu formulário de contacto usa analytics ou pixels de marketing para acompanhar submissões, provavelmente está sujeito ao GDPR e às regras de ePrivacy. A maioria dos formulários de contacto não precisa de tracking — já sabe que alguém submeteu o formulário porque recebeu o email — mas, se está a usar algo como Facebook Pixel ou eventos do Google Analytics, precisa de consentimento explícito antes de esses scripts carregarem.

A abordagem mais simples é não monitorizar submissões de formulários de contacto de todo. Se tiver mesmo de as monitorizar, carregue scripts de tracking apenas depois de o utilizador consentir, e garanta que o seu banner de consentimento está em conformidade.

Principais conclusões

• Nunca coloque endereços de email submetidos por utilizadores no cabeçalho From. Use Reply-To em vez disso.
• A limitação de taxa é obrigatória. Implemente-a ao nível da aplicação, não apenas no servidor web.
• Campos honeypot são um ganho gratuito. CAPTCHAs devem ser um último recurso.
• Serviços de formulários de terceiros são uma escolha razoável para sites pequenos, mas introduzem compromissos de privacidade.
• Se envia qualquer email a partir do seu domínio, precisa de uma política DMARC.

FAQ

Q: Posso simplesmente desativar o formulário de contacto e usar um link mailto em vez disso?

A: Pode, mas links mailto expõem o seu endereço de email a scrapers, e perde a capacidade de recolher dados estruturados. Se o spam for esmagador, um link mailto é melhor do que um formulário de contacto avariado, mas corrigir o formulário é melhor do que ambos.

Q: E se eu precisar de enviar email a partir do endereço do utilizador por motivos legítimos?

A: Quase de certeza que não precisa. Se acha que precisa, provavelmente está a tentar resolver um problema de workflow (como encaminhamento de respostas) que Reply-To já resolve. Se precisar genuinamente de enviar email a partir de endereços arbitrários, precisa de um serviço de email dedicado com autenticação adequada, não de um formulário de contacto.

Q: Como sei se o meu formulário de contacto já está a ser abusado?

A: Verifique os logs do seu servidor de email para ligações SMTP de saída. Se vir um volume elevado de email de saída para endereços que não reconhece, ou se o seu domínio foi sinalizado por bases de dados de spam como Spamhaus, provavelmente está a ser usado como relay. Ferramentas como MXToolbox podem verificar a reputação do seu domínio.

Q: É seguro usar um serviço CAPTCHA gratuito?

A: O reCAPTCHA da Google é gratuito e amplamente usado, mas envia dados de utilizadores para a Google, o que pode entrar em conflito com a sua política de privacidade. hCaptcha é uma alternativa focada na privacidade que não treina modelos de IA com os seus utilizadores. Cloudflare Turnstile é outra opção menos intrusiva do que CAPTCHAs tradicionais.

Q: Qual é a diferença entre SPF, DKIM e DMARC?

A: SPF lista que servidores de email estão autorizados a enviar email a partir do seu domínio. DKIM assina criptograficamente email de saída para que os destinatários possam verificar que não foi adulterado. DMARC liga os dois e diz aos destinatários o que fazer se um email falhar as verificações SPF ou DKIM. Precisa dos três para uma autenticação de email adequada.

Fontes

• OWASP: Email Header Injection — Explicação detalhada de como formulários de contacto podem ser explorados para falsificação de email.
• RFC 5322: Internet Message Format — A norma técnica que define cabeçalhos de email, incluindo From e Reply-To.
• DMARC.org: Overview — Recurso oficial para compreender e implementar políticas DMARC.
• Spamhaus: Domain Blocklists — Verifique se o seu domínio foi sinalizado por spam e compreenda como funcionam as blocklists.