Se os seus e-mails estão caindo no spam, sendo rejeitados ou aparecendo com avisos de “remetente não verificado”, a primeira coisa que você deve checar é a sua configuração de autenticação de e-mail.
Isso significa verificar estes três registros essenciais:
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
- DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Esses registros DNS dizem aos provedores de e-mail como Gmail, Outlook e Yahoo se o seu domínio está realmente autorizado a enviar mensagens. Se algum deles está faltando, quebrado ou fraco demais, suas mensagens perdem confiança rápido.
Neste guia gratuito 2026 você vai aprender:
- como conferir um registro SPF
- como conferir um registro DKIM
- como conferir um registro DMARC
- por que e-mails ainda caem no spam mesmo com os registros existindo
- os erros mais comuns de autenticação
- a forma mais rápida de testar a deliverability de qualquer domínio
Se você gerencia um domínio corporativo, uma newsletter, uma caixa de suporte, uma campanha de outreach, um produto SaaS ou um setup de cold email, essa é uma das checagens técnicas mais importantes que pode fazer.
Resposta rápida: como verificar SPF, DKIM e DMARC de um domínio?
Para verificar SPF, DKIM e DMARC em qualquer domínio:
- Consulte os registros DNS TXT do domínio
- Verifique se existe um registro SPF válido
- Verifique se um selector DKIM resolve para uma chave pública válida
- Procure uma política DMARC em
_dmarc.seudominio.com - Confirme que os registros não só existem, mas estão bem configurados
- Se ainda assim os e-mails caírem no spam, analise os headers de um e-mail real para ver o que de fato passou ou falhou
A forma mais rápida e amigável para iniciantes é começar por uma varredura completa do domínio com o Email Health Checker, e só depois mergulhar nos registros específicos se algo parecer estranho.
Por que SPF, DKIM e DMARC importam em 2026
Os provedores estão mais rígidos do que nunca.
As caixas modernas não olham só para o conteúdo da mensagem — olham se o seu domínio tem uma configuração de envio confiável.
Uma boa configuração de SPF, DKIM e DMARC ajuda você a:
- melhorar a entrega na caixa de entrada
- reduzir o risco de spoofing
- impedir que o seu domínio seja usado para phishing
- diminuir as chances de cair em spam
- aumentar a confiança junto a Gmail, Outlook, Yahoo e gateways corporativos
- construir uma reputação de remetente mais saudável ao longo do tempo
Se você envia:
- e-mails transacionais
- códigos de verificação
- newsletters
- cold outreach
- respostas de suporte
- e-mails de redefinição de senha
- notificações SaaS
…autenticação de e-mail não é mais opcional.
O que são SPF, DKIM e DMARC? (explicação simples)
Antes de checar registros, ajuda entender o que cada um faz.
SPF: quem está autorizado a enviar e-mail pelo seu domínio
SPF é um registro DNS TXT que lista quais servidores ou serviços de e-mail podem enviar em nome do seu domínio.
Por exemplo, se você usa:
- Google Workspace
- Microsoft 365
- Mailgun
- SendGrid
- Amazon SES
- Brevo
- Zoho Mail
…esses serviços costumam precisar estar incluídos no seu SPF.
Do que SPF protege: remetentes não autorizados que se passam pelo seu domínio.
O que SPF não garante: que o endereço visível em “From” esteja alinhado de um jeito que o DMARC aceite.
DKIM: prova que o e-mail foi assinado
DKIM adiciona uma assinatura criptográfica à sua mensagem que sai.
Quando o servidor do destinatário recebe a mensagem, consulta uma chave pública guardada no DNS para confirmar:
- que o e-mail foi assinado por um remetente autorizado
- que a mensagem não foi alterada no caminho
Do que DKIM protege: adulteração da mensagem e falsificação de e-mails sem assinatura válida.
Importante: ter um registro DKIM no DNS não significa automaticamente que o DKIM está funcionando bem nos envios reais.
DMARC: diz aos provedores o que fazer se SPF ou DKIM falharem
DMARC se constrói em cima do SPF e do DKIM.
Ele diz ao servidor receptor:
- se a mensagem que falhou deve ser monitorada, colocada em quarentena ou rejeitada
- para onde enviar relatórios agregados
- se o domínio autenticado está alinhado com o domínio visível em “From”
Valores de política DMARC:
p=none→ só monitorap=quarantine→ mensagens suspeitas podem ir para spamp=reject→ mensagens que falharem devem ser rejeitadas
Do que DMARC protege: spoofing de domínio, impersonificação e aplicação fraca da autenticação.
Como verificar SPF, DKIM e DMARC em um domínio
Esse é o fluxo mais simples e prático.
Passo 1: comece por uma checagem ampla de autenticação
Em vez de checar registros um por um manualmente, comece por uma varredura ampla em nível de domínio.
Use o Email Health Checker para ter uma visão rápida de:
- status do SPF
- presença de DKIM
- presença de DMARC
- configuração MX
- saúde básica de autenticação
- sinais de risco comuns
É o melhor primeiro passo: você sabe na hora se o domínio tem uma falha óbvia antes de descer nos detalhes.
Por que importa: muitos domínios falham por coisas simples — sem DMARC, sem DKIM, MX ausente ou SPF mal estruturado.
Passo 2: como verificar um registro SPF
Para checar SPF do jeito certo, não pergunte só “existe?” — pergunte se está válido, limpo e dentro dos limites.
Como é um SPF válido
Um SPF normalmente começa assim:
v=spf1 include:_spf.google.com ~all
O que olhar
- começa com
v=spf1 - existe apenas um registro SPF TXT no domínio
- inclui seus provedores de envio atuais
- termina com uma política sensata como:
~all(soft fail)-all(hard fail)
- não ultrapassa o limite de 10 lookups DNS
Erros SPF comuns
- publicar vários registros SPF
- deixar
include:antigos de provedores que você não usa mais - usar regras permissivas demais como
+all - estourar o limite dos 10 lookups
- esquecer de atualizar o SPF depois de trocar de ESP
O grande problema SPF de 2026: o limite dos 10 lookups
É um dos “matadores” silenciosos mais comuns da deliverability.
Se o seu SPF aninha provedores demais, serviços de forwarding ou ferramentas SaaS, ele pode estourar o limite e falhar em silêncio.
Se o seu SPF é complexo, o SPF Flattening Tool ajuda a achatar cadeias de include em IPs explícitos para o registro continuar dentro do limite.
Passo 3: como verificar um registro DKIM
Se você procura como checar DKIM, o ponto principal é:
DKIM funciona por selector.
Você precisa, em geral, de:
- o domínio
- o selector usado pela plataforma de envio
Um registro DKIM costuma ficar em algo como:
selector1._domainkey.example.com
O que olhar
- o selector resolve corretamente
- existe um registro TXT
- a chave pública (
p=) está presente - a formatação do registro está correta
- a chave é forte o bastante
- a plataforma realmente assina os e-mails que saem
Erros DKIM comuns
- usar selector errado
- publicar o registro mas não ativar DKIM no provedor
- formatação TXT quebrada no DNS
- chaves fracas ou desatualizadas
- rotacionar chave do jeito errado
- assumir que “o registro existe” = “DKIM está passando”
Para uma inspeção mais profunda do registro em si, use o DKIM Analyzer e veja força da chave, estrutura do registro e possíveis problemas de configuração DKIM.
Passo 4: como verificar um registro DMARC
Para checar status do DMARC corretamente, procure um TXT em:
_dmarc.example.com
Um DMARC simples se parece com:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
O que olhar
- começa com
v=DMARC1 - tem uma política:
p=nonep=quarantinep=reject
- idealmente, um endereço de relatórios:
rua=mailto:...
- relatórios forenses (opcional):
ruf=mailto:...
- ajustes de alinhamento, se presentes:
adkim=aspf=
- rollout gradual (opcional):
pct=
Erros DMARC comuns
- não ter nenhum registro DMARC
- ficar em
p=nonepara sempre - nenhum endereço para relatórios
- sintaxe quebrada
- ignorar falhas de alinhamento
- copiar e colar um registro genérico sem entender
Para validar rápido e ver se o domínio só monitora ou realmente aplica, use o DMARC Checker.
Por que e-mails caem no spam mesmo com SPF, DKIM e DMARC
Uma das partes mais mal entendidas da deliverability.
Um domínio pode ter registros SPF, DKIM e DMARC e ainda assim suas mensagens caírem no spam.
Por quê?
Porque presença não é o mesmo que configuração correta.
Razões comuns:
- SPF existe, mas estoura o limite dos 10 lookups
- SPF passa, mas o alinhamento falha
- registro DKIM existe, mas a assinatura real falha
- DKIM quebra após forwarding ou reescrita
- DMARC existe, mas continua em
p=none - domínio com má reputação
- IP de envio com má reputação
- conteúdo que dispara filtros antispam
- links que parecem suspeitos
- alta taxa de bounce
- alta taxa de reclamações
- reverse DNS ausente ou fraco
- mudança brusca no padrão de volume
Verdade importante
SPF + DKIM + DMARC são a base, não o sistema completo de deliverability.
Eles ajudam os provedores a confiar em você, mas não substituem reputação ruim ou comportamento de spammer.
Como descobrir por que um e-mail caiu no spam
Se os registros DNS parecem certos mas um e-mail real continua caindo no spam, pare de olhar só o DNS.
Você precisa inspecionar os headers brutos da mensagem.
É lá que se vê o que o servidor receptor realmente observou.
Use o Email Header Analyser para examinar:
- SPF pass/fail
- DKIM pass/fail
- DMARC pass/fail
- Authentication-Results
- saltos / caminho dos relays
- pistas de alinhamento
- pistas de roteamento de spam
É decisivo: muita gente checa só DNS e nunca testa a mensagem realmente entregue, que é onde os problemas escondidos aparecem.
Melhor workflow para checar autenticação de e-mail (mais rápido)
Para o fluxo mais prático em 2026, faça nesta ordem:
- Varredura ampla com Email Health Checker
- Política DMARC e nível de aplicação com DMARC Checker
- Qualidade do DKIM e validade do selector com DKIM Analyzer
- Estrutura do SPF e contagem de lookups com SPF Flattening Tool
- Headers reais com Email Header Analyser se a entrega ainda falhar
Você ganha:
- uma visão DNS
- uma visão de política
- uma visão de mensagem real
Bem mais útil do que só fazer um lookup TXT básico.
Erros comuns de SPF / DKIM / DMARC para evitar
Aparecem em domínios corporativos, apps SaaS e setups de cold email com frequência.
Erros SPF
- vários registros SPF TXT
- muitos lookups
include: - provedores antigos ainda listados
+allou política frouxa- não atualizar SPF após troca de provedor
Erros DKIM
- selector errado
- registro publicado, mas assinatura desativada
- formatação TXT quebrada
- chaves fracas
- nenhum teste com mensagem realmente enviada
Erros DMARC
- nenhum registro DMARC
p=nonepara sempre- sem
rua= - ignorar alinhamento
- sintaxe quebrada
- nenhum avanço rumo ao enforcement
Boas práticas SPF / DKIM / DMARC para 2026
Para melhor inbox placement neste ano, mire nesta base:
- publique um único SPF limpo
- mantenha SPF abaixo do limite de 10 lookups
- remova provedores antigos ou não usados do SPF
- use chaves DKIM fortes
- confirme que DKIM assina a mensagem real que sai
- publique DMARC em todos os domínios ativos de envio
- comece monitorando, depois avance para enforcement
- colete os relatórios DMARC
- olhe alinhamento, não só pass/fail
- reteste após mudanças de DNS ou ESP
- analise headers quando algo parecer estranho
- monitore reputação e tendências de bounce
Para quem essa checklist serve?
Esse guia é útil se você gerencia:
- um site corporativo
- um produto SaaS
- uma caixa de suporte
- um sistema de newsletter
- e-mails transacionais
- campanhas de cold outreach
- domínios de cliente gerenciados em agência
- forwarding de e-mail em domínio próprio
- notificações de e-commerce
- sistemas de redefinição de senha / verificação
Se e-mail importa pro seu negócio, autenticação importa também. E se você usa e-mail descartável para testar, entender autenticação te ajuda a escolher provedores que realmente entregam.
Considerações finais
Se você envia e-mail pelo seu domínio, aprender a verificar SPF, DKIM e DMARC é uma das habilidades técnicas com maior ROI.
Te ajuda a:
- melhorar entrega na caixa de entrada
- reduzir risco de spoofing
- diagnosticar por que e-mails caem no spam
- pegar erros DNS escondidos
- construir confiança com provedores
E o ponto mais importante:
Ter registros SPF, DKIM e DMARC não basta — eles precisam ser válidos, alinhados e testados contra o comportamento real do e-mail.
Um domínio pode parecer “configurado” à primeira vista e mesmo assim falhar em produção.
Por isso a abordagem mais inteligente é:
- checar o domínio
- inspecionar os registros
- validar a política
- testar a mensagem real
Faça isso de forma consistente e você vai pegar a maioria dos problemas de autenticação antes que eles afetem a deliverability.
FAQ
Como verifico SPF de um domínio?
Procure um TXT que comece com v=spf1. Garanta que existe apenas um registro SPF, que ele inclui seus provedores ativos e que não passa do limite de 10 lookups DNS.
Como verifico DKIM de um domínio?
Você precisa do domínio e geralmente do selector que a plataforma de envio usa. O TXT DKIM deve conter chave pública válida e formatação correta — e você ainda deve confirmar que mensagens reais estão sendo de fato assinadas.
Como verifico DMARC de um domínio?
Procure um TXT em _dmarc.seudominio.com. Ele deve começar com v=DMARC1 e incluir uma política como p=none, p=quarantine ou p=reject. Um endereço rua= é altamente recomendado.
Qual o melhor verificador SPF / DKIM / DMARC?
O melhor fluxo não é uma única checagem — é a combinação de:
- varredura de autenticação no domínio
- validação direta de DMARC
- inspeção do registro DKIM
- revisão da estrutura SPF
- análise de headers reais
Te dá tanto a visão DNS quanto a visão da mensagem real.
Por que e-mails caem no spam mesmo com SPF, DKIM e DMARC?
Porque a presença dos registros não garante inbox placement. Possíveis motivos:
- falhas de alinhamento
- assinaturas DKIM quebradas
- estrutura SPF fraca
- má reputação de domínio ou IP
- conteúdo que dispara filtros
- altos índices de reclamação ou bounce
- DMARC sem enforcement
DMARC exige SPF e DKIM?
Funciona melhor com ambos bem configurados. Tecnicamente, DMARC pode passar se ao menos um deles passar com alinhamento correto, mas depender dos dois é muito mais robusto e recomendado.
O que é o limite de 10 lookups do SPF?
A avaliação do SPF só permite até 10 lookups DNS. Se o SPF passar disso por excesso de include:, ele pode falhar e prejudicar a deliverability.
p=none ou p=reject no DMARC?
No começo, p=none é útil para monitorar. Mas, no longo prazo, ficar em p=none enfraquece a proteção. Quando a autenticação estiver estável, a maioria dos domínios deveria caminhar para p=quarantine ou p=reject.
Ter SPF, DKIM e DMARC basta para a deliverability?
Não. Esses registros são essenciais, mas a deliverability depende também de:
- reputação do domínio
- reputação do IP
- qualidade do conteúdo
- taxas de reclamação
- taxas de bounce
- comportamento de envio
- higiene da lista
- qualidade da infraestrutura
A autenticação é a base, não o sistema completo.
Continue lendo
- Temp mail não recebe o OTP? Conserte rápido
- O que é e-mail descartável? O guia completo
- Como o e-mail temporário protege a sua privacidade online
- Como evitar spam: 7 estratégias comprovadas
- Como o e-mail anônimo te protege de phishing
- E-mail descartável vs burner email vs temp mail
- O guia completo de privacidade de e-mail
Your temp mail is ready right now
No signup, no password. A disposable inbox waiting the moment you open the page.
Get My Free Temp Mail →