メールは「差出人を名乗り放題」の仕組みです。SMTP は 1980 年代の設計で、送信者が書いた From をそのまま信じます。だから取引先や上司を装った標的型メールが成立します。 これを受信側で見破るのが送信ドメイン認証（SPF・DKIM・DMARC）で、午後では「どのサーバの IP を DNS に登録するか」「どの From を検査するか」「委託先に送らせるとどう崩れるか」という形で出ます。 令和6年 午後Ⅱ問2 が丸ごとこのテーマでした。
攻撃者は自分のサーバから「From: 社長 <president@y-sha.com>」と書いたメールを y-sha.com の社員に送れます。SMTP にはこれを止める仕組みがなく、受信サーバは書いてある通りに受け取ります。 標的型メール攻撃はこのなりすましに、添付ファイルやリンク先のマルウェアを組み合わせたものです（平成26年 午後Ⅱ問1）。
MUA（メーラ）は自社の MTA（メールサーバ）に SMTP で渡します。このとき使うのがサブミッションポート 587 番で、SMTP-AUTH で利用者を認証してから受け付けます。 25 番ではなく 587 番を使うのは、ISP が迷惑メール対策として動的 IP から外向きの 25 番を止めている（OP25B、Outbound Port 25 Blocking）からです。認証付きの 587 番ならどこからでも自社サーバに渡せます（平成28年 午後Ⅰ問1 設問2(4)(5)）。
MTA は宛先アドレスのドメイン（y-sha.com）の MX レコードを DNS で引き、受取サーバの名前と優先度（Preference、小さいほど優先）を得て、そのサーバの 25 番に SMTP で接続します。 MTA 同士の 25 番は認証がありません。だからこそ送信ドメイン認証が要ります。
受信側 MTA は受け取ったメールをメールボックスに入れ、利用者は POP3（110） か IMAP（143）で取り出します。送信ドメイン認証はこの受け取る瞬間に MTA が行います。
SMTP のやり取りは、まず MAIL FROM と RCPT TO コマンドで「差出人と宛先」を伝え、次に DATA コマンドでヘッダーと本文を送ります。 MAIL FROM で渡す差出人がエンベロープ From（封筒の差出人、Return-Path）、DATA の中の From: 行がヘッダー From（便箋の差出人）です。
S: 220 mail.y-sha.com ESMTP C: EHLO mail.x-sha.com C: MAIL FROM:<bounce@x-sha.com> ← エンベロープ From（SPF が見る） C: RCPT TO:<taro@y-sha.com> C: DATA C: From: 営業部 <sales@x-sha.com> ← ヘッダー From（受信者に見える。DMARC が見る） C: To: taro@y-sha.com C: Subject: 請求書の件 C: （本文） C: .
ドメインの持ち主が「このドメインを名乗ってメールを送るサーバの IP アドレスはこれ」を DNS の TXT レコードに書きます。
x-sha.com. IN TXT "v=spf1 ip4:200.a.b.1 ip4:200.a.b.2 include:_spf.saas.example -all" ip4: 送信を許可するサーバの IP アドレス（グローバル側。NAT 後の IP） include: 他社（メール配信サービス等）の SPF をまとめて許可 -all 上記以外は失敗（hardfail）。~all なら softfail（疑わしいが受け取る）
受信側 MTA は、エンベロープ From のドメインの TXT を引き、SMTP 接続の送信元 IP アドレスがその中にあるかを調べます。合っていれば pass です（令和6年 午後Ⅱ問2 設問2(3)、平成28年 午後Ⅰ問1 設問3）。
送信側 MTA が秘密鍵でヘッダーの一部と本文のハッシュに署名し、DKIM-Signature ヘッダーとして付けます。受信側は署名に書かれたセレクタとドメインから selector._domainkey.x-sha.com の TXT を引いて公開鍵を得、署名を検証します。
DKIM-Signature: v=1; a=rsa-sha256; d=x-sha.com; s=sel2024;
h=from:to:subject:date; bh=...; b=...
d= 署名したドメイン s= セレクタ（鍵を切り替えられるよう名前を付ける）
h= 署名対象のヘッダー bh= 本文のハッシュ b= 署名
sel2024._domainkey.x-sha.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..." ← 公開鍵
SPF と DKIM はそれぞれ「通った／通らない」しか出しません。DMARC はヘッダー From のドメインを軸に、次の 2 つを決めます。
_dmarc.x-sha.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-rep@x-sha.com" rua= 集計レポートの送り先。どの IP から自ドメインを名乗るメールが出ているかが分かる
導入は p=none でレポートを集め、正規の送信経路（SaaS やメール配信サービスを含む）が全部 SPF/DKIM を通ることを確認してから quarantine → reject に上げるのが定石です。いきなり reject にすると、SPF/DKIM を設定し忘れた正規サーバのメールが届かなくなります。
送信メールサーバがプライベートアドレスで、FW で NAT されて出ていくなら、SPF に書くのはNAT 後のグローバル IP です。受信側が見るのは SMTP 接続の送信元 IP だからです。 平成26年 午後Ⅱ問1 設問2(3)「社外に送信されるメールの送信元 IP アドレスになるから」、令和6年 午後Ⅱ問2 設問2(1) の「ウ・エ ＝ 200.a.b.1 と 200.a.b.2」がこれです。
Y 社が y-sha.com を名乗るメールの送信をサポート会社 Z に委託すると、Z のサーバから y-sha.com のメールが出ます。
受信側の MTA は、送信元 IP の逆引き（PTR）が引けるか、その名前が送信元の名乗る名前と合うかも見ます。逆引きが無いと迷惑メール扱いされやすいので、送信サーバのグローバル IP には PTR を登録します（令和6年 午後Ⅱ問2 設問1(3) の「逆引き」）。 MX は複数登録でき、Preference が小さいサーバが優先、停止時は次のサーバへ配送されます。切替作業の前には MX の TTL を短くしておきます（同 設問1(2)）。
社内のメールボックスを持つサーバを直接インターネットに晒さず、DMZ にメール中継サーバを置いて MX にはそれを登録します。中継サーバが SPF/DKIM 検査・ウイルス検査・スパム判定を行い、合格したものだけを内部に渡します （平成26年 午後Ⅱ問1 設問2(4)「メール中継サーバ。社外から Y 社宛てのメールを直接受信するから」）。
| 方式 | 守る区間 | 備考 |
|---|---|---|
| STARTTLS（SMTP over TLS） | MTA 間、MUA と MTA 間の通信路 | サーバに届けば平文。相手が非対応なら平文に落ちる（日和見） |
| SMTPS（465）/ POP3S（995）/ IMAPS（993） | MUA と MTA 間の通信路 | 最初から TLS |
| S/MIME / PGP | メール本文そのもの（端から端まで） | サーバ上でも暗号化されたまま。送信者の署名で差出人の証明にもなる。証明書配布が手間 |
| 用語 | 意味 | 午後でのポイント |
|---|---|---|
| MUA / MTA | メーラ / メールサーバ（転送エージェント） | MUA → MTA が 587、MTA → MTA が 25 |
| サブミッションポート（587） | 利用者が自社 MTA に渡す専用ポート | SMTP-AUTH とセット。OP25B を回避 |
| SMTP-AUTH | 送信時の利用者認証 | 認証済み利用者だけ中継する |
| OP25B | ISP が動的 IP からの外向き 25 番を遮断 | 迷惑メール送信 PC 対策 |
| MX / Preference | 受取サーバ / 優先度（小さいほど優先） | FW は MX のサーバだけに 25 番を許可 |
| エンベロープ From（MAIL FROM） | 封筒の差出人。エラー返送先 | SPF の検査対象。受信者に見えない |
| ヘッダー From | 便箋の差出人。受信者に見える | なりすましの対象。DMARC の照合対象 |
| SPF | 送信元 IP を DNS の TXT で宣言 | NAT 後のグローバル IP を書く。転送で壊れる |
| DKIM | 秘密鍵で署名、公開鍵を DNS に | セレクタで鍵を分ける。転送に強い。改ざん検知 |
| DMARC | ヘッダー From とのアライメントとポリシー | none → quarantine → reject。レポート（rua） |
| オープンリレー | 誰からでもどこへでも中継する MTA | 踏み台。自ドメイン宛てと認証済みだけ中継 |
| 逆引き（PTR） | IP → 名前 | 送信サーバの IP に必ず登録 |
| メール中継サーバ | DMZ で外部と直接 SMTP する MTA | MX はこれ。検査はここで |
| STARTTLS / S/MIME | 通信路の暗号化 / 本文の暗号化と署名 | 守る範囲が違う |
| 設問の型 | 答え方 | 出た年度 |
|---|---|---|
| 空欄「MX」「SMTP-AUTH」「サブミッションポート」「MAIL FROM」 | 配送の流れの用語。SPF が見るのは MAIL FROM（エンベロープ From） | H28 午後Ⅰ問1、R6 午後Ⅱ問2 |
| SPF の検査内容 | 送信元メールサーバの IP アドレスが、エンベロープ From のドメインの SPF レコードに登録されていること | R6 午後Ⅱ問2、H28 午後Ⅰ問1、H26 午後Ⅱ問1 |
| SPF に登録する IP アドレスとその理由 | FW で NAT された後のグローバル IP。社外に送信されるメールの送信元 IP になるから | R6 午後Ⅱ問2、H26 午後Ⅱ問1 |
| DKIM の鍵と DNS に置くもの | RSA、DNS に登録するのは公開鍵。署名は送信側の秘密鍵 | R6 午後Ⅱ問2 |
| DKIM で分かること | 受信したメールが正規のメールサーバから送信されたものか（改ざんされていないか） | R6 午後Ⅱ問2 |
| 委託先にも送らせるときの DNS 設定 | 委託先サーバの IP を自ドメインの SPF に追加。DKIM は別セレクタの公開鍵を登録 | R6 午後Ⅱ問2 |
| 委託先用に別の鍵ペアを作る利点 | 委託先から鍵が漏えいしても自社の DKIM は影響を受けない | R6 午後Ⅱ問2 |
| 委託先経由で残る問題 | なりすましメールも委託先サーバから社外に転送されてしまう | R6 午後Ⅱ問2 |
| MX の TTL を短くしている理由 | 切替時にキャッシュ DNS が古い MX を保持する時間を短くするため | R6 午後Ⅱ問2 |
| インターネットからの SMTP を受けるサーバと理由 | メール中継サーバ。社外から自社宛てのメールを直接受信するから | H26 午後Ⅱ問1 |
| 中継しない条件 | 自社宛て以外のメールは中継しない（踏み台防止） | R1 午後Ⅱ問2、H28 午後Ⅰ問1 |
| 利用者がすべき標的型メール対策 | 添付を開かない、リンクにアクセスしない、差出人を確認、不審メールを報告・共有 | H26 午後Ⅱ問1 |
クリックで答えが開きます。
DNS で各レコードを確認する（nslookup） nslookup -type=MX example.com 受取サーバと Preference nslookup -type=TXT example.com "v=spf1 ..." が SPF nslookup -type=TXT _dmarc.example.com "v=DMARC1; p=..." が DMARC nslookup -type=TXT selector._domainkey.example.com DKIM 公開鍵（セレクタはヘッダーの s= を見る） nslookup 200.a.b.1 逆引き（PTR） 受信したメールの「ソースを表示」で見るヘッダー Return-Path: エンベロープ From（MAIL FROM の値） Received: 通った MTA の記録（下から上へ）。送信元 IP が分かる Authentication-Results: spf=pass / dkim=pass / dmarc=pass と受信側の判定結果 DKIM-Signature: d= s= h= bh= b=
このページの用語集（14 語）から作った確認問題です。「意味 → 用語」は意味の説明（用語そのものは＿＿で伏せてある）を読んで用語を入力し、Enter で答え合わせします。 表記ゆれで × になったときは「合っていた」で直せます。「用語 → 意味」は口で説明してから答えを開いて自己採点します。結果はこのブラウザに保存され、「×だけ」で間違えた語だけを解き直せます。
作成 2026-10-28。ネットワークスペシャリスト 科目B（午後）対策。出典の年度・設問番号は IPA 公開の解答例で確認したもの（平成26年秋 午後Ⅱ問1、平成28年秋 午後Ⅰ問1、令和元年秋 午後Ⅱ問2、令和6年春 午後Ⅱ問2）。 関連: DNS とは、プロキシと SWG とは、午後 解答用紙 令和6年。