Inspeção de autenticação de e-mail no DNS
SPF e DMARC podem ser localizados a partir do domínio. DKIM exige o seletor usado pelo assinador, normalmente visível no cabeçalho DKIM-Signature como s=.
SPF autoriza hosts remetentes para uma identidade
SPF é publicado como registro DNS TXT no nome avaliado e começa com v=spf1. Ele autoriza hosts para identidades SMTP como MAIL FROM e HELO; não é apenas uma lista de “servidores de e-mail confiáveis”. A RFC 7208 permite somente um registro SPF aplicável em cada nome. Se a seleção produzir mais de um SPF, a avaliação resulta em permerror.
A famosa regra das “10 consultas DNS” do SPF precisa de contexto
A RFC 7208 limita termos que provocam consultas DNS durante a avaliação SPF. Mecanismos como include, a, mx, ptr e exists, além do modificador redirect, participam desse limite de processamento. O contador exibido aqui é um alerta estático útil baseado nos termos visíveis do registro principal; não é um avaliador SPF completo, pois includes e redirects podem introduzir consultas recursivas adicionais e a RFC 7208 também define outros limites.
DKIM não pode ser consultado corretamente sem conhecer o seletor
Uma assinatura DKIM contém o domínio assinador em d= e um seletor obrigatório em s=. No serviço de chave DNS/TXT, a chave pública é consultada abaixo de seletor._domainkey.dominio. O DNS não oferece uma operação padrão que enumere todos os seletores que um remetente possa ter escolhido, por isso esta página deliberadamente não tenta adivinhar seletores.
Um p= vazio no DKIM significa que a chave pública foi revogada
A RFC 6376 exige a tag p= no registro de chave DKIM. Ela contém os dados da chave pública; um p= vazio possui significado específico: a chave foi revogada. Portanto, um TXT existente com p= vazio não deve ser apresentado como uma chave utilizável e saudável.
DMARC adiciona alinhamento e política aos resultados de SPF e DKIM
A política DMARC é publicada em _dmarc.dominio como DNS TXT. O DMARC avalia se identificadores autenticados por SPF e/ou DKIM estão alinhados ao domínio do cabeçalho visível RFC5322.From. Uma mensagem pode passar em SPF ou DKIM e ainda falhar em DMARC quando o identificador aprovado não está alinhado ao domínio From.
DMARC none, quarantine e reject são políticas solicitadas ao receptor
A tag obrigatória p= solicita tratamento none, quarantine ou reject para mensagens que falham no DMARC. sp= pode definir política para subdomínios. Na RFC 7489, pct= é uma porcentagem opcional usada na aplicação da política e o padrão é 100. Essas tags descrevem a solicitação publicada; o comportamento final do receptor ainda pode ser afetado por políticas locais.
Alinhamento relaxed e strict não é a mesma coisa que pass/fail de autenticação
No DMARC, adkim= controla o alinhamento do identificador DKIM e aspf= controla o alinhamento do identificador SPF. O padrão é relaxed (r); o modo strict é s. Essas configurações determinam quão próximos os domínios autenticados precisam estar do domínio From visível. Elas não alteram se a assinatura DKIM é criptograficamente válida nem se o SPF autoriza o host remetente.
Endereços de relatório DMARC merecem validação operacional separada
DMARC pode publicar destinos de relatórios agregados em rua= e de relatórios de falha em ruf=. Quando relatórios são enviados para um domínio externo, o DMARC define verificações DNS adicionais de autorização dessa relação. Esta ferramenta exibe os valores publicados, mas não afirma que todo destino externo de relatório concluiu essa autorização.
Esta é uma consulta de configuração DNS, não um teste de uma mensagem específica
Para determinar se uma mensagem real passou em SPF, DKIM e DMARC, são necessárias evidências específicas da mensagem: IP remetente, identidade do envelope SMTP, valores de DKIM-Signature e verificação criptográfica, domínio From visível, alinhamento e normalmente Authentication-Results do sistema receptor. Uma página apenas de DNS não pode inferir tudo isso de forma confiável.