# DMARC no WordPress: Configure SPF, DKIM e DMARC em 5 passos 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.
SPF, DKIM e DMARC: função, tipo de registro DNS e o que valida
Registro Tipo no DNS O que valida Falha gera
SPF TXT IP/servidor autorizado a enviar Soft/hard fail no envelope
DKIM TXT (seletor) Assinatura criptográfica do corpo Assinatura inválida
DMARC TXT (_dmarc) Alinhamento de SPF/DKIM com o From none, quarantine ou reject
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:relatorios@seudominio.com`. 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". 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

Por que o e-mail do meu formulário WordPress cai em spam mesmo com plugin de SMTP?

Porque o SMTP autentica a conexão, mas o provedor de destino ainda checa SPF, DKIM e DMARC no DNS do domínio. Se o IP do servidor de envio não estiver no SPF, ou se o DKIM não alinhar com o domínio do From, o Gmail manda para spam. O SMTP é o passo 1; os três registros DNS fecham a cadeia de autenticação.

É possível configurar DMARC sem ter acesso ao painel de DNS do domínio?

Não. O DMARC é um registro TXT no host _dmarc do DNS, então exige acesso ao painel de DNS, seja no registrador, na hospedagem ou na Cloudflare. Sem esse acesso, você não publica a política. A saída é solicitar ao responsável pelo domínio ou apontar o DNS para a Cloudflare, onde os três TXT ficam centralizados em um só lugar.

Qual a diferença entre SPF, DKIM e DMARC na prática?

O SPF lista os IPs autorizados a enviar pelo seu domínio. O DKIM assina cada mensagem com uma chave criptográfica publicada no DNS. O DMARC amarra os dois: define o que o destinatário faz quando SPF ou DKIM falham (none, quarantine ou reject) e pede relatórios. Na prática, SPF e DKIM provam a origem; o DMARC dita a consequência e dá visibilidade.

Quanto tempo o registro DMARC leva para propagar no DNS?

A propagação de um registro TXT de DMARC costuma ficar abaixo de 24 horas, e em DNS gerenciado como a Cloudflare cai para poucos minutos. O fator que define é o TTL configurado no painel. Depois de propagado, valide no MXToolbox antes de assumir que está ativo, porque cache de resolvedores intermediários pode atrasar a leitura em alguns provedores.

O que acontece se eu publicar DMARC com p=reject logo de início?

Todo e-mail legítimo que ainda não estiver com SPF ou DKIM alinhado é bloqueado pelo servidor de destino, incluindo notificações de formulário e o e-mail de redefinição de senha do próprio site. Por isso a política deve começar em p=none por duas a quatro semanas, com leitura dos relatórios, e só depois subir para quarantine e reject de forma gradual.

--- ## 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.