MTA-STS forces senders to use TLS when delivering mail to you. TLS-RPT tells you when they tried and failed. Together they close a gap DMARC does not address.
DMARC's threat model is impersonation. Did the message come from a sender authorized to send for the visible From domain? It does not, and was never designed to, say whether the message was encrypted in transit.
SMTP has supported TLS through STARTTLS since RFC 3207 in 2002. The problem is that STARTTLS is opportunistic. The sending MTA asks whether the receiver supports STARTTLS, and if the receiver says no, or if a man-in-the-middle strips the offer, the sender can fall back to plaintext delivery.
MTA-STS, standardized in RFC 8461, is the policy layer. TLS-RPT, standardized in RFC 8460, is the telemetry layer. Together they cover the inbound transport-security gap that DMARC does not touch.
What MTA-STS does
You publish two things. First, a DNS record at _mta-sts.yourdomain.com:
_mta-sts IN TXT "v=STSv1; id=20260720T120000Z"The id is an arbitrary version string. Bump it whenever the policy changes.
Second, a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mx1.yourdomain.com
mx: mx2.yourdomain.com
max_age: 604800mode: enforce means a compliant sender must refuse delivery if the MX hosts do not match the policy or TLS cannot be negotiated. mode: testing is the staging step that logs failures without dropping mail. max_age controls how long senders cache the policy.
Large senders that honor MTA-STS, including major consumer and enterprise mailbox providers, will no longer fall back to plaintext when delivering to a domain with a valid enforce policy.
What TLS-RPT does
TLS-RPT gives you the telemetry. You publish this DNS record:
_smtp._tls IN TXT "v=TLSRPTv1; rua=mailto:t-...@dmarcify.dev"Senders that support TLS-RPT then send daily JSON reports covering delivery attempts, successful TLS sessions, and failures. The failure categories are the useful part:
starttls-not-supported, when an MX does not advertise STARTTLS.certificate-host-mismatch, when TLS works but the certificate does not match the MX hostname.certificate-expired, when the certificate has aged out.certificate-not-trusted, when the chain is broken, self-signed, or issued by an untrusted CA.validation-failure, the generic bucket for other validation problems.
The common first-day finding is certificate-host-mismatch, usually because a wildcard certificate was reused without covering the actual MX hostname. The next common one is starttls-not-supported, usually a legacy secondary MX nobody still owns.
Why deploy this in 2026
First, encryption in transit is increasingly a regulatory and customer expectation. GDPR, HIPAA, PCI, and sector-specific security questionnaires may not name MTA-STS directly, but the question is concrete: how do you make sure mail delivered to your domain is encrypted?
Second, without TLS-RPT, you do not know what is happening. "We have STARTTLS configured" is not evidence that it is being used. Broken certificates, non-TLS backup MX hosts, and mismatched hostnames can sit unnoticed for years without reporting.
The deployment ramp
A safe rollout is short and measurable.
- Week 1: publish TLS-RPT and observe current inbound TLS posture.
- Week 2: fix reported certificate mismatches and missing STARTTLS.
- Week 3: publish MTA-STS at mode: testing and keep monitoring failures.
- Week 4: switch to mode: enforce once MX and certificate health are stable.
The risk in mode: enforce is operational: if a certificate expires or an MX hostname changes without updating the policy, compliant senders may refuse delivery. The mitigation is ordinary certificate and MX monitoring. The payoff is that attackers can no longer downgrade inbound mail to plaintext for senders that honor the policy.
What MTA-STS is not
- It is not DANE. DANE/TLSA uses DNSSEC-signed TLSA records to bind certificates. It is stricter, but requires DNSSEC. MTA-STS is easier for most organizations to deploy.
- It is not message-level encryption. PGP/MIME and S/MIME encrypt message bodies. MTA-STS only protects the channel between mail servers.
- It is not a DMARC replacement. Different layer entirely. DMARC covers sender authentication. MTA-STS covers inbound transport policy.
Where DMARCify fits
DMARCify monitors TLS-RPT alongside DMARC aggregate reports. The same domain dashboard can show who tried to deliver to you over TLS, which attempts succeeded, and where fallback or validation failed.
The practical goal is not to collect another standard. It is to make the inbound side of email security as visible as the outbound identity side.