メールの送信設定には、ポート・暗号化方式・認証方式の3つの組み合わせがあり、どれかがずれると送れません。さらに今、Basic認証の廃止という大きな変化が進んでいます。

第3回では、メールの中身（ヘッダーとボディ）を見ました。第4回では、その中身を運ぶ通信をどう守るか、そして送信者をどう確かめるかを扱います。

25・587・465の使い分け

RFC 8314（2018年）は、クライアントからの送信にImplicit TLSの465を推奨し、587＋STARTTLSも認めています。Microsoft 365（smtp.office365.com）は465は使えず、587（推奨）か25、Gmail（smtp.gmail.com）は465と587で受け付けます。外向きの25番は、ISPが遮断していることが多いです（第7回）。

STARTTLSとImplicit TLS

メールの経路をTLSで守る方法は2つあります。

• Implicit TLS：TCPの接続直後にTLSのハンドシェイクを行い、その中でSMTPを始める方式。465番を使う
• STARTTLS（RFC 3207）：587番や25番で平文の会話を始め、EHLOの応答に250-STARTTLSがあれば、STARTTLSコマンドでTLSに切り替え、EHLOからやり直す方式

冒頭の「SSL/TLSにしたらタイムアウト」の答えがここです。機器の設定の「SSL/TLS」はImplicit TLS、「STARTTLS」は切り替える方式を指すことが多く、ポートとの組み合わせを誤ると次のような症状になります。

• 465番にSTARTTLSで接続 → 相手はTLSのハンドシェイクを待ち、こちらは平文の220を待つので、タイムアウト
• 587番にSSL/TLSで接続 → 相手は平文の220を送るので、ハンドシェイクが失敗

「SSL/TLS」は465と、「STARTTLS」は587と組み合わせる、と覚えておきましょう。

STARTTLSの弱点

STARTTLSは平文で始めて途中で切り替えるため、切り替える前の平文の部分が攻撃の入り口になります。

• STRIPTLS（ダウングレード攻撃）：経路上の攻撃者がEHLOの応答から250-STARTTLSを消すと、クライアントは相手が暗号化に非対応だと判断し、平文のまま送ってしまう。ファイアウォールのSMTP検査機能が同じ書き換えをする例もある
• コマンドの注入：STARTTLSと同じパケットに平文のコマンドを続けて送ると、TLSに切り替えた後でそれを処理してしまう実装があった（2011年のCVE-2011-0411など。2021年の研究「NO STARTTLS」では40件以上）

暗号化が始まる前の平文は、消すことも足すこともできるのです。対策は次のとおりです。

• クライアントからの送信では、465を使うか「STARTTLS必須」にする
• MTA間では、MTA-STSやDANE（この後で説明）で暗号化を強制する

MTA間の暗号化：日和見的TLS

MTA間の25番の配送は、日和見的TLSで行うのが普通です。

• 送信側は、相手がSTARTTLSに対応していれば暗号化し、していなければ平文で送る。公開されたMTAは、TLSを必須にしてはならない（RFC 3207）とされている
• さらに、多くの送信側のMTAは相手の証明書を検証しない。Postfixのsmtp_tls_security_level = mayでは、自己署名や期限切れの証明書でも、そのまま暗号化して送る
• 盗聴は防げるが、経路上でなりすました相手（中間者）には気づけず、MXを引くDNSの応答の偽装も防げない

弱い区間が1つあれば、そこで読まれます。この弱点を埋めるのが、次のMTA-STSとDANEです。

なお、TLSが守るのは区間ごとの経路だけで、保存されたメールは守りません。端から端まではS/MIMEで守ります（連載「証明書入門」第1回）。

MTA-STSの仕組み

MTA-STS（RFC 8461）は、受信側のドメインが「必ずTLSで、正しい証明書を持つこのMXに送って」と宣言する仕組みです。

1. 受信側は、DNSに_mta-stsのTXTレコードを置き、https://mta-sts.ドメイン名/.well-known/mta-sts.txtにポリシーを公開する
2. 送信側はポリシーをHTTPSで取得して、max_ageの間キャッシュする
3. 配送のたびに、接続先がポリシーのmxに一致し、公開CAが発行したMX名に一致する有効な証明書でTLSを張れるかを確かめる
4. 満たさなければ、enforceモードでは配送せずにキューに残し、testingモードでは配送したうえでレポートで知らせる

HTTPSの証明書で守るためDNSSECは不要ですが、ポリシーをまだ持たない初回の送信は守れません（TOFU）。

MTA-STSの設定例

; DNS：ポリシーの有無と版（id）を知らせる
_mta-sts.example.jp.  3600 IN TXT "v=STSv1; id=20260926T000000"

; https://mta-sts.example.jp/.well-known/mta-sts.txt の中身
version: STSv1
mode: testing
mx: mail1.example.jp
mx: mail2.example.jp
max_age: 604800

$ dig +short TXT _mta-sts.example.jp
$ curl -s https://mta-sts.example.jp/.well-known/mta-sts.txt
PS> Resolve-DnsName _mta-sts.example.jp -Type TXT
PS> (Invoke-WebRequest https://mta-sts.example.jp/.well-known/mta-sts.txt).Content

• modeはtesting（検証するが配送は止めない）→ enforce（止める）の順に進める。やめるときはnone。max_ageは秒（最大31557600＝約1年）。mxのワイルドカードは左端の1ラベルだけ
• ポリシーを変えたらTXTのidを必ず変える。送信側はidが変わったときだけ取り直すため、忘れると古いポリシーがmax_ageの間使われ続ける
• mta-sts.example.jpのWebサーバーと各MXには、公開CAの有効な証明書が必要。MXをMicrosoft 365に向けているなら、mx: *.mail.protection.outlook.comと書く

TLS-RPT

_smtp._tls.example.jp. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.jp"

PS> Resolve-DnsName _smtp._tls.example.jp -Type TXT

{ "organization-name": "Example Sender",                  （届くレポートの抜粋）
  "date-range": { "start-datetime": "2026-09-25T00:00:00Z",
                  "end-datetime": "2026-09-25T23:59:59Z" },
  "policies": [ { "policy": { "policy-type": "sts", "policy-domain": "example.jp" },
      "summary": { "total-successful-session-count": 5326,
                   "total-failure-session-count": 3 },
      "failure-details": [ { "result-type": "certificate-expired",
          "receiving-mx-hostname": "mail2.example.jp", "failed-session-count": 3 } ] } ] }

• TLS-RPT（RFC 8460）は、送信側が「当ドメインへのTLS接続の成否」を1日ごとにまとめて知らせてくれる仕組み。MTA-STS・DANEとセットで使う
• result-typeで失敗の理由（certificate-expired、starttls-not-supported、sts-policy-fetch-errorなど）が分かる。上の例は、mail2の証明書切れ
• レポートはgzipで圧縮したJSONで届く。policy-typeはsts（MTA-STS）・tlsa（DANE）・no-policy-found
• testingモードで数週間レポートを見てからenforceに進めるのが安全。Gmail・Microsoft 365はレポートを送り、Postfixも3.10から作成に対応

DANE for SMTP

もう1つの方法がDANE（RFC 7672）です。

; MX のホスト名とポートの下に TLSA を置く（ゾーンは DNSSEC で署名済みであること）
_25._tcp.mail1.example.jp. 3600 IN TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

$ dig _25._tcp.mail1.example.jp TLSA +dnssec                    （抜粋）
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
_25._tcp.mail1.example.jp. 3600 IN TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B566 64C5D3D6

; 載せる値（サーバーの公開鍵の SHA-256）の作り方
$ openssl x509 -in mail1.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
PS> $c = [Security.Cryptography.X509Certificates.X509Certificate2]::new('mail1.cer')   # PowerShell 7
PS> [Convert]::ToHexString([Security.Cryptography.SHA256]::HashData($c.PublicKey.ExportSubjectPublicKeyInfo()))

• MXの公開鍵（または発行したCAの公開鍵）のハッシュをTLSAレコードでDNSに載せ、送信側が照合する
• MXとTLSAの両方がDNSSECで検証できることが前提（連載「DNS入門」第6回・第9回）。WindowsのResolve-DnsNameはTLSAを指定できないため、確認はdigで行う。digのflagsにadがあれば、DNSSECで検証できたことを示す
• 載せる値は、Linuxではopenssl、WindowsではPowerShell 7の.NETのメソッドで作れる
• digは長い16進を56桁で区切って表示する（DSと同じ）。比べるときは空白を詰める
• SMTPでは3 1 1（サーバーの公開鍵）か2 1 1（CAの公開鍵）を使う。公開CAの信頼の連鎖は見ないため、自己署名の証明書でもよい。MTA-STSと違い、初回の送信から守れる
• 鍵を変えるときは、新しいTLSAを先に追加し、キャッシュが切れてから切り替える。証明書の自動更新で鍵が変わると、TLSAと合わずに配送が止まる（連載「証明書入門」第8回）

DNSSECで守ったDNSが、CAの代わりにサーバーの鍵を保証する、という仕組みです。

REQUIRETLSと主要事業者の対応

REQUIRETLSは、送信者がMAIL FROM:<…> REQUIRETLSで「全区間を検証済みのTLSで運んで」と指定するSMTP拡張です。条件を満たせないMTAは、平文で送らずにエラーで差し戻します。Microsoft 365では、MTA-STS・DANEの検証で止めた送信をExchange管理センターのレポートで確認できます。

SMTP AUTH

ここからは、送信者の認証です。SMTP AUTH（RFC 4954）は、サブミッション（587・465）で送信者を確かめる仕組みです。

S: 250-AUTH LOGIN XOAUTH2                  ← Exchange Online：STARTTLS 後の EHLO の応答
S: 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH    ← Gmail（587）
C: AUTH PLAIN AHVzZXJAZXhhbXBsZS5qcABQYXNzdzByZA==     ← "\0user@example.jp\0Passw0rd" の base64
S: 235 2.7.0 Authentication successful
S: 535 5.7.139 Authentication unsuccessful, basic authentication is disabled.   ← 失敗の例

AUTH PLAINの文字列は、base64を戻せばそのままパスワードが読めます。だからTLSの中でだけ使います。Exchange Onlineは平文のEHLOにはAUTHを広告せず、STARTTLSの後にだけ示します。自前のサーバーでも同じようにし（Postfixのsmtpd_tls_auth_only = yes）、認証したユーザーと送信元のアドレスの一致も確かめます（第8回）。

Basic認証の廃止とOAuth 2.0

冒頭の「Microsoft 365のSMTP AUTHが年末に使えなくなる？」の答えです。

PS> Connect-ExchangeOnline
PS> Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled        # 組織全体（True＝無効）
PS> Get-CASMailbox -Identity scan@example.jp | Format-List SmtpClientAuthenticationDisabled   # 空欄＝組織の設定に従う

• 2026年3月1日から段階的に拒否し4月30日に廃止する、という以前の日程は、2026年1月27日の告知で撤回されている
• OAuthに対応しない複合機やアプリは、ファームウェアの更新、コネクターによるリレー、社内のリレーサーバー、SESなどへの切り替えを検討する（第10回、第12回の問1）
• Googleのアプリ パスワードも、推奨されない暫定策

まずは上のコマンドで、自社のテナントとアカウントの設定を確かめるところから始めましょう。

証明書の扱い

$ openssl s_client -connect smtp.example.jp:587 -starttls smtp \
    -servername smtp.example.jp -verify_hostname smtp.example.jp -brief </dev/null
Protocol version: TLSv1.3
Peer certificate: CN=smtp.example.jp
Verification: OK
Verified peername: smtp.example.jp                                  （抜粋）

• 証明書が要る場所：サブミッションのサーバー（587・465。クライアントが名前を検証する）、MX（MTA-STSを使うなら公開CAの証明書でMX名に一致が必須）、mta-sts.のWebサーバー
• SANに入れるのは、クライアントの設定やMXレコードが指すホスト名（smtp.example.jp・mail1.example.jp）で、メールアドレスのドメイン（example.jp）ではない（連載「証明書入門」第4回）。465は-starttls smtpを外して接続する
• 有効期間の短縮（連載「証明書入門」第6回）で更新が増える。自動更新の後にメールサーバーへ読み込ませる（postfix reloadなど）のを忘れない

Windowsで同じことを確かめる方法（PowerShellでSTARTTLSの後の証明書を見る）は、第9回で扱います。

考えてみよう

1. 社内の複合機・監視サーバー・vCenterは、どのポート・暗号化方式・認証方式でメールを送っていますか。Exchange OnlineのSMTP AUTHのBasic認証が既定で無効になる2026年12月末に、影響を受けるものはありますか。
2. 自社ドメインはMTA-STSとTLS-RPTを公開していますか。公開するなら、testingからenforceへ進める判断の材料は何ですか。
3. 取引先から「貴社宛てのメールはTLSを必須にしたい」と相談されたら、何を確かめ、どう答えますか。

ヒント：この記事の「25・587・465の使い分け」の表、MTA-STS・TLS-RPTの設定例、Basic認証の日程と確認コマンド、openssl s_client -starttls smtpが手がかりです。

まとめ

• 送信は465（Implicit TLS）か587（STARTTLS）＋SMTP AUTH。「SSL/TLS」は465、「STARTTLS」は587と組み合わせる
• STARTTLSは平文の段階を狙われる。送信は465かSTARTTLS必須に
• MTA間は日和見的TLSで、多くは証明書を見ない。強制するならMTA-STS（公開CA）かDANE（DNSSEC）
• MTA-STSはtesting→enforce。変えたらidを変える。TLS-RPTで失敗を知る
• Exchange OnlineのSMTP AUTHのBasic認証は2026年12月末に既定で無効。OAuth・コネクター・リレーへ
• 証明書のSANはホスト名。自動更新の後はMTAに読み込ませる

次回は、メールの送信者を名乗るドメインが本物かを確かめる、送信ドメイン認証（SPF・DKIM・DMARC）を扱います。

連載「メール入門」全12回

1. メールが届くまで
2. SMTPのやり取り
3. メッセージの構造
4. ポートと暗号化・認証（この記事）
5. 送信ドメイン認証 前編
6. 送信ドメイン認証 後編
7. 迷惑メール対策と配信
8. MTAの運用
9. コマンドで調べる
10. クラウドと現代のメール
11. メールのトラブルシュート
12. メールの設計演習