Quarentena e rejeição comunicam diferentes avaliações do proprietário do domínio sobre e-mails que falham DMARC. A escolha entre eles requer evidências sobre as mensagens legítimas do domínio e as consequências se essas mensagens forem tratadas incorretamente.
Trate a decisão como uma mudança controlada. Identifique quais fluxos podem falhar, por que falham e o que os sistemas receptores realmente fazem. Um registo de aspecto mais restritivo não substitui essa investigação.
Mantenha a avaliação separada do manuseio
Sob RFC 9989 §5.3.5, DMARC avalia se uma passagem SPF ou DKIM a identidade se alinha com o domínio De visível. Uma política expressa a avaliação do proprietário do domínio quando a validação falha.
Sob RFC 9989 §4.7, a quarentena classifica a falha no uso como suspeita. Rejeitar expressa a avaliação de que a falha no uso é inválida. Sob RFC 9989 §5.4, os destinatários mantêm a responsabilidade pelas suas decisões de disposição e podem utilizar outras informações.
Conseqüentemente, a quarentena não promete um resultado universal de pasta de spam e a rejeição não prova que todos os destinatários participantes rejeitaram todas as falhas. Confirme as evidências reais recebidas para o caso sob investigação.
Investigue primeiro as falhas legítimas
Para um aplicativo aprovado, compare o domínio De visível com a identidade SPF e todos os domínios de assinatura DKIM relevantes. Estabeleça a configuração suportada e teste uma nova mensagem pela mesma rota.
Não adicione permissões de envio amplas simplesmente porque uma alteração na política expôs uma falha. Primeiro determine qual conta, fluxo de trabalho e identidade a empresa realmente autorizou.
As listas de encaminhamento e de discussão podem afetar os caminhos de autenticação que sobrevivem. Uma falha indireta pode exigir a análise das alterações da mensagem e do comportamento de recebimento, em vez de outra inclusão no domínio de origem. Registro SPF.
Use o propósito do domínio para avaliar a compensação
Uma identidade transacional dedicada pode ter uma população de envio menor e mais controlada do que um domínio de correspondência de pessoal. Revise cada um de acordo.
RFC 9989 §7.4 adverte contra a rejeição de domínios de e-mail de uso geral e discute domínios cujos usuários postam em listas de discussão da Internet. Estabelece orientações de observação e comparação para essa situação, bem como implicações para a participação dos utilizadores.
Aplicar as orientações relevantes em vez de tratar a quarentena como uma sala de espera obrigatória numa jornada automática para a rejeição. O guia de seleção de políticas estabelece o registro de decisão mais amplo.
Revise uma falha concreta, não apenas uma porcentagem global
Considere um exemplo sintético em que as mensagens dos funcionários são aprovadas, mas o sistema de fatura mensal falha. alinhamento. O fluxo de faturas é pequeno o suficiente para quase não afetar a taxa geral.
Uma política solicitada mais forte ainda pode ter um efeito comercial significativo se os destinatários agirem sobre essas falhas. Identifique o serviço de fatura, corrija sua identidade suportada e teste seu fluxo de trabalho real.
O tráfego com falha desconhecida requer uma investigação diferente. Preservar a incerteza até que as provas estabeleçam se se trata de correio legítimo, de uma rota indireta, de utilização não autorizada ou de outra causa. Não conte cada linha desconhecida como um ataque evitado.
Planeje a mudança e suas evidências de aceitação
Salve a política atual e defina o escopo proposto. Registre os serviços testados, as exceções restantes e as condições que exigiriam escalonamento ou restauração.
Após uma alteração aprovada, verifique o registro oficial e as mensagens recebidas pelo representante. Examine as observações do relatório com seus intervalos de relatório e contexto político. Os relatórios de mudanças políticas são abordados em RFC 9990 §3.3. DNS atual não reconstrói a política que um receptor viu anteriormente.
Use evidências separadas para autenticação, tratamento e impacto nos negócios. Sob RFC 9990 §3.1.6, uma disposição de relatório e qualquer motivo de substituição são contextos úteis, mas não são prova da colocação final na caixa de entrada ou do resultado de um fluxo de trabalho de pagamento ou notificação.
Manter o processo operacional após a decisão
Continue monitorando novos aplicativos, rotas alteradas e permissões obsoletas. Uma decisão política válida pode tornar-se inadequada quando a organização altera a forma como utiliza o domínio.
O resultado significativo é uma escolha documentada apoiada por fluxos legítimos verificados, limites compreendidos e um processo de recuperação. Para diagnóstico em nível de mensagem, use o guia de alinhamento; para interpretação de evidências, use Relatórios agregados DMARC.
Registre a decisão e seus limites
Suponha, apenas como exemplo de planejamento, que 9.900 mensagens de funcionários sejam aprovadas e 100 mensagens de fatura falhem. A taxa total de aprovação é de 99%, mas a rota da fatura tem uma taxa de falha de 100%. Estas contagens inventadas ilustram porque é que a rota crítica precisa de reparação; não são medidas de campanha ou um resultado político prometido.