PostfixのTLS強制化と証明書切れ対策｜本番メール配信への影響と段階移行設計

なぜ今、Postfixのメール配信でTLS問題が増えているのか

2023年以降、GmailやYahoo!メールをはじめとする大手メールプロバイダーが送信ドメイン認証（DMARC・SPF・DKIM）の厳格化を順次進めてきました。これと並行して、TLS（Transport Layer Security）によるメール転送の暗号化についても「なんとなく有効化されていればいい」という時代が終わりつつあります。

現場では「急に特定ドメイン宛のメールが届かなくなった」「バウンスメールにTLSネゴシエーション失敗の記録がある」といったトラブルが報告されています。原因の多くは、Postfixの設定がOportunistic TLS（機会的TLS）のままで、相手サーバーがTLSを必須化したケース、あるいは自サーバーの証明書が知らないうちに期限切れになっていたケースです。

本記事では、Postfixを運用しているLinux環境を前提に、TLS強制化の段階的な設計と、証明書切れによる配信停止を防ぐための監視・自動更新の組み合わせを解説します。

Postfix TLS設定の構造を整理する

PostfixのTLS設定は「受信側（smtpd）」と「送信側（smtp）」で独立しています。混同すると意図しない動作になるため、まずこの2軸を明確にしておきます。

受信側のTLSセキュリティレベル

smtpd_tls_security_level は外部から自サーバーへの接続に適用されます。主な値は次のとおりです。

• none：TLSを使わない（非推奨）
• may：相手がTLSを提示すれば使うが、平文も受け付ける（従来のデフォルト）
• encrypt：TLSを必須とし、平文接続を拒否する

パブリックMXとして運用しているサーバーでencryptを設定すると、TLS非対応の送信サーバーからのメールを受信できなくなります。2026年時点では大手のMTAは概ねTLS対応済みですが、古いシステムや一部のオンプレミス環境からの受信が必要な場合は慎重な判断が必要です。

送信側のTLSセキュリティレベル

smtp_tls_security_level は自サーバーが外部へメールを送る際の動作を制御します。

• none：TLSを使わない
• may：相手サーバーが対応していればTLSを使う
• encrypt：TLSが使えない相手には送信しない
• dane：DNSSECとTLSA（DANE）レコードを参照してTLS検証を行う（2026年現在、対応ドメインは限定的）
• verify：証明書のCN/SANを検証する（自己署名証明書への送信は失敗する）
• secure：最も厳格。DANEもしくはverifyと組み合わせて使う

多くの本番環境では送信側をmayで運用してきましたが、Yahoo!やGoogleが受信側でより厳格なTLS検証を求めるようになっており、encryptへの引き上げを検討するフェーズに入っています。

段階移行の設計：一括変更よりフェーズ分けが安全

TLS設定を一度に強制化すると、既存の取引先システムや内部サービスへの配信が突然停止するリスクがあります。現場での推奨は、次のような3フェーズアプローチです。

フェーズ1：現状の可視化（1〜2週間）

まずはTLSログを有効にして、現在どの相手サーバーがTLSで通信しているかを把握します。/etc/postfix/main.cfに以下を追加してPostfixをリロードします。

smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

maillog（またはjournalctl -u postfix）を数日分確認し、Untrusted TLSやTLS session reuse、No TLSなどのキーワードが含まれる接続先を洗い出します。TLS非対応の送信元・宛先が把握できたら、強制化時の影響範囲が見えてきます。

フェーズ2：送信側からencryptへ（2〜4週間）

受信側より先に送信側を強制化するほうがリスクは低いです。自社から外部への送信でTLSが使えない相手への配信が止まるだけで、自社への受信は影響を受けません。

smtp_tls_security_level = encrypt

変更後はバウンスキューを監視します。mailqコマンドで配信保留になっているメールを確認し、エラー内容が証明書関連であれば宛先ごとに例外設定（smtp_tls_policy_maps）を検討します。

フェーズ3：受信側のencrypt化と証明書整備

受信側をencryptにする前に、自サーバーの証明書が有効であることを確認します。Let’s Encryptを使っている場合は自動更新が正常に動いているか、certbotのタイマーを確認します。

systemctl status certbot.timer
certbot certificates

証明書の有効期限が90日以内で自動更新が確認できたら、smtpd_tls_security_level = encryptを設定します。ただし、パブリックMXとして広く使っている場合はmayを維持しつつ、smtpd_tls_auth_only = yesを組み合わせるアプローチも有効です（SMTP AUTH時にのみTLSを必須化する設定）。

証明書切れ対策：監視と自動更新の組み合わせ

証明書の期限切れは、TLSの設定がどれほど正しくても配信停止を引き起こします。特にLet’s Encryptのcertbot自動更新は「設定しただけで安心」になりがちで、実際にはsystemdのタイマーが止まっていたり、Webサーバーのプロセスが占有しているためHTTP-01チャレンジが失敗していたりするケースがあります。

期限切れを事前に検知するコマンド

opensslコマンドで証明書の残り日数を確認できます。

openssl s_client -connect mail.example.com:25 -starttls smtp 2>/dev/null \
  | openssl x509 -noout -dates

このコマンドの出力を定期的にcronで実行し、notAfterの日付が30日以内であればアラートを飛ばすスクリプトを仕込むのが実用的です。Prometheus + Alertmanagerを使っている環境であれば、blackbox_exporterのTLSモジュールで証明書有効期限を自動監視できます。

certbot更新後にPostfixを自動リロードする

certbotが証明書を更新してもPostfixが古い証明書をメモリ上にキャッシュしていることがあります。/etc/letsencrypt/renewal-hooks/deploy/ディレクトリにスクリプトを置くと、更新成功後に任意のコマンドを実行できます。

#!/bin/bash
systemctl reload postfix

このスクリプトを/etc/letsencrypt/renewal-hooks/deploy/reload-postfix.shとして保存し、実行権限を付与しておくことで、証明書更新のたびにPostfixが新しい証明書を読み込むようになります。

切り戻し手順と設定変更時の注意点

設定変更後に配信問題が発生した場合の切り戻しは、main.cfを編集してpostfix reloadするだけです。Postfixは設定ファイルを都度読み込むため、再起動なしで変更を反映できます。

ただし、変更前にかならず設定のバックアップを取っておくことが重要です。

cp /etc/postfix/main.cf /etc/postfix/main.cf.$(date +%Y%m%d)

また、smtp_tls_policy_mapsを使って特定ドメインだけTLSレベルを個別指定することもできます。例えば、古いシステムとの通信にのみmayを維持しつつ、それ以外はencryptを適用する構成が可能です。

# /etc/postfix/tls_policy
legacy-partner.example.jp  may

# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

ファイル編集後はpostmap /etc/postfix/tls_policyでデータベースを生成してからpostfix reloadします。

切り戻し時に確認すべきログのポイント

問題発生時はjournalctl -u postfix --since "30 minutes ago"でログを確認します。よく見られるエラーのパターンは次のとおりです。

• STARTTLS failed：相手サーバーがSTARTTLSを提示したが確立に失敗。証明書不一致やプロトコルバージョン非対応が原因のことが多い
• certificate verification failed：送信側がverifyレベルに設定されているが、相手の証明書を検証できない
• no shared cipher：TLSのCipherSuiteが一致しない。古いサーバーとの通信でOpenSSL 3.x以降の厳格化が影響することがある

2026年現在の環境差分と注意点

2026年時点でUbuntu 24.04 LTS（Noble Numbat）やDebian 12（Bookworm）を使用している環境では、OpenSSL 3.x系がデフォルトになっています。OpenSSL 3.xではTLS 1.0/1.1がデフォルトで無効化されており、古いMTAとの互換性問題が発生するケースが報告されています。

また、RHEL 9系・AlmaLinux 9系・Rocky Linux 9系では、システムワイドな暗号ポリシー（crypto-policies）が適用されており、Postfixの設定だけでなくシステムポリシーも確認が必要です。update-crypto-policies --showで現在のポリシーを確認し、必要に応じてFIPSからDEFAULTまたはLEGACYへ変更することが切り戻しの選択肢になります。

Postfix自体のバージョンも確認が必要です。Postfix 3.8以降ではSMTP over TLS（ポート465/SMTPS）の設定方法に変更があり、smtpsサービスのmaster.cf設定が必要です。古いドキュメントをそのまま参考にすると設定が機能しないことがあるため、インストール済みのバージョンに合ったドキュメントを参照することを勧めます。

TLS強制化は一度設定すれば終わりではなく、証明書の期限管理・OpenSSLのバージョンアップ・相手サーバーの設定変更に継続的に対応が求められる運用です。段階的な移行設計と自動化された監視の組み合わせが、安定した本番メール配信を維持するための現実的なアプローチといえます。