Uma mensagem pode ser autenticada com sucesso e ainda assim ser classificada como indesejada ou perigosa. Por outro lado, uma exceção de caixa de correio ou de filtragem pode afetar o tratamento sem reparar a autenticação do remetente. Quando alguém perguntar por que uma mensagem foi para o Lixo Eletrônico, colete os resultados da autenticação e as evidências de filtragem separadamente e conecte-os à ação de entrega real.
Leia as orientações atuais da Microsoft
A referência de cabeçalho atual da Microsoft distingue Authentication-Results do X-Forefront-Antispam-Report e X-Microsoft-Antispam. Ele descreve a BCL como probabilidade de reclamação em massa, em vez de autenticação de domínio. Afirma também que, em organizações em nuvem, o SCL não determina a classificação ou ação do spam; CAT e DIR fornecem contexto de filtragem. Não aplique uma tabela SCL para pasta antiga como uma regra universal de decisão na nuvem. Isso não significa que o SCL seja irrelevante para a configuração: a Microsoft ainda documenta regras de fluxo de mensagens que solicitam desvio ou tratamento de spam. O SCL carimbado e a ação real devem ser investigados com a regra aplicável e o contexto de categorização. Referência de cabeçalho da Microsoft.
O SCL continua relevante no Exchange local e em alguns processamentos híbridos. Estabeleça qual produto e caminho de entrega produziu o campo antes de interpretá-lo. A Microsoft descreve o SCL em sua própria referência específica do produto e o BCL tem uma referência separada. Preserve a data da documentação porque o comportamento e as explicações do serviço podem mudar. SCL, BCL.
Construa uma tabela de evidências sem reduzir significados
Referências: RFC 8601 §5, RFC 8601 §7.
Grave o receptor SPF, DKIM e DMARC resultados com seus domínios avaliados. Em um grupo separado, registre CAT, DIR, BCL e quaisquer valores relevantes de SFV exatamente como recebidos. Deixe os campos não documentados sem interpretação. Em seguida, adicione a disposição real de um rastreamento autorizado, registro de quarentena ou observação de caixa de correio. Um campo ausente é um resultado desconhecido, não um zero ou um resultado aprovado.
Autentique a fonte dessas observações. Mensagens não confiáveis podem conter texto de cabeçalho enganoso e uma cópia encaminhada pode adicionar ou remover informações. RFC 8601 descreve a necessidade de um limite de confiança em torno dos resultados da autenticação; o mesmo cuidado investigativo se aplica quando alguém envia uma captura de tela dos metadados específicos do produto. RFC 8601 seção 7.
Compare um par sintético de resultados
O fixture fornecido contém uma mensagem deliberadamente inventada com dmarc=pass, CAT:BULK, DIR:INB e BCL:7. Demonstra a coexistência de uma passagem de protocolo e uma classificação em massa. O analisador extrai os campos de forma independente. Ele não executa o classificador da Microsoft, não estabelece um limite real nem prevê a pasta que um destinatário veria.
Em uma investigação real, recupere a política e as evidências de processamento aplicáveis ao destinatário naquele momento. Não presuma que um valor BCL numérico sempre leva à mesma ação em todas as organizações. Um remetente pode precisar de melhor consentimento do público, práticas de envio ou conteúdo, enquanto um caso diferente precisa de um reparo de autenticação. A evidência deve identificar qual tarefa se aplica.
Altere apenas a camada responsável
Referências: RFC 9989 §8.
Se a autenticação falhar, corrija a configuração de envio e verifique a mesma rota. Se a autenticação for aprovada e uma categoria em massa ou de ameaça explicar o tratamento, investigue essa classificação por meio do processo de revisão suportado pela organização receptora. Nunca trate um passe de autenticação como permissão para contornar proteções contra malware, falsificação de identidade ou spam.
Registre as evidências antigas e novas após uma correção aprovada. Indique se a melhoria foi uma mudança de autenticação, uma mudança de política ou uma nova disposição observada. Evite prometer a entrega na caixa de entrada a partir de uma única pontuação ou alterar os limites de todos os e-mails para resolver uma mensagem.
Leia a amostra anotada sem conceder confiança
Referências: RFC 8601 §5.
O registro de anotação retido lista cada campo bruto em ordem com seu gerador real, origem reivindicada e limite de confiança. From é uma identidade fornecida pelo autor; Para é um destinatário exibido em vez de uma prova do envelope SMTP . ID da mensagem, data e assunto são contextos controlados pelo remetente. Cada campo Authentication-Results reivindica um serviço e resultado de relatório, mas nem trusted.example nem untrusted.example estabelecem a proveniência genuína do receptor. List-ID nomeia a lista reivindicada; os campos de cancelamento de assinatura descrevem um mecanismo de ação, não a propriedade da lista. Na amostra de classificação, CAT, DIR, SCL e BCL são veredictos inventados no estilo da Microsoft, e não observações da Microsoft. Nenhuma cadeia recebida, identidade de envelope SPF ou IP de conexão foi estabelecida.
Use este mapa como um exemplo de ensino anotado. Para uma mensagem real, substitua cada origem assumida por evidências de coleta e recebimento e deixe qualquer limite não verificado explicitamente sem solução.