O DMARC é o registro DNS que diz ao servidor de destino o que fazer quando um e-mail do seu domínio falha na autenticação. Segundo o Cloudflare Radar (2026), 26,7% dos e-mails analisados no Brasil foram maliciosos. Sem SPF e DKIM alinhados, a política não funciona. Configure os três antes de exigir reject.

Configurar autenticação de e-mail no WordPress resolve o problema mais silencioso de quem usa formulários: a mensagem que sai do site e nunca chega na caixa de entrada. O DMARC é a camada que amarra SPF e DKIM e instrui o Gmail, o Outlook e o Yahoo sobre como tratar o que falha. No suporte da FULL, a gente vê que boa parte dos chamados de “formulário não envia” é, na verdade, e-mail entregue ao spam por falta desses três registros no DNS. Este guia mostra o caminho técnico, com os valores de registro reais, para o seu conteúdos de formulários WordPress da FULL chegarem ao destinatário.

Primeiros passos: O que SPF, DKIM e DMARC fazem juntos

SPF, DKIM e DMARC são três registros DNS que provam que um e-mail saiu mesmo do seu domínio. O SPF lista os servidores autorizados; o DKIM assina a mensagem com uma chave criptográfica; o DMARC define a política e pede relatórios. Os três trabalham em cadeia, e essa é a causa número um de e-mail de formulário no spam.

A ordem importa. Publique SPF e DKIM, valide o alinhamento e só depois suba a política do DMARC. Inverter essa sequência é o erro que mais aparece nos tickets de entrega.

Por que o e-mail do WordPress cai em spam sem autenticação

Cerca de 26,7% dos e-mails analisados no Brasil nos últimos 28 dias foram classificados como maliciosos, segundo o Cloudflare Radar. Diante desse volume, Gmail e Outlook ficaram rígidos: e-mail sem autenticação alinhada cai em spam. O WordPress, por padrão, envia pela função PHP mail() de um IP de hospedagem compartilhado, sem SPF nem DKIM do seu domínio.

O cenário causal é direto: WordPress usando PHP mail() nativo, mais domínio sem registro SPF, mais provedor de destino exigindo autenticação, igual a e-mail de formulário caindo em spam ou sendo rejeitado sem nenhum aviso ao administrador. A pessoa preenche o formulário, vê “enviado com sucesso”, e a notificação nunca chega. Por isso o primeiro passo técnico raramente é o DMARC: é trocar o envio nativo por um SMTP autenticado, tema que detalhamos em como configurar SMTP no WordPress com plugin premium.

Passo a passo: Configurar SPF, DKIM e DMARC no WordPress

Configurar os três registros leva de 30 a 60 minutos, mais o tempo de propagação do DNS, que costuma ficar abaixo de 24 horas. Você vai trabalhar em duas frentes: o painel de DNS do domínio (na Cloudflare, no registrador ou na hospedagem) e o WordPress, com um plugin de SMTP. Faça na ordem abaixo, validando cada etapa antes de avançar para a próxima.

Passo 1: Ative um SMTP autenticado no WordPress

Instale o WP Mail SMTP e conecte o site a um provedor de envio autenticado, como Gmail/Google Workspace, Brevo ou Amazon SES. Isso substitui o PHP mail() por uma conexão com credenciais, que entrega o e-mail por um servidor com reputação. Esse passo sozinho já corrige boa parte dos casos de formulário no spam, antes mesmo de qualquer registro DNS, e cria o remetente que o SPF vai autorizar.

Passo 2: Publique o registro SPF no DNS

No painel de DNS, crie um registro TXT na raiz do domínio com o valor do seu provedor de envio. Exemplo para Google Workspace: v=spf1 include:_spf.google.com ~all. O ~all é softfail, mais seguro para começar do que -all. Use apenas um registro SPF por domínio: dois registros TXT de SPF invalidam a autenticação inteira. Se você envia por mais de um serviço, combine os include: em uma única linha.

Passo 3: Gere e publique a chave DKIM

No painel do provedor de SMTP, gere o par de chaves DKIM e copie o registro TXT com o seletor (algo como selector1._domainkey). Publique esse TXT no DNS exatamente como o provedor entregou, sem quebrar a chave pública em linhas. O DKIM assina cada mensagem; o destinatário usa a chave pública do seu DNS para conferir que o corpo não foi adulterado e que o remetente é legítimo.

Passo 4: Crie o registro DMARC com p=none

Crie um registro TXT no host _dmarc com a política em modo de observação: v=DMARC1; p=none; rua=mailto:[email protected]. O p=none não bloqueia nada, apenas pede relatórios agregados (rua) para você enxergar quem envia em nome do domínio. Comece sempre por aqui. Subir DMARC com reject antes de validar o alinhamento derruba e-mail legítimo, incluindo o de redefinição de senha do próprio site.

Passo 5: Valide e endureça a política DMARC

Use o MXToolbox para confirmar que SPF, DKIM e DMARC estão publicados e que o alinhamento passa. Depois de duas a quatro semanas lendo os relatórios e confirmando que todo e-mail legítimo está alinhado, suba a política para p=quarantine e, mais tarde, p=reject. O endurecimento gradual é o que separa a proteção real do bloqueio acidental do seu próprio site.

Legenda: os três registros TXT (SPF na raiz, DKIM no seletor e DMARC em _dmarc) convivem no mesmo painel de DNS sem conflito.

Como validar o DMARC e ler os relatórios agregados

Validar o DMARC confirma duas coisas: que o registro está publicado e que SPF ou DKIM alinham com o domínio do campo From. O MXToolbox e o relatório agregado (rua) entregam esse diagnóstico em minutos. O relatório chega em XML, com a contagem de mensagens por IP de origem e o resultado de cada checagem.

É lendo esse XML que você descobre serviços enviando em seu nome, como um CRM, antes de apertar a política. O alinhamento é o ponto que mais gera confusão: um e-mail pode passar no SPF e ainda falhar no DMARC se o domínio do envelope não bater com o From. O mesmo vale para o DKIM, e em subdomínios de envio isso exige atenção redobrada. Pular essa validação e ir direto para p=reject transforma uma camada de segurança em um problema de entrega, especialmente para quem depende de notificações de formulário de contato no WordPress para captar leads.

Erros comuns ao configurar autenticação de e-mail

Os erros mais frequentes ao configurar SPF, DKIM e DMARC concentram-se em três pontos: SPF duplicado, política agressiva cedo demais e chave DKIM quebrada na publicação. Cada um derruba a entrega de um jeito diferente, e nenhum deles avisa o administrador. A regra de ouro é validar com ferramenta externa após cada alteração, nunca confiar só no “salvou no painel”.

• Se o e-mail ainda cai em spam após o SMTP → confira se o SPF inclui o provedor e se não há dois SPF.
• Se e-mails legítimos somem após subir a política → volte para p=none e confirme o alinhamento de DKIM.
• Se o DKIM aparece como inválido no MXToolbox → republique a chave pública sem quebra de linha e aguarde a propagação.
• Se você não tem acesso ao DNS → aponte o domínio para a Cloudflare, onde os TXT ficam centralizados.

Um detalhe que só aparece em operação real: em sites que enviam via PHP mail() de um IP compartilhado, publicar DMARC com p=reject antes de validar o alinhamento derruba até o e-mail de redefinição de senha. Formulário e spam andam juntos quando a autenticação não está pronta, assunto que aprofundamos em proteger formulário de spam no WordPress.

Quando vale a pena ter a infraestrutura gerenciada

Manter SPF, DKIM, DMARC, SMTP e a higiene de DNS de vários sites não escala no esquema “um painel por cliente”. A gente vê no suporte da FULL que agências e operações com muitos domínios perdem horas reconfigurando registros a cada migração. O plano PRO da FULL custa R$849,90 e cobre até 10 sites, o que dá R$85 por site, com os plugins de SMTP, segurança e formulários já no bundle, sem licença avulsa para cada domínio. Para quem gerencia carteira, centralizar a entrega de e-mail e a autenticação em FULL.services/planos reduz o retrabalho a cada novo site conectado, entre os 150 mil sites já na plataforma. Não é hospedagem: é a camada de gestão e os plugins que padronizam SPF, DKIM e DMARC em escala.

Perguntas frequentes sobre SPF, DKIM e DMARC

Próximos passos para garantir a entrega dos formulários

Garantir a entrega dos e-mails do WordPress é uma sequência, não um interruptor: SMTP autenticado, SPF na raiz, DKIM no seletor e DMARC começando em p=none. Endureça a política só depois de ler os relatórios agregados e confirmar o alinhamento. Para quem lida com vários domínios, padronizar essa base de autenticação evita que cada site novo repita o mesmo problema de formulário no spam. Vale revisar também a conformidade com a LGPD no WordPress ao tratar os dados captados, e consultar o tipos de registro DNS e o conceito de DNS sempre que surgir dúvida sobre qual TXT publicar. Para continuar aprendendo, o FULL Academy reúne os tutoriais de WordPress em um só lugar.