MTA-STS and TLS-RPT: Email Privacy for Australian Businesses | Cyborium | Robert Braxton

Robert Braxton explains why MTA-STS and TLS-RPT are critical for email privacy in 2026 — and why most Australian SMEs remain exposed to SMTP downgrade attacks without knowing it.

Most conversations about email security focus on authentication — DMARC, SPF, DKIM. And that is right and proper: email impersonation is a serious and immediate threat to Australian businesses. But there is a second dimension of email security that receives far less attention and affects just as many businesses: the privacy and integrity of email in transit. Even a perfectly authenticated email can be intercepted, read, or modified if the connection between mail servers is not properly secured. That is the problem that MTA-STS and TLS-RPT are designed to solve. And as of 2026, both remain largely unimplemented across the Australian SME landscape — which means most businesses are sending email with an invisible vulnerability they are not aware of. How Email Actually Travels Between Servers When you send an email from your business account to a client, that email does not travel in a single direct connection. It passes through a chain of mail transfer agents — servers that relay the message from origin to destination. At each hop in this chain, the sending server connects to the receiving server and delivers the message. The question is: how is that connection protected? Since the 1990s, the email protocol (SMTP) has supported opportunistic encryption. "Opportunistic" means that the sending server will attempt to establish an encrypted (TLS) connection, but if the receiving server does not support TLS — or if an attacker is interfering with the connection — the sending server will fall back to an unencrypted connection rather than fail the delivery. This fallback behaviour made sense in an era when TLS adoption was incomplete and email delivery was the overriding priority. In 2026, virtually every major mail server supports TLS. The fallback is no longer necessary for legitimate communication — but it remains in place, and attackers know how to exploit it. The SMTP Downgrade Attack A downgrade attack is a man-in-the-middle technique in which an attacker intercepts the connection negotiation between two mail servers and strips out the signals that would normally trigger encrypted delivery. From the sending server's perspective, the receiving server appears to not support TLS — so it falls back to unencrypted delivery, handing the message to the attacker in plaintext. The email arrives at the intended destination, so neither the sender nor the recipient is aware that the message was intercepted. This is not a theoretical attack. Security researchers have documented SMTP downgrade attacks in multiple real-world campaigns. For businesses transmitting contracts, financial information, client data, or sensitive strategic communications by email, the exposure is material. The defences against downgrade attacks are MTA-STS and TLS-RPT. MTA-STS: Enforcing Encrypted Email Delivery MTA-STS stands for Mail Transfer Agent Strict Transport Security. It is a standard that allows a domain to publish a policy declaring: email to this domain must be delivered over a valid, verified TLS connection. If an encrypted connection cannot be established, the email should not be delivered rather than falling back to unencrypted transmission. MTA-STS works through two components: A DNS record** that advertises the existence of an MTA-STS policy for your domain. When a sending mail server looks up your MX records, it also checks for this DNS entry. A policy file** hosted at a specific HTTPS URL on your domain (https://mta-sts.yourdomain.com/.well-known/mta-sts.txt). This file specifies the policy mode and the mail servers that should be used for delivery. The policy modes are: none** — the policy exists but no enforcement action is taken (informational only) testing** — violations are reported but delivery is not blocked enforce** — delivery over unencrypted or invalid TLS connections is refused Once an MTA-STS policy is in enforce mode, sending mail servers that have previously fetched your policy know that email to your domain must be delivered securely. A downgrade attack becomes visible: the sending server has a cached record stating that TLS is required, so if TLS cannot be established, the delivery fails rather than falling back silently. TLS-RPT: Visibility Into Delivery Security Failures TLS-RPT (SMTP TLS Reporting) is the reporting companion to MTA-STS. It is a DNS record that specifies where mail servers should send reports when they encounter TLS delivery issues — failed connections, certificate problems, policy violations — when attempting to deliver email to your domain. TLS-RPT reports provide structured data that tells you: Which sending servers attempted to deliver email to your domain Whether those deliveries succeeded over TLS Where failures occurred and why Any evidence of potential downgrade attempts Without TLS-RPT, you have no visibility into the security of email delivery to your domain. With TLS-RPT, you receive regular, machine-readable reports that your security team or provider can review for anomalies. TLS-RPT does not enforce anything on its own — it is a diagnostic tool. But it is essential for understanding your email delivery security posture and for detecting potential attacks in progress. What a Domain Analysis Typically Reveals When we run domain health assessments at Cyborium and Simple Complex Solutions, MTA-STS and TLS-RPT are almost universally absent — even on domains that have properly configured DMARC, SPF, and DKIM. The reason is straightforward: awareness. DMARC, SPF, and DKIM have been widely discussed in security and IT circles for many years. MTA-STS was only standardised in RFC 8461 in 2018 and has not yet received the same level of mainstream attention — despite being equally important for organisations that transmit sensitive information by email. The other reason is complexity. MTA-STS requires both a DNS record and a hosted policy file, making it slightly more involved to implement than a single DNS record. Many businesses — and many IT providers serving those businesses — are simply not aware of the requirement. Implementation: What Is Involved Implementing MTA-STS and TLS-RPT is not technically complex, but it requires coordination between whoever manages your DNS and whoever hosts your domain's web presence. For TLS-RPT,** you add a single DNS TXT record for _smtp._tls.yourdomain.com specifying a reporting endpoint — typically a dedicated email address or a commercial reporting service. For MTA-STS,** you create a DNS TXT record for _mta-sts.yourdomain.com, then host a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This requires either a subdomain configured in your web hosting or a simple static hosting arrangement. The policy file itself is straightforward — a plain text document specifying the mode (none, testing, or enforce) and your authorised MX hosts. We recommend beginning in testing mode, reviewing TLS-RPT reports for a period of two to four weeks, and then advancing to enforce mode once you are confident that all legitimate email delivery paths are properly secured. The Privacy Case for Australian Businesses For businesses operating under the Australian Privacy Act and the Privacy Principles, the obligation to protect personal information in transit is not discretionary. Email containing client records, financial data, health information, or other personal information should be transmitted securely — and the business sending it is responsible for taking reasonable steps to ensure that security. MTA-STS, in enforce mode, provides a meaningful technical safeguard against email interception in transit. TLS-RPT provides the visibility needed to know when that safeguard is working and when it is under stress. The combination is not a silver bullet. But it closes a specific and significant vulnerability that most businesses are carrying right now without knowing it. If you are ready to assess your email security posture comprehensively — including DMARC, SPF, DKIM, MTA-STS, TLS-RPT, and BIMI — the Cyborium email security assessment delivers a complete picture and a prioritised implementation plan. Reach out through the contact page or book a call directly.