You can now require encryption on mail sent to your domain - carefully

Five days ago we shipped TLS reporting and said the point of it was to make it safe to require encryption later, rather than merely prefer it. That is now on offer.

What it does

MTA-STS publishes a policy that tells every other mail server two things about mail addressed to your domain: it must be delivered over an encrypted connection, and it may only be delivered to the mail servers you name. A server that cannot do both stops rather than falling back to sending in the clear.

Hosting that policy is the reason most products skip this - it has to be served over HTTPS on a subdomain of your domain, with a valid certificate. We do that for you. You publish two DNS records, we serve the policy and issue the certificate, and there is nothing to renew.

Why it starts in testing, and stays there until you have evidence

This is the only setting in Solstral that governs mail arriving at your domain rather than mail you send. Everything else on that screen affects your own campaigns; this affects invoices from your accountant, replies from your customers, and password resets from every other service you use. Get the mail-server list wrong and those messages are refused - not bounced back to you, but rejected at somebody else's server, silently.

So it opens in testing mode, where senders report failures and deliver anyway. All of the visibility, none of the risk. Turning on enforcement is a separate, deliberate step, and the button stays disabled until your TLS reports show a clean run - no failed connections, over a real window, with actual traffic behind it. If there is no evidence yet, the answer is no. Same order we take with DMARC: evidence before enforcement.

The list is on screen before anything is published

The mail servers your policy will permit are read from your own MX records and shown to you, by name, before you publish. That list is the whole blast radius, and you are the one who can tell at a glance whether it looks right.

We re-check it every day afterwards. If you move mail provider - Google Workspace to Microsoft 365, say - your MX changes, and a stored policy naming the old servers would become your outage. We notice, rebuild the policy and re-announce it so senders pick up the new list instead of enforcing the old one. If we cannot look your records up on a given day, we leave the policy exactly as it was rather than guessing.

Turning it off is a thing that happens, not a thing you delete

Deleting the DNS records does not cancel a policy. A sender that cannot fetch a policy keeps using the one it already has - so removing the records early locks in whatever was last published, for up to a week, with no way for anyone to reach it.

Switch off therefore publishes a withdrawal, and the screen tells you the date the records can safely come down. The Remove button is disabled until then. It is one of the few places in the product where we make you wait, and it is the difference between changing your mind and being stuck with it.