Mudar para uma política de aplicação é uma decisão importante de controle de domínio, e não o fim da fraude por e-mail. Relate com precisão o limite alcançado: o domínio solicita um tratamento mais rigoroso das mensagens que falham DMARC. Em seguida, explique as ameaças que ainda podem ser autenticadas ou ultrapassar os limites de identidade, juntamente com o trabalho operacional necessário para manter o funcionamento do correio legítimo.
Declare a proteção sem garantia
DMARC combina autenticação de domínio alinhada com uma preferência de manipulação publicada e estrutura de relatórios. O tratamento real do destinatário pode envolver políticas locais. Não prometa que toda mensagem com falha será rejeitada em todos os lugares ou que uma aprovação significa que a mensagem é segura. RFC 9989.
Mensagens de domínio semelhante, falsificação de nome de exibição e remetentes legítimos comprometidos podem permanecer perigosos após a aplicação. Um fornecedor autenticado ainda pode enviar uma solicitação de pagamento não autorizada. SPF uma autorização mais ampla do que a pretendida também pode deixar disponível uma rota de passagem alinhada. Estas são razões para manter controlos complementares e não razões para abandonar a autenticação de domínio.
Verifique as rotas legítimas antes da mudança
Mantenha uma matriz remetente por remetente com o serviço, proprietário responsável, domínio do autor, domínios autenticados, alinhamento evidências, destinatários críticos e data do último teste. Inclua sistemas de baixo volume, como scanners e alertas. Uma rota tranquila não é necessariamente abandonada. Resolva remetentes desconhecidos antes de considerar o inventário completo.
Documente a diferença de política proposta e quem a aprova. Uma mudança de p=none para p=reject é um exemplo, não um valor para publicar cegamente. Revise os domínios e dependências aplicáveis, planeje a janela de observação e defina gatilhos de recuperação para falhas legítimas importantes. Utilize valores específicos do serviço gerados em vez das identidades de demonstração deste artigo.
Examine um livro de prontidão escrito
Para a alteração proposta p=none para p=reject abaixo, assuma um único De visível válido por mensagem e evidência de autenticação do receptor estipulada. Nenhuma alteração real ou teste do receptor é realizado.
- Faturamento: Operações de Faturamento do proprietário proposto; De invoice@billing.brand.test ; Passe SPF para bounce@billing.brand.test ; DKIM passe com d=billing.brand.test. Ambos os identificadores se alinham exatamente, então a mensagem hipotética é transmitida. Testes reais de destinatários críticos e aprovação de alterações permanecem não fornecidos.
- Suporte: Operações de Suporte do proprietário proposto; De agent@support.brand.test ; Passe SPF para bounce@support.brand.test ; Aprovação DKIM com d=support.brand.test. Ambos se alinham exatamente, então a mensagem hipotética passa. Testes reais de destinatários críticos e aprovação de alterações permanecem não fornecidos.
- Scanner legado: proprietário não confirmado; De, SPF , DKIM e cobertura do destinatário desconhecida. Nenhum veredicto de mensagem pode ser inferido. Designe um proprietário responsável e obtenha evidências da rota antes de declarar prontidão.
A preparação geral para implementação não está estabelecida. Mesmo os dois passes estipulados não são provas de produção observadas. O proprietário da mudança proposta deve mantê-la em espera até que questões desconhecidas, aprovações, gatilhos de recuperação e verificações de rota sejam resolvidos. Nenhum código, consulta DNS ou verificação de assinatura foi executado para este razão.
A seção 7.4 RFC9989 requer assinaturas DKIM válidas ao publicar p=reject e desaconselha a rejeição para domínios cujos usuários possam postar em listas de discussão. Esses domínios devem primeiro avaliar os dados agregados com p=none durante pelo menos um mês e depois p=quarantine por um período igualmente longo. Escolha a política tendo em vista essas restrições de interoperabilidade; um exemplo limpo de envio direto não resolve o risco de correspondência indireta.
Verifique o comportamento após uma implementação aprovada
Em uma mudança real, capture a política publicada, o tempo, as diferenças aprovadas e os testes para cada rota crítica. Compare os resultados do receptor confiável e o manuseio real e analise os relatórios agregados disponíveis com seus limites de cobertura. Relatórios ausentes não são prova de que nenhum e-mail foi enviado ou de que nenhuma falha ocorreu. RFC 9990. Investigue exceções legítimas por rota, em vez de enfraquecer amplamente a proteção sem um proprietário.
Explique o risco de fraude remanescente nos mesmos termos comerciais usados antes da aplicação. As alterações de pagamento ainda exigem verificação independente; o comprometimento da conta ainda requer uma resposta de segurança da conta; sósias exigem detecção e relatórios com escopo adequado. As orientações de verificação de pagamentos do FBI permanecem relevantes mesmo quando o domínio é autenticado. Orientação do FBI.
Uma declaração de conclusão sólida nomeia a política observada, as rotas testadas, as exceções não resolvidas e os controles residuais. Não deveria dizer phishing está resolvido. Mantenha a propriedade e a revisão periódica ativas à medida que os serviços, as chaves e os processos de negócios mudam.