Como verificar registros SPF, DKIM e DMARC

Como verificar um registro SPF pela linha de comando?

O SPF fica como um registro TXT no próprio nome do domínio, então consulte o domínio diretamente:

dig TXT example.com +short
nslookup -type=txt example.com

Um domínio pode ter vários registros TXT sem relação entre si no ápice (strings de verificação de domínio, outros serviços), então procure especificamente o que começa com v=spf1. Se mais de um registro TXT começar com v=spf1, isso já é um problema em si: a RFC 7208 trata vários registros SPF no mesmo nome como um erro, não algo para ser combinado automaticamente. Veja o que é um registro SPF para o que cada mecanismo e qualificador no resultado significa, e confira principalmente o final dele, um registro que termina em +all autoriza literalmente qualquer um e vale a pena corrigir antes de qualquer outra coisa.

Como verificar um registro DKIM quando você sabe o seletor?

As chaves DKIM ficam em seletor._domainkey.dominio, então o seletor precisa ser conhecido primeiro. Com ele em mãos:

dig TXT google._domainkey.example.com +short

Um registro funcionando começa com v=DKIM1 e inclui um valor p= com a chave pública; um p= vazio significa que a chave foi revogada de propósito, e nenhuma resposta significa que esse seletor não está configurado. Alguns provedores, principalmente o Microsoft 365, publicam o seletor como um registro CNAME apontando para a própria infraestrutura deles em vez de um registro TXT direto, o dig segue isso automaticamente e ainda retorna os dados da chave. Veja o que é o DKIM para onde encontrar um seletor que você ainda não conhece, o caminho mais direto é o cabeçalho DKIM-Signature de uma mensagem que o domínio realmente enviou.

Como verificar um registro DMARC?

O DMARC sempre fica em um subdomínio fixo, independentemente de qual seja o domínio em si:

dig TXT _dmarc.example.com +short

Nenhuma resposta significa que nenhum registro DMARC está publicado, o que é comum mas deixa os receptores sem instruções para lidar com e-mail que falha no alinhamento. Um registro que existe mas mostra p=none está só em modo de monitoramento; veja o que é o DMARC para como as três políticas se diferenciam e como o alinhamento entre SPF, DKIM e o endereço visível From: decide se passa ou falha.

Como ler o cabeçalho Authentication-Results de uma mensagem recebida?

As consultas de DNS mostram o que um domínio publicou; elas não mostram o que aconteceu quando uma mensagem real foi entregue. Essa evidência fica no cabeçalho Authentication-Results, definido na RFC 8601 e adicionado pelo servidor de e-mail receptor antes de a mensagem chegar a uma caixa de entrada. Abrir os cabeçalhos completos de uma mensagem (no Gmail, "Mostrar original"; no Outlook, a visualização de detalhes da mensagem) costuma mostrar algo como:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Cada verificação relata o próprio resultado de forma independente, pass, fail, softfail, neutral, none ou um código de erro, junto com qual domínio ela avaliou (smtp.mailfrom= para SPF, header.d= para DKIM, header.from= para o endereço contra o qual o DMARC comparou tudo). Uma mensagem pode mostrar spf=pass e ainda assim mostrar dmarc=fail, que é exatamente a lacuna de alinhamento descrita no guia de DMARC acima: o SPF passou para um domínio que não corresponde ao que o DMARC comparou. Ler esse cabeçalho em uma mensagem realmente entregue é a única forma de ver o veredito real, já que os provedores receptores aplicam suas próprias verificações adicionais e sinais de reputação que uma consulta de DNS sozinha não consegue mostrar.

Em que ordem corrigir os problemas?

Corrija os registros na ordem em que uma mensagem é de fato avaliada: SPF e DKIM primeiro, já que a verificação de alinhamento do DMARC não tem nada para alinhar se nenhum dos dois estiver passando ainda, e o DMARC por último, só depois que os dois primeiros estiverem sólidos. Concretamente:

1. Confirme que o SPF existe, é um único registro, lista toda fonte de envio real e não termina em +all.
2. Confirme que o DKIM está configurado e assinando ativamente o e-mail de saída, não só publicado no DNS sem nada usando-o.
3. Envie uma mensagem de teste real por cada fonte de envio que o domínio usa e verifique o cabeçalho Authentication-Results de cada uma, já que uma fonte que parece correta no papel ainda pode falhar na prática.
4. Só então adicione ou aperte o DMARC, começando em p=none com os relatórios ativados, e avance para quarantine e reject em etapas assim que os relatórios confirmarem que toda fonte legítima está alinhada.

Quais são as falhas mais comuns, e como identificá-las?

• Um segundo registro SPF. Alguém adicionou um novo serviço de envio publicando um registro TXT totalmente novo em vez de editar o existente. A correção é juntar os dois em um único registro com um include ou mecanismo por serviço, e depois apagar a duplicata.
• Um seletor DKIM que não resolve. O sistema de assinatura está carimbando um cabeçalho DKIM-Signature com um seletor cujo registro DNS nunca foi publicado, foi apagado durante uma migração, ou tem um erro de digitação. Consultar com dig o seletor exato indicado em s= mostra isso na hora, nenhuma resposta TXT significa que a assinatura nunca pode ser verificada, não importa o quão correta seja a assinatura em si.
• DMARC parado em p=none indefinidamente. O registro foi adicionado, os relatórios começaram a chegar, e ninguém voltou para lê-los nem apertar a política. Isso dá visibilidade, mas não bloqueia nenhum e-mail forjado; trate p=none como uma fase temporária de monitoramento com uma data prevista para terminar, não como um estado final.
• SPF passando enquanto o DMARC falha. Geralmente uma plataforma de marketing ou encaminhamento enviando com o próprio domínio de envelope enquanto mostra o domínio do cliente em From:. O cabeçalho Authentication-Results deixa isso visível diretamente: spf=pass junto com dmarc=fail na mesma mensagem é a marca de um problema de alinhamento, não de um registro SPF quebrado.

Onde verificar os registros por trás disso

A ferramenta de consulta de DNS consulta registros TXT, o tipo de registro que SPF, DKIM e DMARC usam, a partir da rede de pontos de verificação da HostTracker, útil para confirmar que uma mudança de registro já chegou aos resolvedores a partir dos quais a verificação é feita. A ferramenta de consulta MX lista os servidores de e-mail de um domínio e pode verificar o status da porta 25 e a situação em blacklists de DNS de cada um sob demanda, o que é uma questão separada, mas relacionada, de saber se o e-mail de saída está devidamente autenticado. A HostTracker monitora sites desde 2004, faz verificações a partir de mais de 300 pontos em 158 cidades, e pode alertar por e-mail, SMS, chamada de voz, Slack, Telegram e mais quando uma verificação monitorada muda de estado.

Perguntas frequentes

Preciso verificar SPF, DKIM e DMARC toda vez que envio uma campanha?

Não, essas são verificações de configuração em nível de DNS, não algo que muda por mensagem. Verifique de novo depois de adicionar uma nova plataforma de envio, migrar de provedor de DNS, ou quando problemas de entrega aparecerem sem outra causa óbvia.

Por que o dig às vezes não retorna nada para um registro que sei que existe?

Um registro alterado recentemente ainda pode estar em cache como vazio ou com o valor antigo em alguns resolvedores até que a entrada de cache expire pelo TTL. Consulte a partir de mais de um local, ou espere o TTL passar, antes de concluir que o registro está mesmo faltando.

Uma mensagem pode falhar no DKIM mas ainda passar no DMARC?

Sim, já que o DMARC só exige que pelo menos um entre SPF ou DKIM passe e esteja alinhado, não os dois. Uma mensagem com uma assinatura DKIM quebrada mas um SPF aprovado e alinhado com o domínio visível de From: ainda passa no DMARC no geral.

O que significa dkim=neutral ou spf=none no Authentication-Results?

Isso significa que a verificação não chegou a um veredito definitivo, em vez de uma falha direta, none para SPF geralmente significa que nenhum registro SPF foi encontrado, e neutral para DKIM costuma significar que a mensagem não carregava nenhuma assinatura DKIM para avaliar. Os dois apontam para um registro ou assinatura ausente, não para um quebrado.

Uma consulta de DNS é suficiente para provar que a autenticação de e-mail está funcionando?

Ela prova que os registros estão publicados corretamente, mas só o cabeçalho Authentication-Results de uma mensagem realmente entregue prova que eles funcionaram de fato para aquela mensagem, naquele provedor receptor, a partir daquela fonte de envio.