Separate a published framework from an agency result
New Zealand's Secure Government Email framework is a concrete government implementation programme, not a measurement of whether every agency has complied. The Digital government page, updated 9 September 2026, describes deployment by October 2026 and covers unclassified email and material classified IN-CONFIDENCE or below. It leaves certification and accreditation with each agency. By the research date of 8 November 2026, that stated deployment month has passed; the page alone does not reveal any agency's completion or exception status. SGE framework.
Record the agency, service boundary, information classification and policy authority before assigning an implementation result. Treat the framework as government programme guidance with stated requirements, not a universal law for all New Zealand organisations. A private supplier needs its contractual and service responsibilities identified. A government body needs its own applicable instructions and acceptance authority. Neither relationship can be settled by finding a DMARC record in public DNS.
Map the published control goals
The framework calls for authenticated sending, inbound DMARC processing, reporting, transport protection and agency-specific data-loss controls. Its checklist includes SPF ending in hardfail, DKIM signing of outbound messages and DMARC rejection policy. It cites NZISM 15.2.36.C.04 for regular review of reports. Retain that citation as the framework's stated basis until a reviewer checks the exact current manual clause; do not represent a secondary citation as a completed manual audit. Published SGE checklist.
The NZISM site provides a general email-security explanation, and NCSC published a version 3.9 release notice on 9 May 2025. The manual's large online document initially opened during research, but subsequent clause and version requests timed out. Consequently, this article does not claim to have revalidated every current clause, version annotation or agency exception. The missing detailed verification is an explicit release dependency. NZISM email FAQ and version 3.9 notice.
Do not copy protocol errors into production
Government authority and technical correctness are different checks. The retrieved SGE text includes statements that SPF softfail permits DMARC to pass, and that absent SPF and DKIM results can pass DMARC with lower reputation. It also shows a non-sending-domain example containing adkim-s. Those explanations and syntax must not be copied as a validated implementation. Preserve the source issue in the assessment and ask the responsible technical and policy specialists to reconcile it.
Under the current core protocol, DMARC success requires a passing, aligned authentication path. SPF softfail is not SPF pass; an aligned passing DKIM signature can independently provide the successful path. Absence of both successful paths does not become a low-reputation pass. DKIM alignment compares its signing domain with the Author Domain, rather than using the SMTP envelope sender as its defining comparison. These corrections follow RFC 9989 and SPF's result definitions. DMARC evaluation and SPF results.
Record interpretation without silently rewriting policy
A technical reviewer can identify a malformed example without claiming authority to replace the government's control intent. Keep two adjacent fields: published requirement and proposed implementation interpretation. Link the source passage, document the standards rationale, and leave approval open. If a field implies that every subdomain needs identical records, evaluate actual domain usage and the relevant discovery rules before preparing a change. This article provides no executable DNS prescription.
The same discipline applies to reporting. RFC 9990 describes aggregate feedback, but reports do not necessarily cover every receiver or every message. A retained review log should record reporting windows, missing sources and unresolved failures. Define who investigates a new sender and who can authorise remediation. A functioning report dashboard is useful evidence only when its input coverage, access and continuing ownership are also understood. Aggregate-report specification.
Assess a fictional overdue implementation
Imagine a fictional agency with an approved migration plan but no recorded acceptance for its appointment-reminder supplier by November 2026. The proposed assessment would identify a missed internal evidence milestone, not announce that the agency is legally non-compliant. The owner must establish the applicable programme deadline, any authorised exception, the supplier's identities and the tests still needed. No real agency, message or DNS response is represented by this example.
Useful acceptance evidence would distinguish the public policy record from controlled sender observations, inbound enforcement settings and report-review activity. A failure in any one area should retain its own diagnosis. A malformed DNS example is a specification issue; an undocumented supplier is an ownership issue; missing message observations are an evidence issue. Giving them separate remediation owners avoids treating every uncertainty as a reason to switch immediately to rejection.
Close governance before claiming completion
An agency acceptance pack should include its scope decision, approved interpretation of source ambiguities, controlled observations, unresolved exceptions and the accountable sign-off. Record the approval date separately from the framework's publication date and the source retrieval date. Schedule review when government guidance changes, an email platform migrates, a reporting service retires or a critical supplier changes its sending identities.
The original commission requires: An authority-to-control table reviewed by the appropriate regulatory or legal specialist. The supplied map has no such review attached. Current clause verification, policy applicability, legal-owner approval and operational implementation evidence remain unresolved, as do the independent checker, site presentation and publication gates. This is a source-backed assessment draft with explicit technical cautions, not an agency audit, migration execution or certification.