Purpose

The DMARC and Email Security Standard aims to protect South Australian (SA) Government’s email communications and data integrity by outlining specific policy requirements for the secure use of applications and external email platforms such as Mailchimp, SendGrid, etc that can send emails on behalf of the government agencies. The implementation of this standard will lead to enhanced email security and reduced likelihood of an email service impersonating SA Government, thereby increasing trust and reliability in government email communications.

Scope

This standard applies to all South Australian Government public sector agencies (as defined in ICT Policy Statement 1 – Compliant Authorities).

The requirements in this standard apply to:

• Applications and third-party services that can send emails on behalf of the government (@sa.gov.au) or its sub domains.
• Any mail servers set up by the agency, excluding the centrally managed Microsoft Email Exchange environment.

The SACSF policy statement related to this standard is:

• 2.6 Robust ICT Systems and Operations - Standard operating procedures and technical controls must be in place to provide a consistent and secure approach to system administration, maintenance, and configuration activities.

Standard format

This document provides requirements in a format that includes options to deliver the requirements. The categories are:

• “Must” requirements are mandatory for compliance to this standard.
• “Should” requirements are important but there may exist compensating security controls to justify not implementing the requirement, or the associated security risks are accepted based on agency’s defined risk appetite and management decisions.
• “Could” requirements are desirable but not necessary, and could improve the user experience.
• “Won't” requirements have been agreed by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time.

Standard detail

In today's digital world, keeping emails secure is more important than ever. Email security helps protect sensitive information from adversaries, phishing scams, and data leaks. By having strong email security measures in place, government communications can be kept safe, maintain privacy, and avoid potential financial and reputational harm.

SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) are essential tools in email security.

• SPF helps verify that emails are sent from authorised servers by checking the sender's IP address against a list of approved IPs.
• DKIM adds a digital signature to emails, ensuring the message hasn't been altered during transit and confirming the sender's identity.
• DMARC builds on SPF and DKIM by specifying how to handle emails that fail these checks, helping to identify and/or prevent phishing attacks leveraging domain spoofing.

Currently, there are a wide range of third-party email services such as Mailchimp that are utilised by the agencies where these email security measures are not yet implemented. Without a proper implementation of SPF, DKIM, and DMARC, there is a risk of email impersonation and attacks utilising the @sa.gov.au domain (and sub domains) leading to reduced trust in the government by the community. The absence of a DMARC policy signals a lack of email authentication enforcement, making messages appear less trustworthy to mail service providers and increasing the likelihood of them being marked as spam or junk.

The following standard requirements are required to be implemented for all agency email services, third-party email services and/or agency applications with the ability to send emails on the agency’s behalf.

Use of the SA Government Domain (@sa.gov.au)

Must

• The whole of government domain (@sa.gov.au) must not be used when sending emails via third-party email services. Agencies must use their respective sub domains (@subdomain.sa.gov.au) when configuring these services to send emails on their behalf.
• Where there is a business need to utilise the whole of government domain (@sa.gov.au) to send emails via third-party email services, an exemption must be obtained as per the process outlined below.
• Security assessments must be performed at least every two years for third-party software that can send emails on behalf of the whole of government domain (@sa.gov.au).

Should

• Regular security assessments should be performed for third-party software that can send emails on behalf of the agency’s sub domain (@subdomain.sa.gov.au).

Sender Policy Framework (SPF)

Must

• An SPF record must be created and published for the agency’s sub domain to specify the authorised mail servers and third-party services allowed to send emails on behalf of the agency.
• Configure SPF records with a hard fail (-all) to instruct receiving mail servers to reject emails from unauthorised sources.
• Incorporate SPF records into change management processes, ensuring updates when new mail servers or third-party email services are deployed or DNS entries change.
• Where SPF records are not supported by an agency application or third-party email service, DKIM must be configured.

Should

• Regularly test SPF record for correctness utilising trusted online tools.
• Where a sub domain is not required to send emails, the following SPF record should be published to prevent emails claiming to be coming from that sub domain.
  • V=spf1 -all

Domain Keys Identified Mail (DKIM)

Must

• Implement DKIM on applications and services sending emails on behalf of the agency.
• Ensure that the public key is published in DNS as a TXT record for verification by receiving mail servers.
• At minimum, sign the body and essential headers such as "from", "to", "subject", and "date" to ensure email integrity.
• Where a compromise of DKIM keys is identified, the keys must be changed immediately to prevent misuse.

Should

• Notify users about DKIM implementation so they can anticipate changes in email behaviour and report any issues.
• Periodically review and update DKIM keys as part of a broader security maintenance plan to prevent misuse if keys are compromised.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

Must

• DMARC records must be published in DNS to specify the policy for handling emails that fail SPF and DKIM verification.
• Set DMARC policy “p=none” to enable DMARC in monitoring mode to gather data prior to enforcing stricter DMARC policies.
  • Note: “p=none” does not prevent emails that failed SPF and DKIM verification from being   delivered.
• Configure DMARC records to send report user aggregate (RUA) and report user forensic (RUF) reports, providing insights into email traffic and authentication results.
• Verify that both SPF and DKIM are correctly configured and aligned with DMARC to maximise effectiveness.
• Set DMARC policy “adkim=s” (strict mode) to require an exact match between the DKIM domain and the “from” domain. The default value is “r” (relaxed mode) which permits DKIM domain to differ from the “from” domain by sub domains.
• Set DMARC policy “aspf=s” (strict mode) to require the SPF domain to match directly from the “from” domain. The default value is “r” (relaxed mode) which permits differences in the sub domains between the SPF domain and the “from” domain.

Should

• Set DMARC policy “p=quarantine” to quarantine an email that fails SPF or DKIM verification.
• Continuously review DMARC reports to adjust policies and address any issues with email authentication.

Could

• Set DMARC policy “p=reject” to reject an email that fails SPF or DKIM verification.

Implementation Advice

It is recommended that the following process is followed for implementation of the above standard requirements.

• Phased implementation: Start with establishing a monitoring policy to gather data without enforcing restrictions. This can include collecting and reviewing the following: email sending sources, authentication alignment (SPF/DKIM pass/fail), volume of unauthenticated messages, and potential spoofing attempts. This should provide an understanding the current state of email traffic and identify potential issues. Gradually transition to more restrictive policies as confidence in the system grows and issues are resolved.

For policies other than p=none, phased implementation can be achieved by gradually increasing the percentage of emails subject to the new policy using the DMARC percentage tag (pct).

• Monitoring and Adjusting Configurations: Use DMARC reports to monitor email traffic, including report user aggregate (RUA) and report user forensic (RUF) reports. Continuously review reports to adjust policies based on feedback and operational requirements.
• Utilise Whole of Government DMARCian Subscription: DMARCian is a DMARC analysis and reporting platform designed to support the implementation and management of DMARC, while highlighting SPF/DKIM authentication gaps and unauthorised domain usage. The service provides detailed insights into email authentication, helps identify misconfigurations, and supports compliance with email security standards. By leveraging this tool, agencies can effectively monitor domain activity and detect potential spoofing or unauthorised senders. This enables a gradual move toward stronger enforcement policies, ultimately improving overall email security posture and supporting alignment with standard requirements. Access to this service can be requested through OCIO.
• Regular Security Review: To identify risks arising from the use of external mail services, it is recommended that the security posture of these services is assessed by the Agency’s ITSA and the ICT team regularly.

Policy Exemption

Where an application or service being utilised by the agency does not support implementation of above Must requirements, an exemption must be obtained following the process outlined in Exemption | Department of Treasury and Finance.