SMTP encryption that does not silently fall back to plaintext when an attacker says please.
MTA-STS policy, TLS-RPT reporting, certs that renew themselves, optional DANE for DNSSEC zones.

A one-time engagement deploying the full SMTP transport security stack on your sending and receiving infrastructure. The deliverables: valid TLS certificates from a recognised Certificate Authority (Let's Encrypt by default, commercial CA available on request) covering MX hostnames and the mta-sts subdomain; certificate renewal automation through certbot or equivalent with 30-day pre-expiry alerts; MTA-STS policy hosting at the required HTTPS endpoint with the mode set to testing initially; DNS configuration for _mta-sts and _smtp._tls TXT records; TLS-RPT receiving mailbox setup with aggregate report parsing; phased transition from testing to enforce mode after 14-30 days of clean TLS-RPT data; optional DANE TLSA records published for DNSSEC-signed zones; documentation covering certificate locations, renewal procedures, policy versioning, and incident response. One-time engagement EUR 249, delivery in 3 business days.

Standard SMTP encryption is opportunistic. According to RFC 3207, a sending mail server attempts STARTTLS, accepts whatever certificate the receiving server presents (including self-signed or expired ones), and falls back to plaintext if anything fails. A man-in-the-middle attacker can strip the STARTTLS advertisement from the SMTP handshake and both servers will deliver mail in cleartext without either side noticing. This is called a downgrade attack. MTA-STS (RFC 8461) fixes this by letting your domain publish a policy that says: when you deliver email to my domain, you must use TLS with a valid certificate from a trusted CA matching my declared MX hostnames; if TLS negotiation fails, do not deliver, do not fall back to plaintext. Gmail, Microsoft 365 (since 2020), and most major mail providers honour MTA-STS policies for outbound mail. Without MTA-STS, your email confidentiality during transit depends on attackers not bothering to intercept; with MTA-STS, the encryption is enforced by policy.

The MTA-STS policy declaration accepts three mode values: none, testing, and enforce. None signals that you do not maintain an MTA-STS policy (default before deployment). Testing mode publishes the policy and signals to sending servers that they should report TLS negotiation failures via TLS-RPT, but mail still gets delivered even if TLS fails or the certificate does not match. Enforce mode publishes the policy and instructs sending servers to refuse delivery if TLS negotiation fails or the receiving server does not match the policy MX patterns. We always deploy in testing mode first for 14-30 days. The TLS-RPT data during the testing window surfaces any misconfiguration (certificate name mismatches, missing intermediate certs, MX pattern mismatches, expired certs on backup MX hosts) before they would block real mail. Once TLS-RPT shows clean negotiation across senders, we transition to enforce mode. Switching directly to enforce without testing risks blocking legitimate inbound mail because of misconfigurations that would have been visible in TLS-RPT.

DANE (RFC 7672) is technically stronger but operationally more demanding. DANE binds TLS certificates to your domain through TLSA records published in DNS, requiring DNSSEC to be enabled on the parent zone. The advantage over MTA-STS: DANE removes the Certificate Authority from the trust model, so a rogue CA cannot issue fraudulent certificates that bypass your policy. The disadvantages: DANE requires DNSSEC throughout the resolution chain, requires DNSSEC-validating resolvers on the sending side (most large ISP resolvers and security-focused recursive resolvers do), and DNSSEC misconfigurations cause complete domain resolution failure rather than just TLS failure. Gmail has not implemented DANE for outbound mail despite supporting MTA-STS, citing inconsistent DNSSEC adoption globally. Our recommendation: deploy MTA-STS first as the broad-compatibility baseline. Add DANE as an additional layer if you already have DNSSEC enabled on your domain. Skip DANE if you do not have DNSSEC. The German BSI TR-03108 standard mandates all three (MTA-STS, TLS-RPT, DANE) for compliance with German federal email security requirements; operations needing BSI alignment get all three deployed.

Aggregate reports from sending mail servers describing their TLS negotiation experience with your inbound MX hosts. Reports are JSON-formatted documents (RFC 8460) delivered daily to the email address you publish at _smtp._tls.yourdomain.com. Each report covers a 24-hour window and includes per-sender data on: successful TLS connections (count, certificate chain validation results, policy fetch successes), failed TLS connections with failure categorisation (certificate validation failure, certificate name mismatch, certificate expired, policy fetch failure, STARTTLS not advertised, STARTTLS stripped by middlebox), and aggregate counts per failure category. The practical value: visibility into TLS failures that would otherwise be silent. Without TLS-RPT, an expired certificate on a backup MX host or a middlebox stripping STARTTLS would cause mail to be delivered in cleartext (or rejected if MTA-STS is in enforce mode) and you would never know unless senders complained. With TLS-RPT, you receive structured daily reports that surface these issues. Google, Microsoft, Yahoo, and most major mail providers send TLS-RPT reports for inbound MTA-STS-protected domains.

The MTA-STS specification requires the policy file to be served via HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a valid TLS certificate covering the mta-sts subdomain. The hosting options vary by infrastructure. Default approach: host on ASH infrastructure with Let's Encrypt automated certificate renewal. The HTTPS endpoint runs as a minimal nginx config serving only the static policy file with no other functionality. Alternative approaches we support: Cloudflare Pages with automatic SSL (free hosting), Cloudflare Workers (free, requires Worker code), GitHub Pages with custom domain (free, requires repository management), customer-managed web server if you already operate one with HTTPS. We document the specific hosting approach in your deployment runbook and handle certificate renewal automation regardless of approach. The policy file content includes the version (STSv1), mode (testing or enforce), authorised MX hostname patterns, and max_age (between several days and one year). Policy updates require incrementing the id field in the DNS TXT record to signal sending servers to re-fetch.

Two distinct failure modes depending on which certificate expires. If the MX server TLS certificate expires while MTA-STS is in enforce mode, sending servers honoring MTA-STS will refuse delivery to your domain until the certificate is renewed. Inbound mail bounces with TLS validation failures. TLS-RPT will surface this within 24 hours of expiry. If the mta-sts subdomain HTTPS certificate expires, sending servers cannot fetch the MTA-STS policy file. They will use their cached policy until the max_age expires, then either fall back to opportunistic TLS or refuse delivery depending on sender-side configuration. To prevent these scenarios, the engagement deploys certbot or equivalent automation with 30-day pre-expiry alerts to a monitored mailbox, 14-day escalation alerts to on-call rotation, and 7-day critical alerts requiring immediate response. Most certificates auto-renew without incident; the alert hierarchy exists specifically for the rare cases where renewal fails (rate limiting, DNS validation failures, expired payment methods on commercial CAs). Operations that prefer commercial CAs with longer validity periods (1-year certs from DigiCert or Sectigo) can request that configuration; the engagement supports both Let's Encrypt automation and commercial CA workflows.

Non-disruptive deployment because MTA-STS adds a security layer rather than changing existing email flow. Your current SMTP traffic continues working exactly as it does today during and after the engagement. The engagement adds three new things: a TLS certificate for the mta-sts subdomain (does not affect existing certificates), DNS TXT records for _mta-sts and _smtp._tls (does not affect existing DNS records), and a policy file served on a new HTTPS endpoint (does not affect existing web infrastructure). The testing-mode deployment confirms everything works without affecting deliverability. Transition to enforce mode happens only after TLS-RPT confirms clean TLS negotiation. The engagement coordinates with your existing infrastructure: if you use Microsoft 365 or Google Workspace for inbound mail, the MTA-STS policy lists those MX patterns; if you use Postfix or similar on ASH infrastructure, the policy lists your MX hostnames; mixed configurations (some traffic to Microsoft 365, some to ASH) are supported by listing multiple MX patterns in the policy.