Receiver Shield: MTA-STS and TLS reporting, without the infrastructure

DMARCTrust has always been about sender authentication. SPF, DKIM, DMARC. Making sure that when someone receives an email from your domain, they can verify it actually came from you.

Over the past few months, we have been quietly building something new. We call it Receiver Shield, and it covers a problem that most DMARC deployments leave untouched: whether the email was encrypted in transit.

DMARC answers one question: “Is this email really from who it claims to be?” That is a solved problem for anyone running a properly configured policy. But DMARC says nothing about what happens to that email between the sending server and the receiving server. And that gap is bigger than most people realize.

The problem: STARTTLS is a suggestion, not a guarantee

SMTP, the protocol that moves email between servers, was designed in 1982. Encryption was not part of the original spec. It was bolted on later through an extension called STARTTLS, defined in RFC 3207.

Here is how STARTTLS works in practice. A sending mail server connects to a receiving mail server and says: “Do you support TLS?” If the receiving server responds with “yes, I do,” the two servers upgrade the connection to an encrypted channel and proceed with the delivery. If the receiving server says “no,” or simply does not respond to the TLS request, the sending server delivers the email in plaintext. No encryption. No error message. The email goes through anyway.

This is called opportunistic encryption. The sending server tries to encrypt, but if it cannot, it falls back to sending in the clear. Most of the time this works fine, because most modern mail servers do support TLS. Google’s Transparency Report shows that around 96% of inbound Gmail traffic is encrypted. That sounds reassuring until you look at who makes up the other 4%, and until you consider what happens when someone deliberately interferes.

The vulnerability is called STARTTLS stripping. An attacker positioned on the network between two mail servers, think a compromised router, a hostile ISP, or a state-level surveillance operation, intercepts the initial connection and removes the STARTTLS command from the conversation. The sending server never sees the “I support TLS” response, so it assumes the receiving server does not support encryption and delivers the email in plaintext. Neither server knows anything went wrong. There is no error, no warning, no bounce. The email arrives, readable by anyone who was watching.

This has happened in the real world. ISPs in multiple countries have been caught stripping STARTTLS to perform surveillance on email traffic. If your domain handles anything sensitive, this is a gap that DMARC does not close.

If you have deployed DMARC at p=reject, you have solved spoofing. But every email delivered to your domain still travels unencrypted unless the sending server successfully negotiates TLS, and with opportunistic encryption, “successfully” is not guaranteed.

The fix: MTA-STS and TLS-RPT

Two standards from 2018 address this directly.

MTA-STS (Mail Transfer Agent Strict Transport Security), defined in RFC 8461, lets you publish a policy that tells sending mail servers: “When you deliver email to my domain, you must use TLS, and you must verify that the certificate on my mail server matches these specific MX hostnames.” If the sending server cannot establish a secure connection that passes these checks, it must not deliver the email in plaintext. It either retries later or bounces the message.

MTA-STS has three components:

1. A DNS TXT record at _mta-sts.yourdomain.com that signals “I have an MTA-STS policy” and includes a policy ID.
2. A policy file hosted over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This file contains the policy mode (testing or enforce), the list of valid MX hostnames, and a max_age value that tells senders how long to cache the policy.
3. A mode. In testing mode, senders log TLS failures but still deliver the email. In enforce mode, senders refuse to deliver over an insecure connection.

TLS-RPT (TLS Reporting), defined in RFC 8460, is the feedback mechanism. You publish a DNS TXT record at _smtp._tls.yourdomain.com that tells sending servers where to send reports about TLS negotiation results. Think of it like DMARC aggregate reports, but for transport encryption instead of sender authentication. Major senders like Google, Microsoft, and Yahoo send daily JSON reports showing how many TLS sessions succeeded, how many failed, and the specific reason for each failure.

Why adoption is low

MTA-STS has been a standard since 2018, but adoption is far behind DMARC. The reason is operational overhead.

MTA-STS requires you to host a policy file over HTTPS on a specific subdomain (mta-sts.yourdomain.com). That means you need a web server, a valid TLS certificate for that subdomain, and a process to keep the certificate renewed and the policy file in sync with your DNS TXT record. If the policy file says one thing and the DNS record says another, senders will either ignore your policy or fail to fetch it entirely.

TLS-RPT reports are JSON files sent via email. Parsing them manually means reading nested objects with fields like result-type, sending-mta-ip, and failure-reason-code. For a single domain receiving reports from a dozen senders, that is hundreds of lines of JSON per day. Nobody does this by hand for long.

The result is predictable. Teams that attempt MTA-STS typically publish the DNS records, set the mode to testing, and then stop. They never look at the TLS-RPT data because parsing it is painful. They never move to enforce because they do not know what would break. The protection sits there, unused.

What we built: Receiver Shield

Receiver Shield adds MTA-STS hosting and TLS-RPT monitoring to DMARCTrust.

One CNAME, done

Instead of running your own web server and managing certificates, you add one DNS record:

mta-sts.yourdomain.com  CNAME  mta-sts-proxy.dmarctrust.com

We handle everything behind that CNAME: the HTTPS endpoint, the TLS certificate, the automatic rotation, and the policy file. You configure the mode, the MX hosts, and the max_age from your DMARCTrust dashboard.

The policy file served at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt follows the exact format specified in RFC 8461. When you edit the policy, we update the served file and generate a new policy ID. Senders will not pick up the change until you update the _mta-sts TXT record in your DNS with that new ID and their cache expires. The dashboard shows when your TXT record is out of sync and tells you exactly what to update.

One thing we spent time getting right is safe teardown. If you disable hosted MTA-STS or downgrade your plan, we do not simply remove the policy file. Senders that previously fetched your enforce-mode policy have it cached for up to max_age seconds. If the policy file suddenly disappears, those senders would continue enforcing the cached version, potentially blocking mail if your certificates or MX hostnames change in the meantime.

Instead, when you disable hosting, we transition the policy to mode: none, which tells senders to stop enforcing. We keep serving that policy until the max_age cache window expires, then remove it. Your mail flow stays uninterrupted throughout the transition.

Know before you enforce

The biggest barrier to MTA-STS enforcement is not the infrastructure. It is the uncertainty. Moving from mode: testing to mode: enforce means that any sender who cannot establish a verified TLS connection to your mail server will have their email bounced. If a legitimate partner has an expired certificate, or an older mail server that does not support TLS, their email to you stops arriving.

This is where TLS-RPT data comes in.

When you publish a TLS-RPT DNS record (we generate the exact value for you), sending servers start delivering daily reports to your DMARCTrust reporting address. The same address you already use for DMARC reports. No separate mailbox to configure.

We parse those reports and show the results in your Receiver Shield dashboard.

Failures are grouped by type (certificate expired, STARTTLS not supported, hostname mismatch, DANE validation failure) and by receiving MX host. If one of your MX hosts has a misconfigured certificate while the others are fine, you see it right away. The transport insights tab in your main dashboard breaks things down further by reporting organization, so you can see which senders are experiencing problems.

This data tells you what would happen if you moved to enforce mode today. Zero failures across 30 days of reports from major senders? You are probably safe to enforce. A handful of failures from a specific partner? Reach out to their IT team first, fix the issue, then enforce.

When you are ready, enforcement is one click from the dashboard. We require explicit confirmation so nobody enables it by accident. And because we cap enforce-mode max_age at 7 days, you can roll back quickly if something unexpected happens.

Getting started

Setting up Receiver Shield takes a few minutes.

1. Sign in to DMARCTrust and open any domain from your dashboard. Click the Receiver Shield tab.
2. Publish the TLS-RPT DNS record. We generate the exact TXT record value for you, including your reporting address. Copy it into your DNS provider.
3. Wait 24-48 hours. Major senders will start delivering TLS-RPT data. Google typically sends reports within a day. Others may take longer.
4. Review your dashboard. Failures show up grouped by type, by sender, and by MX host.
5. If you are on the Pro plan, add the CNAME record for hosted MTA-STS. We will provision the certificate automatically. Start in testing mode.
6. As reports accumulate, review the failure data. When you are confident that enforcement will not block legitimate mail, move to enforce.

TLS-RPT monitoring is available on all paid plans, including Starter ($19/month). Hosted MTA-STS policy serving and enforcement controls are included in Pro ($49/month), alongside SPF flattening and extended data retention.

What comes next

Receiver Shield is not finished. We are working on alerting when a major sender’s TLS configuration degrades, an enforcement readiness score that tells you concretely when it is safe to flip the switch, and tighter integration between TLS-RPT data and the DMARC insights already in your dashboard.

If you are already a DMARCTrust customer, Receiver Shield is live in your dashboard now. Open any domain and click the Receiver Shield tab to get started.

If you are evaluating MTA-STS for the first time, run your domain through our free domain checker to see your current MTA-STS and TLS-RPT status. For a deeper look at how MTA-STS works, see our MTA-STS documentation. And if you have questions about your specific setup, get in touch.