「複合機の設定で『SSL/TLS』にしたら、送信がタイムアウトになります」
「Microsoft 365のSMTP AUTH、年末に使えなくなるって本当ですか？」
メールの送信設定には、ポート・暗号化方式・認証方式の3つの組み合わせがあり、どれかがずれると送れません。さらに今、Basic認証の廃止という大きな変化が進んでいます。
第3回では、メールの中身（ヘッダーとボディ）を見ました。第4回では、その中身を運ぶ通信をどう守るか、そして送信者をどう確かめるかを扱います。
25・587・465の使い分け
| ポート | 用途 | 暗号化 | 認証 |
|---|---|---|---|
| 25/tcp（SMTP） | MTA 間の配送（MX への配送） | STARTTLS（日和見的） | なし。受信側は接続元 IP と送信ドメイン認証（第5回）で判断 |
| 587/tcp（submission） | クライアント → MSA の送信（RFC 6409） | STARTTLS。サーバー側で必須にする | SMTP AUTH が必須 |
| 465/tcp（submissions） | クライアント → MSA の送信（RFC 8314） | 接続直後から TLS（Implicit TLS） | SMTP AUTH が必須 |
| 25/tcp（社内） | 機器・システム → 社内のリレーサーバー | 機器しだい。平文も多い | 接続元 IP の制限が多い（第8回・第10回） |
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に送って」と宣言する仕組みです。
- 受信側は、DNSに
_mta-stsのTXTレコードを置き、https://mta-sts.ドメイン名/.well-known/mta-sts.txtにポリシーを公開する - 送信側はポリシーをHTTPSで取得して、
max_ageの間キャッシュする - 配送のたびに、接続先がポリシーの
mxに一致し、公開CAが発行したMX名に一致する有効な証明書でTLSを張れるかを確かめる - 満たさなければ、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).Contentmodeは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と主要事業者の対応
| 方式 | 誰が宣言するか | 前提 | 主な対応（2026年9月時点） |
|---|---|---|---|
| 日和見的 TLS | なし（送信側の判断） | なし | ほぼすべての MTA |
| MTA-STS（RFC 8461） | 受信ドメイン | HTTPS と公開 CA の証明書 | Gmail・Microsoft 365 が送信時に常に検証。受信側は各ドメインがポリシーを公開。Postfix は外部の追加モジュールで対応 |
| DANE（RFC 7672） | 受信ドメイン | DNSSEC と TLSA | Microsoft 365 が送信時に常に検証、受信側も有効にできる（2024年10月一般提供）。Postfix は標準で対応 |
| TLS-RPT（RFC 8460） | 受信ドメイン | — | Gmail・Microsoft 365 がレポートを送る。Postfix 3.10 以降 |
| REQUIRETLS（RFC 8689） | 送信者（メール1通ごと） | 全区間で MTA-STS か DANE で検証した TLS | Postfix 3.11（2026年3月）が対応。大手のサービスの対応は限られる |
REQUIRETLSは、送信者がMAIL FROM:<…> REQUIRETLSで「全区間を検証済みのTLSで運んで」と指定するSMTP拡張です。条件を満たせないMTAは、平文で送らずにエラーで差し戻します。Microsoft 365では、MTA-STS・DANEの検証で止めた送信をExchange管理センターのレポートで確認できます。
SMTP AUTH
ここからは、送信者の認証です。SMTP AUTH（RFC 4954）は、サブミッション（587・465）で送信者を確かめる仕組みです。
| 方式 | 送るもの | 規格 | 注意 |
|---|---|---|---|
| PLAIN | ユーザー名とパスワードを base64 で1回で送る | RFC 4616 | base64 は暗号ではない。TLS の中でだけ使う |
| LOGIN | ユーザー名とパスワードを別々に base64 で送る | 標準化されていない（広く実装） | PLAIN と同じく TLS が必須 |
| CRAM-MD5 | チャレンジに対する MD5 の応答 | RFC 2195 | 古い方式。使わない |
| XOAUTH2 | OAuth 2.0 のアクセストークン | Google・Microsoft の独自方式 | Exchange Online・Gmail が対応。Basic 認証の代わり |
| OAUTHBEARER | OAuth 2.0 のアクセストークン | RFC 7628 | XOAUTH2 の標準版。Gmail が対応 |
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が年末に使えなくなる？」の答えです。
| サービス | これまで | 現状と日程（2026年9月時点） | 代わりの方法 |
|---|---|---|---|
| Exchange Online の SMTP AUTH | ユーザー名とパスワード（Basic 認証）で送信 | 2026年12月末まで変更なし。12月末に既存のテナントで既定で無効（管理者が有効に戻せる）。それ以後の新規テナントでは既定で使えない（OAuth が前提）。最終的な廃止日は2027年後半に発表予定 | OAuth 2.0（XOAUTH2）、Graph API、コネクターによるリレー（第10回） |
| Exchange Online の POP・IMAP・EWS 等 | Basic 認証 | 2022年10月から無効化し、現在はすべてのテナントで無効。有効に戻せない | 先進認証（OAuth）に対応したクライアント（POP・IMAP 側は連載「POP・IMAP入門」第9回（暗号化と認証）・第13回（クラウドとこれから）） |
| Google（Gmail・Workspace） | 「安全性の低いアプリ」としてパスワードで接続 | 2025年3月14日から OAuth が必須になり、2025年5月1日で対応を終了（Google の告知） | OAuth（XOAUTH2）、アプリ パスワード（2段階認証プロセスが前提）、Workspace の SMTP リレー（第10回） |
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回で扱います。
考えてみよう
- 社内の複合機・監視サーバー・vCenterは、どのポート・暗号化方式・認証方式でメールを送っていますか。Exchange OnlineのSMTP AUTHのBasic認証が既定で無効になる2026年12月末に、影響を受けるものはありますか。
- 自社ドメインはMTA-STSとTLS-RPTを公開していますか。公開するなら、testingからenforceへ進める判断の材料は何ですか。
- 取引先から「貴社宛てのメールは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）を扱います。
コメント