Nenhum registro DMARC encontrado: rastreie o nome do host e a autoridade DNS

Um “não Registro DMARC encontrado" é um ponto de partida para o diagnóstico. Ele pode refletir uma política genuinamente ausente, uma consulta para o nome errado, uma edição em uma conta DNS inativa, uma resposta antiga em cache ou uma falha de resolução.

Antes de publicar outro registro, estabeleça o que a ferramenta consultou e quais servidores autorizados controlam essa resposta. Preserve o código de resposta DNS , bem como quaisquer dados TXT retornados. Isso separa um registro ausente de um recorde que existe, mas não pode ser recuperado por meio de um caminho de pesquisa específico.

Capture a pesquisa exata com falha

Registre a ferramenta, o domínio consultado, o carimbo de data/hora, o resolvedor e a resposta DNS completa, quando disponível. Salve o registro de política atual e a configuração DNS antes de editar.

Esses comandos ilustrativos do BIND dig não são executados aqui. Substitua os nomes da documentação pelo destino aprovado e pelo servidor delegado real. O Manual de escavação BIND define o servidor, nome, tipo e opções de consulta. A seção de autoridade ajuda a reter o contexto de resposta negativa; os comentários retêm o status e os sinalizadores do cabeçalho. Uma consulta simples para o domínio From visível example.com começa aqui:

cavar _dmarc.example.com . TXT +noall +resposta +autoridade +comentários

Mantenha o status da resposta, bem como a seção de resposta. Uma exibição curta pode ocultar a distinção entre um nome sem dados TXT relevantes e um erro de resolução.

Identifique quem controla a resposta DNS pública

Este problema muitas vezes se torna um problema de propriedade. Uma empresa pode ter comprado o domínio de um provedor, transferido seu site para outro lugar e delegado DNS a uma terceira conta. Um registro adicionado no painel errado pode parecer completo e não afetar as verificações de e-mail públicas.

Peça ao operador para identificar o host DNS oficial atual e mostrar sua resposta para o nome pretendido. Evite pagar por correções repetidas sem um caminho de publicação comprovado. Pergunte também se o aviso diz respeito ao seu domínio principal, a um subdomínio de envio ou a uma identidade diferente usada por um aplicativo.

Verifique o nome e a conta de publicação

Verifique a delegação autorizada da zona, incluindo uma zona filha delegada separadamente, se existir. Consulte diretamente um servidor autoritativo relevante, usando seu nome real:

dig @ ns1.example.net _dmarc.example.com . TXT +norecurse +noall +resposta +autoridade +comentários

Se o editor DNS anexar automaticamente a zona, inserindo _dmarc.example.com pode publicar acidentalmente _dmarc.example.com.example.com. Em outro editor, inserindo apenas _dmarc pode estar errado. Verifique o nome final do proprietário publicado em vez de prescrever o mesmo formato de entrada para cada provedor.

Outros erros frequentes incluem um Registro TXT na raiz do domínio, uma edição em uma conta DNS inativa, uma alteração não salva ou uma pesquisa pelo domínio de envio errado.

Distinguir ausência de falha de pesquisa

• Observação: NXDOMAIN ; O que investigar: O nome consultado é reportado como inexistente
• Observação: NOERROR sem dados TXT relevantes; O que investigar: o nome consultado não possui resposta TXT aplicável nessa resposta
• Observação: SERVFAIL ; O que investigar: Falha na resolução; inspecionar autoridade, delegação, validação e dependências
• Observação: existe uma resposta oficial, mas a resposta recursiva é diferente; O que investigar: estado do cache, visualização do resolvedor, caminho e tempo de delegação
• Observação: Vários registros de políticas de candidatos; O que investigar: um problema de conjunto de registros, não uma simples condição de registro ausente

Os status DNS e a distinção de respostas negativas são descritos em RFC 1035 §4.1.1, RFC 2308 §2.1 e RFC 2308 §2.2. Não trate SERVFAIL como permissão para publicar outro registro. O registro pode existir, mas não estar disponível através do caminho de resolução com falha. Da mesma forma, a falta de um registro no nome de um filho não determina se um receptor pode descobrir uma apólice aplicável em outro lugar sob RFC 9989 §4.10.1.

Exemplo resolvido: o registro está em uma zona inativa

Considere esta investigação ilustrativa. Um administrador adiciona _dmarc ao painel DNS do registrador. A delegação pública, no entanto, aponta para um host DNS separado usado durante uma migração de site anterior.

O painel do registrador mostra o valor pretendido. Uma consulta direta à autoridade atualmente delegada não a retorna. Esperar mais tempo não pode tornar uma zona inativa autoritária.

A correção é publicar através da própria autoridade, com a devida aprovação. Depois, retenha a resposta oficial e compare a observação recursiva. Alterar os servidores de nomes apenas para tornar o painel anterior eficaz pode interromper registros não relacionados da web e de e-mail, portanto, essa é uma mudança separada e muito mais ampla.

Compare respostas oficiais e em cache

Sob RFC 2308 §5, um resolvedor pode armazenar em cache uma resposta negativa anterior. Um novo registro oficial pode, portanto, coexistir temporariamente com uma observação recursiva de resposta faltante. A limpeza do cache de um laptop não limpa o estado do resolvedor de um receptor externo.

Compare a autoridade e as observações recursivas relevantes com carimbos de data/hora. Se os servidores autorizados discordarem, investigue o estado publicado. Se DNS interno e o público forem diferentes, estabeleça qual visualização o receptor de email externo usa.

Evite prometer que todas as respostas convergirão após um número fixo de minutos. Diagnosticar o caminho real e armazenar evidências em cache.

Corrija o processo de publicação

Trate a descoberta como um problema de propriedade de controle quando ela revelar responsabilidades pouco claras DNS , contas abandonadas ou delegação não gerenciada. Registre quem pode fazer alterações, qual zona está ativa e como um segundo revisor verifica o resultado.

Uma observação de política ausente é uma descoberta de configuração. Não estabelece que um phishing campanha bem-sucedida, que cada subdomínio não possui uma política ou que cada mensagem recebida falha DMARC. Mantenha essas conclusões separadas e reúna as evidências que cada uma exige.

Verifique a política e uma mensagem real

Após a correção pretendida, confirme a pesquisa da política aplicável e teste uma mensagem real e legítima através do serviço relevante. Verifique seu resultado de autenticação confiável e alinhamento.

Usar o fluxo de trabalho de criação de registros quando uma nova política é realmente necessária. Se a política estiver visível, mas o e-mail falhar, vá para diagnóstico de alinhamento. Se um guia antigo e um novo receptor diferirem na descoberta, inclua Prontidão DMARCbis na investigação.

A lição prática

Feche a descoberta com o caminho de publicação corrigido e a resposta oficial resultante. Em seguida, verifique a política aplicável e uma mensagem realmente legítima. Isso deixa um diagnóstico reproduzível em vez de um resultado inexplicável do verificador.

Mantenha a decisão e as evidências separadas

Para o dispositivo de zona inativa, escolha a autoridade ativa como alvo de publicação proposto; não altere a delegação apenas para tornar relevante um painel obsoleto. Inspecione o sinalizador de resposta autoritativa e o contexto completo da resposta, não apenas o texto retornado. RFC 8767 §4 permite o uso qualificado de respostas obsoletas além do vencimento do TTL, portanto, um TTL não é um prazo de convergência universal. Nenhuma pesquisa ou alteração de configuração foi executada.