Escreva o contrato de aceitação
Uma prova de conceito deve responder a uma questão operacional concreta, como por exemplo se o fluxo de trabalho proposto pode distinguir correio alinhado, serviços legítimos não alinhados e fontes não resolvidas, preservando simultaneamente as provas. Defina a população testada, ações permitidas, versão de entrada e operador responsável. Defina critérios de sucesso antes da demonstração, incluindo como são contadas as observações incompletas e as tarefas interrompidas.
Não deixe que um fornecedor selecione apenas casos favoráveis depois de ver os resultados. Congele um pequeno pacote representativo e guarde um controle negativo retido, se apropriado. Especifique se o objetivo é revisão documental, simulação local ou execução dentro de locatário autorizado. Cada modo prova coisas diferentes. A falta de acesso do locatário é uma limitação da evidência de execução, e não uma falha automática de um recurso documentado.
Meça todo o fluxo de trabalho
Registre a interpretação esperada, a interpretação observada, a exportação de evidências e o esforço do operador separadamente. Um rótulo de autenticação correto não conclui uma investigação se o proprietário do remetente permanecer desconhecido. O tempo gasto na limpeza de insumos, na solicitação de acesso ou na correção de uma importação deve ser incluído em uma medição da carga de trabalho operacional, em vez de ser removido como ruído de configuração sem explicação.
Um pacote de aceitação útil proposto inclui uma identidade alinhada estipulada, um caso de serviço legítimo não alinhado e um caso com evidência de identidade insuficiente. Preserve o último caso como desconhecido. Renomeá-lo deliberadamente como alinhado deverá falhar na avaliação, mesmo que a exportação ainda esteja aberta. Este é um controle negativo proposto, não uma falha observada do produto.
Encerre com uma decisão responsável
Para cada critério que falhou, registre se o problema é um defeito do produto, capacidade não suportada, erro de design de teste ou falta de acesso. Permitir uma nova execução corrigida em uma nova versão sem excluir o primeiro resultado. Se os critérios mudarem, explique o motivo e repita os casos afetados; não mova o portão apenas para obter uma pontuação favorável.
Defina uma reunião final que analise as evidências brutas, os riscos não resolvidos, o esforço interno retido e a autoridade para alterar. A decisão pode ser prosseguir, prosseguir dentro de um escopo mais restrito, estender um teste específico ou parar. RFC 9989 e RFC 9990 fornecem bases de protocolo e relatórios, mas não definem um limite de aceitação de compra. Os limites neste guia são controles de avaliação propostos. Uma simulação aprovada não pode autorizar alterações DNS de produção ou estabelecer entrega, conformidade legal ou colocação garantida na caixa de entrada.
Use um livro de aceitação explícito
Para cada versão de entrada do registro de caso, rótulo esperado, rótulo observado, próxima solicitação de evidência, proprietário necessário, permissão de alteração e local de exportação. Um rótulo desconhecido correto emparelhado com uma alteração automática DNS ainda falha no critério de autoridade. Uma exportação que elimina a linha desconhecida falha na preservação da evidência. Uma conexão de locatário ausente deixa esse critério de execução não testado, não aprovado ou diagnosticado como defeito do produto.
Suponha que todas as verificações de classificação sejam aprovadas, mas o arquivo exportado omita suas referências de entrada. Mantenha o critério de exportação de evidências, retenha a primeira execução e teste novamente a versão corrigida. Não calcule a média do portão obrigatório que falhou com uma pontuação de apresentação alta. O contrato de aceitação deve identificar quais critérios são obrigatórios e quais permitem uma exceção de escopo. Nenhum fluxo de trabalho local, teste de locatário ou execução mutada foi executado para este exemplo escrito.
Escopo do protocolo e limites de avaliação
RFC 9989 Seções 4.4, 5.3.5 e 5.4 distinguir identificadores autenticados; alinhamento e manuseio do receptor. Uma assinatura válida por si só não é uma assinatura completa DMARC veredicto, e um passe não valida o conteúdo comercial. RFC 9990 Seções 3.1, 3.5.1, 3.5.4 e 7 descrever evidências agregadas, relatar identidade, duplicatas e privacidade. A avaliação comercial proposta, a equipe e as portas de autoridade aqui são recomendações editoriais, e não características do produto exigidas pela RFC. Nenhum suplemento executável ausente é necessário para ler estes exemplos escritos; as reivindicações operacionais exigem testes observados autorizados separadamente.