SPF, DKIM e DMARC: como impedir o spoofing de e-mail passo a passo

Resumo: o SPF lista os servidores autorizados a enviar e-mails em nome do seu domínio, o DKIM assina cada mensagem e o DMARC verifica se um dos dois passa para o domínio do endereço visível no campo From, e depois diz aos servidores de destino o que fazer com as mensagens que falham. Desde fevereiro de 2024, Gmail e Yahoo exigem SPF ou DKIM de todos os remetentes e SPF, DKIM e DMARC de remetentes em massa, e o Gmail endurece a aplicação das regras desde novembro de 2025. Publique um único registro SPF, ative o DKIM em todos os serviços que enviam e-mails por você, comece o DMARC em p=none com relatórios e passe para p=quarantine ou p=reject quando seus e-mails legítimos estiverem passando.

O e-mail foi criado sem nenhuma prova de quem enviou a mensagem. Qualquer pessoa pode colocar billing@yourcompany.com no campo From e, sem registros de autenticação, o servidor receptor não tem como saber que é falso. É assim que funcionam a fraude de faturas e o phishing em seu nome, e é também por isso que seus e-mails verdadeiros podem parecer suspeitos para o Gmail.

SPF, DKIM e DMARC resolvem isso com três registros DNS. Este guia explica como eles se encaixam, o que os grandes provedores de e-mail exigem, como nosso verificador gratuito de SPF e DMARC lê o seu domínio e como sair de nenhum registro até uma política aplicada sem quebrar seus próprios e-mails.

Como SPF, DKIM e DMARC funcionam juntos

O ponto fraco de SPF e DKIM isolados está na linha "qual domínio verifica". A RFC 7208 diz que o SPF verifica as identidades MAIL FROM e HELO, que o destinatário nunca vê. Um golpista pode passar no SPF do próprio domínio enquanto exibe o seu no campo From. O DMARC fecha essa brecha com o alinhamento: uma mensagem só passa no DMARC se o SPF ou o DKIM passar para um domínio que corresponda ao domínio do From (o alinhamento relaxado permite subdomínios da mesma organização).

SPF em um registro

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Cada include autoriza os servidores de um provedor; o -all no final diz que todo o resto falha. A RFC 7208 define os qualificadores: - é fail, ~ é softfail ("provavelmente não autorizado"), ? é neutral e + é pass. O +all autoriza a internet inteira e anula o propósito do registro.

DKIM em um registro

Seu provedor de e-mail assina as mensagens enviadas com uma chave privada e entrega uma chave pública para você publicar sob um seletor, por exemplo google._domainkey.example.com. Cada serviço de envio usa o próprio seletor, então você pode ter várias chaves DKIM ao mesmo tempo (RFC 6376).

DMARC em um registro

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p é a política do domínio, sp a dos subdomínios, e rua recebe relatórios agregados diários dos servidores receptores, listando quais servidores enviaram e-mails como o seu domínio e se passaram.

O padrão DMARC foi atualizado em 2026

Em maio de 2026, a IETF publicou a RFC 9989, que substitui a especificação original do DMARC, a RFC 7489, e leva o DMARC para a Standards Track. Os registros existentes continuam funcionando; a tag de versão segue sendo v=DMARC1. As mudanças que vale conhecer:

• pct foi removido. A RFC diz que ele "normalmente não era aplicado com precisão". Uma nova tag t ("testing") o substitui: t=y pede aos servidores receptores que não apliquem a política, mais ou menos como o antigo pct=0.
• np foi adicionado, uma política para subdomínios inexistentes.
• rf e ri foram removidos, e uma "tree walk" (percurso em árvore) no DNS substitui a Public Suffix List para encontrar o domínio organizacional.

Os servidores receptores vão adotar as novas regras em ritmos diferentes, e o guia de configuração do próprio Google ainda recomenda pct durante a implantação. Usar pct não quebra nada, mas não conte com ele como uma porcentagem precisa.

O que Gmail e Yahoo exigem

Os dois provedores começaram a aplicar requisitos para remetentes em fevereiro de 2024.

Fontes: diretrizes para remetentes do Google e boas práticas para remetentes do Yahoo. O Google avisa que mensagens não autenticadas "podem ser marcadas como spam ou rejeitadas com um erro 5.7.26", e seu FAQ diz: "A partir de novembro de 2025, o Gmail está intensificando a aplicação das regras ao tráfego fora de conformidade", com rejeições temporárias e permanentes. O mesmo FAQ recomenda alinhar o DMARC com SPF e DKIM e diz que o alinhamento provavelmente se tornará obrigatório mais adiante.

Mesmo que você envie bem menos de 5.000 mensagens por dia, esses registros decidem se suas faturas, redefinições de senha e respostas chegam à caixa de entrada, e se outra pessoa pode enviar e-mails convincentes em seu nome.

Como funciona o verificador de SPF e DMARC da Searvia

O verificador de SPF e DMARC gratuito faz parte do nosso verificador de SEO de sites e mostra primeiro a checagem de autenticação de e-mail. Informe um domínio (um www. inicial é removido) e ele:

1. Consulta os registros TXT do domínio e pega os que começam com v=spf1. Mais de um é sinalizado, porque nesse caso o SPF falha.
2. Conta as consultas DNS que o registro SPF exige (include, a, mx, ptr, exists e redirect, seguindo cada include um nível de profundidade) e sinaliza mais de 10.
3. Consulta os registros TXT de _dmarc. mais o domínio e pega o que começa com v=DMARC1.
4. Lê a política p= do registro DMARC e verifica se há um endereço de relatório rua.
5. Mostra os dois registros completos, com um visto ou uma cruz, e uma linha de DKIM marcada como "Not checked".

Na auditoria geral, essa checagem tem prioridade média. Repare no rigor com o DMARC: p=none atende ao mínimo do Gmail, mas ainda exibe um alerta, porque não impede o spoofing.

O que a checagem gratuita não cobre:

• DKIM. As chaves DKIM ficam sob seletores escolhidos por cada serviço de e-mail, e não há como listá-las pelo DNS, então o relatório marca o DKIM como não verificado. Confira o DKIM no painel de administração do seu provedor de e-mail ou nos cabeçalhos de uma mensagem que você enviou (procure dkim=pass).
• Todas as regras do SPF. Ela sinaliza registros duplicados e mais de 10 consultas, mas não se o registro termina em -all ou ~all. Os includes são seguidos um nível de profundidade, então um registro com aninhamento profundo pode precisar de mais consultas do que a contagem mostra.
• Detalhes do DMARC. Ela lê p= e verifica rua, mas não sp= nem as configurações de alinhamento.

Como interpretar o resultado

• Fail: seu domínio está aberto a spoofing e seus e-mails não atendem aos requisitos de Gmail e Yahoo. Comece pelo passo 1 abaixo.
• "DMARC is missing" ou "SPF is missing": metade do caminho. Adicione o registro que falta.
• "DMARC is set to none": o resultado mais comum. Você está coletando relatórios (se rua estiver definido), que é a primeira etapa correta. Planeje a passagem para a aplicação da política.
• Pass: ótimo. Confira o que a ferramenta gratuita não enxerga: DKIM para cada remetente, includes de SPF muito aninhados e a política sp dos subdomínios.

Como corrigir, passo a passo

Passo 1: liste tudo o que envia e-mails como o seu domínio

Seu provedor de caixa de e-mail (Google Workspace, Microsoft 365), ferramenta de newsletter, CRM, help desk, software de faturamento, plataforma de e-commerce, formulário de contato do site e qualquer servidor que envie notificações. Esquecer um deles aqui é o principal motivo de a aplicação do DMARC dar errado depois.

Passo 2: publique um único registro SPF

1. Reúna o valor de include: que cada provedor documenta.
2. Combine todos em um registro. A RFC 7208 é explícita: se existir mais de um registro SPF, o resultado é "permerror".
3. Termine com ~all enquanto testa e depois use -all.
4. Conte as consultas. include, a, mx, ptr, exists e redirect custam uma consulta DNS cada, e o limite é 10, incluindo as consultas dentro de includes aninhados. Acima de 10 é permerror. Remova serviços que você não usa mais e abandone o ptr, que a RFC diz que "SHOULD NOT be published" (não deve ser publicado).

Se um provedor envia com o próprio domínio de envelope (comum em ferramentas de newsletter), ele nem precisa estar no seu SPF; precisa de DKIM com o seu domínio para o DMARC passar.

Passo 3: ative o DKIM em todos os remetentes

Em cada serviço, encontre a configuração de autenticação de domínio ou DKIM, publique o registro que ele fornece (um TXT ou CNAME sob um seletor) e ative a assinatura. O Google recomenda aguardar 48 horas após configurar SPF e DKIM antes de adicionar o DMARC. Depois envie uma mensagem de teste para um endereço do Gmail e verifique em "Mostrar original": você quer ver SPF: PASS, DKIM: PASS e DMARC: PASS.

Passo 4: publique o DMARC em p=none com relatórios

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

O Google recomenda começar com p=none e sempre incluir rua. Os relatórios agregados são arquivos XML; um serviço de relatórios DMARC ou um parser os torna legíveis. Se o endereço de relatório estiver em outro domínio, esse domínio precisa autorizá-lo com um registro DNS.

Passo 5: leia os relatórios e corrija as falhas

Por duas a quatro semanas, procure serviços legítimos que falham no alinhamento de SPF ou DKIM. Cada um precisa de assinatura DKIM com o seu domínio ou de um include de SPF. E-mails encaminhados e listas de discussão podem falhar por motivos legítimos; a RFC 9989 sugere que domínios cujos usuários escrevem em listas de discussão passem pelo menos um mês em p=none e um período parecido em p=quarantine antes de p=reject.

Passo 6: passe para quarantine e depois para reject

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Mude um degrau por vez e continue acompanhando os relatórios. Ao chegar em p=quarantine, nosso verificador mostra Pass. O p=reject é o objetivo: os servidores receptores recusam as mensagens que falham.

Passo 7: proteja domínios que não enviam e-mails

Domínios estacionados e domínios usados só para redirecionamento atraem golpistas porque ninguém os monitora. O guia do governo do Reino Unido recomenda:

example.net.               TXT  "v=spf1 -all"
_dmarc.example.net.        TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
*._domainkey.example.net.  TXT  "v=DKIM1; p="
example.net.               MX   0 .

Confira os registros por conta própria

O verificador lê SPF e DMARC; você pode ver os três registros com ferramentas de DNS padrão. No macOS ou Linux:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

No Windows, nslookup -type=TXT _dmarc.example.com faz o mesmo. Para o DKIM você precisa do seletor, que seu provedor mostra nas configurações de DKIM e que aparece como s= no cabeçalho DKIM-Signature de qualquer mensagem enviada por você; google é o padrão do Google Workspace. Alguns provedores publicam a chave como um CNAME apontando para o DNS deles, o que não tem problema.

O teste de ponta a ponta mais confiável é uma mensagem real. Envie uma de cada serviço para um endereço do Gmail e abra "Mostrar original": ele lista o resultado de SPF, DKIM e DMARC e o domínio para o qual cada um passou. Um DKIM aprovado para o domínio do provedor em vez do seu significa que o alinhamento do DMARC ainda falha, então procure o seu próprio domínio no resultado.

Erros comuns

Exemplo prático (hipotético)

O exemplo a seguir é hipotético, não são dados reais. A Pinecrest Dental, uma clínica inventada, ouve de pacientes que eles receberam um falso pedido de pagamento "da" clínica. O verificador de SPF e DMARC mostra:

• SPF: v=spf1 include:_spf.google.com ~all
• DMARC: ausente. Resultado: warning, "DMARC is missing."

O passo 1 encontra três remetentes: Google Workspace, o sistema de agendamento que envia lembretes por e-mail e uma ferramenta de newsletter. O sistema de agendamento precisa de um include de SPF; a ferramenta de newsletter usa o próprio domínio de envelope, então recebe DKIM com o domínio da clínica. A clínica publica o DMARC em p=none com um endereço de relatório. Duas semanas de relatórios mostram o sistema de agendamento passando no SPF e a newsletter passando no DKIM, além de algumas centenas de mensagens de servidores desconhecidos em outros países falhando nos dois: o spoofing. A clínica passa para p=quarantine, onde o verificador mostra Pass, e um mês depois para p=reject. As mensagens falsas em seu nome agora são recusadas pelos servidores que aplicam o DMARC.

Um checklist para concluir esta semana

1. Rode o verificador de SPF e DMARC em todos os domínios que você possui, inclusive os estacionados.
2. Liste todos os serviços que enviam e-mails como o seu domínio.
3. Una o SPF em um único registro, com menos de 10 consultas, terminando em ~all ou -all.
4. Ative o DKIM em cada serviço e teste com "Mostrar original" no Gmail.
5. Publique o DMARC em p=none com rua e leia os relatórios.
6. Passe para p=quarantine e depois para p=reject.
7. Publique v=spf1 -all e p=reject nos domínios que não enviam nada.

Como a Searvia monitora a autenticação do seu e-mail

O verificador de SPF e DMARC gratuito lê seus registros em segundos, sem cadastro, como parte de uma auditoria de 38 checagens que também cobre a aparência do seu site nas buscas, a velocidade e a segurança.

Uma conta gratuita da Searvia adiciona uma varredura de segurança semanal que vai além no e-mail: ela sinaliza um registro SPF ausente ou aberto demais (+all, ?all ou sem all), uma política DMARC ausente ou ainda em p=none e a falta de um registro CAA, com a consulta DNS por trás de cada achado e um registro que você pode copiar. A varredura se repete toda quinta-feira, então uma alteração de DNS que quebre seus registros aparece em até uma semana. Para o lado da segurança do site, veja nosso guia de security headers.