Setting up MTA-STS for Mailcow (self-hosted)

MTA-STS for Mailcow: configurable in the UI since 2025-09 — mailcow hosts the policy centrally, you only set TXT and CNAME.

Last updated: July 2026

In short: After this guide your domain enforces encrypted delivery for incoming mail to your Mailcow server. Since mailcow 2025-09 you click the policy together in the UI — mailcow hosts the policy file itself.

⚠️ Delivery risk: a faulty MTA-STS policy in enforce mode can make other servers stop delivering mail to your domain — and max_age keeps the mistake cached for days. Always start with mode: testing and review TLS-RPT reports before enforcing.

Prerequisites

mailcow version 2025-09 or newer
A domain pointing to your mailcow installation, with a valid SSL certificate (e.g. Let's Encrypt)
Access to your domain's DNS settings

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) tells other mail servers: "Deliver mail to my domain only over a valid, encrypted TLS connection." This prevents downgrade and man-in-the-middle attacks on the transport path.

The starting point at Mailcow — pleasantly simple

Here self-hosting has the advantage: unlike Google Workspace and Microsoft 365, where you have to host the policy file over HTTPS yourself, mailcow hosts the policy file centrally. You configure everything in the UI, set two DNS records — done.

This integration came about as part of the BSI initiative "E-Mail-Sicherheitsjahr 2025" (email security year 2025). Technically important: mailcow no longer creates a .well-known/mta-sts.txt file, but generates the policy dynamically. Anyone who previously placed a file manually has to switch to the UI configuration.

Step-by-step guide

1. Activate MTA-STS in the mailcow UI

Log in as administrator and go to Email → Configuration, then the Domains tab. Edit the domain (Edit) — you now see an MTA-STS tab. The options:

Version: STSv1 (currently the only one defined by the RFC)
Mode: none (monitoring only), testing (active, violations only logged) or enforce (active, "policy is active and violations are blocked")
Maximum Age: how long servers cache the policy — recommended 86400 seconds (1 day)
MX entries: your MX records, comma-separated

Tick Active and click Save changes. Start with testing, switch to enforce after analyzing the TLS-RPT reports.

2. Create the DNS records

Two entries at your DNS provider:

TXT at _mta-sts.example.com:

v=STSv1; id=2025071012

The id (format YYYYMMDDHH) must be incremented on every policy change — mailcow's docs example is v=STSv1; id=2024090101. Handy: mailcow automatically generates a new id on UI changes; the DNS check button in the UI shows the current value.

CNAME at mta-sts.example.com, pointing to your mailcow FQDN:

mta-sts.beispiel.de.    CNAME    mail.beispiel.de.

The CNAME is mandatory — only this way can a valid certificate be generated and receiving servers fetch the policy.

3. Check

Use the DNS check in the mailcow UI (blue button) to confirm that TXT and CNAME are set correctly and propagated. Additionally, the free Kuveris scanner checks the policy from the outside.

Verify the result

Check your configuration with the free Kuveris scanner — it fetches the _mta-sts record and the policy and shows them together with TLS-RPT and your TLS status.

Common mistakes

Old manual .well-known file. After the update to 2025-09, manually placed mta-sts.txt files are no longer reachable — the policy now comes from the UI configuration.

Forgot the CNAME. Without the mta-sts CNAME to the FQDN there's no certificate for the policy URL — MTA-STS doesn't take effect.

id not incremented. On manual changes, increase the id (mailcow does this itself on UI changes).

Straight to enforce. First testing, check TLS-RPT reports, then enforce.