A mid-size firm rolls out MTA-STS from testing to enforce, with TLS-RPT reports that expose an expired backup mail server certificate
A professional services firm of about 220 staff with offices in Miami and Atlanta, a leader in its segment.
- Scale
- About 220 mailboxes, 3 mail domains, 2 inbound mail servers per domain, 1 policy host, daily TLS reports from about 12 sending providers
- Engagement
- Two weeks of preparation, six weeks in testing mode, then enforce and a quarter of monitoring
The challenge
The firm had SPF, DKIM and DMARC in place, so forged mail was rejected, but nothing protected mail in transit. By default, one mail server offers encryption (STARTTLS) and the sender uses it if it can, and an attacker on the path can strip that offer and force plain text, or present any certificate and be accepted. A client's counsel had asked for assurance that mail to the firm travels encrypted, and the firm could not say which senders actually used encryption, which of its own servers had valid certificates, or whether anyone would notice a downgrade.
Email encryption between companies is opportunistic by default. A sending server asks whether the receiver supports STARTTLS and uses it if the answer is yes, and an attacker who can interfere with that exchange can make the answer no. SPF, DKIM and DMARC say who a message is from; they say nothing about whether it travelled in the clear. MTA-STS closes that gap for senders that check it, by publishing a policy that says: deliver to these servers only, over TLS, with a valid certificate.
The risk in rolling it out is self-inflicted. A policy in enforce mode tells the world to hold mail rather than deliver it to a server with a bad certificate, so a forgotten backup server or a mismatched certificate name turns into delayed mail. That is why the work started with reporting. TLS-RPT costs nothing to publish, and weeks of daily reports show every failure a strict policy would have caused, before it causes any.
The reports were the most valuable part of the project. They surfaced problems nobody had on a list: an old backup mail server still named in DNS with an expired certificate, and a gateway that presented the vendor's name instead of the firm's. Neither had hurt anyone yet, because senders rarely reach a backup server. They would have the first time the primary went down at a bad moment.
The rollout also changed how the firm handles mail changes. A new mail host now means updating the policy and its id first, waiting for caches, and only then changing DNS. Certificate expiry is an alert rather than a surprise. In this illustrative case the firm ended up with a mail path it can describe in one paragraph to a client's counsel, which was the original request.
What our team delivered
- An inventory of the mail path for each domain: the MX records, the certificates each server presents and when they expire, the TLS versions offered, and whether a mail security gateway or the mailbox platform answers first. Two domains pointed to a gateway, one to the platform directly, and one old backup server still sat in the MX records for the main domain
- A TLS-RPT record (RFC 8460) published first, as a TXT record at the name _smtp._tls under each domain, with a reporting address that feeds a mailbox the team reads and a parser that turns the daily JSON files into a table. Senders that support it send a report per day with counts of successful sessions and each failure type
- An MTA-STS policy (RFC 8461) in testing mode: a TXT record at _mta-sts with an id, and a policy file served over HTTPS from the mta-sts subdomain, listing the allowed MX host names, mode testing and a short maximum age of one day. The policy host has its own certificate from a public authority, renewed automatically, and is monitored, because a sender that cannot fetch the policy falls back to its cached copy or to no policy at all
- Six weeks of reading reports before changing anything. Most failures were small, but the reports showed that the old backup MX presented a certificate that had expired five months earlier, so senders that tried it, mainly when the primary was briefly unreachable, would have been refused under enforcement. The gateway also presented a certificate for the vendor's hostname instead of the MX name the policy listed, which a strict sender treats as a mismatch
- Fixes driven by what the reports showed: the expired backup server was retired and its MX record removed, the gateway was configured with a certificate for the exact MX host names, TLS 1.0 and 1.1 were disabled on both inbound paths, and the policy's mx lines were reduced to the two hosts that were meant to receive mail
- A move to enforce mode only when two consecutive weeks showed no failures other than known scanners that never completed a session. The maximum age was raised in steps, from one day to one week and then to several months, and any change to the MX hosts now starts with a policy update and a new id before the DNS change, not after
- A runbook with what to check when a TLS-RPT report shows a spike: a certificate that expired, a name mismatch after a vendor change, a sender with an old TLS stack, or a policy fetch error. Reports are also compared against the DMARC aggregate data to see which senders are real
Result
Mail from the providers that support MTA-STS is now delivered only over validated TLS to the two named servers, and a downgrade or a certificate mismatch makes the sender hold the message, which the firm sees in its next report. Reports showed that about 97 percent of sessions during the testing period already used encryption with a valid certificate, and the failures came from three causes the firm fixed itself: an expired backup server, a gateway certificate with the wrong name, and a handful of senders limited to old TLS versions. Certificate expiry is now an alert 30 days ahead rather than a surprise. MTA-STS protects only mail from senders that check it, and it does not replace encryption for sensitive content. This is an illustrative engagement that describes the kind of work our team does; details are composite.
Get this for your company
Related services with fixed prices and a written scope.
Emergency package: security engineer in 1 hour
Is your company in a cybersecurity crisis? Purchase this package and a security engineer will call you within 1 hour.
Callback within 1 hour, 24 hours a day, 365 days a year
$1,950 per incident
Initial assessment of public endpoints
What an attacker can see and reach from the internet: your domains, mail, websites, remote access and cloud exposure.
Report within 5 business days of kickoff
$1,000 per assessment
Managed IT and security (MSP)
One monthly price per team member: help desk, device management, patching, backup monitoring and security basics.
Onboarding starts within 10 business days
$100 per team member, per month
Show 3 more
Email security with AI detection and DLP
Inbound and outbound protection: phishing, malware and impersonation caught by AI detection, with data loss prevention for what leaves.
Live within 7 business days
$7 per mailbox, per month
Compromised-mailbox monitoring and alerts
We watch each mailbox for signs of takeover, such as odd logins, forwarding rules and mass sending, and alert you fast.
Live within 5 business days
$4 per mailbox, per month
Managed security monitoring
Endpoint detection and response watched by our analysts, priced per device.
Agents deployed within 7 business days
$18 per endpoint, per month
After you purchase, we contact you within 1 hour, any time of day or night, to start onboarding.
No payment is taken online. When we call you within the hour we confirm the scope and send an invoice (ACH, card or crypto).
Mail that keeps flowing
Incoming mail is authenticated and scanned before it reaches anyone, mailboxes are copied across three regions so a server failure goes unnoticed, and outgoing mail leaves signed and encrypted.
DMARC: from watching to rejecting
Share of mail claiming the domain that passes DMARC (SPF or DKIM aligned), week by week. In the monitoring phase (p=none) reports reveal forgotten senders; each one gets SPF and DKIM fixed. Quarantine sends failures to spam, reject refuses them at the receiving server. Illustrative figures.
Five million events, three escalations
What a managed SOC does to a day of log volume for a 250‑seat organisation. Collection produces millions of events; correlation rules turn them into a thousand or so alerts; triage merges and dismisses most of those into dozens of incidents; only a few need a human on the customer side. Bar length is the logarithm of the count, so each step is orders of magnitude. Illustrative figures.
Facing something similar?
Tell us about your environment. We will tell you plainly what we would do and what it would take.