A autenticação de e-mail prova ao destino que a mensagem saiu do seu domínio, via SPF, DKIM e DMARC. Segundo o Google Postmaster (2024), a Gmail exige os três de quem envia acima de 5.000 mensagens por dia. Sem eles, o e-mail do formulário cai no spam ou volta com erro 550. Configure os registros no DNS antes do plugin.

A autenticação de e-mail é o conjunto de registros DNS que diz aos servidores da Gmail, Outlook e Yahoo se a mensagem enviada pelo seu site é legítima ou falsificada. No WordPress, o problema aparece quando o formulário de contato manda um e-mail, ele some, e o cliente jura que nunca recebeu. A causa quase nunca é o plugin: é o domínio sem SPF, DKIM e DMARC. Quem cuida de formulários no WordPress da FULL sabe que sem essa base de DNS nenhum plugin de envio resolve. Este guia explica os três registros, o que cada um faz e como validar.

O que é autenticação de e-mail e por que o WordPress depende dela

A autenticação de e-mail é o trio de provas que viaja com cada mensagem: o SPF diz qual servidor pode enviar pelo domínio, o DKIM assina o conteúdo com uma chave criptográfica e o DMARC decide o que o destino faz quando os dois falham. Desde fevereiro de 2024 a Gmail exige os três de quem envia em volume.

Esse aperto desceu até o site pequeno. Um WordPress padrão envia e-mail pela função mail() do PHP, sem assinatura nenhuma. Para o servidor da Gmail, isso é uma carta sem remetente: a autenticação de e-mail ausente é o motivo número um de mensagem do plugin de formulário parar no spam ou ser rejeitada.

Os 3 registros da autenticação de e-mail: SPF, DKIM e DMARC

A autenticação de e-mail no WordPress se apoia em 3 registros DNS que resolvem problemas diferentes: o SPF autoriza servidores, o DKIM assina a mensagem e o DMARC define a política de bloqueio. Pular um só já abre o buraco que a Gmail enxerga em milissegundos. A tabela abaixo resume a função de cada um.

Os três registros da autenticação de e-mail resolvem problemas diferentes e por isso são complementares, não substitutos. O SPF lista, num registro TXT, os IPs autorizados a enviar pelo domínio: se o servidor de envio não estiver na lista, a checagem falha. O DKIM adiciona uma assinatura digital que o destino confere contra uma chave pública publicada no DNS do WordPress; se um caractere da mensagem mudou no caminho, a assinatura quebra. O DMARC amarra os dois: ele define a política (p=none, p=quarantine ou p=reject) e ainda envia relatórios. Pular qualquer um deixa um buraco que a Gmail enxerga em milissegundos.

Por que o e-mail do seu formulário cai no spam

O e-mail do formulário cai no spam porque o WordPress, na configuração padrão, envia pela função mail() do PHP a partir do servidor de hospedagem, e esse servidor quase nunca está autorizado no SPF do seu domínio. Sem autenticação de e-mail válida, a Gmail aplica a política mais conservadora.

O resultado é uma falha de alinhamento: o cabeçalho From diz “[email protected]”, mas a mensagem saiu de um IP de hospedagem compartilhada que o domínio nunca declarou. Nos últimos dias, segundo o Cloudflare Radar (janela de 2026-06-09), 26,7% do tráfego de e-mail analisado no Brasil foi classificado como malicioso, então os provedores estão mais rígidos do que nunca. A gente vê no suporte da FULL que a maioria dos casos de “formulário não chega” se resolve com SPF correto mais um plugin SMTP, sem tocar no tema.

Como o WordPress envia e onde a autenticação entra

A autenticação de e-mail entra no momento em que o WordPress troca a função mail() do PHP por um envio SMTP autenticado, que sai de um servidor real e já alinhado ao seu SPF e DKIM. O plugin WP Mail SMTP, com mais de 3 milhões de instalações ativas, faz exatamente essa troca de transporte.

Ele redireciona todo e-mail do site (formulário, recuperação de senha, pedido WooCommerce) para um provedor como Gmail, Brevo ou Amazon SES, que assina a mensagem com DKIM no seu nome. A relação causal é direta: formulário do WPForms mais função mail() do PHP em servidor compartilhado mais domínio sem registro SPF resulta em e-mail entregue pela porta dos fundos, que a Gmail joga no spam ou rejeita com erro 550. Trocar o transporte por SMTP autenticado tende a resolver isso na maioria dos cenários, desde que o DNS esteja correto.

Como validar a autenticação de e-mail antes de confiar nela

Validar a autenticação de e-mail leva cerca de 5 minutos e dispensa adivinhação: três ferramentas leem seu domínio e dizem exatamente o que falta. O MXToolbox checa SPF, DKIM e DMARC publicados no DNS e aponta erros de sintaxe na hora.

O Mail-Tester recebe um e-mail de teste do seu próprio site e devolve uma nota de 0 a 10, sinalizando se a assinatura DKIM bateu e se o SPF passou. O Google Postmaster Tools mostra, para quem usa Gmail, a taxa de spam e o status de autenticação ao longo do tempo. A confiança aqui tende a ser maior quando os três relatórios concordam, e não quando um plugin apenas afirma que está tudo certo. Validar antes evita a surpresa de descobrir, pela reclamação do cliente, que o e-mail nunca chegou.

A plataforma FULL: Autenticação e formulários sem mexer no DNS na unha

Configurar a autenticação de e-mail na unha exige editar três registros TXT no DNS, e um erro de sintaxe num deles derruba a entrega do domínio inteiro. Na plataforma FULL, o SMTP autenticado e os plugins de formulário já chegam ativados em um clique.

Com isso, o e-mail do site sai assinado por DKIM desde o primeiro envio, sem você tocar no DNS na unha. O plano PRO custa R$849,90 por ano para dez sites, o que dá R$85 por site, com os 17 plugins do bundle inclusos (WPForms entre eles). A gente vê no suporte da FULL que boa parte do tempo perdido com “e-mail não chega” some quando o transporte já nasce autenticado. Veja os planos da FULL para entender o que muda entre eles.

DMARC na prática: Comece em p=none, não em p=reject

A política do DMARC define o que o destino faz quando a autenticação de e-mail falha, e há 3 níveis: p=none só monitora, p=quarantine manda para o spam e p=reject bloqueia de vez. Começar pela mais dura é o erro mais comum em domínio novo.

Subir o DMARC direto para p=reject antes de passar uma semana lendo os relatórios agregados (o RUA) costuma bloquear o próprio e-mail transacional do site, porque um serviço legítimo como o formulário de contato ainda não foi incluído no SPF. O caminho seguro é começar em p=none, ler o RUA por alguns dias e só então endurecer. A relação a evitar é clara: DMARC com p=reject mais DKIM desalinhado entre o domínio de envio e o cabeçalho From bloqueia o e-mail legítimo do próprio site. O DMARC.org publica a especificação completa para quem quer ir a fundo.

Perguntas frequentes sobre autenticação de e-mail no WordPress

Próximos passos para entregar todo e-mail do seu site

A autenticação de e-mail deixou de ser detalhe técnico e virou requisito de entrega: sem SPF, DKIM e DMARC, o e-mail do formulário não chega, e nenhum plugin sozinho contorna um DNS incompleto. Comece publicando os três registros, troque o envio para SMTP autenticado, valide no MXToolbox e no Mail-Tester e suba o DMARC com calma de p=none até p=reject. Se você já protege o login com camadas extras, vale aplicar a mesma disciplina ao e-mail: quem configura autenticação de dois fatores no WordPress entende que segurança se constrói em camadas. Para continuar aprendendo, o FULL Academy reúne os tutoriais e guias de WordPress em um só lugar.