MTA-STS and TLS-RPT: The Email Security Standards Most Brands Miss

The authentication stack looks complete on paper. SPF passes, DKIM is aligned, DMARC is at p=reject. Every item on the standard compliance checklist is green. Then two missing DNS records catch the eye — the kind that never appear on a Google or Yahoo compliance list, but tell a trained observer that this domain’s email security was set up years ago and hasn’t been revisited since.

MTA-STS and TLS-RPT. Most eCommerce brands have never heard of them. Fewer still have implemented them.

MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS-RPT (SMTP TLS Reporting) are a pair of email security standards that complete your domain’s transport-layer protection. MTA-STS declares that your domain requires TLS encryption for inbound email delivery. TLS-RPT delivers daily reports on TLS connection failures. Neither is required by Google or Yahoo — which is exactly why most senders skip them.

What Is MTA-STS and What Does It Protect?

MTA-STS is an email security standard defined in RFC 8461, published in September 2018. It protects your domain’s inbound email from STARTTLS downgrade attacks — the specific vulnerability that exists in standard SMTP delivery today.

STARTTLS is the mechanism current mail servers use to upgrade a plaintext SMTP connection to an encrypted one. The problem is that STARTTLS is opportunistic: a sending server asks to upgrade, but if the request is stripped by an attacker sitting between the two servers, the sending server accepts the unencrypted fallback and delivers the message in plaintext. The email arrives — but readable to anyone on the network path.

According to Google’s Email Security Transparency Report, over 90% of email received by Gmail is now encrypted in transit using TLS — but that encryption relies on the same opportunistic STARTTLS that MTA-STS is designed to harden. The remaining percentage, plus any actively intercepted connection, is exactly the gap MTA-STS closes.

MTA-STS closes that gap by making TLS mandatory. When a sending server retrieves your MTA-STS policy and finds mode: enforce, it refuses to deliver mail to your domain if TLS cannot be negotiated with a valid certificate — rather than silently downgrading to plaintext.

Implementing MTA-STS requires two components: a DNS TXT record at _mta-sts.yourdomain.com and a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The policy file lists the MX hostnames that accept mail for your domain and the enforcement mode — none, testing, or enforce.

What Is TLS-RPT and Why Does Reporting Matter Before You Enforce Anything?

TLS-RPT gives you visibility into inbound TLS failures before you enforce a policy that could block legitimate mail. That is the reason to deploy it first — monitoring before enforcement is the right sequence.

TLS-RPT is defined in RFC 8460, published alongside MTA-STS in September 2018. It is a single DNS TXT record at _smtp._tls.yourdomain.com that specifies a reporting address:

_smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

Supporting mail servers — including Gmail, Outlook, and Yahoo — send daily JSON reports to that address showing every TLS connection attempt to your domain: successes, failures, failure reasons, and the sending server IP involved.

We’ve seen brands receive TLS-RPT reports showing repeated connection failures from a major shipping carrier’s notification system — the carrier’s mail servers were presenting an expired certificate. Without TLS-RPT in place, that failure had been silently causing missed shipping notification emails for weeks. One DNS record surfaced it.

Common failure reasons in the reports include expired certificates, hostname mismatches, and cipher suite incompatibilities. When reports show failures from a recognized sender — your ESP, a shipping carrier, or a payment processor — contact that provider’s technical support team with the report details. Failures from unfamiliar IP ranges warrant investigation as potential interception attempts. InboxEagle’s TLS-RPT checker parses these reports into readable summaries.

Does MTA-STS Actually Help Your Email Deliverability?

The honest answer: MTA-STS will not improve your Klaviyo campaign inbox rates. It protects mail coming TO your domain — not campaigns going FROM your domain to Gmail, Outlook, or Yahoo inboxes.

Your outgoing campaigns run through Klaviyo’s mail infrastructure. The TLS security of that outbound path is Klaviyo’s responsibility. Google’s Email Sender Guidelines require that bulk senders use TLS-encrypted connections when transmitting mail — which Klaviyo handles on your behalf.

What MTA-STS protects is your domain’s inbound email: order confirmation replies, customer service threads, supplier correspondence, transactional webhook responses. For eCommerce brands, that inbound channel carries operationally critical communication — and it is currently protected only by opportunistic STARTTLS unless you have explicitly published an MTA-STS policy.

The indirect deliverability connection is real, even if it is not a direct ranking signal. A domain with the complete email security stack — SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT — signals that the operator understands email at a protocol level. ISPs evaluate domain trustworthiness cumulatively. It is rarely the absence of one record that causes a problem; it is the pattern of which records are absent that tells the full story.

In every deliverability audit I run for eCommerce brands, MTA-STS and TLS-RPT are the two missing records I find most consistently — even in programs with DMARC at p=reject and BIMI implemented. InboxEagle is an email deliverability monitoring platform for eCommerce brands, and this gap shows up across brand sizes and verticals.

How Do You Implement MTA-STS and TLS-RPT?

Start with TLS-RPT — it is a single DNS record with no enforcement implications and immediate monitoring value. Add a TXT record at _smtp._tls.yourdomain.com pointing to a mailbox that can receive JSON attachments. Within 24 hours of Gmail’s first nightly report cycle, you will have real visibility into your domain’s inbound TLS health.

InboxEagle’s TLS-RPT record generator builds the correctly formatted record. Once you have been receiving reports for a week and confirmed no unexpected failures, proceed to MTA-STS.

For MTA-STS, work through these steps in order:

1. Identify your MX hosts — the exact hostnames in your domain’s MX records. These must match precisely in your policy file.
2. Host the policy file — create an HTTPS endpoint at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. This requires a TLS certificate on the mta-sts subdomain specifically — not a path on your existing domain. Your hosting provider or ESP may handle this.
3. Publish the DNS record — add the TXT record at _mta-sts.yourdomain.com with a unique id value (a timestamp works: id=20260420120000).
4. Start in testing mode — set mode: testing in your policy file. Receiving servers report violations via TLS-RPT but do not block delivery.
5. Review TLS-RPT reports for 2–4 weeks — confirm no legitimate senders are failing TLS negotiation to your domain before moving to enforcement.
6. Switch to enforce mode — update mode: enforce and change the id value. Sending servers that cannot establish TLS to your domain now receive a delivery failure and the sender gets a bounce notification — mail is not silently dropped.

Use InboxEagle’s MTA-STS checker and MTA-STS generator to validate your configuration at each step.

MTA-STS and TLS-RPT belong after SPF, DKIM, and DMARC are stable — they are the final layer, not the foundation. If you are still working through the authentication fundamentals, the SPF, DKIM, and DMARC explained guide covers that foundation first. The complete email deliverability guide maps how every layer connects.

Most eCommerce brands will never be penalized for skipping MTA-STS. But the brands with the cleanest email programs and the strongest domain reputations have the complete stack — because building trust with ISPs is a cumulative signal, and every gap in the record set is a gap in the signal.

If you want to know exactly where your domain’s email security posture stands right now, InboxEagle’s deliverability tools give you a complete picture in minutes.

Note: Content created with the help of AI and human-edited and fact-checked to avoid AI hallucinations.