MTA-STS stands for SMTP MTA Strict Transport Security, a standard that lets a domain tell other mail servers to only deliver to it over an encrypted, authenticated connection. It is a receiving-side protection, which means it has almost nothing to do with whether your cold email sends successfully, covered in full in our SPF, DKIM and DMARC guide.
This page explains what MTA-STS and its companion TLS-RPT actually do, the DNS record and policy file behind them, the three modes you can set, and why a cold email sending domain can usually skip this one entirely.
What is MTA-STS and what problem does it solve for cold email domains?
MTA-STS is a mechanism, defined in RFC 8461, that lets a domain declare it can receive TLS-secured SMTP connections and specify what a sending server should do if TLS cannot be negotiated. The RFC's own abstract describes it as a way for mail service providers to declare their ability to receive secure SMTP connections, and to tell senders whether to refuse delivery when a trusted certificate is not offered.
The problem it solves is a downgrade attack. SMTP's STARTTLS extension is opportunistic by design, meaning a server will fall back to plaintext if TLS negotiation is interrupted, and an attacker who can intercept that negotiation can force a downgrade without either side noticing. MTA-STS closes that gap for mail arriving at the protected domain.
How does the MTA-STS DNS record and policy file work for cold email domains?
MTA-STS works through a small DNS TXT record that points senders to a separate HTTPS-hosted policy file, rather than putting the whole policy in DNS. RFC 8461 section 3 describes this as a deliberate split: the TXT record is cheap to check on every send, and the policy file carries the actual rules.
- The domain publishes a TXT record at
_mta-sts.yourdomain.com, containing a version and anidthe sender can use to detect a changed policy without refetching it every time. - A sending server that sees this record fetches a policy file over HTTPS from a fixed well-known path on the domain.
- The policy file names the domain's valid MX hosts, a mode, and a max age for how long the policy can be cached.
- The sending server applies the policy according to the mode, refusing delivery if TLS cannot be established in enforce mode, or just logging the failure in testing mode.
| Tag | Meaning |
|---|---|
v | Record version, STSv1 |
id | An opaque string that changes whenever the policy changes, so senders know to refetch |
What is TLS-RPT and how does it relate to MTA-STS for cold email domains?
TLS-RPT, defined in RFC 8460, is a reporting mechanism that lets sending servers tell a domain how its TLS connections to that domain have been going, including failures. RFC 8460's own introduction describes it as "a companion to the specification for SMTP MTA-STS" that adds reporting for both MTA-STS and the related DANE standard.
A TLS-RPT record is published separately, as a TXT record at _smtp._tls.yourdomain.com, and names where aggregate reports should be sent, either by email or HTTPS. The report itself is a daily JSON summary of successful and failed TLS negotiations other servers attempted when sending to your domain. This is the main way to actually see whether an MTA-STS policy is working as intended rather than silently blocking mail nobody notices.
What are the three MTA-STS modes and which one should a cold email domain use?
MTA-STS policies run in one of three modes, named directly in the policy file, and the choice decides what happens to mail that cannot be delivered over authenticated TLS.
| Mode | What it does |
|---|---|
testing | Logs TLS failures via TLS-RPT but still delivers mail even if TLS cannot be established |
enforce | Refuses delivery to MX hosts that cannot be authenticated over TLS |
none | Signals an intent to stop using MTA-STS, typically used briefly while retiring a policy |
RFC 8461 recommends starting in testing mode, since it reveals which senders might fail under enforcement before anything actually gets blocked. Moving straight to enforce without a testing period risks losing legitimate mail that happens to come from a server with an older TLS configuration.
Does MTA-STS matter for a cold email sending domain's deliverability?
Not much, because MTA-STS protects mail coming into your domain, not mail your domain sends out. RFC 8461 defines the "Policy Domain" as the recipient side of the connection, the domain whose MX hosts a sending server is trying to reach securely. A cold outreach domain's outbound sending reputation, bounce rate and authentication on the From address are governed by SPF, DKIM and DMARC, covered in our spam-trigger causes guide, none of which MTA-STS touches.
Where it is relevant is the reverse direction: if your sending domain also receives mail, such as replies to a cold outreach campaign, MTA-STS can protect those inbound replies from interception. For a sending-only domain with no mailbox that ever receives real mail, there is little reason to bother. For the mailbox a prospect actually replies to, it adds a layer of protection on the inbound side, but it will not change whether your outbound cold email gets through.
When is MTA-STS actually worth setting up for a cold email domain?
MTA-STS is worth setting up for a domain that receives sensitive or high-value mail, where protecting incoming connections from interception matters independent of anything to do with cold outreach. A company's primary business domain, or a domain handling password resets, invoices or confidential correspondence, is the typical case the standard was built for.
For the sending domains a cold outreach program creates specifically to send and then retire, MTA-STS adds DNS and policy-hosting overhead with no measurable benefit to deliverability. If you are unsure whether your domain currently has a policy published, our MTA-STS checker reads the TXT record and policy file for you.
How does Pipefire set up DNS for cold email sending domains?
Pipefire writes SPF, DKIM and DMARC for every sending domain it sets up, which are the records that actually govern whether your cold outreach lands in the inbox. MTA-STS is not part of that setup, because it addresses inbound mail security rather than the sending-side authentication a cold email campaign depends on.
If a domain also needs to receive mail securely, such as a mailbox that takes replies, that is a separate decision from the sending setup Pipefire handles. See our deliverability guide for the full list of signals that actually move cold outreach into the inbox.
MTA-STS cold email FAQ
Does MTA-STS stop my cold emails from going to spam?
No. MTA-STS has nothing to do with spam filtering or inbox placement; it only governs whether a TLS-secured connection can be established when mail is delivered to your domain. Spam placement is driven by authentication through SPF, DKIM and DMARC, sender reputation and content signals, not by MTA-STS.
Do I need MTA-STS if I already have SPF, DKIM and DMARC for cold email?
No, they solve different problems. SPF, DKIM and DMARC authenticate who sent a message and what to do if that fails; MTA-STS protects the transport layer of mail arriving at your domain from interception. A cold email sending domain needs the first three; MTA-STS is optional and mostly relevant to inbound mail.
What happens if I set MTA-STS to enforce mode on a cold email domain with no policy tested?
Mail from servers that cannot negotiate TLS to your MX hosts will be rejected outright rather than delivered, which can silently block legitimate inbound mail if your own mail server configuration has gaps. RFC 8461 recommends testing mode first specifically to avoid this.
Can Google Workspace or Microsoft 365 publish MTA-STS for my cold email domain?
Both providers support receiving mail under MTA-STS when correctly configured. Publishing the TXT record and hosting the policy file for your own domain is still something you or your DNS provider sets up; it is not automatic just because you use either platform for mailboxes.
Is MTA-STS the same as DANE for cold email domains?
No, though they solve a similar problem differently. DANE relies on DNSSEC and TLSA records to authenticate a domain's certificate, while MTA-STS relies on certificate authorities and HTTPS instead of DNSSEC. RFC 8461 notes the two are designed not to interfere when both are deployed on the same domain.