最新您知道哪些法規適用於貴公司嗎?3 分鐘內即可確認。我們誠摯的禮物:歐盟法規工具韓國法規工具
我們能為您做什麼?

透過以下方式傳訊

KakaoTalkLINE

48 小時內回覆

傳送電郵給我們 →
MTA-STS Policies in Practice
電子郵件安全

MTA-STS Policies in Practice

2026年9月22日·Alex Holmquist, Panke IT Solutions LLC

Out of 131,024 Korean domains we analysed, only 3 publish an enforcing MTA-STS policy. Email delivery for the other 131,021 domains is still vulnerable to TLS downgrade and MiTM attacks.

In this post, we will go over what MTA-STS is, why it is important, and how it works so you can set it up in your own domain.

A sending and a receiving mail server exchanging messages, with an attacker labelled EVE standing on the wire between them. The receiver's capability list arrives with the 250-STARTTLS line struck out and every other line passed through, the sender does not notice that STARTTLS is missing, and the message then crosses the wire as plaintext under a watching eye.

Email Encryption is off by default

Mail servers encrypt opportunistically. When the sender sends a HELLO message, the receiving server replies with a list of everything it supports. That list might or might not include STARTTLS.

250-mail.example.com
250-PIPELINING
250-SIZE 35882577
250-STARTTLS
250 ENHANCEDSTATUSCODES

If the sender parses a STARTTLS line, it initiates a TLS connection. Ultimately, the mail message crosses the internet encrypted.

However, when STARTTLS is not sent by the receiver, a sending server falls back to cleartext.

RFC 3207, the specification that added TLS to SMTP in 2002, names the consequence in its own security section:

RFC 3207 §6: "A man-in-the-middle attack can be launched by deleting the '250 STARTTLS' response from the server."

The attacker deletes one line and passes the rest through, making the sender think the receiver doesn't support TLS.

How MTA-STS works

MTA-STS is defined in RFC 8461.

To configure MTA-STS, a domain has to publish two things.

  • A pointer in DNS. A TXT record at _mta-sts.<domain> carrying v=STSv1 and an id. The version string in id must change whenever the policy changes to indicate to senders that a policy change was made.
  • A policy over HTTPS. A plain-text file at https://mta-sts.<domain>/.well-known/mta-sts.txt. This file is used to name the MX hosts allowed to receive your mail. max_age defines how often senders should re-check the policy, and mode determines how the policy is enforced.

The two halves of an MTA-STS deployment. In DNS, a _mta-sts record carrying v=STSv1 says a policy exists; an arrow labelled fetch policy leads down to the policy served over HTTPS at mta-sts.<your-domain>/.well-known/mta-sts.txt, which carries mode: enforce and a list of permitted mail servers.

mode takes three values:

  1. enforce - a sender that cannot get a valid TLS connection to one of your named MX hosts MUST refuse to deliver the message
  2. testing - a sender delivers anyway and reports the failure
  3. none - the policy is inert. This is used to retire an old policy.

Reporting is done according to RFC 8460, which defined TLS-RPT. It's a TXT record at _smtp._tls.<domain>. This address receives daily summaries of how senders' TLS connections to you ended up: if they failed or not.

A Korean census of MTA-STS enforcement

Curious to find out how prevalent MTA-STS is in Korea, we queried 217,129 .kr domains, collected from the Tranco list, the Chrome UX Report for Korea, a top-10-million domain list and the FTC online-seller register (통신판매사업자). 81,957 of them no longer exist, and 4,148 lookups returned SERVFAIL or timed out. Both groups are excluded, which leaves 131,024 live domains.

count
Publish an MTA-STS pointer 20
— whose policy is valid 6
Publish TLS-RPT 20
Publish MX 72,094
DNSSEC-signed 118

That is an astounding 0.015% of the domains. For comparison, URIports' January 2026 scan of the global top million domains found 7,377 publishing a policy — 0.7%, up from 0.3% in 2024.

That means Korea seems have figured out MTA-STS at a rate about 45 times lower than the rest of the world.

The census result at a glance: 131,024 labelled domains asked, set in type that fills the frame, above a rule and a footer reading 20 publish the record, 6 valid policy.

The largest Korean domains are no better: none of naver.com, kakao.com, daum.net, samsung.com, coupang.com, hyundai.com, skt.co.kr, kt.com, toss.im, shinhan.com or kbstar.com publishes either record. google.com, gmail.com and microsoft.com publish both.

The six Korean exceptions

Only three Korean domains we found enforce MTA-STS: goodoc.co.kr, 8percent.kr and glitter.kr. Each policy returns HTTP 200 with mode: enforce, and its mx: lines cover every published MX record. goodoc.co.kr, for example, lists five mx: lines that match its five MX records exactly. A sender reading it will refuse to hand over mail to anything else.

Three more serve a valid policy in mode: testing, which reports failures and still delivers.

DANE is not the fallback

You might have heard of DANE. It is another way to pin mail transport encryption. In fact, it is stronger: the TLSA record lives in DNSSEC-signed DNS, with no web server in the path.

DANE is great. Nevertheless, it does not help if your MX hostname does not publish a DS record. For instance, if you host email on Google Workspace, DANE is not an option. 8,808 of the domains in our census first-listed MX is a Google host: a TLSA record is unverifiable no matter what.

That said, kr and co.kr both carry DS records at their parent, so a Korean domain can sign its zone if it wants to. 118 of the 131,024 do.

Cons of implementing MTA-STS

There's a reason most domains don't use MTA-STS. For many, maintaining the setup is too much work for too little in return.

The main concern raised by businesses is that certificate expiration and MX policy misalignment makes senders refuse to deliver your mail. If you don't have mature certification rotation procedures and streamlined MX management policies, you might break your organization's email delivery.


We are curious to know: did you even know MTA-STS existed?

References

  1. IETF — RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) (September 2018)
  2. IETF — RFC 8460: SMTP TLS Reporting (September 2018)
  3. IETF — RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security (February 2002)
  4. URIports — MTA-STS adoption: three years of steady growth (scan of the top million domains, first week of January 2026)
  5. Panke — Email spoofing: we tested 10,000+ Korean domains (1 September 2026)
  6. Panke — Email Security Explained: One Message, Six Checks (21 September 2026)
  7. Panke — MTA-STS and TLS-RPT census of 217,129 .kr domains, 131,024 live (first-party measurement, 23 September 2026)
  8. Google — Chrome UX Report, country list for Korea, August 2026, via crux-top-lists (CrUX datasets by Google, CC BY 4.0)
擔心您的攻擊面暴露風險?

若想了解您的基礎設施在攻擊者掃描模型中的評分,請聯絡 contact@pankeit.com,進行攻擊面評估。

訂閱我們的部落格

掌握最新資安趨勢

絕無垃圾郵件,隨時可取消訂閱。

©2026 Panke IT Solutions LLC

Austin, TX