Emails do formulário de contacto a cair no spam — a correção do envio pelo servidor web (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

Os emails do formulário de contacto e do site caem no spam porque o seu servidor web os envia sem autenticação — sem autorização SPF, sem assinatura DKIM. A correção fiável é encaminhar esse correio por SMTP autenticado, não colocar o servidor numa lista branca. 46,4% dos 261.086.232 domínios classificados no censo do Defaults.Exposed (dados a 2026-06-29) não publicam qualquer registo SPF.

A ordem da correção importa e a maioria dos tutoriais tem-na ao contrário. Execute uma verificação gratuita para ver o que o seu domínio realmente publica; encaminhe o correio do site por SMTP autenticado (o seu fornecedor de email ou um serviço de email transacional) para que receba uma assinatura DKIM real; corrija o endereço From do formulário; e só adicione o IP do servidor ao SPF em último recurso.

Porque é que os emails do meu site vão para o spam?

Por causa de quem realmente os envia. Quando um visitante submete o seu formulário de contacto, o email não é enviado pelo seu fornecedor de correio — o servidor web gera-o ele próprio, normalmente através do mail() do PHP. Do lado de quem recebe, essa mensagem:

vem de um IP que o seu registo SPF não autoriza (o seu SPF cobre o seu fornecedor de correio, não o seu alojamento web);
não traz assinatura DKIM nenhuma, portanto nada a liga criptograficamente ao seu domínio;
muitas vezes sai de um IP de alojamento partilhado cuja reputação é definida pelos sites de centenas de desconhecidos.

Correio não autenticado a partir de um IP de reputação mista é exatamente o que os filtros de spam existem para apanhar — o Gmail e o Outlook veem um servidor qualquer a afirmar ser você. O panorama geral é sombrio: 46,4% dos domínios não publicam SPF nenhum, e apenas 10,59% (27.640.987 de 261.086.232 domínios classificados, censo a 2026-06-29) aplicam uma política DMARC.

Porque é que isto atinge sobretudo sites WordPress?

O WordPress envia todo o seu email — notificações de formulários, reposições de palavra-passe, confirmações de encomenda — através de uma única função, wp_mail(), que por omissão usa o mail() do PHP no servidor web. Todos os sites WordPress que não foram deliberadamente reconfigurados são, de origem, remetentes não autenticados. Os plugins de formulários (Contact Form 7, WPForms, Gravity Forms) entregam todos o correio à mesma função: parece um problema do plugin, mas é um problema de transporte.

A correção não é outro plugin de formulários mas sim um plugin de SMTP (WP Mail SMTP e equivalentes), que redireciona tudo o que o wp_mail() envia através de uma conta de correio real e autenticada — infraestrutura que o seu SPF já autoriza, com assinatura DKIM incluída.

Que método de envio deve o site usar?

Método de envio	SPF	DKIM	Sobrevive a uma migração de alojamento?	Veredicto
`mail()` do PHP / `wp_mail()` por omissão a partir da máquina web	falha	nenhum	n/a — avariado em todo o lado	o problema, não uma opção
SMTP autenticado através do seu fornecedor de email (Google Workspace, Microsoft 365, etc.)	passa	assinado	sim — independente do alojamento	a correção para a maioria dos sites
Serviço de email transacional (SES, Postmark, Brevo, etc.) com o seu domínio verificado	passa	assinado	sim	a correção em volume (e-commerce, formulários grandes)
IP do servidor web adicionado ao seu registo SPF	passa (apenas SPF)	nenhum	não — parte-se em silêncio quando o IP muda	apenas último recurso — veja abaixo

Para meia dúzia de notificações por dia, SMTP através da caixa de correio que já paga é o caminho mais curto; com volume a sério, um serviço transacional foi feito para isso. Ambos lhe dão DKIM — o atalho de colocar o IP na lista branca nunca dá.

Como corrijo a entregabilidade dos emails do formulário de contacto?

Execute a verificação gratuita em defaults.exposed antes de tocar em qualquer coisa. Mostra que SPF, DKIM e DMARC o seu domínio realmente publica — se está a corrigir o transporte do formulário, um registo em falta, ou ambos. Não tem SPF nenhum? Comece por como corrigir o SPF.
Crie uma identidade SMTP dedicada para o site — por exemplo [email protected] no seu fornecedor de email, ou um domínio de envio verificado num serviço transacional. Use uma palavra-passe de aplicação ou chave de API que possa revogar, não a palavra-passe da caixa de correio de uma pessoa.
Encaminhe o correio do site por essa conta. WordPress: instale um plugin de SMTP e aponte-o para essa conta. Outras stacks: configure o mailer da framework em vez do mail() local.
Corrija o endereço From (o anti-padrão abaixo): o From tem de ser o seu próprio domínio; o visitante vai no Reply-To.
Se o remetente for um serviço transacional, adicione os registos DKIM dele (normalmente um par de CNAMEs) para que o correio seja assinado com o seu domínio — os passos de DNS seguem o modelo dos guias de configuração do SPF.
Envie uma submissão de teste e volte a verificar. Os cabeçalhos devem mostrar spf=pass e dkim=pass para o seu domínio; depois resolva tudo o resto que a verificação assinalar através de corrigir o SPF e corrigir o DKIM.

Porque é que o formulário envia “de” o endereço de email do visitante?

A ferida autoinfligida mais comum na configuração de formulários, e muitos plugins faziam-no por omissão: a notificação chega From: o endereço do visitante, para poder carregar em responder. Parece conveniente, e é falsificação. O seu servidor não tem qualquer direito de enviar correio como [email protected] — falha o SPF e o DKIM para gmail.com, e a política DMARC do Gmail diz aos recetores para o mandarem para o lixo ou rejeitarem. A correção não custa nada:

From: um endereço no seu próprio domínio (a identidade SMTP do passo 2)
Reply-To: o endereço do visitante — a resposta continua a ir diretamente para ele

Todos os plugins de formulários mais usados suportam isto; são dois campos nas definições da notificação.

Porque não adicionar simplesmente o IP do servidor ao meu registo SPF?

É a correção a que a maioria dos fóruns recorre primeiro, e é o último recurso por uma razão. Adicionar ip4:<server> (ou um mecanismo a para o seu alojamento web) ao SPF faz de facto passar a verificação bruta — mas:

Em alojamento partilhado, autoriza desconhecidos. O IP pertence à máquina, não a si; todos os outros sites nesse servidor podem agora enviar correio que passa o SPF como o seu domínio.
Parte-se em silêncio. Os alojamentos migram servidores e mudam IPs sem lhe dizer; o seu SPF continua a autorizar um endereço que abandonou há meses.
Não lhe dá DKIM. O SPF sozinho parte-se com o reencaminhamento e não o consegue levar até à aplicação do DMARC como uma assinatura consegue.

Reserve este caminho para o caso genuinamente limitado: um servidor dedicado com um IP estático que controla e uma aplicação que não consegue falar SMTP — e, se puder, junte-lhe assinatura DKIM na própria máquina.

O SPF sequer verifica o endereço que o meu formulário põe no “From”?

Não — e isto engana metade dos diagnósticos caseiros. Os recetores avaliam o SPF em relação ao domínio do Return-Path (RFC5321.MailFrom), não ao cabeçalho From. Os servidores web muitas vezes carimbam o seu próprio hostname no Return-Path, portanto o seu registo SPF nunca foi sequer consultado — o recetor verificou o SPF de srv0421.examplehost.com. O SMTP autenticado corrige isto também: o Return-Path passa a ser o seu domínio, e o SPF que passa conta finalmente para si. É também por isto que o DKIM importa — o alinhamento DMARC precisa de um resultado positivo ligado ao domínio no From, e uma assinatura DKIM viaja com a mensagem.

Perguntas frequentes

Um plugin de SMTP corrige também os emails de reposição de palavra-passe e do WooCommerce? Sim. No WordPress tudo flui através do wp_mail(), portanto redirecioná-lo corrige notificações de formulários, reposições de palavra-passe e emails de encomenda de uma só vez.

Continuo a precisar de registos SPF e DKIM se usar um plugin de SMTP? Sim — o plugin muda qual infraestrutura envia o seu correio; os registos são o que a autoriza. Se o seu domínio está entre os 46,4% dos 261.086.232 domínios classificados sem registo SPF (censo, 2026-06-29), o SMTP autenticado sozinho não o salva. A checklist de email para domínios novos cobre o conjunto completo de registos.

Os emails do meu formulário passam o SPF mas continuam a falhar o DMARC — porquê? Quase sempre é o anti-padrão de falsificação do From descrito acima, ou o SPF a passar para o domínio do Return-Path do alojamento em vez do seu. Corrija primeiro o From/Reply-To; se continuar a falhar, a peça em falta é uma assinatura DKIM alinhada — veja “DKIM signature not valid”. Se as ferramentas SaaS para além do site também falharem, o guia de SPF a falhar para SaaS cobre a ordem de correção.

Vale a pena tudo isto para um formulário de contacto com pouco tráfego? O formulário é normalmente por onde o dinheiro entra — um pedido de contacto perdido é um cliente que nunca soube que perdeu. E a correção é gratuita; a barreira é saber que o servidor web era, desde o início, o remetente não autenticado.

Envie o relatório ao proprietário

Se é o programador ou o prestador de serviços a corrigir isto: quando a submissão de teste passar, volte a executar a verificação gratuita e reencaminhe o relatório classificado ao proprietário do site — um registo datado, em linguagem simples, de que o domínio autentica corretamente, e o comprovativo de que ele vai precisar na próxima renovação do seguro cibernético ou questionário de segurança de um cliente. Se é o proprietário e está a ler isto porque os pedidos de contacto deixaram de chegar: envie esta página e o seu relatório de verificação a quem gere o seu site — é trabalho de uma tarde, com um antes-e-depois que lhe podem mostrar.

Verifique o seu domínio → · SPF a falhar para as suas ferramentas SaaS? → · Corrigir o SPF → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.