“DMARC monitoramento" pode significar qualquer coisa, desde o recebimento de relatórios até a investigação de falhas do remetente e a implementação de alterações aprovadas. Um catálogo de serviços deve permitir que um cliente preveja o que acontecerá quando um novo aplicativo começar a enviar, um relatório revelar uma fonte desconhecida ou uma notificação crítica falhar.
Organize-se em torno das tarefas do cliente
Defina a integração, a investigação do remetente, o planejamento de mudanças, a implementação aprovada, a revisão contínua e a desativação como resultados separados. Para cada um, indique suas entradas, proprietário, saída, evidências de aceitação e exclusões. Explique o que o cliente deve fornecer, como propriedade do aplicativo, acesso DNS ou aprovação do impacto nos negócios.
Use evidências de protocolo para restringir a promessa. RFC 9990 relatórios agregados fornecem atividade de autenticação relatada, mas não enumeram todos os aplicativos nem garantem cobertura completa do destinatário. RFC 9989 descreve a autenticação DMARC e alinhamento; isso não faz com que a autenticação passe uma garantia de posicionamento na caixa de entrada. Evite palavras de serviço que impliquem qualquer resultado.
Especifique a unidade de trabalho
Uma unidade de integração do remetente pode incluir um aplicativo, domínios acordados, caminhos de envio suportados e uma janela de teste definida. Uma unidade de alteração pode abranger uma diferença de registro revisada e uma reversão autorizada. Definir como aplicações adicionais, encaminhamentos complexos, trabalhos urgentes e provedores sem suporte entram em uma avaliação separada, em vez de expandir silenciosamente o escopo original.
Distinguir a coleta contínua da análise com equipe. Se os relatórios são coletados o dia todo, mas os analistas os revisam apenas durante horários específicos, diga isso. Defina a entrada e o escalonamento de incidentes separadamente. Descreva onde o serviço depende da equipe do cliente, dos hosts DNS e dos sistemas destinatários, com evidências de cada dependência.
Siga a jornada do cliente
Suponha que um cliente informe que seu aplicativo de fatura usa uma identidade de assinatura de provedor não alinhada. Uma unidade de investigação local pode identificar a conta, confirmar o proprietário e fornecer um diagnóstico baseado em evidências. Se o escopo acordado do MSP excluir alterações na assinatura do aplicativo, seu produto final deverá nomear o proprietário do aplicativo, a verificação exigida pelo fornecedor e a evidência de aceitação necessária após o reparo. Não deve marcar a implementação como concluída apenas porque o diagnóstico está correto.
Uma unidade de mudança autorizada separadamente pode seguir se o fornecedor tiver demonstrado capacidade e o cliente aprovar o escopo exato. Mantenha a verificação do caminho da mensagem distinta da leitura da configuração. Esta hipotética jornada do cliente não é um catálogo fornecido, uma investigação concluída, um preço, um contrato ou uma capacidade verificada do produto. Mostra como uma exclusão deve produzir uma transferência responsável em vez de uma paragem inexplicável.
Torne as exclusões operacionalmente úteis
Uma exclusão deve indicar para onde o cliente irá em seguida. Se o serviço não puder modificar as configurações de assinatura do aplicativo, identifique o proprietário do aplicativo e forneça uma transferência de diagnóstico. Se for necessária revisão legal ou aprovação de privacidade para o processamento do relatório, registre essa dependência antes da coleta. Não trate uma exclusão como permissão para abandonar um incidente ativo sem uma transferência responsável.
Feche cada unidade com um pacote de evidências e exceções não resolvidas. Um cliente deve ser capaz de ver o que foi entregue, o que resta e quem é o responsável pela próxima ação. Revise o catálogo após repetidas solicitações fora do escopo ou alterações de capacidade. Atualize as promessas somente depois de confirmar que a equipe, as ferramentas e a capacidade de verificação podem apoiá-las.