Transport Security Guide
Transport security for email, made practical
Opportunistic TLS is better than nothing, but it can still fall back to plaintext. MTA-STS and TLS-RPT help you enforce encryption in transit and see what breaks before you flip the switch.
On this page
- What MTA-STS and TLS-RPT do (and why they matter)
- How they work together in a safe rollout
- Common failure modes that cause delivery problems
- Links to guides and tools to validate your setup
When email "TLS" isn't guaranteed
Most mail delivery on the internet uses opportunistic TLS via STARTTLS: sending servers try to negotiate encryption, and if it fails, many will still deliver the email unencrypted.
That creates two real-world problems:
- Downgrade/stripping attacks: an attacker in the middle can interfere with STARTTLS so the session falls back to plaintext (or never encrypts at all).
- Silent misconfiguration: certificates, TLS settings, or DNS changes can break encryption and you won't know which senders are failing — until users complain about missing mail.
Public guidance calls this out directly: a downgrade attack against opportunistic TLS can result in plaintext communication, not just "weaker TLS".
Reference: Australian Cyber Security Centre guidance (PDF) View PDF
What good looks like
A "good" transport security posture for inbound email usually means:
- Your domain advertises a clear stance: "TLS is required"
- Sending systems that support MTA-STS will fail closed if they can't establish a valid TLS session
- You receive automated visibility into failures, so changes don't break mail silently
- You have an operational process for MX/certificate changes (because that's where most breakage comes from)
MTA-STS and TLS-RPT in plain English
MTA-STS: "Only deliver mail to us if it's encrypted properly"
MTA-STS lets you publish a policy stating that:
- Your inbound MX hosts support TLS, and
- Senders should refuse delivery if they can't negotiate TLS with a trusted certificate.
It's designed to reduce the risk of MITM and downgrade attacks on SMTP connections.
TLS-RPT: "Tell us when TLS delivery fails and why"
TLS-RPT is how you get reports when a sender can't deliver securely (for example: invalid certs, name mismatch, STARTTLS not offered, policy mismatch).
Those reports help you detect:
- Misconfiguration (expired certs, wrong names, wrong MX)
- Potential attacks (unexpected failure patterns)
- Real-world sender compatibility issues
How they work together in practice
If you want to enforce MTA-STS without surprises:
- Enable TLS-RPT first (visibility before enforcement)
- Publish MTA-STS in testing mode and validate policy retrieval
- Fix failures reported by major senders (Microsoft, Google, large ESPs)
- Move to enforce once your failure reports are clean and stable
This is the approach recommended in UK government guidance: TLS-RPT gives you the confidence to progress MTA-STS to "enforce".
Common scenarios (quick paths)
- "We're not sure whether inbound email is always encrypted" → Start with TLS-RPT
- "We want to prevent downgrade attacks and enforce TLS inbound" → MTA-STS
- "We changed MX / migrated provider and mail started failing" → Validate MTA-STS policy + certificates
- "Our MTA-STS policy file still lists old MX hosts" → Fix policy MX alignment and re-test
The things that usually go wrong
Outdated MX entries in your MTA-STS policy
A policy that still references legacy MX hosts (for example after a migration) can trigger delivery failures for senders that honour MTA-STS.
Certificate mismatch on inbound MX
If your MX cert doesn't match the hostname (or chain is broken/expired), enforcement can cause legitimate senders to fail closed.
Policy not reachable or cached incorrectly
MTA-STS depends on retrieving a policy file over HTTPS and caching behaviour. Small hosting/config issues can cause intermittent "policy fetch" failures.
No one reads the reports
TLS-RPT and (separately) DMARC reports only help if someone is responsible for reviewing them and acting on them.
What you need before you start
- Control of DNS for the domain(s)
- A stable place to host the MTA-STS policy file over HTTPS
- Certificate management for inbound MX (and a change process)
- A mailbox or platform to receive and analyse TLS-RPT reports
- A clear owner for "mail transport security" changes
How Cydaura helps
We help teams implement MTA-STS and TLS-RPT in a way that survives real-world change (migrations, acquisitions, routing changes, certificate renewals).
That typically includes:
- Validating your current inbound TLS posture and MX/cert alignment
- Setting up TLS-RPT reporting and making the reports actionable
- Publishing and validating MTA-STS policy (testing → enforce)
- Establishing operational guardrails so future changes don't silently break mail
From start to MTA-STS enforced in 4 weeks
Working with a UK agricultural body, we helped them meet the standards set out in UK Government Guidance on email transport security by designing, implementing, testing and enforcing MTA-STS in 23 days.
The result was MTA-STS in enforce mode, full TLS-RPT visibility, and no disruption to email communications.
Why teams choose us
- Ex-Mimecast consultants with deep, hands-on experience of mail routing and operational realities
- Independent advice aligned to your objectives (not licence sales)
- Practical delivery focus: implement, validate, and leave you with a process you can run