Uma política de rejeição pode ser uma parte útil da proteção de um domínio de envio. Não pode estabelecer que todas as mensagens que uma pessoa recebe são seguras, que todos os destinatários tomarão a mesma ação ou que um remetente autenticado está agindo honestamente.
A questão prática não é se um domínio alcançou um rótulo político específico. É qual rota de representação o controle aborda e quais evidências apoiam a próxima decisão. Um programa de segurança precisa que esse limite seja claramente definido antes que a porcentagem do painel se torne uma reivindicação de gerenciamento.
Descreva a identidade controlada
Sob RFC 9989 §5.3.5, DMARC avalia o uso do domínio no endereço De visível em relação à passagem, alinhado SPF ou DKIM evidência. Uma política se aplica a esse relacionamento de domínio. Ele não autentica um nome de exibição, aprova uma solicitação de pagamento ou julga um site vinculado; RFC 9989 §5.4 deixa claro que o uso de domínio validado não é uma afirmação de valor sobre uma mensagem.
Uma política de rejeição expressa a avaliação solicitada pelo proprietário do domínio para mensagens que falham na validação. O manejo final do receptor também depende da sua própria análise. RFC 9989 RFC 9989 §7.4 exige especificamente que os destinatários considerem mais do que uma política de rejeição publicada, especialmente quando está envolvido correio indireto legítimo.
Esses limites não tornam o controle sem importância. Eles tornam sua cobertura mensurável. Usar o guia de seleção de políticas para conectar a política ao propósito real do domínio.
Teste quatro histórias de ataque diferentes
Os cenários a seguir são ilustrativos. Não são incidentes de clientes ou resultados de ataques medidos.
- Cenário: um remetente usa o domínio De exato de uma organização sem uma identidade alinhada de passagem; O que a evidência do domínio pode mostrar: A falha DMARC pode informar o tratamento de acordo com a política aplicável; O controle ainda é necessário: análise do receptor, monitoramento e resposta a incidentes
- Cenário: um remetente usa um domínio diferente com um nome de exibição executivo convincente; O que a evidência do domínio pode mostrar: Que um domínio diferente pode ser autenticado com sucesso; O controle ainda é necessário: detecção de falsificação de identidade e relatórios de usuários
- Cenário: Uma conta legítima é assumida e enviada por uma rota aprovada; O que a evidência do domínio pode mostrar: A mensagem pode ter autenticação alinhada válida; O controle ainda é necessário: segurança e investigação da conta
- Cenário: Um fornecedor envia uma mensagem autenticada solicitando uma alteração fraudulenta de conta bancária; O que a evidência do domínio pode mostrar: O uso do domínio pelo fornecedor pode ser validado; O controle ainda é necessário: verificação independente de alteração de pagamento
Um único “phishing "bloqueado" ocultaria essas diferenças. Rotule os testes por identidade, rota e controle esperado. Para um exercício seguro, use contas de teste autorizadas e conteúdo sintético; não há necessidade de expor um destinatário real a uma instrução fraudulenta para estabelecer o limite do protocolo.
Verifique o correio legítimo antes de alterar a política
Uma política restritiva pode afetar a comunicação legítima cuja autenticação esteja ausente ou cujas identidades estejam desalinhadas. Faça um inventário de cada serviço comercial, seu proprietário e a conta ou rota que o envia. Adicione evidências de mensagens recebidas ao lado do estado DNS .
Uma matriz sintética de prontidão poderia mostrar faturamento verificado, suporte verificado e um aviso fiscal trimestral ainda aguardando teste de envio. A decisão correta de liberação é resolver o fluxo crítico ausente, e não tirar a média, porque o faturamento é responsável pela maior parte do volume.
Trate as fontes desconhecidas como não resolvidas até que as evidências as identifiquem. Um provedor de nuvem familiar não prova aprovação e uma linha de relatório com falha não prova um ataque. Um inventário de remetente mantido dá a essas investigações um lugar para pousar.
Conta para encaminhamento e listas de discussão
Uma mensagem pode sair de sua rota original através de um alias, encaminhador ou lista de discussão. O encaminhamento altera a fonte de conexão vista pelo receptor final em RFC 7208 §10.3; alterações no conteúdo coberto podem afetar a verificação DKIM sob RFC 6376 §3.7. A falha resultante pode dizer respeito a uma mensagem legítima.
Atual RFC 9989 §7.4 adverte contra a rejeição de domínios de uso geral cujos usuários possam postar em listas de discussão da Internet. Também exige que os domínios rejeitados pela publicação apliquem assinaturas DKIM válidas, em vez de depender apenas do SPF . Um domínio transacional e um domínio de correspondência pessoal podem, portanto, necessitar de decisões políticas diferentes.
Um teste entregue por meio de um encaminhador é uma evidência dessa rota e tempo. Não estabelece que toda lista, receptor ou modificação futura se comporte de forma idêntica. Registre a rota de trabalho e a incerteza.
Mantenha o registro de alteração vinculado à reivindicação
Antes de uma alteração de política aprovada, preserve o registro anterior, a diferença proposta, o escopo do domínio, o proprietário, as evidências revisadas e a ação de recuperação. Depois, compare os fluxos legítimos observados, os erros retornados e os relatórios disponíveis. Registre os resultados reais em vez de presumir que uma publicação DNS bem-sucedida prova uma comunicação bem-sucedida.
Para um exercício sintético, a nota de alteração poderia dizer que um domínio de recebimento dedicado foi considerado para uma avaliação mais rigorosa após a revisão dos seus serviços conhecidos e rotas indiretas. Não se deve dizer que todo o phishing foi eliminado. A evidência apoia uma decisão sobre esse domínio e seus fluxos de correio documentados.
Relate o risco residual em linguagem útil
Uma declaração de gestão clara nomeia o domínio, a população monitorizada, os serviços legítimos verificados, a política actual e as fraquezas restantes. Ele mantém as descobertas de domínios falsificados separadas do comprometimento da conta, domínios semelhantes e fraude em transações.
Ações úteis de acompanhamento incluem a remoção de permissões de envio obsoletas, a melhoria da proteção da conta, a validação de solicitações confidenciais por meio de um canal independente conhecido e a manutenção de um processo de denúncia de mensagens suspeitas. Essas ações abordam diferentes caminhos de falha; seu valor não deve ser atribuído ao Registro DMARC sozinho.
O resultado a ser almejado é preciso: o uso legítimo do domínio From escolhido é compreendido e mantido, as falhas são investigadas e a política se ajusta ao uso do domínio. Mantenha visíveis os cenários de fraude restantes para que uma política de domínio mais forte não se torne uma falsa promessa sobre todas as mensagens.
Registre uma decisão que possa ser revisada
Para os quatro cenários, mantenha descobertas separadas para falha no domínio exato, um domínio autenticado diferente, aquisição de conta e uma solicitação de alteração de pagamento autenticada. Não os some em uma reivindicação de sucesso DMARC não qualificada. Os controlos de acompanhamento propostos são recomendações operacionais e não garantias ou requisitos do protocolo DMARC . Nenhum incidente, simulação de ataque ou implantação de política foi realizado.