MTA-STS Management for Enterprises with Multi-Domain Environments

MTA-STS helps secure inbound email by requiring other servers to use TLS when sending to your domain. If they can’t establish a secure TLS connection, delivery fails.

In larger organizations, inbound email delivery doesn’t stay the same forever. When server configuration changes, MTA-STS needs to be updated too – otherwise you can end up with unexpected delivery problems.

Sendmarc makes it easy to implement and continuously monitor transport controls across your domains – reducing the risk of misconfigurations and keeping delivery stable.

What MTA-STS Helps You Achieve

When MTA-STS is set up correctly, it can help you:

Enforce encrypted delivery to your domain

Reduce downgrade attacks

Limit delivery to approved MX hosts

Understanding MTA-STS

MTA-STS is a security standard. It lets a receiving domain publish a policy that tells sending servers:

  • Which MX hosts are authorized for the domain
  • Whether to require TLS and a valid certificate for email delivery

MTA-STS uses two parts:

A DNS TXT record, published at _mta-sts.<domain> that signals support

A policy file hosted over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt

MTA-STS is commonly paired with TLS-RPT, which gives you aggregated reports when senders can’t deliver to you securely.

How MTA-STS Works in Three Steps

A sending server checks for
_mta-sts.<domain> in the DNS

If present, it fetches the policy file from the web server

The sending server follows your company’s policy

MTA-STS Record and Policy Basics

MTA-STS DNS TXT Record

The MTA-STS TXT record lives at _mta-sts.<domain> and includes:
v=STSv1

id=<policy-id>

MTA-STS TXT record example:

Host: _mta-sts.yourdomain.com

Type: TXT

Value: v=STSv1; id=<policy-id>

A typical policy includes:

  • version: The policy version
  • mode: Can be enforce, testing, or none
  • mx: One or more authorized MX records
  • max_age: The number of seconds sending servers can cache the policy

TLS-RPT DNS TXT Record

TLS-RPT is published as a TXT record at _smtp._tls.<domain> and typically includes:
v=TLSRPTv1

rua=mailto:...

TLS-RPT DNS record example:

Host: _smtp._tls.yourdomain.com

Type: TXT

Value: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com

Sendmarc helps you implement MTA-STS and TLS-RPT across your domains, then keep them maintained as your inbound email setup evolves – so transport security stays reliable, and delivery doesn’t suffer.

Why MTA-STS Projects Stall

Common reasons MTA-STS projects slow down include:
  • MX record changes during migrations: Inbound routing shifts, so policies drift out of date.
  • Policy hosting and certificate dependencies: The policy must stay reachable over HTTPS, and certificate renewal failures can cause delivery issues.
  • Limited visibility without TLS-RPT: Without reports, TLS failures look like unexplained delivery problems and take longer to diagnose.
Laptop Displaying Warning Alert Symbol

Protect Against Identity-Based Attacks

Impersonation typically takes three forms: Direct spoofing, lookalike domains, and compromised accounts.

Sendmarc helps reduce risk across all three by giving teams a shared view of authentication posture and identity-based threat activity.

SPF

Keep your approved sending sources accurate as platforms, vendors, and business units change.

Confirm outbound email is signed correctly, so receivers can verify message authenticity.

Set a policy for authentication failures and use reporting to understand who’s sending from your domain.

MTA-STS

Strengthen inbound delivery by requiring TLS, so senders can’t fall back to unencrypted connections.

TLS-RPT

See where TLS delivery fails, so you can pinpoint misconfigurations and recurring transport issues.

Lookalike Domain Defense

Identify lookalike domains that mimic your brand, and reduce the risk of impersonation.

Breach Detection

Get notified of breaches early, so you can investigate quickly, respond faster, and limit the impact.

MTA-STS FAQs

What is MTA-STS?

MTA-STS is a standard that lets a receiving domain publish a policy requiring sending servers to use TLS when delivering email to that domain.

Yes, MTA-STS is necessary for organizations that prioritize email security and compliance. It helps prevent cyberattacks by ensuring messages are only delivered over encrypted channels.

The _mta-sts DNS record is used to signal that your domain supports MTA-STS and to publish an id value that indicates the current policy version.

MTA-STS offers three policy modes:
  • enforce: Emails are only delivered if a secure TLS connection can be established.
  • testing: Reports issues but allows delivery even if TLS can’t be established.
  • none: No policy is enforced; the standard is effectively inactive.

TLS-RPT is a reporting standard that lets senders provide aggregated reports when they can’t deliver to your domain securely. TLS-RPT isn’t required for MTA-STS, but TLS-RPT makes it much easier to spot and troubleshoot delivery failures tied to TLS.

MTA-STS works alongside SPF, DKIM, and DMARC to create a comprehensive email security strategy. While SPF, DKIM, and DMARC authenticate the sender and protect against spoofing, MTA-STS secures the transport layer by enforcing encryption during email delivery.