Enable MTA-STS for Secure Email Transport
Ensure email is encrypted during transfer between servers to enhance security.
Plain language
This control is about setting up a system called MTA-STS to make sure emails sent from your server to another are always encrypted. If you don't do this, sensitive information in those emails, like financial details or personal data, could be easily intercepted by cyber criminals during the transfer.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
May 2024
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for emailSection
Email gateways and serversOfficial control statement
MTA-STS is enabled to prevent the unencrypted transfer of emails between email servers.
Why it matters
Without MTA-STS, sensitive emails risk unencrypted transit, making them vulnerable to interception and exposure of confidential data.
Operational notes
Regularly verify the MTA-STS policy file and DNS record for changes or errors that could disrupt enforced TLS delivery.
Implementation tips
- IT Manager should assess the email server setup: Start by taking inventory of the email servers in use. Confirm that they support MTA-STS encryption protocols, either natively or with updates.
- IT Team should configure MTA-STS: Implement the policy by adjusting the server's settings to specify that emails can only be sent if the receiving server supports encryption. Use guides from trusted sources like the Australian Cyber Security Centre.
- Email Administrator should test the setup: Conduct tests to ensure that the email server only sends emails when they are encrypted properly. Use various scenarios to test the settings and track the test results.
- Business Owner should verify vendor compliance: If using a third-party email service, contact them to ensure MTA-STS is enabled and supported. Request written confirmation that they comply with the encryption standards.
- Security Officer should update documentation: Document the configuration changes and the testing process. This includes detailing the steps taken and any support sources consulted, like the Australian Signals Directorate guidelines.
Audit / evidence tips
-
Askthe MTA-STS policy documentation: Request the configuration document that describes how MTA-STS is implemented on the servers
Goodshows a detailed description matching official guidelines
-
Askemail server configuration logs: Request the logs that demonstrate email transactions only occur with encryption in place
Goodreveals no unencrypted transmission attempts
-
Askthe encryption compliance report: Request a report on the compliance status of the organisation's email service with MTA-STS requirements
Goodprovides recent, positive test outcomes
-
Askan email service third-party audit: Request an audit or correspondence with a third-party provider proving their compliance with encryption standards
Goodincludes confirmation from the provider on their letterhead
-
Askstaff training records: Request evidence of training given to IT staff regarding setting up and maintaining MTA-STS
Goodshows regular training and complete attendance by relevant staff
Cross-framework mappings
How ISM-1589 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (1) expand_less | ||
| Annex A 5.14 | ISM-1589 requires organisations to enable MTA-STS to prevent unencrypted SMTP transport between mail transfer agents | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.