将已发布的框架与机构结果分开
新西兰的安全政府电子邮件框架是一项具体的政府实施计划，而不是衡量每个机构是否遵守的标准。数字政府页面于 2026 年 9 月 9 日更新，描述了 2026 年 10 月之前的部署情况，并涵盖分类为“机密”或以下的非机密电子邮件和材料。它把认证和认可留给每个机构。截至研究日期 2026 年 11 月 8 日，所述部署月份已过；该页面本身并不显示任何机构的完成或例外状态。 SGE框架.
在分配实施结果之前，记录机构、服务边界、信息分类和政策权限。将该框架视为具有明确要求的政府计划指南，而不是适用于所有新西兰组织的普遍法律。私人供应商需要确定其合同和服务责任。政府机构需要有自己的适用指令和接受机构。这两种关系都不能通过找到一个解决方案来解决 DMARC记录 在公共DNS中。
绘制已发布的控制目标
该框架要求经过身份验证的发送、入站 DMARC 处理、报告、传输保护和机构特定的数据丢失控制。其清单包括 SPF 以困难失败告终， DKIM 出站消息的签名和DMARC拒绝策略。它引用 NZISM 15.2.36.C.04 来定期审查报告。保留该引用作为框架的规定基础，直到审阅者检查确切的当前手册条款；不代表二次引用作为已完成的手动审核。 发布上金所清单.
NZISM 网站提供了一般电子邮件安全说明， NCSC于 2025 年 5 月 9 日发布了 3.9 版发布通知。该手册的大型在线文档最初在研究期间打开，但后续条款和版本请求超时。因此，本文并不声称已重新验证每个当前条款、版本注释或机构例外。缺少的详细验证是显式的发布依赖性。 NZISM 电子邮件常见问题解答 和 3.9版本通知.
不要将协议错误复制到生产中
政府权威和技术正确性是不同的检查。检索到的 SGE 文本包括SPF softfail允许DMARC通过的语句，以及缺少SPF和DKIM结果可以通过DMARC以较低的信誉。它还显示了一个非发送域示例，其中包含 adkim-s。这些解释和语法不得复制为经过验证的实现。在评估中保留源问题，并要求负责的技术和政策专家对其进行协调。
在当前核心协议下， DMARC成功需要通过、一致的身份验证路径。 SPF softfail不是SPF通过；对齐传球 DKIM签名 能够独立提供成功路径。缺乏这两条成功路径并不意味着声誉低下。 DKIM 结盟 将其签名域与作者域进行比较，而不是使用SMTP 信封发件人 作为其定义比较。这些更正如下 RFC 9989 和SPF的结果定义。 DMARC评估 和 SPF结果.
记录解释，无需默默重写政策
技术审查者可以识别格式错误的示例，而无需声称有权取代政府的控制意图。保留两个相邻字段：已发布的要求和建议的实施解释。链接源段落，记录标准基本原理，并保留批准。如果某个字段意味着每个子域都需要相同的记录，请在准备更改之前评估实际域使用情况和相关发现规则。本文没有提供可执行的DNS处方。
同样的纪律也适用于报告。 RFC 9990 描述汇总反馈，但报告不一定涵盖每个接收者或每条消息。保留的审查日志应记录报告窗口、缺失的来源和未解决的故障。定义谁调查新发件人以及谁可以授权补救。仅当其输入覆盖范围、访问权限和持续所有权也被理解时，功能正常的报告仪表板才是有用的证据。 聚合报告规范.
评估虚构的逾期实施
想象一个虚构的机构，其迁移计划已获得批准，但到 2026 年 11 月尚未记录其预约提醒供应商的接受情况。拟议的评估将识别错过的内部证据里程碑，而不是宣布该机构在法律上不合规。业主必须确定适用的计划截止日期、任何授权的例外情况、供应商的身份以及仍需要的测试。此示例不代表任何真实的机构、消息或DNS响应。
有用的接受证据将公共政策记录与受控发件人观察、入站执行设置和报告审查活动区分开来。任何一个领域的失败都应该保留自己的诊断。格式错误的DNS示例属于规范问题；无证供应商是所有权问题；缺失的消息观察是一个证据问题。为他们提供单独的补救责任人，可以避免将每一个不确定性都视为立即拒绝的理由。
在宣布完成之前关闭治理
机构验收包应包括其范围决定、对来源模糊性的批准解释、受控观察、未解决的例外情况和负责任的签字。将批准日期与框架的发布日期和来源检索日期分开记录。当政府指南发生变化、电子邮件平台迁移、报告服务停用或关键供应商更改其发送身份时安排审核。
最初的委员会要求： 由适当的监管或法律专家审查的控制权表。所提供的地图没有附加此类评论。当前的条款验证、政策适用性、合法所有者批准和运营实施证据仍然悬而未决，独立检查器、网站演示和发布门也是如此。这是一份有来源支持的评估草案，具有明确的技术注意事项，而不是机构审计、迁移执行或认证。