Um relatório pode mostrar uma política de rejeição publicada sem relatar uma rejeição. Leia o perfil do relato antes de interpretar a disposição: atual RFC 9990 define passe para uma passagem de mensagem DMARC sob uma política de aplicação, enquanto relatórios mais antigos não podem usar nenhuma como mensagem passageira. Interprete o contexto da política, os resultados da autenticação e a decisão de tratamento como evidências distintas. A sua relação, em vez de um único campo, explica o que precisa de ser investigado.
Leia a configuração observada primeiro
policy_published registra a configuração de política observada pelo receptor para o domínio de política do relatório. É uma evidência histórica de relatórios, não uma nova pesquisa DNS . Se você consultar DNS hoje, mantenha o resultado e o carimbo de data/hora separados. Uma política pode ter sido alterada durante ou após o intervalo relatado.
RFC 9990 permite vários relatórios quando as configurações são alteradas durante um período; caso contrário, um repórter deverá anotar a configuração final observada. Portanto, um instantâneo de política nem sempre pode explicar todas as condições no momento da mensagem. Retenha o intervalo e altere o histórico antes de acusar um repórter de inconsistência.
Avalie o domínio do autor e os caminhos alinhados
Um recordeO header_from de fornece o domínio do autor. Pode ser diferente do domínio de política quando os subdomínios dependem da política de outro domínio. Determine o relacionamento de política aplicável em vez de assumir que cada linha usa o valor p de nível superior isoladamente.
Os valores dkim e spf em policy_evaluated descrevem a avaliação do identificador relacionado ao DMARC. Eles diferem dos resultados brutos em auth_results. Um caminho alinhado de passagem pode satisfazer DMARC ; uma identidade passageira não relacionada não pode. Uma mensagem que passa DMARC não é uma candidata à rejeição de políticas apenas porque o domínio publica p=reject.
Leia a disposição com motivos de substituição
Caso um ilustrativo do perfil atual: policy_published mostra p=reject, alinhado DKIM passa e a disposição é aprovada, conforme descrito no RFC 9990 Apêndice A e ilustrado no Apêndice B. Caso dois: ambos os caminhos alinhados falham, mas a disposição permanece nenhuma por um motivo de política local. O relatório descreve uma substituição do receptor, não um resultado de autenticação reparado. Preserve a falha e o motivo separadamente.
RFC 9990 exige um motivo quando alinhamento falha e a política aplicada não corresponde à política configurada. Informações faltantes ou inesperadas devem ser sinalizadas para investigação, em vez de preenchidas com uma explicação inventada. Uma sequência de motivos é a explicação do repórter e ainda pode precisar de corroboração.
Esses casos são sintéticos. Nem a disposição nenhuma nem um resultado de autenticação aprovado provam o posicionamento da caixa de entrada. Outras decisões de filtragem e entrega podem existir fora do tratamento DMARC descrito no relatório.
Investigue metodicamente uma incompatibilidade real
Compare o período do relatório, a política observada, o domínio do autor, o modo de alinhamento e os identificadores brutos com suas alterações datadas DNS e evidências de mensagens controladas. Confirme se o remetente é uma rota comercial autorizada. Se o relatório permanecer inconsistente internamente, preserve o XML e registre a incerteza.
Não enfraqueça uma política de domínio simplesmente para fazer com que os rótulos de um painel concordem. Corrija um defeito de envio verificado quando existir; documentar separadamente as substituições do receptor e as limitações de relatórios. O resultado deve ser uma narrativa que outro administrador possa reproduzir a partir dos mesmos campos.
Compare dois acessórios de campo explícitos
Ambos os mapas sintéticos parciais usam o perfil de relatório e domínio de política RFC 9990 atuais e header_from brand.example , p=reject, alinhamento relaxado e intervalo de época 1704067200–1704153600 (1 de janeiro de 2024 00:00 a 2 de janeiro de 2024 00:00 UTC). No primeiro, count=25, bruto SPF passa para vendor.example e DKIM passa para brand.example /selector billing1. Os resultados alinhados calculados são falha SPF e aprovação DKIM ; DMARC passa. A disposição fornecida é aprovada no perfil de relatório RFC 9990 atual.
No segundo, count=4 e ambos os mecanismos brutos passam para vendor.example , com Seletor DKIM v1. Nenhuma das identidades se alinha, portanto o resultado DMARC calculado falha. A disposição fornecida ainda é nenhuma, acompanhada pelo tipo de razão local_policy e o comentário explicitamente sintético “exceção de tratamento do encaminhador confiável”. Essa razão explica o manuseio fictício sem alterar o alinhamento com falha.
As comparações de campo explicam ambos os resultados da autenticação; o segundo exemplo fornece explicitamente uma razão. Esses mapas de campo parciais não são XML completos ou observações ao vivo. A decisão de tratamento do receptor é uma entrada e não uma consequência inferida apenas da autenticação.
Escolha a próxima ação
- Passe alinhado mais passe de disposição do perfil atual (ou perfil legado nenhum): nenhuma rejeição DMARC é solicitada para essa mensagem de passagem; investigue a entrega separadamente, se necessário.
- Ambos os caminhos alinhados falham e nenhuma disposição: inspecione o motivo da substituição e corrobore o remetente, em vez de renomear a autenticação como aprovada.
- O relatório e DNS atual discordam: compare o intervalo do relatório com o histórico datado de alterações de política.
- Motivo obrigatório ausente: preserve o relatório e sinalize uma incompatibilidade inexplicável. Não invente uma exceção de política local.
Distinguir disposições atuais e legadas
O Apêndice A RFC 9990 define a aprovação de disposição como nenhuma ação para passar DMARC com uma política de aplicação. Ele não retém nenhum, pois nenhuma ação foi tomada. Os relatórios mais antigos no formato RFC 7489 não possuem a disposição de passagem e não podem relatar nenhuma para uma mensagem de passagem. Verifique o namespace, o perfil de relatório e os resultados alinhados juntos: nenhum não é universalmente inválido, mas não deve substituir silenciosamente o exemplo de passagem do perfil atual. Nenhum dos valores prova o posicionamento da caixa de entrada.