Separe uma estrutura publicada de um resultado de agência
A estrutura de e-mail governamental seguro da Nova Zelândia é um programa concreto de implementação governamental, e não uma medida para saber se todas as agências cumpriram. A página do governo digital, atualizada em 9 de setembro de 2026, descreve a implantação até outubro de 2026 e cobre e-mails não classificados e materiais classificados IN-CONFIDENCE ou abaixo. Deixa certificação e credenciamento com cada agência. Na data da pesquisa, 8 de novembro de 2026, o mês de implantação declarado já passou; a página por si só não revela o status de conclusão ou exceção de nenhuma agência. Quadro SGE.
Registre a agência, o limite do serviço, a classificação das informações e a autoridade política antes de atribuir um resultado de implementação. Trate a estrutura como uma orientação de programa governamental com requisitos declarados, e não como uma lei universal para todas as organizações da Nova Zelândia. Um fornecedor privado necessita que as suas responsabilidades contratuais e de serviço sejam identificadas. Um órgão governamental precisa de suas próprias instruções aplicáveis e autoridade de aceitação. Nenhum relacionamento pode ser resolvido encontrando-se um Registro DMARC em DNS público.
Mapeie as metas de controle publicadas
A estrutura exige envio autenticado, entrada DMARC processamento, relatórios, proteção de transporte e controles de perda de dados específicos de agências. Sua lista de verificação inclui SPF terminando em hardfail, DKIM assinatura de mensagens de saída e política de rejeição DMARC . Cita o NZISM 15.2.36.C.04 para revisão regular dos relatórios. Manter essa citação como base declarada da estrutura até que um revisor verifique a cláusula exata do manual atual; não representam uma citação secundária como uma auditoria manual concluída. Lista de verificação SGE publicada.
O site NZISM fornece uma explicação geral sobre segurança de e-mail, e NCSC publicou um aviso de lançamento da versão 3.9 em 9 de maio de 2025. O grande documento online do manual foi aberto inicialmente durante a pesquisa, mas as cláusulas subsequentes e as solicitações de versão expiraram. Consequentemente, este artigo não pretende ter revalidado todas as cláusulas, anotações de versão ou exceções de agência atuais. A verificação detalhada ausente é uma dependência de lançamento explícita. Perguntas frequentes sobre e-mail do NZISM e aviso da versão 3.9.
Não copie erros de protocolo na produção
A autoridade governamental e a correção técnica são verificações diferentes. O texto SGE recuperado inclui declarações de que softfail SPF permite a aprovação DMARC e que os resultados ausentes SPF e DKIM podem passar DMARC com menor reputação. Ele também mostra um exemplo de domínio sem envio contendo adkim-s. Essas explicações e sintaxe não devem ser copiadas como uma implementação validada. Preservar a questão fonte na avaliação e pedir aos especialistas técnicos e políticos responsáveis que a reconciliem.
No protocolo principal atual, o sucesso DMARC requer um caminho de autenticação alinhado e de passagem. softfail SPF não é aprovação SPF ; uma passagem alinhada Assinatura DKIM pode fornecer de forma independente o caminho de sucesso. A ausência de ambos os caminhos de sucesso não se torna um passe de baixa reputação. DKIM alinhamento compara seu domínio de assinatura com o domínio do autor, em vez de usar o SMTP remetente do envelope como sua comparação definidora. Essas correções seguem RFC 9989 e definições de resultados do SPF . Avaliação DMARC e Resultados SPF.
Grave a interpretação sem reescrever silenciosamente a política
Um revisor técnico pode identificar um exemplo malformado sem reivindicar autoridade para substituir a intenção de controle do governo. Mantenha dois campos adjacentes: requisito publicado e interpretação de implementação proposta. Vincule a passagem original, documente a justificativa dos padrões e deixe a aprovação em aberto. Se um campo implicar que cada subdomínio precisa de registros idênticos, avalie o uso real do domínio e as regras de descoberta relevantes antes de preparar uma alteração. Este artigo não fornece nenhuma prescrição DNS executável.
A mesma disciplina se aplica aos relatórios. RFC 9990 descreve o feedback agregado, mas os relatórios não cobrem necessariamente todos os destinatários ou todas as mensagens. Um registro de revisão retido deve registrar janelas de relatórios, fontes ausentes e falhas não resolvidas. Defina quem investiga um novo remetente e quem pode autorizar a correção. Um painel de relatórios funcional só é uma evidência útil quando a sua cobertura de input, acesso e propriedade contínua também são compreendidos. Especificação de relatório agregado.
Avalie uma implementação fictícia atrasada
Imagine uma agência fictícia com um plano de migração aprovado, mas sem aceitação registada para o seu fornecedor de lembretes de compromissos até novembro de 2026. A avaliação proposta identificaria um marco de evidência interna perdido e não anunciaria que a agência não está em conformidade legal. O proprietário deverá estabelecer o prazo do programa aplicável, qualquer exceção autorizada, as identidades do fornecedor e os testes ainda necessários. Nenhuma agência, mensagem ou resposta DNS real é representada por este exemplo.
Evidências úteis de aceitação distinguiriam o registro de política pública das observações controladas do remetente, das configurações de aplicação de entrada e da atividade de revisão de relatórios. Uma falha em qualquer área deve manter o seu próprio diagnóstico. Um exemplo DNS malformado é um problema de especificação; um fornecedor indocumentado é uma questão de propriedade; observações de mensagens perdidas são um problema de evidência. Dar-lhes proprietários de remediação separados evita tratar cada incerteza como uma razão para mudar imediatamente para a rejeição.
Fechar a governança antes de reivindicar a conclusão
Um pacote de aceitação da agência deve incluir a sua decisão de âmbito, interpretação aprovada das ambiguidades da fonte, observações controladas, excepções não resolvidas e a aprovação responsável. Registre a data de aprovação separadamente da data de publicação da estrutura e da data de recuperação da fonte. Programe a revisão quando as orientações do governo mudarem, uma plataforma de e-mail migrar, um serviço de relatórios for desativado ou um fornecedor crítico alterar suas identidades de envio.
A comissão original exige: Uma tabela de autoridade para controle revisada pelo especialista regulatório ou jurídico apropriado. O mapa fornecido não contém tal revisão anexada. A verificação da cláusula atual, a aplicabilidade da política, a aprovação do proprietário legal e as evidências de implementação operacional permanecem sem solução, assim como o verificador independente, a apresentação do site e as portas de publicação. Este é um rascunho de avaliação apoiado por fontes com precauções técnicas explícitas, e não uma auditoria de agência, execução de migração ou certificação.