メールが届くまでの経路

添付ファイルを暗号化し、パスワードを別のメールで送れば安全でしょうか。配送経路の盗聴、メールボックスの侵害、宛先の間違いでは、必要な対策が違います。まず、誰から誰までを守るのかを整理しましょう。

事例：見積書を取引先へ送る

営業担当が見積書を partner.example の担当者へ送ります。自社の送信サーバから取引先の受信サーバへ配送され、担当者のメールボックスに保存されます。営業担当の送信アカウントと、取引先の受信アカウントは別々です。

見積書の内容を中継サーバにも読ませたくない要件と、自社ドメインを装ったメールを判別したい要件があります。内容の暗号化と、差出人ドメインの認証は別の仕事です。

メールが届くまでの経路

1. 投稿
2. SMTP配送
3. 取得

各矢印は別の通信区間です。TLSの終端後に保存された本文まで、TLSだけで保護できるわけではありません。

図では中継を一段にまとめています。実際に複数サーバを経由する場合も、保護する区間と保存先を順に確認します。

SMTPとMX：メールは何を見て配送する？

SMTPはサーバ間でメールを運ぶためのプロトコルです。送信サーバは配送先ドメインのMXレコードを調べ、配送を担当するサーバを選びます。MXの数値は小さいものが優先で、応答しない場合などに別候補を試します。

MX
宛先ドメインのメール交換サーバを指定するDNSレコード。宛先の個人名や暗号鍵ではありません。
RCPT TO
SMTPの配送先を指定する命令。宛先を表示するToヘッダとは役割が異なります。
MAIL FROM
SMTPで送信元を指定する命令。通常は不達通知の戻り先にも関係します。
From
利用者に表示する差出人を示すメールヘッダ。MAIL FROMと一致するとは限りません。

text

partner.example.  MX 10 mx1.partner.example.
partner.example.  MX 20 mx2.partner.example.

MAIL FROM:<sales@sender.example>
RCPT TO:<buyer@partner.example>
From: 営業部 <sales@sender.example>

この例ではMX 10を先に試します。配送キューへの受入応答を受けても、担当者がメールを読んだことや、添付を安全に開けたことまで証明できません。

TLSで守るのは、どこからどこまで？

利用者から送信サーバへの投稿と、送信サーバから受信サーバへの配送は区別します。投稿では465番の暗黙的TLS、587番のSTARTTLSなどが使われます。

暗黙的TLSは接続直後からTLSを始め、STARTTLSは既存接続をTLSへ切り替えます。

安全性は番号だけでは決まりません。TLS接続を必須にし、証明書を検証し、失敗時に平文へ戻さない条件を確認します。サーバ間の25番ポートの配送も、すべてが自動的に必須TLSになるわけではありません。

通信路のTLSは、両端のサーバで復号された本文を守り続ける仕組みではありません。保存先の権限、端末、メールボックスの保護も必要です。

取引先のメール配送でTLSを要求する仕組みにはMTA-STS等がありますが、端末間の本文暗号化とは異なります。

S/MIMEなら、中継サーバに内容を読ませずに送れる？

S/MIMEはメールの本文や添付を暗号化したり署名したりする方式です。受信者の信頼できる証明書を使って暗号化し、受信者は対応する秘密鍵で復号します。本文自体は共通鍵で暗号化し、その鍵を受信者ごとに保護する方式が使われます。

署名は送信者の秘密鍵で作り、受信者が証明書と署名を検証します。証明書の信頼、対象のメールアドレス、有効性、鍵の管理を確認します。署名だけでは内容を隠せず、暗号化だけでは添付が無害であると保証できません。

通信路とメール本文の保護

S/MIMEの保護範囲はメッセージ構造と実装で変わります。本文・添付と、配送先などの外側の情報を分けて考えます。

図のS/MIMEは暗号化を使う場合です。件名や配送情報まで常に隠せるとは言えません。受信者証明書の交換、鍵を紛失した際の業務継続、退職者の鍵の扱いも事前に決めます。

SPF・DKIM・DMARCは、何を照合する？

SPFは受信側から見た送信サーバのIPアドレスが、MAIL FROMのドメインなどに許可されているかを調べます。DKIMは署名対象のヘッダや本文と署名を検証します。どちらも単独では表示上のFromドメインとの一致まで確認しません。

d=
DKIM署名に責任を持つドメイン。DMARCでは署名が有効で、このドメインがHeader Fromと整合するかを見ます。
s=
DKIMの公開鍵をDNSで探すためのセレクタ。鍵の世代や送信システムを区別できます。
DMARC
Header Fromのドメインと、認証に成功したSPFまたはDKIMのドメインの整合を確認します。

整合したSPFか、整合したDKIMの少なくとも一方が成功すれば、DMARCはpassになり得ます。厳密な整合は完全一致、緩和された整合は組織ドメインの関係を使います。単に末尾が似ているという判断ではありません。

2026年のRFC 9989は従来のRFC 7489等を置き換えています。過去の試験の説明にも使える基本的な照合関係を扱い、組織ドメイン探索やレポート形式の詳細は仕様を参照します。

転送で受信側が見る送信IPが変わるとSPFが失敗することがあります。DKIMも本文の変更等で失敗することがあります。認証失敗を即座になりすましと断定せず、正規の配送経路と認証結果を確かめます。

DMARCのpassは、本文や振込先が安全であるという証明ではありません。正規アカウントの侵害、似た別ドメイン、表示名だけを使う詐欺は別に確認します。

PPAPを変えるなら、何を条件に選ぶ？

ここでのPPAPは、パスワード付きZIPとそのパスワードをメールで別送する運用を指します。同じメールボックスを攻撃者に読まれた場合、二通を分けても両方を取得されます。誤った相手へ二通とも送れば、宛先間違いも解消しません。

守りたい対象	候補	残る確認点
メール内容	S/MIME等の本文暗号化	受信者の鍵・端末
配布先と期間	認証付き共有・期限設定	権限・失効・閲覧記録
なりすまし	送信ドメイン認証	本文・正規アカウント侵害
不審な添付	検査・実行制限	暗号化後の検査可否

共有リンクへ変えても、誰でも開ける公開リンクでは送付先を制限できません。利用者認証、最小限のアクセス権、必要な保存期間、取消しの方法をセットで決めます。ZIP暗号の方式や検査可否も製品で変わるため、別送という手順だけで安全性を評価しません。

演習1：MXの優先順

条件：MX 10とMX 20があり、どちらも利用可能である。

問い：配送時に先に選ぶ候補はどれか。

解答例：優先値が小さいMX 10の候補。

根拠：MXは数値が小さいものを優先する。

誤答の理由：『20の方が高性能だから先』という推測はDNSレコードの意味と異なる。

演習2：暗号化の範囲

条件：自社送信サーバと取引先受信サーバの間はTLS。両サーバで本文を復号して保存する。

問い：中継サーバに本文を読ませない要件を満たすか。

解答例：満たさない。本文自体を受信者向けに暗号化する必要がある。

根拠：TLSの保護は通信区間で終わり、両端で復号される。

誤答の理由：『TLSなので全保存先でも暗号文』とは言えない。

演習3：鍵の向き

条件：取引先担当者だけが見積書を復号できるようにS/MIMEで暗号化する。

問い：暗号化に用いる相手の鍵と復号する鍵を答える。

解答例：担当者の証明書にある公開鍵を使い、担当者の秘密鍵で復号する。

根拠：秘密鍵を持つ受信者へ復号を限定するため。

誤答の理由：営業担当の秘密鍵は署名の役割と混同している。

演習4：DMARC整合

条件：Header Fromはsender.example。SPFはvendor.exampleでpass、DKIMはd=sender.exampleでpass。

問い：DMARCはpassになり得るか。

解答例：なり得る。有効なDKIM署名のドメインがFromと整合している。

根拠：整合した認証成功はSPFとDKIMの双方である必要はない。

誤答の理由：『SPFがFromと不一致なので必ずfail』はOR条件を取り違えている。

演習5：パスワード別送

条件：取引先のメールボックスが侵害され、ZIPのメールとパスワードのメールを両方読まれた。

問い：別送がこの侵害を防げない理由を述べる。

解答例：同じ侵害済みメールボックスで暗号文と復号用パスワードの両方を取得されるため。

根拠：二通を別に送っても、攻撃者の取得範囲が共通している。

誤答の理由：『暗号化はすべて無意味』ではなく、この配送・保管条件の問題を答える。

演習6：認証成功の限界

条件：正規アカウントから、振込先変更を指示するメールが届き、DMARCはpassだった。

問い：振込先をすぐ変更してよいか。

解答例：認証結果だけでは決めず、登録済みの連絡先など独立した経路で変更の事実を確認する。

根拠：DMARCはドメイン利用の認証で、正規アカウント侵害や内容の妥当性まで保証しない。

誤答の理由：メール内に新しく記載された電話番号だけへ確認すると、同じ攻撃者へ連絡する可能性がある。

出典と仕様を確認する

メールはどこで守られる？｜SMTP・S/MIME・送信ドメイン認証