termo · verificação de dmarc

Como fazer uma verificação de DMARC para e-mails de aplicação?

Uma verificação de DMARC deve confirmar quatro coisas separadas: uma política válida pode ser descoberta no DNS, suas tags obrigatórias são interpretadas corretamente, pelo menos um identificador SPF ou DKIM autenticado se alinha ao domínio From visível em uma mensagem real e todos os remetentes legítimos da aplicação estão contemplados antes da aplicação da política. Consulte o nome _dmarc, inspecione o registro e depois examine os resultados de autenticação de envios controlados. Passar no DMARC valida o uso autorizado do domínio; não comprova a entrega nem a chegada à caixa de entrada.

Trate a verificação de DMARC como quatro testes, não como uma consulta

Uma verificação útil tem quatro camadas. Primeiro, descubra a política que se aplica ao domínio do autor da mensagem. Segundo, valide o registro TXT como uma política DMARC, em vez de aceitar qualquer texto retornado pelo DNS. Terceiro, teste o alinhamento de identificadores em uma mensagem real: o domínio MAIL FROM autenticado pelo SPF ou um domínio de assinatura DKIM verificado precisa se alinhar ao domínio do cabeçalho From visível. Quarto, confirme a cobertura operacional enviando por todas as aplicações, provedores, regiões e classes de mensagem legítimas que usam o domínio. Uma consulta DNS verde cobre apenas parte das duas primeiras camadas. Ela não mostra que um provedor assina com o domínio pretendido, que um return path personalizado está ativo, que o encaminhamento alterou o comportamento do SPF nem que um sistema esquecido vai sobreviver a uma política aplicada.

Consulte o nome DNS correto e siga a descoberta de política

Comece pelo domínio exato do cabeçalho From da RFC5322, muitas vezes chamado de domínio do autor. Consulte o TXT em _dmarc seguido desse domínio. Para uma mensagem de alerts@notify.example.test, comece em _dmarc.notify.example.test, e não no host do site, no host MX ou no domínio do return path. A RFC 9989 define uma descoberta de política que vai além de uma única consulta: se o domínio do autor não tem um registro válido, o receptor pode percorrer a árvore DNS para encontrar a política organizacional ou de sufixo público aplicável. O tratamento de subdomínios pode vir da tag sp, np ou p, dependendo do que existe e de onde a política é encontrada. Isso significa que um verificador deve informar tanto o nome consultado quanto o domínio de política efetivamente selecionado. Um resultado que diz apenas "registro encontrado" pode esconder erros de herança ou uma política de subdomínio explícita que muda o tratamento esperado.

Valide a estrutura do registro antes de interpretar a política

Um registro de política DMARC usa sintaxe de tag-valor. Segundo a RFC 9989, v=DMARC1 é obrigatório, diferencia maiúsculas de minúsculas e deve aparecer primeiro; uma tag p válida fornece a política de avaliação solicitada. Valores comuns de política são none, quarantine e reject. Tags opcionais descrevem destinos de relatórios, comportamento de subdomínios e alinhamento SPF e DKIM strict ou relaxed. Não corrija silenciosamente tags com erros de grafia, um valor p ausente, registros duplicados ou conflitantes, separadores inválidos ou um valor copiado com artefatos de aspas do provedor DNS. Trate um erro de avaliação permanente como um resultado que precisa de correção, não como aprovação ou falha de DMARC. Também diferencie um erro transitório de consulta DNS de um registro malformado. Tente novamente uma falha transitória do resolvedor por um caminho controlado, mas não afirme que o domínio não tem política até que o DNS autoritativo possa ser consultado de forma confiável.

Verifique o alinhamento de SPF e DKIM em uma mensagem real

O DMARC é avaliado com base na autenticação da mensagem, não na configuração DNS isolada. Para o SPF, compare o domínio MAIL FROM autenticado com o domínio From visível. Para o DKIM, compare o domínio d= de cada assinatura verificada com sucesso com o domínio From visível. O alinhamento relaxed aceita domínios com o mesmo domínio organizacional; o alinhamento strict exige domínios idênticos. Uma mensagem passa quando pelo menos um identificador autenticado passa no seu mecanismo subjacente e está alinhado. Por exemplo, o return path de um provedor pode fazer o SPF passar para o domínio do provedor, mas continuar sem alinhamento com billing.example.test. Se o DKIM verificar com d=example.test sob alinhamento relaxed, a mensagem ainda pode passar no DMARC. Capture o cabeçalho Authentication-Results bruto de contas de destinatário controladas, mas interprete-o no contexto, porque ele informa o resultado do receptor que avaliou e pode conter vários saltos ou assinaturas.

Leia com precisão os resultados pass, fail, none e error

Uma aprovação de DMARC significa que um registro de política se aplica e que um identificador SPF ou DKIM autenticado está alinhado ao domínio do autor. Uma falha significa que uma política se aplica, mas não existe identificador autenticado alinhado. None significa que nenhuma política aplicável foi encontrada. Permerror e temperror indicam erros durante a avaliação de DMARC; uma mensagem com erro de DNS não pode ser considerada aprovada ou reprovada em DMARC. Esses resultados não dizem onde o provedor de caixa de entrada colocou a mensagem. A RFC 9989 limita explicitamente uma aprovação à validação de que o uso pelo proprietário do domínio foi autorizado; ela não afirma que a mensagem é segura, desejada, confiável ou digna da caixa de entrada. Mantenha a aceitação pelo provedor, a aceitação pelo servidor de recebimento, o resultado DMARC, sinais de reclamação e a colocação observada como campos separados em diagnósticos e painéis.

Mapeie todos os remetentes legítimos antes da aplicação da política

Faça o inventário de todos os sistemas que colocam o domínio no From: aplicações de produção, e-mails de autenticação, avisos de cobrança, ferramentas de suporte, plataformas de marketing, alertas de monitoramento, fluxos de CRM, contas regionais e sistemas de emergência. Para cada fluxo, registre o domínio From visível, o domínio MAIL FROM, o domínio d= e o seletor DKIM, a conta do provedor, o responsável, a classe de mensagem e o volume esperado. Envie mensagens controladas pelo caminho normal de produção e verifique tanto a autenticação quanto o alinhamento. Os relatórios agregados de DMARC podem revelar fontes que usam o domínio, mas precisam de interpretação e podem incluir encaminhamentos ou tráfego não autorizado. Comece com monitoramento enquanto o inventário estiver incompleto e corrija os fluxos legítimos não alinhados antes de solicitar um tratamento mais rígido aos receptores. Não altere uma política organizacional compartilhada só para deixar uma aplicação verde, e não passe para a aplicação da política com base em uma única mensagem de teste.

Diagnostique falhas comuns em e-mails de aplicação

Se nenhuma política for encontrada, verifique a zona DNS e o nome do registro antes de editar o valor. Se o registro tiver um erro permanente, reduza-o a uma única política válida e confira a ordem das tags e a sintaxe. Se o DKIM falhar, verifique se o seletor esperado existe, se o provedor de fato assinou a mensagem testada, se o corpo ou os cabeçalhos assinados mudaram no trajeto e se o domínio d= verificado está alinhado. Se o SPF passar, mas o DMARC falhar, compare o domínio MAIL FROM com o domínio From visível, em vez de tratar qualquer pass de SPF como suficiente. Se só os e-mails encaminhados falharem, lembre-se de que o encaminhamento costuma mudar o caminho do envelope e pode quebrar o SPF, enquanto uma assinatura DKIM válida e alinhada pode sobreviver. Se uma implantação causar rejeições, preserve os cabeçalhos com falha e a resposta do receptor, interrompa novos endurecimentos da política e corrija o fluxo responsável, em vez de enfraquecer controles de autenticação não relacionados.

Aplique de forma deliberada as regras de alinhamento de cada provedor

Remetentes terceirizados precisam de uma configuração que vincule seus identificadores autenticados a um domínio controlado pela organização. O Amazon SES documenta dois caminhos: um domínio MAIL FROM personalizado e alinhado para o SPF e um domínio de assinatura DKIM alinhado. O return path padrão, de propriedade do provedor, pode autenticar com SPF sem se alinhar ao domínio From visível; por isso, o DKIM costuma ser o mecanismo alinhado prático, a menos que um domínio MAIL FROM personalizado esteja configurado. Outros provedores usam nomes diferentes para return paths, domínios de bounce, autenticação de domínio e identidades de assinatura. Verifique a mensagem de saída exata, em vez de presumir que o selo de verificado de um painel estabelece o DMARC. As diretrizes atuais do Gmail para remetentes também exigem autenticação e alinhamento para o tráfego aplicável e recomendam relatórios de DMARC. Os requisitos dos receptores e os recursos dos provedores podem mudar, então consulte novamente a documentação oficial no lançamento e durante a revisão de incidentes.

Use evidências do provedor sem tratá-las como um veredito de DMARC

O SendHQ oferece envio com domínio verificado, eventos de entrega, supressões e um painel. Use as informações de domínio de envio e entrega para investigar um fluxo de mensagens, depois verifique o DMARC pelo cabeçalho Authentication-Results do destinatário e separe as evidências de SPF, DKIM e alinhamento. A aceitação pelo provedor e os eventos de entrega não comprovam a chegada à caixa de entrada.

Registre um resultado de verificação de DMARC auditável

Um resultado durável deve conter o domínio do autor, o horário da consulta, o resolvedor, o nome _dmarc consultado, o domínio de política selecionado, o registro normalizado exato, os modos de política e de alinhamento, o status do DNS e se o parsing produziu uma sintaxe aceitável, permerror ou temperror. Adicione uma linha por mensagem controlada com um identificador de mensagem não sensível, o sistema de envio, o domínio From visível, o domínio SPF autenticado e o resultado, os domínios e seletores DKIM verificados, as decisões de alinhamento, o resultado DMARC final e o receptor. Guarde os cabeçalhos brutos em armazenamento restrito, porque podem expor endereços, detalhes de roteamento e identificadores internos. Vincule cada achado a um responsável e a uma data de correção. Verifique novamente depois que os TTLs do DNS expirarem, após mudanças de configuração do provedor, rotação de chaves, novos fluxos de mensagens ou endurecimento da política. Essa evidência torna a verificação reproduzível e evita que uma captura de tela ou um selo de ferramenta vire prova permanente depois que a configuração subjacente muda.

Perguntas frequentes

Onde um registro DMARC deve ser verificado?

Comece pelo TXT em _dmarc seguido do domínio exato do endereço From visível. Identifique também o domínio de política selecionado pelas regras atuais de descoberta de DMARC, porque uma política organizacional ou de subdomínio pode se aplicar quando o primeiro nome consultado não tem um registro válido.

Encontrar v=DMARC1 significa que o DMARC passa?

Não. Isso apenas contribui para um registro de política válido. Uma mensagem passa quando o SPF ou o DKIM autentica com um domínio alinhado ao domínio From visível. Teste uma mensagem real e inspecione os resultados de autenticação do receptor.

O DMARC pode passar quando o SPF não está alinhado?

Sim. Uma assinatura DKIM verificada com sucesso pode fornecer o identificador autenticado alinhado de que o DMARC precisa. O inverso também é possível: um SPF alinhado pode sustentar um pass quando o DKIM não passa, embora depender de um único mecanismo reduza a resiliência.

Passar no DMARC comprova a chegada à caixa de entrada?

Não. Valida o uso autorizado do domínio do autor para aquela mensagem. O receptor ainda pode aplicar sinais de reputação, conteúdo, destinatário, abuso e política local ao aceitar, rejeitar, colocar em quarentena ou categorizar a mensagem.

Uma aplicação deve ir direto para p=reject?

Normalmente não sem evidências de inventário e monitoramento. Mapeie todos os remetentes legítimos, valide o alinhamento em mensagens controladas, revise relatórios agregados, corrija falhas e coordene mudanças de política com o proprietário do domínio antes de solicitar um tratamento mais rigoroso.

O que deve ser verificado novamente depois de trocar de provedor de e-mail?

Verifique novamente a política descoberta para cada domínio From, os domínios MAIL FROM e DKIM do provedor, o DNS do seletor, os resultados de SPF e DKIM, o alinhamento relaxed ou strict, os relatórios agregados e cada classe de mensagem controlada da aplicação antes de aumentar o tráfego de produção.

Fontes