Verificar SPF e DMARC: como consultar, ler e corrigir os registros do seu domínio

O que SPF, DKIM e DMARC verificam

O SPF e o DKIM podem passar para um domínio que o leitor nunca vê. Como resume o Antispam.br, do CGI.br e do NIC.br, o SPF verifica só o envelope, enquanto o DKIM verifica o cabeçalho da mensagem. O DMARC fecha essa lacuna com o alinhamento: a mensagem passa quando o SPF ou o DKIM passam para um domínio alinhado com o domínio do From, e uma única aprovação alinhada basta. O alinhamento relaxado, que é o padrão, só exige o mesmo domínio organizacional, então bounce.example.com se alinha com example.com. O alinhamento estrito exige o nome exato.

Um serviço hipotético de newsletter mostra por que isso importa. Ele envia como news@example.com, mas usa como remetente do envelope um domínio de devolução próprio, em example.net. O SPF passa para example.net, que não está alinhado; então o DMARC só passa se o serviço assinar com DKIM como d=example.com.

Como consultar os registros com dig ou nslookup

Basta o dig (Linux, macOS) ou o nslookup (Windows):

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
nslookup -type=TXT _dmarc.example.com

O registro SPF é o TXT que começa com v=spf1; tokens de verificação de outros serviços costumam ficar ao lado dele. O registro DMARC é o TXT em _dmarc que começa com v=DMARC1. Verifique o SPF no domínio do remetente do envelope, que pode ser diferente do domínio do From; o cabeçalho Return-Path de uma mensagem entregue mostra qual é.

As chaves DKIM não podem ser listadas de fora, porque cada uma fica sob um seletor. Leia os valores s= e d= no cabeçalho DKIM-Signature de uma mensagem que você enviou e consulte esse nome, por exemplo dig +short TXT s1._domainkey.example.com.

Depois de uma mudança, os resolvedores podem continuar entregando a resposta antiga até o TTL dela acabar. Para ver o que está publicado agora, descubra os servidores autoritativos com dig +short NS example.com e consulte um deles diretamente: dig +short TXT example.com @ns1.example.net. Depois, envie uma mensagem real para uma caixa que você controla e leia o cabeçalho Authentication-Results. Ele mostra o que o provedor de destino decidiu sobre SPF, DKIM e DMARC, e é esse o resultado que conta.

Como ler um registro SPF

v=spf1 ip4:192.0.2.10 include:_spf.mail.example.net -all

Os mecanismos são avaliados da esquerda para a direita, e o primeiro que corresponder decide o resultado. Cada um pode ter um qualificador: + pass (o padrão), - fail, ~ softfail, ? neutral.

~all ou -all

~all diz que os servidores fora da lista provavelmente não estão autorizados, e os destinatários não devem rejeitar só por isso. -all diz que eles não estão autorizados; o que acontece depois depende da política de quem recebe. As duas opções são razoáveis, e a BSI, a agência federal alemã de segurança da informação, aceita qualquer uma. A RFC 9989 faz uma ressalva: com -all, um destinatário que verifica o SPF logo no início da sessão SMTP pode rejeitar uma mensagem que o DKIM alinhado aprovaria, tipicamente um e-mail encaminhado, e essa rejeição nunca aparece nos relatórios DMARC. ?all, ou nenhum all, não diz nada sobre os servidores fora da lista. +all deixa qualquer endereço IP da internet passar; nunca o publique.

O limite de 10 consultas

Os destinatários avaliam no máximo 10 termos que geram consultas DNS, contando os que estão dentro dos registros incluídos (seção 4.6.4). Acima disso, o resultado é permerror, e o SPF deixa de ajudar a mensagem a passar no DMARC. Um limite separado vale para as consultas que não retornam resposta: mais de duas também devem terminar em permerror. Um registro que mostra quatro termos ainda pode passar do limite quando os registros incluídos têm includes próprios; por isso, conte de forma recursiva. Para voltar a ficar dentro do limite, remova os serviços que você não usa mais, escreva ip4/ip6 para os endereços que você controla e mova os serviços de alto volume para um subdomínio de devolução próprio, com registro SPF próprio. O chamado flattening, que copia as faixas de IP de um provedor para o seu registro, fica desatualizado quando o provedor muda essas faixas.

Um registro por nome

Dois registros TXT começando com v=spf1 no mesmo nome geram permerror; junte-os. Um caso comum é seguir o passo a passo de um serviço novo (o e-mail corporativo, a plataforma da loja, a ferramenta de e-mail marketing), que manda “criar um registro SPF”, e criar um segundo registro em vez de editar o que já existe. Um registro com mais de 255 caracteres vai num único registro TXT dividido em várias strings entre aspas, que os destinatários juntam sem espaços. O SPF também não é herdado: um registro em example.com não cobre mail.example.com, então cada nome usado como remetente do envelope precisa do seu.

Como ler um registro DMARC

O DMARC agora é a RFC 9989 (maio de 2026), uma especificação de padrão da IETF (Standards Track) que substitui a RFC 7489. O registro continua em _dmarc e começa com v=DMARC1:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Um registro em example.com também cobre os subdomínios que não têm registro próprio; os destinatários o encontram com o que a RFC 9989 chama de DNS Tree Walk, uma subida pela árvore do DNS. Os destinatários que enviam relatórios agregados os entregam como arquivos XML, geralmente diários, com os endereços IP que enviaram em nome do seu domínio e os resultados. Se o rua apontar para outro domínio organizacional, como um serviço de relatórios, esse domínio precisa publicar um registro TXT como example.com._report._dmarc.reports.example.net começando com v=DMARC1 (RFC 9990, seção 4), ou os destinatários ignoram o endereço.

De none até reject

1. Liste todos os serviços que enviam em nome do domínio: e-mail corporativo, newsletter, CRM, emissor de notas fiscais, central de atendimento, formulários do site.
2. Publique p=none com rua e leia os relatórios.
3. Corrija cada fonte legítima até ela passar com alinhamento, de preferência pelo DKIM, que em geral sobrevive ao encaminhamento, ao contrário do SPF.
4. Passe para quarantine, se quiser primeiro com t=y, e então avalie o reject.

A RFC 9989 diz que domínios cujos usuários enviam mensagens a listas de discussão não deveriam (SHOULD NOT) publicar reject; os que ainda quiserem devem passar antes pelo menos um mês em none e o mesmo tempo em quarantine, comparando os resultados. Todo domínio que publica reject precisa (MUST) assinar os seus e-mails com DKIM. A diretriz técnica TR-03182 da BSI alemã adota a linha mais rígida: um domínio que envia e-mail deveria (SHOULD) exigir reject. Um domínio usado só para notas fiscais e avisos de sistema é um caso diferente de um que a equipe usa em listas de discussão. A RFC 9989 também diz aos destinatários que não rejeitem só com base em p=reject, mas reconhece que, na prática, mensagens de listas com o From inalterado muitas vezes são rejeitadas.

Domínios que não enviam e-mail

Domínios estacionados, domínios registrados só para proteger a marca contra erros de digitação e domínios que só redirecionam ainda podem aparecer no campo From de um e-mail falsificado. É o caso, por exemplo, da versão .com de uma marca que usa .com.br, ou o contrário. A RFC 7208 chama de boa prática bem estabelecida publicar um registro SPF para domínios que não enviam e-mail. Um conjunto completo para um domínio estacionado hipotético:

example.net.         TXT  "v=spf1 -all"
_dmarc.example.net.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
example.net.         MX   0 .

O registro SPF não autoriza ninguém, e p=reject não custa nada aqui, porque não há e-mail legítimo a perder. O MX nulo da RFC 7505 diz que o domínio não aceita e-mail; por isso, os relatórios vão para example.com, que precisa publicar example.net._report._dmarc.example.com. A TR-03182 da BSI lista essa mesma combinação como obrigatória (MUST) para domínios sem uso. A política DMARC cobre os subdomínios, mas o SPF não; então publique também um v=spf1 -all em qualquer subdomínio que tenha registro A ou MX próprio.

O que Gmail, Yahoo e Outlook.com exigem de quem envia

Desde novembro de 2025, o Gmail vem endurecendo a aplicação dessas regras, incluindo rejeições. As regras do Google valem para contas pessoais do Gmail, não para destinatários do Google Workspace. Google e Yahoo exigem chaves DKIM de pelo menos 1024 bits. A Microsoft rejeita com 550 5.7.515 as mensagens que não atendem aos requisitos. Os três aceitam p=none, que cumpre a regra, mas não expressa nenhuma preferência sobre e-mails falsificados; trate-o como uma etapa, não como a configuração final. Essas regras dependem do provedor da caixa de destino, não do país de quem envia: valem igualmente para um domínio .com.br que manda mensagens para endereços do Gmail ou do Hotmail.

MTA-STS e CAA: mais dois registros para verificar

O MTA-STS (RFC 8461) protege o e-mail que chega: ele diz aos remetentes que não entreguem aos seus hosts MX a menos que eles ofereçam TLS com um certificado confiável. Ele precisa de um registro TXT em _mta-sts.example.com, como v=STSv1; id=20261001000000Z;, e de um arquivo de política em https://mta-sts.example.com/.well-known/mta-sts.txt com o modo, os nomes MX e o max_age. Comece no modo testing, em que os remetentes continuam entregando e relatam falhas se os relatórios de TLS estiverem configurados em _smtp._tls.example.com, e depois mude para enforce. Troque o id sempre que a política mudar.

O CAA (RFC 8659) indica as autoridades certificadoras que podem emitir certificados TLS para o domínio, por exemplo CAA 0 issue "ca.example.net". As CAs públicas precisam consultá-lo antes de emitir; ele não impede que uma CA autorizada emita por engano, e os navegadores não o usam. Um registro em example.com cobre os subdomínios que não têm registro próprio. Liste todas as CAs que você usa, incluindo a da sua CDN, ou as renovações podem falhar. O guia de certificado SSL/TLS e cabeçalhos de segurança trata dos certificados com mais detalhes.

Erros comuns de SPF e DMARC e como corrigir

O que o snapshot gratuito verifica no DNS de e-mail

O snapshot gratuito de prontidão para lançamento roda oito verificações passivas em uma origem pública, sem cadastro. Ele não é um pentest nem a auditoria das seis áreas. Uma das oito verificações lê os registros DNS de e-mail:

• Nome exato. MX, TXT, _dmarc, _mta-sts e CAA são consultados no nome que você digitar, sem recorrer ao domínio pai. Um registro ausente em www.example.com não significa que example.com esteja desprotegido. Para que os registros do seu domínio de e-mail sejam lidos, digite esse domínio (example.com em vez de www.example.com); ele precisa resolver para um endereço para o snapshot gerar uma pontuação.
• SPF. Um registro ausente é apontado (médio) só quando o host tem registros MX. +all é apontado como risco alto e ?all como baixo; ~all e -all não geram nada. Um registro com mais de dez termos que geram consultas DNS é apontado (médio), mas só os termos do registro principal são contados, porque o include: não é seguido.
• DMARC. Um registro ausente é apontado (médio) só quando o host tem registros MX. p=none é apontado como modo de monitoramento (baixo), e quarantine ou reject contam como aprovados. sp, pct, rua e o alinhamento não são avaliados.
• MTA-STS e CAA. A falta do registro TXT _mta-sts é apontada (baixo) só quando o host tem registros MX; o arquivo de política não é baixado. Qualquer registro CAA conta como aprovado, e a falta dele gera um sinal baixo; o conteúdo não é comparado com o seu certificado.
• Fora da verificação: DKIM, relatórios de TLS e DNSSEC.

Você recebe uma pontuação com a nota correspondente, a nota de blindagem, a contagem de sinais de risco e de verificações aprovadas e até três sinais, os mais graves primeiro; assim, um achado de e-mail pode ficar atrás de um achado do site. Um nome que não resolve para um endereço não recebe pontuação. O checklist de lançamento de site percorre as oito verificações, e o guia de segurança de e-mail e DNS trata da revisão contínua.