Um aumento repentino nos relatos DMARC falhas é um motivo para investigar, não um diagnóstico. Pode refletir um remetente legítimo quebrado, uma nova tentativa de representação, alteração na cobertura do receptor ou ingestão duplicada. Comece preservando a observação e descobrindo quais dessas explicações as evidências apoiam.
O fluxo de trabalho abaixo separa qualidade do relatório, autorização do remetente, autenticação e impacto nos negócios. Não pressupõe acesso ao conteúdo da mensagem nem promete que cada falha tenha uma causa única visível nos dados agregados.
Congelar um instantâneo de incidente útil
Referências: RFC 9990 §3.1.1.4, RFC 9990 §3.5.4.
Salve o intervalo de relatórios, a organização do receptor, o identificador do relatório, o domínio da política e as contagens de registros afetados. Preserve o relatório original dentro dos controles de acesso e retenção aprovados pela organização. Registre o tempo de ingestão separadamente do intervalo descrito pelo relatório, pois uma chegada atrasada pode criar hoje um pico no painel para o tráfego visto anteriormente.
Confirme se as novas tentativas ou reprocessamentos do relatório não foram contados duas vezes. Compare as janelas atuais e anteriores usando cobertura equivalente. Registre se o alerta significa mais mensagens com falha, uma proporção maior, uma nova fonte ou uma disposição alterada. Essas são observações diferentes.
Isole o menor grupo afetado significativo
Referências: RFC 9990 §3.1.1.8, RFC 9990 §3.1.1.10, RFC 9990 §3.1.1.11.
Agrupar por IP de origem relatado, domínio do autor, avaliado SPF e DKIM identidades, receptor e configuração de política, quando disponíveis. Mantenha a contagem agregada com cada grupo. Evite converter uma linha do relatório em uma mensagem ou tratar o nome do proprietário da infraestrutura como prova de autorização do cliente.
Verifique se a falha afeta todo o tráfego de uma aplicação conhecida ou apenas uma rota, receptor ou intervalo de tempo. Combine o resultado com os registros de implantação e alteração DNS . Um carimbo de data/hora comum restringe uma investigação, mas não prova causalidade.
Autenticação separada do alinhamento
Referências: RFC 9989 §5.3.5, RFC 6376 §6.1.2.
Inspecione os resultados SPF e DKIM e seus alinhamento com o domínio do autor. Um resultado de autenticação aprovado sob uma identidade não relacionada de um serviço não fornece um caminho alinhado. Por outro lado, um caminho SPF com falha não faz com que DMARC falhe quando um caminho alinhado Assinatura DKIM passa.
Caso ilustrativo: um aplicativo de fatura muda para um aplicativo não relacionado caminho de retorno enquanto é Seletor DKIM aponta para uma chave perdida. Suponha uma política válida aplicável, uma chave ausente estabelecida em vez de um tempo limite, nenhuma outra assinatura alinhada e verificações SPF concluídas. Ambos os caminhos alinhados não estão disponíveis no exemplo, portanto as falhas observadas são plausíveis. O reparo suportado é restaurar a assinatura pretendida ou a configuração do envelope após a verificação, e não adicionar IPs arbitrários até que o gráfico fique verde. Este é um cenário de diagnóstico sintético, não um incidente ao vivo.
Estabeleça autorização e impacto
Peça ao proprietário conhecido do aplicativo para confirmar a rota e o volume esperado. Use mensagens recebidas controladas, enviando registros e evidências de impacto no cliente, quando disponíveis. Edite conteúdo desnecessário antes de compartilhar evidências. Se ninguém conseguir estabelecer autorização, mantenha uma classificação de fonte desconhecida em vez de legitimar a fonte através de alterações DNS .
Priorize redefinições de senha, faturas ou avisos essenciais interrompidos usando evidências reais de impacto. Um grande fluxo de falhas aparentemente não autorizadas sob fiscalização pode necessitar de análise de abuso, enquanto uma pequena falha legítima pode exigir a recuperação imediata do serviço. Mantenha esses fluxos de trabalho distintos.
Repare a causa suportada e verifique
Faça a menor alteração autorizada apoiada pelo diagnóstico. Uma reversão de política em todo o domínio enfraquece a aplicação de mensagens não relacionadas e não deve ser a resposta padrão a um gráfico inexplicável. Se uma exceção temporária for justificada, documente seu escopo, aprovador, risco, proprietário e vencimento.
Envie uma nova mensagem controlada pela rota afetada e inspecione os resultados da autenticação do receptor confiável. Em seguida, confirme se os relatórios comparáveis subsequentes apoiam a recuperação, permitindo atrasos nos relatórios. Encerre com a causa, alteração, evidências e limites de cobertura restantes. Se a causa permanecer incerta, diga-o e nomeie o próximo teste, em vez de registrar uma solução suposta como comprovada.
Limite a conclusão e próxima ação
Para a regressão de fatura fictícia, obtenha o seletor de assinatura e o domínio exatos, evidências de pesquisa oficiais e resultado de recebimento confiável antes de escolher um reparo. Uma observação sem chave não é evidência de que a autorização de IP não relacionada conserte a mensagem. Nenhuma pesquisa DNS , reparo de incidente ou teste de email foi executado.