メールの守りは2つの層に分かれます。送信ドメイン認証は「そのドメインから正しく出たメールか」を受け取り側が確かめる仕組み。S/MIMEは本文そのものに署名と暗号化を施す仕組みです。役割が違うので、どちらかで代替できません。
先に押さえる
S/MIMEがやることは2つ。署名＝差出人が本人で、中身が改ざんされていないと示す。暗号化＝宛先だけが読めるようにする。署名は自分の秘密鍵で作り、暗号化は相手の公開鍵で行います。使う鍵が逆なので、ここを取り違えると設問で必ず外します。
署名と暗号化で、使う鍵が逆になる
署名する
- 作るとき：自分の秘密鍵
- 確かめるとき：差出人の公開鍵（証明書に入っている）
- 示せること：本人が書いた・改ざんされていない
暗号化する
- かけるとき：相手の公開鍵
- 開くとき：相手の秘密鍵
- 示せること：宛先だけが読める
したがって、暗号化して送るには、先に相手の証明書が要ります。設問では「まず署名付きメールをやり取りして互いの証明書を得る」という段取りが出てきます。これは手間ではなく仕組み上の前提です。
つまずきポイント
本文を暗号化すると、経路上の装置が中身を見られなくなります。ウイルス検査や情報漏えいの検査をメールサーバで行っている場合、それらが素通りすることになります。設問はここを突いてきます。対策は端末側で検査するか、いったん復号して検査する仕組みを置くか——どちらも「見える場所をどこに作るか」の話で、TLSの傍受と同じ構図です。
層が違うので、両方要る
1守る対象が違う
送信ドメイン認証「このドメインから出たか」を受信側が確認する（差出人の詐称対策）
↓これだけでは、中身の改ざんも盗み見も防げない
S/MIME本文に署名・暗号化。本人が書いたかと宛先だけが読めるか端から端まで守る
見抜きどころ
答案では「送信ドメイン認証はドメイン単位、S/MIMEは差出人個人と本文」と切り分けます。もう1つの定番は証明書の失効確認で、退職者の証明書が失効しているかを確かめなければ、過去の鍵で署名されたメールを信じてしまいます。「署名を検証する」だけでなく失効を確認するまで書けると強くなります。
運用でつまずく所
全員に証明書を配る必要があり、発行・更新・失効・端末への導入が回らないと定着しません。設問でも「利用者が増えたときの運用負荷」が論点になります。範囲を社外とやり取りする部署に絞るといった現実的な落としどころが用意されていることが多いです。