No. It governs how other servers deliver mail to you. Protecting your outbound mail depends on the receiving domain publishing its own policy — which is a fair argument for publishing one yourself.
MTA-STS and TLS-RPT
Mail servers negotiate encryption opportunistically, which means an attacker positioned between them can often persuade both to give up and send in the clear.
STARTTLS was designed to be non-breaking, so when the handshake fails, delivery proceeds unencrypted rather than stopping. That is a sensible default for compatibility and a poor one for confidentiality.
It means a network attacker can downgrade the connection by interfering with the handshake, and the mail is delivered in plaintext with no warning to sender or recipient. This is the layer most organisations skip entirely — DMARC gets attention because spoofing is visible, while transport encryption fails invisibly.
MTA-STS publishes a policy stating that mail for your domain must be delivered over TLS to hosts you name. Compliant senders then refuse to downgrade, so a stripped connection results in a deferred message rather than a plaintext one.
The policy has to be served over HTTPS from a specific hostname with correct headers. We host that endpoint, which removes the part teams most often get wrong or leave to expire.
Enforced, not hoped for
Policy mode
Failure reporting
MTA-STS has a testing mode for a good reason, and skipping it is an avoidable mistake.
In testing mode, senders report policy failures without changing delivery behaviour. You see what would have broken — a misconfigured MX host, an expired certificate, a hostname that does not match — while mail keeps flowing normally.
TLS-RPT is what makes that useful. It gives you a daily report from each sending domain describing failed negotiations, so problems surface as data rather than as a user telling you an expected message never arrived.
Once the reports come back clean, moving the policy to enforce is a one-line change with a known outcome. That progression mirrors how DMARC should be rolled out, and for the same reason: never enforce something you have not first observed.
Something not covered here? Talk to our team.
No. It governs how other servers deliver mail to you. Protecting your outbound mail depends on the receiving domain publishing its own policy — which is a fair argument for publishing one yourself.
Daily summaries from sending domains covering TLS negotiation outcomes: successful sessions, failures, and the reason. It is how you find a certificate that expired on a secondary MX before it becomes a delivery incident.
It is not usually named explicitly, but transport encryption sits inside the general obligations most frameworks place on data in transit, and auditors increasingly ask about it. Publishing a policy is straightforward evidence.
No. The policy file must be served over HTTPS from a defined hostname with the correct content type — we host it, so there is no certificate to renew and no endpoint to forget.
