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.
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
MTA-STS is a security standard. It lets a receiving domain publish a policy that tells sending servers:
MTA-STS uses two parts:
A DNS TXT record, published at _mta-sts.<domain> that signals support
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.
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.<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 versionmode: Can be enforce, testing, or nonemx: One or more authorized MX recordsmax_age: The number of seconds sending servers can cache the policy_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.
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.
Set a policy for authentication failures and use reporting to understand who’s sending from your domain.
Strengthen inbound delivery by requiring TLS, so senders can’t fall back to unencrypted connections.
See where TLS delivery fails, so you can pinpoint misconfigurations and recurring transport issues.
Identify lookalike domains that mimic your brand, and reduce the risk of impersonation.
Get notified of breaches early, so you can investigate quickly, respond faster, and limit the impact.
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.
_mta-sts DNS Record Used For? 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.
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.