MTA-STS — Seabhac.io

MTA-STS (RFC 8461) lets a domain tell sending mail servers to deliver only over TLS, only to the MX hosts it lists, and only when those hosts present a valid certificate. Without it, SMTP encryption is opportunistic: an attacker who strips STARTTLS from the conversation gets the mail in plain text.

Seabhac.io can host the policy for you, or monitor one you already run yourself.

Plans

	Free	Pro	Business	Enterprise
MTA-STS check monitors (self-hosted or hosted)	✓	✓	✓	✓
Hosted MTA-STS	–	✓	✓	✓

Hosted MTA-STS is available for any of your DMARC domains. Each MTA-STS check monitor counts towards your plan’s email-authentication check limit.

Enabling hosted MTA-STS

Go to DMARC → MTA-STS and click Enable hosted MTA-STS on the domain. Before anything changes, the page shows the two records you will need and what those names resolve to today.

When you confirm:

A policy is created in testing mode, covering your domain’s current MX hosts.
We publish its id in DNS.
A check monitor is created, with default alert rules, and runs once straight away.

Then add the two CNAME records at your DNS provider:

mta-sts.example.com.   CNAME  mta-sts.seabhac.io.
_mta-sts.example.com.  CNAME  example.com.seabhac.eu.

The first record lets senders fetch your policy over HTTPS from us. The second points the _mta-sts TXT lookup at the record we publish, so when the policy changes, its id changes in DNS without you editing anything.

Use the Check DNS button to confirm both records. Once both point at us, the domain is marked as verified. A TLS certificate for mta-sts.example.com is issued automatically the first time the policy is fetched.

TLS reporting

To see how senders fare when they connect to you, also add a TLS-RPT record, using your domain’s reporting address from DMARC → Setup:

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:example.com@<your reporting domain>"

Reports appear under DMARC → TLS Report, and a 14-day summary is shown on each MTA-STS domain.

Common DNS problems

The Check DNS button explains what is wrong when a record does not point at us. The usual causes:

A wildcard record answers instead. A * record at your domain also answers for mta-sts.example.com, so the name never reaches us. Add the explicit CNAME; a specific record takes precedence over the wildcard.
An old record is still there. A name with a CNAME cannot have any other records. If mta-sts.example.com still has an A record, or _mta-sts.example.com still has your own v=STSv1 TXT record from a self-hosted setup, delete it first.
The change has not propagated yet. Resolvers keep the old answer for the record’s TTL, often 30–60 minutes. The check queries DNS through a normal caching resolver, so it can show the old answer for a while after your DNS provider’s panel shows the new one.

Senders keep using a cached copy of a policy until it expires, so a short DNS problem does not cause bounces in testing mode.

Policy modes

Mode	What senders do
`testing`	Deliver as before, and report TLS problems via TLS-RPT. Hosted policies start here, with a `max_age` of 1 day.
`enforce`	Refuse to deliver unless an MX host listed in the policy offers TLS with a valid certificate.
`none`	Stop applying the policy. Used when hosted MTA-STS is disabled.

Switching a hosted policy to enforce is not available yet; it will be gated on passing checks and clean TLS reports.

MX patterns

The policy lists which MX hosts senders may deliver to. Patterns are taken from your MX records when you enable hosting, and can be edited on the MTA-STS page. A wildcard is allowed only as the whole first label, for example *.mail.example.com, and it matches exactly one label.

If an MX host is not covered by any pattern, the page and the check both warn you. In enforce mode, senders would refuse to deliver to it.

The MTA-STS check

The check monitor runs every 6 hours, from your monitor’s region. Like a sending mail server, it:

Looks up the _mta-sts TXT record and requires exactly one v=STSv1 record with a valid id.
Fetches https://mta-sts.<domain>/.well-known/mta-sts.txt. It requires a valid certificate, HTTP 200, Content-Type: text/plain and no redirects, then parses the policy.
Connects to every MX host on port 25 and upgrades with STARTTLS, requiring TLS 1.2 or newer and a certificate valid for that MX hostname.

The result shows every problem found, and per MX host: whether it is covered by the policy, the TLS version, and how many days its certificate has left.

You can add the same check for a self-hosted policy: create a monitor of type MTA-STS Policy with your domain name.

Default alert rules

Monitors created by hosted MTA-STS start with these rules, which you can change like any other alert rule:

Rule	Metric	Fires when
MTA-STS check failing	`mta_sts_valid`	the check fails 2 runs in a row
MX host not covered by MTA-STS policy	`mta_sts_uncovered_mx`	any live MX host is missing from the policy
MTA-STS certificate expiring	`mta_sts_cert_days_left`	the policy host or an MX certificate has fewer than 14 days left

Disabling

Click Disable on the domain. We switch the policy to mode: none under a new id, and keep serving it until senders’ cached copies of the previous policy have expired (its max_age). Then we remove the policy and its DNS record. The check monitor is removed straight away.

Keep both CNAME records in place until the page says the policy is gone, then delete them. A DMARC domain with hosted MTA-STS cannot be removed until hosting is disabled.