Secure Government Email Common Implementation Framework

Purpose

The All of Government Secure Government Email (SGE) Common Implementation Framework provides guidance to agencies on industry practices for securing external email. This will:

• improve the overall security of external email services within the New Zealand government
• decrease the likelihood of successful spoofing of domains in phishing attacks
• enable the retirement of the SEEMail (Secure Encrypted Email) service.

Introduction

The Department of Internal Affairs (DIA) is the lead agency for ICT Common Capabilities. DIA has developed an email security framework using email security controls available through the Domain Name System (DNS). This framework is intended to enable the retirement of the SEEMail service.

These freely available security controls will deliver additional levels of protection as they can be applied to all emails, not just those specifically tagged to route via SEEMail. When reviewing the use of open standards to replace SEEMail, it was determined this could and should be extended to all NZ government agencies.

Guidance to support this framework is provided by the Secure Government Email Architecture, which was approved in March 2024 by the Government Chief Information Security Officer (GCISO) and the SEEMail Security Working Group (SSWG).

Goal

The goal of this framework is to provide technical settings for email security that meet industry standards. The settings will provide:

• transmission security through encryption
• message integrity through digital signing
• a basic level of nonrepudiation through permitting only authorised services to send email on behalf of each domain
• protection against domain spoofing.

Exclusions and limitations

Classification up to IN-CONFIDENCE only

This guidance covers the use of email platforms for the transmission of unclassified email and email classified IN-CONFIDENCE and below.

Certification and Accreditation

All Certification and Accreditation (C&A) for email security services remains the responsibility of each agency.

Protective Security Requirements (PSR) classification markings

This framework does not change the requirements under the PSR for protective markings. NZ government information, including emails, requires protective marking.

How to protect information — PSR

Exceptions

As with any technology settings, this framework attempts to address most use cases. However there will be some situations where specific services may not be able to conform to the recommended settings. Exceptions to this framework are the responsibility of individual agencies.

Technologies being used

The technologies required to be deployed:

• Transport Layer Security (TLS) providing session level encryption with a minimum version of TLS1.2, including controls enforcing encryption for all email (Implicit TLS).
• TLS Reporting (TLS-RPT) to receive feedback on issues related to the encryption of email transmissions using TLS.
• Sender Policy Framework (SPF) to ensure only authorised servers and services can send messages from your domain.
• Domain Keys Identified Mail (DKIM) for message signing, providing limited nonrepudiation and ensuring messages are not altered in transit.
• Domain-based Message Authentication, Reporting, and Conformance (DMARC) for tying SPF and DKIM together with policy and providing reporting. A DMARC reporting tool is required.
• Mail Transfer Agent Strict Transport Security (MTA-STS) for enforcing encryption on all inbound messages from supported sending domains.
• Data Loss Prevention (DLP) for ensuring messages marked with classifications higher than IN-CONFIDENCE are blocked.

Agency implementation

To request detailed configuration settings for the SGE Framework, email sge@dia.govt.nz.

Appropriately skilled suppliers will be invited to offer services in support of the framework on Marketplace.

Pae Hokohoko | Marketplace

This will allow agencies to select from a panel of suppliers to gain assistance with their implementation projects to enable SPF, DKIM, DMARC, MTA-STS. It will also help with the iterative work required to move towards the enforcement of these security controls.

Agencies will also be able to procure DMARC reporting and/or ongoing operational support for managing the security controls if needed.

The Marketplace service scope will be flexible so it can adapt to any future changes to the guidance.

These services will include DMARC reporting tools which will most likely be third party Software as a Service (SaaS) providers like Valimail, OnDMARC, EasyDMARC, Proofpoint or others.

It is important for agencies to use a DMARC reporting tool to ensure they can meet their expectations under New Zealand Information Security Manual (NZISM) section 15.2.36.

Section 15.2.36 — NZISM

Deployment timeline — October 2025

All agencies should have lifted their email security standards to be in line with this framework by this date.

Compliance monitoring and reporting

The All of Government Services Delivery (AoGSD) team will monitor compliance to the framework. Monitoring will initially cover SPF, DMARC and MTA-STS settings and will be expanded to include DKIM. Changes to these settings will also be monitored, enabling reporting on email security compliance across All of Government.

Ongoing monitoring will:

• highlight changes to domains
• ensure new domains are set up with security in place
• track the implementation of future email security technologies.

Where compliance changes, for example an agency has a domain with an SPF record ending with -all, which is changed to ~all, this will be captured, to facilitate agency communication by the AoGSD Security team to determine if there is an issue or if an error has been made. AoGSD will review each case individually and will communicate directly with agencies.

Securing all email enabled domains

Purpose

This section defines the required settings for securing all enabled domains.

Transport Layer Security (TLS)

TLS has become the default standard for providing encryption at the session layer between messaging servers. For most mail services TLS is enabled by default, however there are specific steps required to ensure TLS is always used.

Microsoft Office 365 configuration

If an agency uses Microsoft Office 365, then TLS1.2 (minimum) with strong cyphers is enabled by default. However, if the recipient’s server does not support TLS or the TLS handshake fails, the email can revert to sending in the clear. To address this risk, configure an Outbound Connector to require TLS and a mail flow rule to reject non-TLS connections inbound.

Configuring a connector to require TLS for all outbound mail

This forces Office 365 to only send mail via an encrypted connection. If the receiving mail server does not support TLS, the email will be rejected and not sent.

1. Log in to Exchange Admin Centre (EAC):
   • Go to the Microsoft 365 admin centre, then navigate to the Exchange Admin Centre.
2. Go to Mail Flow > Connectors:
   • In the left-hand panel, click Mail Flow, then select Connectors.
3. Create a New Outbound Connector:
   • Click the + (plus) sign to add a new connector.
   • Choose From: Office 365 and To: Partner Organization. This will cover external outbound mail.
4. Set Domain Scope to All Domains:
   • In the domain settings, choose the Any domain option. This ensures the connector applies to all emails sent outside your organisation.
5. Require TLS Encryption:
   • In the Security Restrictions section, select Force TLS.
6. Test and Save:
   • Review the configuration, test it, and click Save to enable the connector.

Creating a mail flow rule to reject non-TLS connections

This forces Office 365 to reject any incoming connection requests where the sending server does not support TLS.

1. Log in to Exchange Admin Centre (EAC):
   • Go to Mail flow and select Rules.
2. Create a new rule:
   • Click the + sign to create a new rule and select Create a new rule.
3. Configure conditions:
   • In the Apply this rule if... section, select The recipient domain is external.
   • Alternatively, you can use Any recipient if you want the rule to apply to all emails.
4. Block non-TLS emails:
   • Under Do the following, select Reject the message with the explanation.
   • Customize the rejection message to indicate that TLS encryption is required.
5. Exception handling (optional):
   • If there are specific trusted domains that do not support TLS but are allowed, add those domains as exceptions.
6. Save the rule:
   • Review the rule configuration and click Save to enforce it.

Google Cloud Platform

If an agency uses Google Cloud Platform (GCP), they will need to manually disable TLS1.0 and 1.1.

Restrict TLS versions — Google Cloud

By default, all outbound email from GCP is encrypted, and if TLS fails, outbound email will not be sent unencrypted and will instead queue for delivery once TLS is restored.

TLS Reporting (TLS-RPT)

TLS reporting is a mechanism that allows domain owners to receive feedback on issues related to the encryption of email transmissions using Transport Layer Security (TLS). Specifically, it provides reports on the status of email message delivery over TLS, such as failures to establish secure connections due to misconfigurations, certificate issues, or downgrades.

TLS-RPT works by allowing mail exchange servers to send reports to the domain owner whenever there’s a failure in TLS negotiation. These reports help organisations monitor their email traffic and ensure their messages are delivered securely.

Microsoft 365 offers TLS reporting capabilities within its suite of security and compliance tools to monitor secure email delivery and TLS encryption health. Various managed DMARC providers can also provide this service.

The only configuration required if using either Microsoft 365 or Google Cloud Platforms is for a DNS record to be created. Once the DNS record propagates, you’ll start receiving reports from other email servers that encountered issues delivering emails to your domain using TLS.

Sender Policy Framework – SPF

When correctly configured, SPF provides protection to domains by only permitting delivery of email which have been sent from valid source servers.

Most domains already have SPF records enabled. However, DNS scanning has shown many SPF records end with a softfail ~all instead of a hardfail -all. This is a weak posture as ~all limits any protection afforded by SPF.

If an SPF record has ~all at the end, a malicious email sender can use any SMTP capable server to send on behalf of the domain, and the message will not be dropped by DMARC checks. While it will not ‘pass’ checks as being specifically listed as an authorised source, it will also not fail checks as the ~all permits unknown sending servers.

Example SPF record

The following is an example SPF record from the domain nsw.gov.au. This domain permits messages outbound only from the Microsoft Office online IP address ranges and denies all other addresses.

When configuring SPF records consideration must be given to all servers and services which may send email on behalf of the domain. If the only source is Microsoft Office 365 for sending all email then “v=spf1 include:spf.protection.outlook.com -all” will cover all email.

However, SPF entries will also need to be included for email sent from:

• bulk mail senders — such as Sendgrid or Mailchimp
• other external systems — such as Finance, HR, Payroll or CRM platforms.

Agency’s bulk sending services will be able to supply their requirements for SPF.

Moving from ~all (softfail) to -all (hardfail)

Moving from ~all to -all can have a severe impact on email flows. All valid source servers must be identified and included within the SPF statements before making the change.

DMARC reports should be reviewed to look for messages which are hitting the softfail controls. This will highlight source servers which are not explicitly permitted to send on behalf of an agency’s domains.

Once all source servers have been explicitly defined the suffix should be changed from ~all to -all.

Domain Keys Identified Mail – DKIM

DKIM is used to cryptographically sign messages as they leave an organisation. The cryptographic signature can be verified by the recipient server ensuring the message has not been altered in transit. DKIM signing needs to be provided on the exit points of all systems sending email on behalf of the organisation.

Domain-based Message Authentication, Reporting and Conformance – DMARC

DMARC ties the above SPF and DKIM settings together, advising recipient servers how to handle non-compliant messages from your domain. Most agencies have DMARC policies in place, however most also have the compliance set to p=none. There are 3 options available for DMARC compliance: none, quarantine or reject.

When a receiving server receives an email appearing to be from an agency’s domain, it will look up their DMARC policy for instructions on how it should be applied. If the message passes the associated DKIM and SPF checks, the message will be delivered, or at least continue for further processing by other security measures, for example, spam filters. If DKIM and/or SPF checks fail, it is the DMARC controls which advise the recipient server on how to proceed.

If the flag is set to p=none, any DKIM and SPF failures may be ignored, and the message delivered to the recipient’s inbox. The exact way the message is handled may be determined by the recipient server’s internal policies.

If the flag is set to p=quarantine any DKIM and SPF failures should result in the message being sent to quarantine, depending on how the receiving server is configured. For example, there may not be a quarantine service configured, so the message might be delivered to the junk-mail folder instead. This is not considered a good approach. It has been proven that end users frequently get email released from quarantine and will read messages in their junk mail folder, including clicking on links.

If the flag is set to p=reject, messages failing DKIM and SPF checks should be rejected and discarded by the recipient server. Many mail exchange (MX) servers in the sending path also check for DMARC compliance so non-compliant messages may be discarded before they even reach the destination server.

Moving to p=reject

Moving to p=reject is generally not a big move, and one which has been overestimated by many organisations.

Safe migration is achieved through:

1. ensuring all sending servers are covered within the SPF policy
2. monitoring DMARC reporting and following up on any identified issues.

The key is identifying these mail flow issues before switching over to reject.

DKIM alignment within DMARC

Another important consideration in DMARC is the option to enforce strict alignment of the mailfrom and sender domain addresses within DKIM. This is set through adkim=s (for strict) or adkim=r (for relaxed) within the DMARC record. The default is relaxed. It is recommended that strict alignment be implemented, however this can cause issues if there are other services sending on behalf of a domain.

The recommended solution is to have bulk mail senders operating from a different subdomain to end users. Although it is understood changing existing services to this could be disruptive.

This option gives recipient servers the highest confidence the message is genuine and provides the sender with the greatest assurance the message will be delivered to the destination mailbox.

Inbound messages and DMARC

In both Microsoft 365 and Google GCP, you do not need to configure anything specific to handle incoming DMARC. Both platforms automatically check incoming emails against the sender’s DMARC policy. If the DMARC check fails, they will act based on the policy defined in the DMARC record (for example, none, quarantine, or reject).

For other email providers it is up to the agency to check and ensure their email service performs DMARC checks and acts on the senders’ policies.

Emails which fail DMARC (either reject or quarantine) should never make it to the users’ mailboxes. Where the sending domain policy has p=quarantine these emails should not go to users’ junk mail folders. They should go to the email platform quarantine for release only by administrators (security operations team) after review. The expectation is these will not be valid business emails. Sending them to users’ junk mail folders may result in phishing links being clicked on and followed.

Where the sending domain policy rejects the email, the email should be rejected and dropped.

DMARC reporting services

Control 15.2.36.C.04 of the NZISM requires agencies to review DMARC reports on a regular basis. To meet this requirement a DMARC reporting tool is required. There are many SaaS DMARC reporting providers. Some will be made available via Marketplace.

Pae Hokokoko | Marketplace

Enforce DLP in line with the PSR and NZISM requirements

Agencies are required to review and apply their own DLP settings.

MTA-STS

MTA-STS provides recipients with the ability to prevent incoming TLS sessions from downgrading to sending in the clear. This prevents adversary-in-the-middle attacks on the STARTTLS session commands where they attempt to force messages to default back to send unencrypted to intercept them. MTA-STS uses certificate verification to ensure the destination domain is valid and traffic is not being maliciously re-routed. This protection will be superseded by DANE (DNS-based Authentication of Named Entities).

Securing non-email enabled domains

Purpose

The purpose of deploying email security to non-email enabled domains is to prevent spoofed messages from that domain. This requirement remains even if the root level domain has SP=reject set within its DMARC record.

Implementation of SPF, DKIM and DMARC records

The following settings apply to all non-email domains, sub-domains and all new domains. Sub-domains can consist of as little as a single A record. They set blank records for SPF and DKIM and set DMARC to reject. After these are set, given the same spoofing examples above the messages would fail all DMARC checks and almost certainly be dropped.

Implementation of these SPF, DKIM and DMARC records remains with each agency through their normal DNS change processes.

SPF settings for non-email enabled domains

The required SPF record needs to deny all senders. This is achieved through having no sending servers listed in the SPF record and using the hard fail -all option. Any message received by a recipient MX server performing SPF checks will be rejected and dropped as the sending IP address will not match the blank SPF list.

DKIM settings for non-email enabled domains

The purpose of a DKIM record on a non-email enabled domain is to force all messages to fail DKIM. This is achieved through providing a DKIM key with no public key.

DMARC settings for non-email enabled domains

DMARC provides protection through directing recipient domains to reject messages which fail the SPF and DKIM checks above. The purpose of setting RUA (Reporting Uniform Resource Identifier for Aggregate) reports is to provide you the ability to check for any sources attempting to spoof messages from those domains. This is especially useful where those domains might be related to controversial public interest sites or events where people may seek to promote their own agenda through impersonated emails.

These settings configure the alignment to strict for both SPF and DKIM, rejecting 100% of messages which fail those checks on both the root level and sub-domains.

Agency deployment checklist

The following table is a checklist for agencies to ensure they meet the requirements of this framework.