Um pai DMARC A política pode estabelecer como os destinatários devem lidar com alguns e-mails de subdomínios que falham na autenticação. Ele não pode informar qual aplicativo envia aquele e-mail, quem o aprovou ou se um serviço de notificação crítico ainda funciona. Essas questões exigem um inventário de remetentes vinculado à evidência de mensagens recebidas.
A distinção é importante durante a aplicação. Uma verificação DNS pode mostrar uma política de proteção no domínio principal da organização, enquanto uma plataforma de campanha antiga usa uma política infantil explícita, uma subsidiária controla seu próprio namespace ou um serviço de redefinição de senha é autenticado com uma identidade de fornecedor não relacionada. O registro e o inventário respondem a questões diferentes.
Comece com o domínio que o destinatário vê
Para cada fluxo de trabalho comercial, capture o domínio no endereço De da mensagem. Não substitua o domínio do site, o domínio de login da conta ou a marca do provedor de e-mail. Em seguida, identifique a política aplicável, a identidade avaliada pelo SPF e o DKIM assinando domínio ou domínios.
De acordo com a descoberta atual DMARC , um registro aplicável encontrado especificamente para o Domínio do Autor tem precedência sobre o substituto para o domínio do autor. domínio organizacional ou sufixo público. A especificação atual usa um Caminhada na árvore DNS. Um pai imediato não é automaticamente o limite organizacional aplicável. Ver RFC 9989 §4.10.1.
Seu inventário deve, portanto, registrar o domínio da apólice descoberto, e não apenas uma caixa de seleção rotulada “coberto pelo pai”. Registre também o receptor ou avaliador utilizado e a data do teste. Implementações mais antigas podem usar comportamento de descoberta herdado, portanto, um cálculo documental não estabelece uma implantação universal.
Compare três casos de subdomínio
O que se segue é uma ilustração sintética e não uma configuração observada do cliente. Assumir example.com é o domínio organizacional, a descoberta seleciona seu registro quando não existe nenhum registro filho e seu registro contém p=reject; sp=quarantine; np=reject. A tag version é omitida nesta frase apenas para facilitar a leitura; um verdadeiro registro político deve começar com v=DMARC1.
- Caso de domínio do autor: existente
billing.example.com, sem nenhuma expressão explícita Registro DMARC; Política aplicável neste exemplo: Paisp=quarantinepor falha no correio; O que o inventário ainda deve estabelecer: qual fluxo de trabalho de cobrança envia, seu proprietário e o resultado de autenticação alinhado de uma mensagem recebida - Caso de domínio do autor: inexistente
unused.example.com, sem política explícita; Política aplicável neste exemplo: Painp=rejectpor falha no correio; O que o inventário ainda deve estabelecer: se ele realmente não existe no DNS e se algum fluxo de trabalho legítimo o utiliza inesperadamente - Caso de domínio do autor: existente
news.example.com, com seu própriov=DMARC1; p=noneregistro; Política aplicável neste exemplo: O filho explícitop=nonepolítica; O que o inventário ainda deve estabelecer: Quem é o dono dessa exceção, por que ela existe e quando será reavaliada
Em todos os três casos, uma identidade alinhada com passagem pode produzir passagem DMARC . A coluna de política descreve o tratamento solicitado de falha, não um comando para rejeitar todas as mensagens do domínio. As decisões do receptor permanecem separadas sob RFC 9989 §5.4. O sp e np regras de seleção são especificadas em RFC 9989 , seção 4.10.1.
Uma zona DNS delegada é outro item de inventário, e não prova de uma política DMARC explícita. Registre quem o controla e teste a descoberta de seus domínios de autor reais. Não deduza os limites organizacionais do gráfico da sua empresa.
Conecte cada remetente a um proprietário de empresa
Crie uma linha por fluxo de trabalho de envio significativo. Um único aplicativo pode precisar de linhas separadas para campanhas, notificações transacionais e mensagens acionadas por funcionários se usarem identidades ou rotas diferentes.
No mínimo, mantenha o fluxo de trabalho, o proprietário responsável, o domínio do autor, o domínio do envelope, o domínio de assinatura e seletor, serviço de envio, política aplicável, último teste e condição de aposentadoria. Adicione o local da evidência e qualquer problema não resolvido. Um fornecedor nomeado sem uma conta de cliente ou proprietário de empresa identificado continua sendo um líder de investigação, e não uma autoridade de envio aprovada.
Usar relatórios agregados para encontrar o tráfego observado e compará-lo com esse registro. Sob RFC 9990 §3.1 e RFC 9989 §5.3.8, os relatórios descrevem o tráfego visto pelos receptores participantes; a ausência de um relatório não é prova de que não existe um fluxo de trabalho mensal ou raramente usado. Peça aos proprietários de aplicativos que executem deliberadamente redefinições de senha, recebimentos, alertas e trabalhos agendados.
Alterar política em relação ao inventário
Antes de alterar a política pai, identifique as linhas que herdarão a mudança e as linhas com política filha independente. Atribua testes aos seus proprietários. Uma revisão segura pergunta se o correio legítimo permanece autenticado e alinhado, se as exceções são justificadas e se a recuperação pode ser restrita ao fluxo de trabalho afetado.
Evite enfraquecer a política pai simplesmente porque a configuração de um aplicativo está incompleta. Primeiro estabeleça se o serviço pode usar um domínio de assinatura alinhado compatível. Se uma exceção for necessária, documente seu escopo, aprovador, vencimento e plano de verificação. Trate isso como uma decisão de risco explícita, em vez de ocultar discretamente o remetente do inventário.
Após a alteração, compare os resultados e relatórios das novas mensagens com as linhas anteriores à alteração. Mantenha a diferença de política e as evidências juntas. Feche a alteração somente quando os proprietários de negócios afetados confirmarem seus fluxos de trabalho reais e os remetentes não resolvidos tiverem uma próxima ação nomeada.
Mantenha a cobertura da apólice e a cobertura do remetente separadas
Um painel útil tem duas medidas: domínios com uma política aplicável verificada e fluxos de trabalho de envio comercial com um proprietário atual e uma rota alinhada testada. Melhorar um não melhora automaticamente o outro. Use o guia de inventário do remetente para o registo operacional e para o guia de política de subdomínio para detalhes da descoberta.
Torne a próxima decisão explícita
Para o dispositivo de três domínios, faturamento de grupo sob a política sp herdada, não utilizado sob a política np aplicável assumida e notícias sob sua política p explícita. Uma mudança no sp pai não deve ser descrita como uma mudança na política de notícias explícita. Mantenha cada proprietário de fluxo de trabalho e cada lacuna de evidência separados. Isto é uma consequência das suposições de descoberta declaradas, e não de uma caminhada na árvore viva ou da aprovação para alterar a política.