Is Email Always Encrypted in Transit? What MTA-STS Changes

When somebody outside your organisation sends you an email, their email provider must find the servers that receive mail for your domain and decide whether it can use a trusted encrypted connection to reach them.

Modern email services will normally try to use encryption while transferring messages between mail servers. However, encrypted delivery is not always a strict requirement. Traditional email delivery was designed to keep messages moving between many different providers and older systems, so ordinary SMTP delivery may sometimes continue when a secure connection cannot be established.

STARTTLS allows an SMTP connection to be upgraded to encryption. The limitation is that ordinary opportunistic TLS does not always tell the sending service in advance that encryption is mandatory, which receiving mail servers are approved or whether delivery must stop when certificate checks fail.

MTA-STS allows the owner of a receiving domain to publish those requirements. It tells compatible sending services that email should be delivered only to approved receiving servers through a trusted and authenticated TLS connection.

For a small organisation, reviewing MTA-STS is not normally a single switch inside Microsoft 365 or Google Workspace. The work can involve checking DNS and MX records, every gateway or filtering service that receives mail, certificate hostnames, an HTTPS-hosted policy, TLS reporting, testing periods and future provider changes.

Evening Computing’s work in this area is an advanced email-security and configuration review. This may include mapping the real inbound mail path, checking DNS and provider dependencies, planning a testing period, interpreting reports and coordinating changes with email, DNS, filtering and hosting suppliers. Enforcement should be based on the organisation’s actual configuration rather than copied from a generic example.

This guide explains what MTA-STS changes, what happens when a sender does not support it, why testing and reporting matter and how it differs from SPF, DKIM, DMARC and DANE.

MTA-STS should not be treated as proof that email is currently being intercepted. It is an additional email-transport assurance control that normally sits alongside email authentication, account protection, filtering, monitoring, backup and recovery.

Use the links below to jump to the section most relevant to your question.

• Is email always encrypted in transit?
• What is MTA-STS?
• How email delivery and STARTTLS normally work
• What problem does MTA-STS try to reduce?
• How MTA-STS works
• Why MTA-STS is mainly an inbound-domain policy
• What happens when a sender does not support MTA-STS?
• Why TLS-RPT reporting matters
• Why MTA-STS should normally be tested before enforcement
• What happens when MTA-STS validation fails?
• STARTTLS, MTA-STS and DANE compared
• How MTA-STS differs from SPF, DKIM and DMARC
• What MTA-STS does not protect against
• Is lack of MTA-STS proof that email is being intercepted?
• When should a small organisation review MTA-STS?
• How MTA-STS fits into layered email security
• Related email security guides
• Supporting references
• Further Guidance and Support

Email between modern providers is often transferred using TLS encryption, but ordinary email delivery does not always make encryption a strict requirement.

SMTP was created before encrypted transport became a normal expectation. STARTTLS was added later so that two mail servers could upgrade an existing connection to TLS where both systems supported it.

This approach improved email privacy while preserving compatibility with older systems. However, it is commonly opportunistic. The sending service may try to use encryption but may still continue delivery if a secure connection cannot be established and its own rules permit fallback.

The sender may also establish an encrypted connection without having a previously published policy confirming:

• • Which receiving mail servers are authorised.
  • Whether TLS is mandatory.
  • Whether the receiving certificate must be publicly trusted.
  • Whether the certificate must match the receiving server’s hostname.
  • Whether delivery must stop if those checks fail.

MTA-STS provides that additional policy layer for sending services that support it.

It does not mean that every message was previously sent without encryption. It means that ordinary STARTTLS alone may not provide the same strict, previously published delivery requirements.

MTA-STS stands for Mail Transfer Agent Strict Transport Security.

It is an email transport security standard that allows the owner of a receiving domain to publish a policy describing how compatible sending services should deliver email to that domain.

An enforced policy tells a supporting sender that:

• • TLS must be used for the connection.
  • The receiving mail server must present a valid and trusted certificate.
  • The certificate must contain a valid identity matching the MX hostname used for delivery.
  • The receiving server must be one of the mail hosts permitted by the published policy.
  • The sender should not fall back to weaker delivery if those checks fail.

MTA-STS does not create a different email-message format. The message remains an ordinary email. The standard controls the server-to-server connection used to deliver it.

MTA-STS is therefore mainly concerned with the route and connection used for inbound email. It does not establish whether the visible sender is genuine and does not replace SPF, DKIM or DMARC.

When an email is sent, the sending mail service looks up the destination domain’s MX records. These DNS records identify the servers that are responsible for receiving email for the domain.

The sending service then connects to one of those servers using SMTP. The receiving server may advertise support for STARTTLS, which allows the existing connection to be upgraded from an ordinary SMTP session to a TLS-encrypted session.

Where both services support appropriate TLS, the remaining SMTP conversation and message transfer can take place over the encrypted connection.

This is commonly called opportunistic TLS. The sending server attempts to use encryption when it is available, but ordinary SMTP compatibility may allow delivery to continue when encryption cannot be established.

That behaviour exists because email has to operate between many different providers, servers and legacy systems. Historically, refusing every message when TLS was unavailable could have prevented legitimate email from being delivered.

The limitation is that the sending service may not always know why encryption is unavailable. The cause could be a temporary configuration problem, an invalid certificate, a legacy server or deliberate interference with the connection.

MTA-STS is designed to reduce two related email-transport risks: removal of the STARTTLS offer and redirection towards an unexpected receiving server.

These risks occur before the message reaches the intended mailbox. The receiving organisation may therefore have limited visibility unless the sending service reports what happened.

STARTTLS downgrade or stripping

SMTP delivery normally begins before TLS has been negotiated. The receiving mail server can then advertise STARTTLS so that the connection is upgraded to encryption.

A normal opportunistic path may look like this:

Sending mail server
↓
Connects to receiving mail server
↓
Receiving server advertises STARTTLS
↓
TLS connection is established
↓
Email is transferred over the encrypted connection

A downgrade or stripping attempt changes that path:

Sending mail server
↓
STARTTLS is offered by the receiving server
↓
Something in the network path removes or alters that offer
↓
Sending server believes TLS is unavailable
↓
Without a previously known strict requirement, ordinary SMTP rules may permit fallback

MTA-STS changes the sender’s decision where a valid policy has already been discovered:

Sender knows the receiving domain requires authenticated TLS
↓
STARTTLS, certificate or approved-MX requirements cannot be satisfied
↓
The sender should not silently fall back to weaker delivery

Documented research has shown that STARTTLS stripping has occurred on real networks, so the weakness is not purely theoretical. However, a TLS failure does not by itself show that deliberate interference has occurred. Configuration faults, certificate problems and provider changes can produce similar symptoms.

Redirection towards an unexpected mail server

Email delivery also depends on DNS MX records. If a sender is given incorrect or manipulated MX information, it could be directed towards a server that is not genuinely authorised to receive email for the destination domain.

An unexpected server could still offer encryption. Encryption alone would not establish that the server is the correct destination.

MTA-STS allows the receiving domain to publish the expected mail-server hostnames. A compatible sender can then compare the server it reaches with the hosts permitted by the policy.

This helps reduce the risk of delivery being redirected towards a different server without the sender recognising that the destination has changed.

Certificate and configuration failures

Even when a receiving mail server offers TLS, encryption alone is not enough. The sending system also needs a way to establish that the server it has reached is entitled to identify itself as the expected receiving mail server.

MTA-STS relies on the public certificate trust system for this part of the check. A compatible sending service can check that:

• the receiving server presents a valid certificate

• the certificate chains to a trusted public Certificate Authority

• the certificate has not expired

• the identity in the certificate matches the MX hostname being used for delivery.

A simplified check is:

Reached mail server
↓
TLS certificate presented
↓
Is the certificate trusted and valid?
↓
Does its identity match the expected MX hostname?
↓
Does that MX hostname also appear in the MTA-STS policy?

These are related checks, but they answer different questions. The certificate helps authenticate the server identity, while the MTA-STS policy tells the sender which receiving server identities the domain has declared acceptable.

A certificate or policy failure is not automatically evidence of an attack. Provider changes, missing mail-server entries, expired certificates and configuration errors can produce the same type of failure.

MTA-STS uses a DNS discovery record together with a policy file hosted over HTTPS.

The DNS record signals that a policy exists and identifies its current version. The HTTPS file contains the actual policy, including the permitted receiving mail servers and the operating mode.

The MTA-STS DNS discovery record

The discovery record is published as a TXT record at:

_mta-sts.example.org

A typical record may contain:

v=STSv1; id=20260802T120000;

The v value identifies the version of the standard.

The id value identifies the current version of the policy. It does not need to be a sequential number, but it must change whenever the policy file changes.

A compatible sending service can compare the current ID with the value it saw previously. If the ID is different, the sender knows that it should retrieve the policy file again.

Using a date and time as the ID is one practical way of showing when the policy was changed.

The HTTPS policy file

The policy file is published at a fixed address:

https://mta-sts.example.org/.well-known/mta-sts.txt

A testing policy may contain:

version: STSv1

mode: testing

mx: mail.example.org

max_age: 86400

The policy contains:

• • The policy version.
  • The operating mode.
  • One or more permitted MX hostnames.
  • The length of time for which the sender may cache the policy.

The valid policy modes are:

• • testing
  • enforce
  • none

In testing mode, compatible sending services may continue delivery as though there were no MTA-STS validation failure. Where the sender also supports TLS-RPT and the receiving domain has published a reporting record, the failure can be included in an aggregate report.

Enforce mode tells compatible senders not to deliver when the required TLS, certificate and permitted-MX checks cannot be satisfied.

The none mode is normally used when a domain is withdrawing MTA-STS in a controlled way. It does not provide active transport enforcement.

The example values must not be copied directly into a live domain. The MX entries must match the organisation’s real email-routing arrangement, including any filtering provider, continuity service, gateway or intermediary that receives mail before the main email platform.

Policy caching and max_age

The max_age value tells sending services how long the policy may remain cached.

Caching is important because it gives the policy a memory effect. Once a supporting sender has retrieved the policy, temporary interference with DNS or the HTTPS policy host does not necessarily remove the previously learned requirements immediately.

A longer cache period can strengthen continuity of the policy, but it also increases the consequences of publishing an incorrect enforced configuration. A sender may continue using a cached policy until it refreshes it or the policy expires.

For this reason:

• • Testing normally uses a shorter cache period.
  • The policy ID should change whenever the file changes.
  • When a policy is changed, the revised HTTPS policy file should be published first and the DNS id should be changed afterwards. This reduces the risk of a sending service seeing the new ID but retrieving and caching the previous policy file.
  • Provider migrations and MX changes should be coordinated with the policy.
  • Enforcement should not begin until the published mail routes have been confirmed.

Why the first successful policy retrieval matters

MTA-STS does not use DNSSEC to authenticate its DNS discovery record. On an initial contact, a sender that has never previously obtained the domain’s policy does not yet have a cached MTA-STS requirement to rely on.

Once a compatible sender has successfully retrieved and cached a valid policy, the situation changes:

First contact
Sender discovers and retrieves the policy
↓
Policy cached
Sender now remembers the published requirements for the max_age period
↓
Later delivery attempt
Unexpected DNS, certificate, MX or TLS conditions can be checked against those previously learned requirements

This is why caching is an important part of the MTA-STS design. It strengthens protection after policy discovery, but MTA-STS should not be described as removing every possible first-contact or policy-discovery risk.

What the sending service checks

When a compatible sender applies an enforced MTA-STS policy, it checks that:

• • The connection uses TLS.
  • The receiving server presents a certificate issued through a trusted public certificate chain.
  • The certificate is valid and has not expired.
  • The certificate contains a valid identity matching the MX hostname used for delivery.
  • The receiving server matches one of the hosts permitted by the policy.

UK implementation guidance expects receiving mail infrastructure to support TLS 1.2 or higher. The MTA-STS policy file itself does not contain a setting that selects the TLS version. Supported versions are controlled by the sending and receiving mail infrastructure and any separate provider or organisational requirements.

The organisation receiving email publishes the MTA-STS policy.

For example, the owner of example.org publishes a policy describing how messages addressed to people at example.org should be delivered.

The external sending service is responsible for discovering, retrieving and applying that policy.

This means:

• • Publishing MTA-STS principally helps protect email arriving at the domain.
  • It does not automatically impose the same requirements on messages sent by the organisation.
  • Outbound protection depends on the sending provider checking policies published by recipient domains.
  • The sender and receiver do not need to use the same email provider.
  • Support by sending services is required for the policy to have an effect.

The receiving provider does not necessarily offer a simple MTA-STS switch. The domain owner may publish the required DNS and HTTPS information where the provider’s receiving servers, certificates and documented hostnames satisfy the policy requirements.

Where MX records point to a third-party email-security gateway, filtering service, forwarding service or continuity provider, that intermediary becomes part of the delivery path. Its documented MTA-STS values and certificate arrangements must be reviewed rather than assuming that generic Microsoft 365 or Google Workspace values apply.

Publishing an enforced MTA-STS policy does not normally cause the receiving mail server to reject every message from a sender that does not support the standard.

MTA-STS is applied by the sending mail service. It is not a special message format and it is not normally a receiving-mailbox rule that checks whether the sender understands MTA-STS.

There are three main situations.

The sending service supports MTA-STS and validation succeeds

The sender retrieves or uses the cached policy, connects to a permitted MX server, validates the certificate and delivers the message over TLS.

The sending service supports MTA-STS and validation fails

The sender should not ignore the enforced policy and fall back to weaker delivery.

It may try another permitted receiving server, queue the message and try again later. If the problem continues, the sending service may eventually return a non-delivery report to the sender.

The intended receiving server does not normally accept the message and then silently drop it. In many cases, the message has not yet reached that server because the sending service stopped before completing delivery.

The sending service does not support MTA-STS

The sender does not retrieve or apply the MTA-STS policy.

It uses its normal SMTP delivery process. That process may still use opportunistic TLS, but it will not provide the additional MTA-STS policy validation.

If TLS cannot be established and the sender’s own rules permit fallback, the message could potentially be delivered without encryption.

The receiving system will normally accept the message if it meets the provider’s ordinary mail-flow and security requirements.

A receiving organisation can separately configure a gateway, connector or mail-flow rule that requires TLS and rejects non-TLS delivery. That is a different control and may affect senders that cannot meet the requirement. It should not be confused with the normal effect of publishing an MTA-STS policy.

TLS-RPT stands for SMTP TLS Reporting.

It allows a receiving domain to request aggregated reports from compatible sending services about TLS and policy conditions encountered while attempting to deliver email.

These are aggregate transport reports. They contain connection, policy and failure information rather than the contents of individual email messages.

The reporting record is published as a TXT record at:

_smtp._tls.example.org

A typical record may contain:

v=TLSRPTv1; rua=mailto:[email protected]

The reports are normally supplied in structured JSON format and may include:

• • Aggregate counts of successful and failed TLS sessions.
  • TLS not being offered by a receiving mail server.
  • Certificates that are expired or untrusted.
  • Certificates that do not match the receiving MX hostname.
  • Receiving MX hosts that do not satisfy the MTA-STS policy.
  • MTA-STS policy retrieval or validation failures.
  • Other TLS negotiation or validation failures reported by the sending service.

TLS-RPT is particularly useful because the problem occurs on the sending side of the connection. The intended receiving organisation may not otherwise know that an external sender was unable to establish the expected secure delivery path.

A report identifies a condition that needs review. It does not automatically establish the cause.

The same type of report could result from:

• • A certificate-renewal problem.
  • A provider migration.
  • An omitted MX server.
  • An unavailable mail gateway.
  • An incorrect policy.
  • A temporary routing problem.
  • Deliberate interference.

Reports should be reviewed during testing and should continue to be monitored after enforcement. For organisations receiving many reports or operating several domains, a reporting platform may be more practical than attempting to interpret raw JSON attachments manually.

An incorrect MTA-STS policy can interfere with legitimate inbound email when supporting senders apply it in enforce mode.

Testing mode allows the organisation to observe possible failures before asking compatible senders to stop delivery when validation cannot be completed.

A staged implementation should normally include the following steps.

1. 1. Identify every domain and subdomain that receives email.
   2. Confirm the current MX records and the real servers or services reached by external senders.
   3. Identify any email gateway, spam-filtering service, continuity platform, forwarding service or hybrid server in the delivery path.
   4. Check that every permitted receiving server supports the expected TLS configuration and presents a valid hostname-matched certificate.
   5. Configure TLS-RPT reporting.
   6. Publish the MTA-STS policy in testing mode with a shorter cache period.
   7. Review reports for recurring certificate, policy, DNS, routing or MX-host problems.
   8. Correct the identified issues and update the policy ID whenever the policy file changes.
   9. Remain in testing long enough to observe normal mail flow and relevant provider behaviour.
   10. Move to enforce mode only after the results and operational dependencies have been reviewed.
   11. Continue monitoring reports after enforcement.

The appropriate testing period depends on the organisation’s mail volume, providers, routing complexity and business requirements. A domain receiving very little mail may need more time to gather meaningful evidence than a high-volume domain.

Testing does not guarantee that every future provider change will be detected in advance. Certificates, server hostnames, filtering arrangements and continuity routes can change later, so continued ownership and periodic review remain necessary.

When an MTA-STS-aware sender finds an enforced policy but cannot satisfy it, the sender should not continue by silently using an unencrypted or unauthorised route.

A validation failure may occur because:

• • The reached MX host is not permitted by the policy.
  • The receiving server does not offer the required TLS connection.
  • The server certificate has expired.
  • The certificate is not trusted.
  • The certificate does not match the server hostname.
  • A mail provider or gateway has changed its infrastructure without a corresponding policy update.

The sending service may first try another MX host that is permitted by the policy.

If no suitable route is available, it will normally queue the message and retry later. This allows time for a temporary certificate, service or routing problem to be corrected.

If the failure continues for long enough, the sender may receive a non-delivery report.

This behaviour is intentional. In enforce mode, the policy tells compatible senders that weaker delivery is not an acceptable substitute.

It is therefore important to distinguish between:

• • The receiving server rejecting an accepted message.
  • The sending service deferring delivery before the message is accepted.
  • The sending service eventually returning a non-delivery report.

MTA-STS failures will often involve the second or third situation rather than a message being accepted and then lost without explanation.

STARTTLS, MTA-STS and DANE all relate to email transport security, but they do not use the same mechanism or trust model.

They should not be treated as interchangeable names for the same control.

MTA-STS

MTA-STS uses a DNS discovery record and an HTTPS-hosted policy.

The policy identifies the permitted MX hostnames and tells compatible senders whether the domain is using testing or enforcement.

It relies on HTTPS and publicly trusted certificates. It does not require the receiving domain to deploy DNSSEC.

The sender must first discover and retrieve the policy. Once retrieved, the policy can be cached for the period defined by max_age.

STARTTLS

STARTTLS allows an SMTP connection to be upgraded to TLS after the initial connection has been established.

It provides encryption when the two mail services successfully negotiate an appropriate TLS session.

Ordinary opportunistic STARTTLS does not necessarily tell the sender in advance that TLS is mandatory, which receiving hostnames are approved or whether the sender must stop rather than fall back.

DANE for SMTP

DANE uses DNSSEC-protected TLSA records to publish the expected certificate or public-key information for a receiving mail server.

Its trust model is based on the DNSSEC chain rather than an HTTPS policy and the public web certificate-authority system.

DANE can provide authenticated information on the initial delivery attempt when the DNSSEC chain and TLSA records are valid.

However, it depends on:

• • Correct DNSSEC operation.
  • Provider support.
  • Control of the relevant MX hostnames.
  • Accurate TLSA records.
  • Coordination of certificate and key changes.

Where a hosted email provider controls the receiving server hostnames and does not offer customer DANE deployment, the customer cannot safely create TLSA records for those provider-controlled systems.

Are MTA-STS and DANE alternatives?

They address related risks through different trust mechanisms and can be complementary.

DANE should not be presented as universally better simply because it avoids some of the initial policy-discovery limitations associated with MTA-STS. Its DNSSEC, TLSA and certificate-management dependencies also need to be maintained correctly.

For many small organisations using hosted email, MTA-STS may be the more practical control because it uses familiar DNS and HTTPS components and does not require control of the provider’s TLSA records.

The appropriate choice depends on provider support, DNSSEC, mail-routing control and the organisation’s ability to maintain the configuration.

SPF, DKIM and DMARC help receiving systems assess whether a message is authorised to use a domain.

MTA-STS addresses a different question: how compatible sending services should protect the connection used to deliver email to the receiving domain.

SPF

SPF publishes which sending systems are authorised to send email using a domain’s envelope sender.

It does not secure the transport connection used to deliver inbound email.

DKIM

DKIM adds a cryptographic signature to a message.

The receiving service can use a public key published in DNS to verify the signature and determine whether the signed parts of the message have been altered.

DKIM does not publish the receiving domain’s TLS requirements.

DMARC

DMARC uses SPF and DKIM results and checks whether the authenticated domain aligns with the domain shown in the visible From address.

It also allows the domain owner to publish a policy requesting monitoring, quarantine or rejection when the required alignment checks fail.

DMARC is concerned with domain authentication and handling policy, not the security of the SMTP transport connection.

MTA-STS

MTA-STS tells compatible senders which receiving mail-server hostnames are permitted and that an authenticated TLS connection should be required.

In simple terms:

• • SPF, DKIM and DMARC help determine whether a message is authorised to use a domain.
  • MTA-STS helps protect the server-to-server delivery connection and confirms that the receiving MX host matches the domain’s published policy.

These controls complement one another, but none replaces the others.

MTA-STS has a specific transport-security purpose. It should not be presented as complete email protection.

MTA-STS does not:

• • Provide end-to-end encryption of the message.
  • Prevent the sending or receiving email provider from accessing message content.
  • Authenticate the person who wrote the message.
  • Prevent direct-domain spoofing by itself.
  • Replace SPF, DKIM or DMARC.
  • Protect a compromised mailbox.
  • Prevent account takeover.
  • Detect all phishing or impersonation attempts.
  • Scan links or attachments for malicious content.
  • Protect messages stored inside a mailbox or cloud platform.
  • Provide backup or recovery.
  • Protect delivery from sending services that do not support MTA-STS.
  • Correct an invalid certificate or incorrect mail-server configuration.
  • Remove every possible first-contact, DNS or certificate-authority risk.
  • Guarantee that every email connection will always succeed securely.

It protects one part of a wider email system: the server-to-server transport connection used by participating services.

A useful boundary is:

MTA-STS
protects the expected transport path between participating mail services

SPF, DKIM and DMARC
address domain authentication and alignment

Mailbox and identity security
protect access to accounts and administrative services

Filtering and endpoint protection
help address harmful content and behaviour

Backup and recovery
provide options when information or services need to be restored.

Strength in one of these areas does not remove the need to consider the others.

No.

The absence of MTA-STS means that the domain has not published this particular strict transport policy.

It does not prove that:

• • Email is currently being intercepted.
  • Messages are routinely being delivered without encryption.
  • Someone has read or altered a message in transit.
  • The organisation has experienced a security incident.
  • The email provider is insecure.
  • Every message sent to the domain is exposed.

Many email providers use opportunistic TLS for ordinary delivery even where the recipient domain does not publish MTA-STS.

MTA-STS adds stronger assurance for compatible senders by stating that they should not fall back silently when the published TLS, certificate and receiving-host conditions cannot be met.

The absence of the control should therefore be treated as a configuration and assurance question rather than evidence of compromise.

Similarly, a TLS-RPT failure should be investigated but should not automatically be described as an attempted attack. Operational errors and deliberate interference can produce similar symptoms.

MTA-STS is normally an advanced email-transport control rather than the first email-security change an organisation should make.

It is generally sensible to understand the more fundamental controls first, including SPF, DKIM, DMARC, mailbox security, multifactor authentication, account recovery, filtering, monitoring and backup.

MTA-STS may be worth reviewing where:

• • Email is operationally important to the organisation.
  • Messages regularly contain confidential, legal, financial, safeguarding or commercially sensitive information.
  • SPF, DKIM and DMARC have already been reviewed.
  • The organisation wants additional assurance over inbound email transport.
  • The current MX records and receiving mail routes are understood.
  • The email provider documents suitable MTA-STS values or requirements.
  • DNS and HTTPS policy hosting can be maintained.
  • Someone is responsible for reviewing TLS-RPT reports.
  • Provider, certificate and mail-routing changes can be coordinated.

Enforcement may need to be delayed where:

• • Active and backup MX routes are not fully understood.
  • A third-party gateway or continuity service has not been accounted for.
  • Certificates or receiving hostnames are unstable.
  • The organisation cannot review reports.
  • A provider migration is imminent.
  • The organisation does not control the required DNS or policy-hosting components.
  • The email provider does not support a suitable implementation.

The decision should be proportionate to the organisation’s actual mail environment and its ability to maintain the policy, not based only on whether an online checker reports that the record is absent.

Because the correct configuration depends on the domain’s actual MX records, email provider, certificates and any filtering, forwarding or continuity services, these parts should be reviewed together before an enforced policy is published. Changing one record in isolation can produce misleading test results or affect delivery for sending services that apply the policy.

Email security depends on several connected controls because different problems occur at different stages.

A layered email-security approach may include:

• • SPF to identify authorised sending systems.
  • DKIM to add a verifiable message signature.
  • DMARC to check alignment and publish a handling policy.
  • STARTTLS to provide encrypted transport where supported.
  • MTA-STS or DANE to add stricter transport assurance where appropriate.
  • TLS-RPT and DMARC reporting to provide visibility.
  • Multifactor authentication or passkeys to protect account access.
  • Appropriate filtering for malicious links, files and impersonation attempts.
  • Separate administrator accounts and restricted privileges.
  • Mailbox auditing and monitoring.
  • Independent backup and tested recovery.
  • Clear ownership of DNS, providers, gateways and third-party sending services.

No single DNS record, mail gateway, authentication method or security product addresses every part of email security.

MTA-STS is most useful where the organisation already understands its email environment and can maintain the policy as certificates, mail routes and providers change.

This guide is designed around the enduring purpose of MTA-STS rather than one provider’s current interface or implementation. The mechanism remains the same: a receiving domain publishes transport requirements that compatible sending services can discover, remember and enforce.

The implementation around that mechanism can change. Providers, certificates, MX routes, gateways, reporting behaviour and supported standards should therefore be reviewed periodically.

An MTA-STS configuration is not something to publish and forget. Its value depends on the published policy continuing to describe the organisation’s real receiving-mail environment.

The following Evening Computing guides provide supporting information about email authentication, DNS security, account protection and recovery.

Email validation and security explained

How to read a DMARC record and choose the right policy

Why DNSSEC matters and how DNS attacks can redirect internet traffic

What is layered security and why does it matter

How do cyber attacks usually start in small businesses?

Are passkeys and security keys the same thing?

Cloud Storage vs Backup. Why Sync Is Not Backup

The following sources support the technical standards, implementation principles and documented examples used in this guide.

UK National Cyber Security Centre: Using MTA-STS to protect the privacy of your emails

GOV.UK: Using the Mail Transfer Agent Strict Transport Security protocol in your organisation

RFC 8461: SMTP MTA Strict Transport Security

RFC 8460: SMTP TLS Reporting

Google Workspace Help: About MTA-STS and TLS reporting

Microsoft Learn: Enhance mail flow with MTA-STS

APNIC Blog: SMTP downgrade attacks and MTA-STS

Electronic Frontier Foundation, 2014: historical report on observed STARTTLS stripping by network providers

Hardenize: Introducing MTA Strict Transport Security

MTA-STS is an advanced email-transport control and should be considered within the organisation’s wider email, DNS, cloud-service and security arrangements.

For help reviewing Microsoft 365, Google Workspace, DNS, inbound mail gateways or related cloud-service configuration, see our Cloud Solutions page.

For broader guidance on layered protection, monitoring, backup and continuity, see our Security and Resilience page.

Where an organisation is considering MTA-STS testing or enforcement, Evening Computing can review the current mail path, provider dependencies and reporting requirements before changes are made.

Tell Us About Your Email Security or Configuration Requirements

Return to all guides

Author
Elías Sánchez
IT Support Consultant
Evening Computing

This guide was prepared by Elías Sánchez with research and drafting assistance from AI tools. All technical content has been reviewed and adapted for clarity and accuracy.

Last reviewed
17 August 2026