# Autenticação de e-mail no WordPress: Os 3 registros (SPF, DKIM, DMARC)

A <strong>autenticação de e-mail</strong> prova ao destino que a mensagem saiu do seu domínio, via SPF, DKIM e DMARC. Segundo o <a href="https://support.google.com/mail/answer/81126">Google Postmaster (2024)</a>, 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 <a href="https://full.services/formularios-wordpress/">formulários no WordPress da FULL</a> sabe que sem essa base de <a href="https://full.services/glossario/dns/">DNS</a> 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 <a href="https://full.services/wp-forms-plugin-formulario-wordpress/">plugin de formulário</a> 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.

<table id="comparativo-spf-dkim-dmarc">
  <caption>SPF, DKIM e DMARC na autenticação de e-mail: função de cada registro</caption>
  <thead>
    <tr>
      <th scope="col">Registro</th>
      <th scope="col">O que prova</th>
      <th scope="col">Onde fica</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">SPF</th>
      <td>Quais servidores podem enviar pelo domínio</td>
      <td>Registro TXT no DNS</td>
    </tr>
    <tr>
      <th scope="row">DKIM</th>
      <td>Assinatura criptográfica do conteúdo da mensagem</td>
      <td>Registro TXT com chave pública no DNS</td>
    </tr>
    <tr>
      <th scope="row">DMARC</th>
      <td>O que o destino faz quando SPF e DKIM falham</td>
      <td>Registro TXT em _dmarc.seudominio</td>
    </tr>
  </tbody>
</table>

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 <a href="https://full.services/o-melhor-guia-de-dns-do-wordpress/">DNS do WordPress</a>; 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 "contato@seudominio.com.br", mas a mensagem saiu de um IP de hospedagem compartilhada que o domínio nunca declarou. Nos últimos dias, segundo o <a href="https://radar.cloudflare.com/security/email">Cloudflare Radar</a> (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.

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia: Como avaliamos a autenticação de e-mail</h2>
<p>As observações deste guia vêm de tickets de suporte da FULL sobre formulários que não entregam e-mail, somadas a testes de envio entre <time datetime="2026-02">fevereiro</time> e <time datetime="2026-05">maio de 2026</time>, em WordPress 6.x com PHP 8.2, usando WP Mail SMTP e formulários do WPForms e do Contact Form 7. Cada domínio foi checado no MXToolbox e no Mail-Tester antes e depois de publicar SPF, DKIM e DMARC. As notas de entrega vieram do Mail-Tester e do painel do Google Postmaster Tools. Os números de mercado, como a exigência da Gmail desde 2024 e a fatia de e-mail malicioso, vêm de fontes externas nomeadas, não de medição interna.</p>
</aside>

---

## 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 <a href="https://full.services/planos">planos da FULL</a> 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 <a href="https://dmarc.org">DMARC.org</a> publica a especificação completa para quem quer ir a fundo.

<h2 id="faq">Perguntas frequentes sobre autenticação de e-mail no WordPress</h2>

<details>
<summary>O que é autenticação de e-mail no WordPress e por que ela importa?</summary>
<p>Autenticação de e-mail é o trio de registros DNS (SPF, DKIM e DMARC) que prova ao provedor de destino que a mensagem saiu mesmo do seu domínio. Importa porque o WordPress envia pela função mail() do PHP sem assinatura, e desde fevereiro de 2024 a Gmail exige os três. Sem eles, o e-mail do formulário cai no spam.</p>
</details>

<details>
<summary>É possível autenticar o e-mail do WordPress sem mexer no código?</summary>
<p>Sim. Um plugin SMTP como o WP Mail SMTP, com mais de 3 milhões de instalações, redireciona todo o envio do site para um provedor que assina com DKIM, sem tocar em uma linha de código. Você ainda precisa publicar o SPF e o DMARC no DNS, mas isso é colar três registros TXT, não programar.</p>
</details>

<details>
<summary>Por que o e-mail do meu formulário de contato cai no spam?</summary>
<p>Porque o servidor de hospedagem que envia pela função mail() do PHP quase nunca está autorizado no SPF do seu domínio. O cabeçalho From diz seu domínio, mas o IP de envio é outro, e a Gmail trata esse desalinhamento como suspeito. Trocar para SMTP autenticado com SPF correto resolve a maioria dos casos.</p>
</details>

<details>
<summary>Quanto tempo o DMARC leva para começar a proteger o domínio?</summary>
<p>O registro DMARC propaga no DNS em até 48 horas, mas a proteção real vem por etapas. Comece em p=none por cerca de uma semana, lendo os relatórios RUA, e só então passe para p=quarantine e p=reject. Pular direto para p=reject em um domínio novo costuma bloquear o próprio e-mail legítimo do site.</p>
</details>

<details>
<summary>Qual a diferença entre SPF, DKIM e DMARC na prática?</summary>
<p>O SPF lista quais servidores podem enviar pelo domínio; o DKIM assina o conteúdo da mensagem com uma chave criptográfica; e o DMARC decide o que o destino faz quando os dois falham, além de enviar relatórios. São três camadas complementares: o ideal é publicar os três, porque cada provedor confere combinações diferentes deles.</p>
</details>

---

## 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 <a href="https://full.services/como-configurar-autenticacao-de-dois-fatores-2fa-no-wordpress/">autenticação de dois fatores no WordPress</a> entende que segurança se constrói em camadas. Para continuar aprendendo, o <a href="https://full.services/academy/">FULL Academy</a> reúne os tutoriais e guias de WordPress em um só lugar.