Verificar Autenticação de Email
Autenticação de email é o conjunto de registros de DNS — SPF, DKIM e DMARC — que deixa o servidor que recebe confirmar que a mensagem veio mesmo do seu domínio e decidir o que fazer quando não veio. Desde fevereiro de 2024, Google e Yahoo exigem os três de quem envia email em volume. Este verificador lê os três de uma vez e diz exatamente quais estão no lugar e quais estão faltando.
Como usar
- 1
Digite o domínio de envio
Use o domínio do seu From — a parte depois do @. Se você envia como [email protected], verifique acme.com.br.
- 2
Coloque o seletor DKIM se souber
O DKIM fica em seletor._domainkey.seudominio. A verificação tenta seletores comuns sozinha, mas se voltar vazio e você souber o seu (google, s1, k1, dkim…), digite.
- 3
Leia SPF, DKIM e DMARC
Verde é registro publicado e coerente. A linha de veredito no topo diz se você passa na régua do Gmail/Yahoo, e cada falha tem link pra ferramenta que resolve.
Como funciona
Por que os três, e por que virou urgente
Por anos SPF, DKIM e DMARC foram “boa prática” — recomendados, quase nunca cobrados. Isso mudou em fevereiro de 2024. Google e Yahoo passaram a exigir de quem envia em volume (grosso modo, 5.000+ mensagens por dia pra endereços Gmail ou Yahoo) publicar SPF, assinar com DKIM e ter um registro DMARC, além de manter reclamação de spam abaixo de 0,3% e oferecer descadastro em um clique. Não cumpriu, o email é limitado ou rejeitado direto.
Na prática, um domínio que enviava bem em 2023 pode bater na trave em 2024 sem você mudar nada — quem recebe mudou a régua. Checar os três juntos importa porque eles são uma corrente: o DMARC só faz o trabalho quando SPF ou DKIM passa E alinha com o seu domínio From. Um SPF verde sem DMARC ainda te deixa falsificável e fora das regras.
SPF: quem pode enviar
O SPF é um único registro TXT começando com v=spf1 que lista os servidores autorizados a enviar pelo seu domínio — o seu servidor de email e todo SaaS que envia no seu nome (o help desk, a plataforma de newsletter, o CRM). Quem recebe compara o IP do servidor que conectou com essa lista.
A pegadinha que quebra o SPF calado é o limite de lookups: o RFC 7208 §4.6.4 permite no máximo 10 consultas de DNS ao avaliar o registro. Cada include: (e a maioria dos fornecedores te dá um) conta. Some serviços demais e a avaliação devolve permerror, que muito receptor trata como falha — então contratar uma ferramenta nova pode quebrar a autenticação de tudo sem avisar.
DKIM: a assinatura criptográfica
O DKIM prova que o corpo não foi alterado e que a mensagem veio mesmo de um servidor que tem sua chave privada. Sua plataforma assina cada mensagem que sai; quem recebe busca a chave pública num TXT em seletor._domainkey.seudominio e confere a assinatura. O seletor é só um rótulo que deixa você rodar várias chaves ao mesmo tempo (uma por provedor, ou a antiga e a nova durante uma troca).
O tamanho da chave importa: 1024 bits é o piso antigo e 2048 bits é a recomendação atual. Se o DKIM voltar como faltando aqui, quase sempre é seletor não publicado ou registro cortado — provedores de DNS às vezes quebram valores TXT longos errado, e uma chave pública quebrada falha na verificação igual a não ter chave.
DMARC: a política que amarra tudo
O DMARC é o registro que transforma SPF e DKIM numa decisão de verdade. Ele diz ao receptor o que fazer quando a mensagem falha na autenticação — p=none (só reporta), p=quarantine (manda pro spam) ou p=reject (devolve) — e pra onde mandar os relatórios agregados no endereço rua=. Gmail e Yahoo aceitam p=none pra cumprir a exigência, mas p=none não protege ninguém: email falsificado ainda chega.
O que quase todo mundo esquece é o alinhamento. Uma mensagem pode passar no SPF e ainda falhar no DMARC se o domínio que o SPF autenticou não bate com o domínio do From — comum quando um SaaS envia por você usando o return-path dele. O DMARC exige que SPF ou DKIM passe E alinhe com o From visível. É por isso que “SPF passa mas DMARC falha” é um resultado tão comum e tão confuso.
Como ler o resultado
| Resultado | O que significa | O que fazer |
|---|---|---|
| SPF — verde | Um registro v=spf1 está publicado e fica abaixo de 10 lookups. | Nada a fazer — recheque ao adicionar um remetente. |
| SPF — âmbar (acima de 10 lookups) | A avaliação passa do limite do RFC e pode dar permerror. | Achate ou tire include: que não usa. |
| DKIM — vermelho (sem chave) | Nenhuma chave pública no seletor testado. | Publique o DKIM do seu provedor ou informe o seletor certo. |
| DMARC — âmbar (p=none) | Publicado mas sem enforcement; falsificação ainda funciona. | Suba pra p=quarantine quando os relatórios estiverem limpos. |
| DMARC — vermelho (faltando) | Sem DMARC — você falha na exigência do Gmail/Yahoo. | Publique ao menos v=DMARC1; p=none; rua=mailto:voce@dominio. |
Problemas comuns
Gmail rejeita ou limita seu envio em volume
Cause: Falta um entre SPF, DKIM ou DMARC desde as regras de fev/2024.
Publique os três; o DMARC pode começar em p=none pra cumprir a exigência.
Rode a verificação acimaSPF passa mas o DMARC ainda falha
Cause: O domínio autenticado não alinha com o domínio do From.
Use um return-path/domínio DKIM que alinhe, ou troque o domínio de envio.
Verificador DMARCSPF permerror depois de adicionar um fornecedor
Cause: A cadeia de include: passou de 10 consultas de DNS.
Junte os includes ou achate o registro pra ficar dentro do limite.
Verificador SPFDKIM aparece como faltando mas você configurou
Cause: Seletor errado, ou o provedor de DNS quebrou o valor TXT longo.
Informe o seletor exato e confirme que a chave publicada não está cortada.
Validador DKIMPerguntas frequentes
Fontes
Atualizado em: