センセイメモ - 先生の観察を、通知表の言葉に。所見の下書きをLINEで
センセイメモ｜観察を通知表の言葉に
所見の下書きをLINEで、無料から！
NEW!

STARTTLS

メールサーバー | IT用語集

この用語をシェア

STARTTLSとは

STARTTLSは、平文（暗号化されていない）接続をTLS暗号化接続にアップグレードするコマンド（プロトコル拡張）です。SMTPについてはRFC 3207、IMAP/POP3についてはRFC 2595（後にIMAPはRFC 3501、POP3はRFC 2449系にも記述）で標準化されており、25番・587番・143番・110番といった既存のポート番号を変更せずに暗号化通信へ移行できる点が最大の特徴です。

1990年代後半にSTARTTLSが設計された背景には、当時すでに広く運用されていたメールサーバー同士の相互接続性を壊さずに暗号化を導入したいという要求がありました。HTTPが80番のHTTPと443番のHTTPSという別ポートに分離したのに対し、メールの世界では同一ポート上で「平文のまま話しかけ、対応していれば暗号化に切り替える」というopportunistic（日和見的）な暗号化の考え方が採用されています。この設計により、STARTTLS非対応の古いサーバーとも後方互換性を保ちながら段階的に暗号化を普及させることができました。一方で、この「途中から暗号化に切り替える」という挙動そのものが、後述するダウングレード攻撃やコマンドインジェクションのリスクの温床にもなっています。

STARTTLSの仕組み・詳細解説

基本的な通信フロー

SMTPを例にすると、STARTTLSによる暗号化開始は以下の手順で行われます。EHLOコマンドへの応答でサーバーがSTARTTLS拡張への対応を通知し、クライアントが明示的にSTARTTLSコマンドを送信して初めてTLSハンドシェイクが始まる点がポイントです。

1. クライアント: 平文で接続
   → EHLO client.example.com

2. サーバー: STARTTLS対応を通知
   ← 250-mail.example.com
   ← 250-STARTTLS
   ← 250 8BITMIME

3. クライアント: 暗号化を要求
   → STARTTLS

4. サーバー: TLS開始を承認
   ← 220 Ready to start TLS

5. TLSハンドシェイク実施
   [暗号化通信開始]

6. 以降の通信はすべて暗号化（再度EHLOからやり直す）

手順6にあるように、TLSハンドシェイク完了後はセッション状態が破棄されるため、クライアントは暗号化されたコネクション上でもう一度EHLO（またはHELO）を送信し直す必要があります。これはSTARTTLS以前の平文でのコマンドが暗号化後のセッションに紛れ込む「コマンドインジェクション」を防ぐための重要な仕様です。

プロトコルごとのコマンド名の違い

「STARTTLS」という名称は主にSMTPとIMAPで使われるコマンド名ですが、POP3では歴史的にSTLSという別名のコマンドが使われます（いずれもRFC 2595が起点）。実務でPOP3サーバーのログを見て「STARTTLSコマンドが見当たらない」と混乱するケースがあるため、この呼称の違いは覚えておくと役立ちます。

プロトコル 平文ポート アップグレードコマンド 対応の通知方法
SMTP（MTA間） 25 STARTTLS EHLO応答の250-STARTTLS
Submission 587 STARTTLS EHLO応答の250-STARTTLS
IMAP 143 STARTTLS CAPABILITY応答のSTARTTLS
POP3 110 STLS CAPA応答のSTLS

コマンドインジェクションとバッファリングの注意点

STARTTLSの実装では、TCP上でパイプライン化されたコマンドがバッファに残ったまま暗号化に切り替わると、攻撃者が平文段階で仕込んだコマンドがTLSハンドシェイク後の暗号化セッション内で実行されてしまう「STARTTLSコマンドインジェクション」と呼ばれる脆弱性クラスが過去に複数のメール実装で報告されています。原因の多くは、STARTTLSコマンド送信後に受信バッファを確実にクリアしないままTLSレイヤーへ引き継いでしまう実装不備にあります。自社でMTA/MDAを実装・改修する場合や、STARTTLS対応の独自プロキシを挟む構成では、STARTTLSコマンド応答後に未処理の平文データが残っていないかをバッファレベルで確認する実装レビューが欠かせません。Postfix・Dovecot・Eximなど主要OSS実装は継続的な修正でこの種の問題に対応済みですが、古いバージョンや自作ツールでは注意が必要です。

証明書検証とSNI・ホスト名一致

STARTTLSはあくまで「暗号化を開始する合図」であり、TLS証明書の検証を必須とするかどうかは実装・設定次第です。Postfixのsmtpd_tls_security_levelを例にすると、may（提供のみ、証明書検証なし）、encrypt（暗号化必須だが検証なし）、verify（ホスト名一致まで検証）、secure（DNSSEC/DANEを含む厳格検証）という段階があり、多くのMTA間配送は運用上の互換性維持のためmayで稼働しています。つまり「STARTTLSで接続できている」ことと「相手サーバーの身元を検証している」ことは別問題であり、この前提を理解せずに「暗号化していれば安全」と考えるのは実務上の誤解のもとになります。SNI（Server Name Indication）を用いたホスト名ベースのTLS終端を行うプロキシ環境では、STARTTLS対応時にSNIで振り分けたバックエンドの証明書とEHLOで名乗ったホスト名が一致しているかも合わせて確認します。

具体例・ユースケース

ユースケース1: MTA間のオポチュニスティックTLS（ポート25）

インターネット上の別ドメイン宛にメールを配送する際、送信側MTAは相手のMXホストにポート25で接続し、EHLO応答に250-STARTTLSがあれば自動的にSTARTTLSを試みます。現在では主要なパブリッククラウドのメールサービスや大手プロバイダのMXサーバーの多くがSTARTTLSに対応しているとされ、Postfixではデフォルト（smtp_tls_security_level = may）でこの挙動になります。相手がSTARTTLS非対応であれば平文にフォールバックするため、暗号化は「できれば行う」レベルにとどまる点に注意が必要です。

ユースケース2: メールクライアントからのSubmission送信（ポート587）

Thunderbird・Outlook・スマートフォンの標準メールアプリなどから自社メールサーバーへ送信する際は、Submissionポート（587）でSTARTTLSを必須化するのが定石です。ユーザーの認証情報（SASL）がネットワーク上を流れるため、このポートではオプションではなく強制にすべきという点が、MTA間配送（ポート25）との運用方針の違いになります。

ユースケース3: IMAPクライアントによるメール受信（ポート143）

社内のメールクライアントがIMAPでポート143に接続し、CAPABILITY応答のSTARTTLSを見てから暗号化に切り替えるケースです。近年は最初からTLSで接続するポート993（Implicit TLS）を案内するプロバイダが増えていますが、既存のファイアウォールポリシーで143番しか開放していない環境ではSTARTTLSの運用が引き続き必要になります。

ユースケース4: opensslによる動作検証

実際にSTARTTLSが正しく応答するかは、サーバー構築時や証明書更新後の疎通確認としてopensslコマンドで手早く確認できます。

# SMTP（ポート25）でSTARTTLS応答を確認
openssl s_client -connect mail.example.com:25 -starttls smtp -crlf

# Submission（ポート587）でSTARTTLS応答を確認
openssl s_client -connect mail.example.com:587 -starttls smtp -crlf

# IMAP（ポート143）でSTARTTLS応答を確認
openssl s_client -connect mail.example.com:143 -starttls imap

# POP3（ポート110）でSTLS応答を確認
openssl s_client -connect mail.example.com:110 -starttls pop3

接続後に証明書チェーンと有効期限、Verify return code: 0 (ok)が表示されるかを確認し、期限切れや中間証明書の欠落がないかをチェックするのが実務上の基本手順です。

メリット・デメリット

メリット

  • 既存ポート（25/587/143/110）をそのまま利用できるため、ファイアウォールやロードバランサーの設定変更が不要
  • 後方互換性があるopportunisticな仕組みのため、STARTTLS非対応の古いサーバー・クライアントとも通信を継続できる
  • 証明書とTLS設定を追加するだけで導入でき、既存システムへの導入コストが比較的低い
  • SMTP・IMAP・POP3という複数プロトコルに対して共通の考え方で暗号化を適用できる

デメリット・注意点

  • ダウングレード攻撃（STARTTLSストリッピング）のリスク: 中間者がSTARTTLSコマンドや250-STARTTLS応答を通信経路上で削除・改ざんし、平文通信を強制する攻撃が成立し得ます。対策としてMTA-STSやDANEの併用が事実上必須です
  • opportunisticモードでは証明書検証をしないことが多いため、暗号化はされていてもなりすましサーバーへの誤配送を防げない場合があります
  • 実装によってはコマンドインジェクションの脆弱性（前述）が過去に報告されており、実装のバッファ処理品質に依存する
  • 平文接続からのアップグレードのため、Implicit TLSに比べてラウンドトリップが1往復程度余分に発生する（実運用上のボトルネックになることは少ない）
  • PostfixやDovecotの設定を誤ると「STARTTLSを提供しているつもりが実際は必須化されていない」といった意図しないオプション運用に陥りやすい

混同されやすい用語・類似技術との違い

Implicit TLS（暗黙的TLS）との違い

項目 STARTTLS Implicit TLS
接続開始 平文 最初から暗号化
ポート（SMTP送信/Submission） 25, 587 465
ポート（IMAP） 143 993
ポート（POP3） 110 995
ダウングレード攻撃耐性 △（対策併用が必要） ◎（そもそも平文段階が存在しない）

STLS（POP3）とSTARTTLS（SMTP/IMAP）の呼称の違い

前述の通りコマンド名が異なるだけで、目的と仕組みは同一です。ログや設定ファイルを読む際に別物と誤解しないよう注意してください。

MTA-STSとの違い

STARTTLSそのものは「暗号化を開始する手順」に過ぎず、相手が対応していなければ平文にフォールバックします。MTA-STS（SMTP MTA Strict Transport Security）はその上位に位置するポリシーの仕組みで、「このドメイン宛のメールは必ずSTARTTLSで、かつ有効な証明書で暗号化しなければならない」という方針をDNS＋HTTPSで配布し、ダウングレード攻撃を防ぎます。STARTTLSが暗号化の「手段」、MTA-STSはその「強制力」を与える仕組みと整理すると理解しやすくなります。

DANEとの違い

DANEはDNSSECで署名されたTLSAレコードを使い、証明書または公開鍵のハッシュ値をDNS上で検証する仕組みです。MTA-STSが認証局（CA）ベースのPKIを前提にするのに対し、DANEはCA階層に依存せずDNSSECの信頼チェーンだけで検証できる点が異なります。どちらもSTARTTLSのダウングレードを防ぐための補完技術であり、両方を併用する運用例もあります。

SSLとTLSの呼称混同

「STARTTLS」という名称にもかかわらず、実務会話では今も「SSL」という古い呼び方が使われることがあります。SSLはTLSの前身のプロトコルであり、SSL 2.0/3.0は脆弱性のため既に非推奨・廃止されています。現在使われているのは実質的にTLS（1.2または1.3）であり、「STARTTLS＝SSLを使う設定」という表現は不正確です。

自社メールサーバー運用への応用

Postfixでの設定例

# main.cf - STARTTLS設定
smtpd_tls_security_level = may  # STARTTLSを提供（強制はしない）
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# Submission（ポート587）ではSTARTTLS強制
# master.cf
submission inet n       -       y       -       -       smtpd
  -o smtpd_tls_security_level=encrypt

smtpd_tls_security_levelはnone（無効）、may（提供のみ）、encrypt（暗号化必須）、verify（証明書のホスト名検証あり）、secure（DANE等での厳格検証）の段階で設定できます。ポート25（MTA間受信）は相互接続性を優先してmay、ポート587（Submission）はユーザー認証情報を扱うためencrypt以上、という使い分けが実務上の定石です。

Dovecot（IMAP/POP3）での設定

# /etc/dovecot/conf.d/10-ssl.conf
ssl = yes
ssl_cert =

MTA-STS / DANEによるダウングレード対策の設定例

STARTTLSのダウングレード攻撃対策として、DNSに以下のようなレコードを公開する運用が広がっています。

# MTA-STSポリシーの存在をDNS TXTで示す
_mta-sts.example.com.   IN TXT  "v=STSv1; id=20260701000000Z"

# TLS-RPT（TLS Reporting）でネゴシエーション失敗の報告を受け取る
_smtp._tls.example.com. IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

# https://mta-sts.example.com/.well-known/mta-sts.txt の内容例
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

# DANE用のTLSAレコード例（ポート25のSMTP宛）
_25._tcp.mail.example.com. IN TLSA 3 1 1 <証明書公開鍵のSHA-256ハッシュ>

modeはまずtestingで導入し、TLS-RPTのレポートを確認しながら問題がなければenforceへ移行するのが安全な手順です。DANEを使う場合はDNSSECの署名が前提条件になるため、DNSゾーン側の対応状況を事前に確認してください。

運用・トラブルシューティングのポイント

  • Submission（ポート587）ではSTARTTLS必須にする
  • TLS 1.2以上のみを許可（TLS 1.0/1.1は脆弱性あり）
  • 有効な証明書を使用（Let's Encryptなど）し、certbot renew --deploy-hook "systemctl reload postfix dovecot"のように更新時のリロードを自動化する
  • 強固な暗号スイートを設定し、定期的に外部ツールでTLS設定を再チェックする
  • Postfixのmaillog（/var/log/mail.log）でAnonymous TLS connection establishedやTLS is required, but was not offeredといったログを確認し、STARTTLSが実際に成立しているか検証する
  • opensslコマンド（前述）で定期的に疎通確認を行い、証明書失効や設定ミスによるSTARTTLS失敗を早期に検知する

まとめ

STARTTLSは、既存ポートで暗号化通信を実現する標準的な方法であり、SMTP・IMAP・POP3という主要なメールプロトコルで共通の考え方が採用されています。一方で、opportunisticな性質上「対応していれば暗号化する」だけの緩い挙動になりやすく、ダウングレード攻撃や証明書検証の甘さといった弱点も抱えています。自社メールサーバーでは、Submission（ポート587）でSTARTTLSを必須化し、ポート25ではオプション提供としつつMTA-STSやDANEで補強する、という段階的な設計が現実的な落としどころです。TLS 1.2以上の使用と有効な証明書の導入、そしてログとopensslによる定期的な動作確認が、STARTTLS運用を形骸化させないための実務上のポイントになります。

2025-2026年の最新動向

MTA-STS（SMTP MTA Strict Transport Security）の採用が拡大しています。STARTTLSのダウングレード攻撃を防止するため、受信サーバーがTLS暗号化を必須とするポリシーをDNSで公開する仕組みで、Gmail、Microsoft 365、Yahoo!など主要なメールサービスが対応済みです。あわせてTLS-RPT（RFC 8460）でネゴシエーション失敗のレポートを受け取り、ダウングレードの兆候を運用側が把握できる体制を整える組織が増えています。

暗黙的TLS（ポート465）への回帰も進んでいます。RFC 8314の推奨に基づき、メールクライアントからサーバーへの送信にはSubmissions（ポート465、暗黙的TLS）の使用が推奨されるようになっており、STARTTLS（ポート587）と暗黙的TLS（ポート465）の両方をサポートするメールサービスが一般的になっています。

TLS 1.3の普及により、STARTTLSのハンドシェイク自体も往復回数が減って高速化し、暗号スイートの選択肢も安全な方向に絞り込まれています。TLS 1.0/1.1の無効化はほぼ業界標準となっており、新規構築するメールサーバーではTLS 1.2以上のみを許可する設定が前提になっています。

外部リンク

関連ブログ記事

関連用語

  • TLS - トランスポート層セキュリティ
  • Submission - メール送信ポート587
  • DANE - DNS認証によるTLS検証
  • Postfix - メール転送エージェント
  • Dovecot - IMAP/POP3サーバー
  • IMAP - メール受信プロトコル
  • POP3 - メール受信プロトコル（STLSコマンドを使用）
  • 対称暗号 - TLSで使用される暗号化方式

よくある質問（FAQ）

Q. STARTTLSとは？

平文通信をTLS暗号化にアップグレードするプロトコル拡張です。SMTP（RFC 3207）、IMAP・POP3（RFC 2595）で使用され、25・587・143・110番といった既存ポートのまま暗号化通信に移行できます。

Q. 暗黙的TLSとの違いは？

STARTTLSは平文接続後にアップグレード、暗黙的TLSは最初からTLSで通信します。RFC 8314では暗黙的TLS（SMTPSは465、IMAPSは993、POP3Sは995）が推奨されていますが、STARTTLSも広く使われ続けています。

Q. POP3のSTLSとSTARTTLSは別物ですか？

目的と仕組みは同じですが、コマンド名が異なります。SMTPとIMAPでは「STARTTLS」、POP3では「STLS」というコマンド名が使われます。いずれもRFC 2595を起点とする同種の仕組みです。

Q. セキュリティリスクは？

中間者がSTARTTLSコマンドや応答を除去して平文通信を強制する「ダウングレード攻撃」のリスクがあります。対策としてMTA-STS（RFC 8461）やDANE、TLS-RPT（RFC 8460）の導入が推奨されます。また過去には実装のバッファ処理不備によるコマンドインジェクション型の脆弱性も報告されています。

Q. STARTTLSが正しく動作しているか確認する方法は？

openssl s_client -connect mail.example.com:587 -starttls smtp -crlfのようにopensslコマンドで接続し、証明書チェーンとVerify return code: 0 (ok)が表示されるかを確認します。Postfixのmaillogで暗号化確立のログを確認する方法もあります。

Q. MTA-STSやDANEはSTARTTLSの代わりになりますか？

いいえ、代替ではなく補完の関係です。STARTTLSが暗号化を開始する「手段」であるのに対し、MTA-STSとDANEはSTARTTLSの利用を必須化し、ダウングレード攻撃を防ぐための「ポリシー・検証の仕組み」です。

この用語についてもっと詳しく

STARTTLSに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。