The New Zealand government recently published its Secure Government Email (SGE) framework. It’s designed to protect official information from email-based menaces, primarily phishing and spoofing. All the New Zealand government agencies must comply with the requirements by October 2025. These standards are introduced to improve email security while also retiring the outdated SEEMail service. This is because SEEMail has limited scope when it comes to scaling, aligning with external partners, and keeping up with the new-age security standards.
The new Secure Government Email (SGE) framework
Secure Government Email (SGE) is a system used by the New Zealand Government to keep email communication safe when talking to other agencies or outside partners.
In simple words, SGE:
- Adheres strictly to security rules to safeguard sensitive information.
- Makes it difficult for hackers to impersonate government emails.
- Strengthens the overall email security for government communication.
- Has replaced the old SEEMail service with this improved system.
Technologies mandated for the New Zealand Government bodies
The technologies that need to be used are:
- TLS (Transport Layer Security): This encrypts emails during sending. It should be at least TLS version 1.2 and must force encryption for all emails.
- TLS Reporting (TLS-RPT): This lets you get reports if there are any problems with email encryption.
- SPF (Sender Policy Framework): This makes sure that only approved servers can send emails using your domain name.
- DKIM (DomainKeys Identified Mail): This adds a digital signature to emails to prove they came from you and weren’t changed on the way.
- DMARC: This connects SPF and DKIM to enforce your email security policies and gives you reports on email activity (you’ll need a DMARC reporting tool).
- MTA-STS (Mail Transfer Agent Strict Transport Security): This makes sure incoming emails are always encrypted if the sender’s domain supports it.
- DLP (Data Loss Prevention): This blocks emails that are labelled as more sensitive than “IN-CONFIDENCE” from being sent out.
SPF, DKIM, and DMARC- the email authentication trio
SPF and DKIM work independently, but DMARC is a mechanism that connects them, allowing domain owners to decide how receiving mailboxes should treat unauthorized emails sent on their behalf. Here is how each of these functions-
Sender Policy Framework (SPF)
A correctly configured SPF protocol prevents threat actors from abusing a domain by only allowing the delivery of emails sent from sources approved by the domain owner or an authorized person. Emails that are sent from unapproved sources are subjected to either a Soft Fail(~all) or a Hard Fail (-all). As per the Soft Fail setting, such emails will get marked as spam, whereas, as per the Hard Fail mechanism, they will be rejected.
According to the SGE framework, all New Zealand government bodies are required to set their SPF record to -all.
When creating an SPF record, it’s important to add all the IP addresses and servers that are used to send emails from your domain. This also includes any vendors or CRM platforms.
DomainKeys Identified Mail (DKIM)
DKIM works by cryptographically signing the outgoing emails. The cryptographic signature is verified at the receiving end to ensure the email has not been tampered with or altered in transit. The New Zealand government now mandates DKIM signing on the exit points of all systems sending email on behalf of government organizations. They require it to be applied at the last MX server in the sending email flow.
Domain-based Message Authentication, Reporting, and Conformance (DMARC)
DMARC ties SPF and DKIM, telling recipients’ servers how to handle non-compliant messages sent from your domain. Many domain owners have deployed DMARC; however, they have set the compliance to p=none—the weakest policy.
There are basically three DMARC policies– none, quarantine, and reject.
- If the DMARC setting is p=none, any emails that fail DKIM or SPF checks will usually still be delivered to the recipient’s inbox. However, what happens exactly depends on the receiving server’s rules.
- If the setting is p=quarantine, emails that fail DKIM or SPF checks will usually be sent to quarantine or the junk mail folder. But this isn’t ideal because users often check their junk mail and might open risky emails or click on dangerous links.
- If the setting is p=reject, any emails that fail DKIM or SPF checks will be blocked completely and won’t reach the recipient. Also, many email servers along the way check for DMARC rules, so these failing emails might get stopped even before reaching the final server.
According to control 15.2.36.C.06 of the NZISM, government agencies must regularly review DMARC reports to determine if someone is attempting to send emails on their behalf. Evaluating DMARC reports also helps determine if any genuine source has not been added to the SPF record.
