If your organisation is still running its own mail stack in Australia, the September 2026 release of the Australian Signals Directorate's Information Security Manual gives you a fresh reason to treat email as a short term containment problem, not a forever platform. The Information security manual (September 2026) was first published on 7 September 2026, and its Guidelines for email remain explicit about policy, filtering, blocking non-approved webmail, and handling email markings and gateway controls. If your exit to Microsoft 365 or Google Workspace is about six months away, the right question is not whether to keep self-hosting. It is what to harden first so you reduce the chance of compromise, data loss and migration disruption during the gap period. This post sets out that short term order of work. It assumes you are not rebuilding the platform. You are reducing risk, preserving evidence, and making the eventual move cleaner. If your team is also deciding how much of the current estate to keep alive versus retire, our pieces on self-hosted mail vs Google Workspace vs Microsoft 365 and migrating to Google Workspace without losing mail help frame the longer move.
01What changed in September 2026, and what it means for a six month bridge
The September 2026 ISM release sits inside a broader ASD refresh. The main ISM publication was released on 7 September 2026, and ASD then published Transitioning from the Essential Eight on 15 October 2026 to show how existing Essential Eight work carries forward into ASD Essentials for enterprise IT. For a mail team, that means two things. First, email controls still matter directly. Second, foundational controls such as MFA, patching, least privilege and backups are not separate from mail hardening, they are part of it.
The email guidance itself is practical rather than theoretical. It requires an email usage policy, says access to non-approved webmail services should be blocked, and keeps emphasis on gateway and handling controls in the Guidelines for email. ASD also maintains separate practical guidance on email hardening, including authentication, TLS and filtering measures. So if migration is six months away, your bridge plan should focus on the controls that cut common attack paths now, without creating rework you will throw away at cutover.
That leads to a simple priority rule. Start with controls that reduce account takeover, malicious mail delivery, unauthorised sending, and blind spots in detection. Defer work that behaves like a major redesign of your current mail architecture.
- Treat the current platform as a temporary risk surface, not a strategic asset
- Prefer changes that survive migration, such as DNS authentication, MFA, logging and documented routing
- Avoid major replatforming of on premises mail if the target state is already chosen
02Harden identity and admin paths first, before touching mail flow
Most mail incidents start with identity compromise or excessive admin access, not a subtle SMTP flaw. ASD continues to position the Essential Eight as core mitigation, covering patch applications, patch operating systems, MFA, restricted administrative privileges, application control, macro controls, user application hardening and regular backups. The October 2026 transition guidance says prior Essential Eight investment still carries forward, but may need broader or stronger application in the new model in Transitioning from the Essential Eight.
For a six month bridge, this means your first hardening sprint should not be about obscure mail server tuning. It should be about every path that can administer the mail platform or impersonate a user. Put MFA on administrator accounts, webmail, VPN, remote management, and any directory or control plane that can reset mail credentials. Remove standing admin rights where possible, use separate admin accounts, and close unused protocols and remote access paths. If your mail platform still exposes broad admin consoles or legacy remote management to the internet, fix that before arguing about advanced transport features.
This is also the right moment to define who owns the platform until cutover. The ISM includes explicit guidance on governance and cyber security roles in the September 2026 release, reinforcing that security ownership should be clear and maintained in system specific documentation. If nobody owns mail operations, incident decisions will be slow exactly when you need them to be fast.
- Require MFA for webmail, admin panels, VPN and jump hosts
- Separate admin identities from daily use accounts
- Review all service accounts, connectors and delegated access
- Patch the operating system, hypervisor and mail application on a fixed window
- Document one accountable owner for mail risk until migration completes
03Lock down the internet facing mail surface, then simplify routing
Once identity is tightened, reduce the exposed surface area of the mail system itself. Internet facing mail servers, webmail, admin portals, and SMTP relays should be inventoried and justified. If a component is only there because of old workflow decisions, remove it now. Every extra relay, legacy spam appliance, forgotten test MX, or public admin endpoint increases both attack surface and migration complexity.
ASD's email guidance stresses gateway and server controls in the Guidelines for email, while its email hardening material points organisations to secure configuration, filtering and platform specific hardening. A practical bridge plan is to reduce the number of paths mail can enter and leave your environment. Route inbound mail through one controlled path. Route outbound mail through one controlled path. Retire direct server to server exceptions unless there is a documented business reason.
This work often exposes hidden dependencies, scanners that email directly, ERP alerts, CRM workflows, website forms, and third party tools sending as your domain. That is useful. You need that inventory anyway before migration, and finding it now lets you stop dangerous unauthenticated senders before they break your reputation.
- Close public admin interfaces unless they are behind VPN or a hardened access path
- Remove unused MX records, relays and legacy gateways
- Inventory every application and device that sends mail as your domain
- Force all approved outbound mail through a controlled relay
- Disable or isolate protocols and features you do not need for the next six months
| Priority | What to harden | Why first | What good looks like in 30 days |
|---|---|---|---|
| 1 | Identity and admin access | Stops the easiest compromise path | MFA enforced, separate admin accounts, exposed admin paths reduced |
| 2 | Internet facing mail surface | Cuts attack surface and routing sprawl | One controlled inbound path, one controlled outbound path, unused services removed |
| 3 | Domain authentication and transport security | Reduces spoofing and downgrade risk | SPF, DKIM, DMARC working, TLS posture tested, MTA-STS considered |
| 4 | Filtering, logging and detection | Improves prevention and incident response | Centralised logs, alerting, quarantine review, tested abuse mailbox |
| 5 | Backup and migration readiness | Reduces recovery and cutover risk | Restore tested, senders inventoried, migration dependencies documented |
04Get domain authentication and transport controls into a known good state
If your domain authentication is half done, this is the point to finish it. SPF, DKIM and DMARC reduce impersonation and improve control over who can send as your domain. Internet.nl's mail test explicitly checks DMARC, DKIM, SPF, STARTTLS and related modern standards, which makes it a useful external validation pass before and after changes. Its authentication explainer also summarises why DMARC, DKIM and SPF matter together rather than as isolated DNS records.
For transport security, opportunistic TLS alone is not enough if you want stronger assurance. RFC 8461 defines SMTP MTA Strict Transport Security, MTA-STS, which lets receiving domains declare expected TLS support and certificates. RFC 8460 defines SMTP TLS Reporting, which gives you reports about failures and downgrade issues. Not every organisation needs to implement every advanced control in a six month bridge, but you should at least know your current state and whether your receiving domain can publish a clean MTA-STS policy without collateral damage.
Be disciplined here. Do not publish a strict DMARC policy if your legitimate senders are still unknown. First inventory senders, align DKIM where possible, tighten SPF, monitor reports, then move policy. The same principle applies to transport controls. Test first, enforce second. This is exactly the type of work that reduces phishing and spoofing risk now and also carries cleanly into hosted mail later.
- Validate SPF syntax and remove obsolete includes and hosts
- Enable DKIM signing for every approved outbound path
- Publish DMARC with reporting, then tighten policy in stages
- Test STARTTLS and certificate posture externally
- Assess whether MTA-STS and TLS reporting can be added safely before migration
05Improve filtering, monitoring and incident response before users become your detection system
A temporary mail platform still needs proper detection. The ISM September 2026 change material notes strengthened thinking around evidence based monitoring after remediation in the broader manual update, and ASD's hardening guidance keeps emphasising practical controls for detecting and limiting email based threats. That matters because mail compromises often show up first as odd forwarding rules, impossible travel, bursts of outbound mail, or sudden authentication failures rather than a dramatic outage.
Start by ensuring logs from the mail server, relays, spam or filtering layer, webmail, directory, and admin actions land in a central place. Then decide what you will actually alert on during the bridge period. Good short term detections include admin logins from new locations, mailbox rule creation, disabled security controls, sudden outbound volume spikes, repeated auth failures, and changes to connectors or accepted domains. If your spam or phishing filtering is still mostly default, tune it for your real traffic and review quarantine operations weekly.
Also make reporting easy. The ISM guidance is clear that policy matters, and a practical email usage policy should tell users where to report suspicious messages, how to verify payment or credential requests, and what not to bypass. If users can route around the controls by using personal webmail, the Guidelines for email explicitly say that access to non-approved webmail services should be blocked.
- Centralise mail, webmail, directory and admin logs
- Alert on mailbox rule changes, admin changes and outbound spikes
- Tune filtering against real false positives and false negatives
- Set and test an abuse or phishing reporting path
- Block non-approved webmail access from managed environments
06Do the recovery and migration preparation work that most teams leave too late
Six months is enough time to harden and still prepare a clean exit, but only if you do recovery work in parallel. The Essential Eight continues to include regular backups in ASD guidance, and that is especially relevant for self-hosted mail because restore confidence is often assumed rather than tested. Test mailbox, message store and configuration restores now, not during a ransomware event or the migration freeze window.
At the same time, prepare the move. Microsoft says there are multiple migration approaches to move mailboxes to Microsoft 365, including cutover migration for certain on premises Exchange environments and IMAP based migration for IMAP enabled systems. Microsoft notes cutover migration is suggested for supported on premises Exchange environments with fewer than 2,000 mailboxes, while IMAP migration moves mailbox content from IMAP enabled servers. On the Google side, Google documents Google Workspace Migrate and related migration requirements for larger moves.
This matters to hardening because the cleanest migrations come from cleaner source systems. If aliases, service accounts, shared mailboxes, stale connectors, and application senders are undocumented, your cutover risk increases. If you need help running the bridge and the eventual changeover as one piece of work, SyncTrix can support that through cybersecurity and risk services and adjacent mail infrastructure work.
- Test restore of mail data, configuration and authentication dependencies
- Document shared mailboxes, aliases, lists, groups and forwarding rules
- List every application, scanner and service account that sends or receives mail
- Choose the likely migration path now, Exchange cutover, IMAP, or Google migration tooling
- Set a freeze date for risky mail changes in the final month before cutover
07Questions to ask your vendor or internal team this month
If you only ask one thing, ask for evidence, not reassurance. A team that says the platform is secure should be able to show config, logs, DNS records, patch state, restore tests and a migration dependency list. This is the same mindset we use in governance and compliance work, and it is especially important when the mail stack is inherited or thinly documented.
Use this checklist in your next review. Which public endpoints exist for mail, and why. Which admin paths require MFA. Which systems can send as our domain. What is our current SPF, DKIM and DMARC alignment status. Are mail logs centralised, and what alerts are enabled. When did we last test restore a mailbox and full configuration. Which migration method are we targeting, and what source side blockers remain. Which controls would we avoid changing because they would disrupt cutover.
If the answers are vague, your first job is not optimisation. It is reducing unknowns. In a six month bridge, uncertainty itself is a security risk.
- Show me every internet facing mail related endpoint
- Show me proof of MFA on all admin and user remote access paths
- Show me all approved senders for our domain
- Show me current DNS auth records and recent validation results
- Show me the last successful restore test
- Show me the migration runbook draft and open blockers
Sources
- About the email test - Internet.nl
- Protection against email phishing (DMARC, DKIM and SPF)
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) | RFC Editor
- RFC 8460: SMTP TLS Reporting | RFC Editor
- Ways to migrate multiple email accounts to Microsoft 365 or Office 365
- What you need to know about a cutover email migration in Exchange Online
- What you need to know about migrating your IMAP mailboxes to Microsoft 365 or Office 365
- About Google Workspace Migrate
Topics
SyncTrix Editorial
SyncTrix · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.