11. ログ分析とインシデント対応

SPF・DKIM・DMARCとは？3技術の関係・設定例・アライメントをSC試験対策で徹底解説

2026年6月12日

Kenta Banno

元CIOの窓際サラリーマン（50代）。プライム上場企業の片隅で、情報処理安全確保支援士の合格を目指して奮闘中！ 現在はAI（Gemini/Claude）を「壁打ち相手」として徹底活用し、日々の学習の備忘録とアウトプットを兼ねて記事を投稿しています。同じ資格を目指す初学者の参考になれば嬉しいです。

「自社ドメインを名乗る迷惑メールが取引先に届いている」：ある日突然、こんな連絡を受けたら何から手を付けるべきでしょうか。メールの送信元アドレス（From）は、実は技術的には誰でも自由に名乗れます。この「なりすまし放題」の仕組みを是正するために生まれたのが、SPF・DKIM・DMARCというメール認証（送信ドメイン認証）の3技術です。

2024年2月にGoogleが「メール送信者のガイドライン」を施行し、Gmail宛てに1日5,000通以上送信する事業者にはSPF・DKIM・DMARCの3点セットが事実上の必須要件となりました。もはやメール認証は「大企業のオプション」ではなく、メールを送るすべての組織にとっての基礎インフラです。そしてSC試験では、この3技術は午前II・午後を通じて最頻出クラスのテーマです。

この3技術は、単独では防げないなりすましを役割分担で補い合う「連携」がすべてです。本記事ではまず3技術の関係を1枚の図で俯瞰し、DNSレコードの設定例を並べて見比べたうえで、SC試験の論述で核心になるDMARCのアライメント、そして転送問題とARCまで深掘りします。前回の記事「ビジネスメール詐欺（BEC）の手口と対策」でBEC対策の文脈で紹介した概要の、深掘り編です。

この記事で学べること

  • SPF・DKIM・DMARC 3技術の関係と連携の全体像
  • メール認証の大前提：エンベロープFromとヘッダFromの違い
  • SPF・DKIM・DMARCそれぞれのDNSレコード（TXT）設定例と読み方
  • SPFのDNSルックアップ10回制限、DKIMのセレクタの役割
  • DMARCのアライメント（strict／relaxed）とポリシー制御・レポート機能
  • メール転送で認証が壊れる問題とARCによる解決
  • Googleから実際に届いたDMARC集計レポート（XML）の読み方
  • SC試験での出題パターンと午後試験で書けるべき論点

SPF・DKIM・DMARCの関係：3技術はどう連携するか

個別の仕組みに入る前に、3技術がどう連携するのかを俯瞰します。ここがつかめれば、後半の細かい構文もすべて「連携の中のどの役割か」として位置づけられます。

SPFとDKIMが認証結果を作り、DMARCが統括する

SPF・DKIM・DMARCは並列に並ぶ3つの対策ではありません。役割が重ならないよう分担された「層」です。まずSPFとDKIMが、それぞれ別の角度から「このメールは本当にこのドメインから出たものか」という認証結果を作ります。SPFは送信元IPアドレスの照合で、DKIMは電子署名の検証でこれを確認します。そのうえでDMARCが、この2つの認証結果を受信者の目に映るヘッダFromと突き合わせ、最終的な合否とその後の処置（配信・隔離・拒否）を統括します。

SPF・DKIM・DMARCの関係図。SPF（送信元IP照合）とDKIM（電子署名検証）が並列で認証結果を作り、その2つの結果をDMARCがヘッダFromとのアライメント検証で統括し、none／quarantine／rejectのポリシーを適用する流れ

この連携があるからこそ、単独では見抜けなかったなりすましが検出できます。SPFは転送に弱く、DKIMは本文加工に弱いという弱点を互いに補い、さらにDMARCが「認証は通っているが表示上の差出人だけ別ドメイン」という巧妙な偽装を初めて検出します。この補完関係こそ、SC試験の午後で論述させられる最重要ポイントです。

導入順序はSPF・DKIM → DMARC

連携の構造から、導入順序も自然に決まります。DMARCはSPFとDKIMの認証結果を材料にするため、先にSPFとDKIMを整備し、両方が安定して認証を通る状態にしてからDMARCを設定します。この順序を逆にすると、DMARCが参照すべき認証結果が揃っておらず、正規メールがいきなり隔離・拒否される事故につながります。「なぜこの順序か」を連携の仕組みから説明できると、午後問題での応用が効きます。

”
FREE PDF
SC午後記述
テンプレート集
登録特典
メール講座 登録で無料プレゼント
「知っているのに書けない」を、型で解消するPDF
設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。SC午後の記述で手が止まらなくなる1冊です。
設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し
無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

登録無料·いつでも配信停止

大前提：メールには「Fromが2つ」ある

SPF・DKIM・DMARCの理解でつまずく最大の原因は、この大前提を飛ばしてしまうことです。電子メールには送信者情報が2つ存在します。

1つ目は「エンベロープFrom」です。SMTP通信の MAIL FROM コマンドで指定される送信者アドレスで、配送エラー（バウンスメール）の返送先として使われます。封書に例えるなら「封筒の差出人欄」です。郵便局（メールサーバー）はこちらを見て配送処理を行います。

2つ目は「ヘッダFrom」です。メールデータ内の From: ヘッダに書かれたアドレスで、メールソフトが「差出人」として画面に表示するのはこちらです。封書に例えるなら「便箋に書かれた署名」です。受信者が目にするのはこちらだけです。

エンベロープFrom（封筒の差出人＝SMTPのMAIL FROM、サーバーが参照）とヘッダFrom（便箋の署名＝From:ヘッダ、受信者が参照）の比較図

重要なのは、この2つは一致している必要がなく、どちらも送信者が自由に設定できるという点です。攻撃者はエンベロープFromに自分のドメインを、ヘッダFromに「example.co.jp」のような正規ドメインを書くことで、受信者には本物に見えるなりすましメールを作れます。

このあと解説する3技術が「どちらのFromを検証するのか」を意識すると、全体像が一気にクリアになります。先に結論を示すと、SPFはエンベロープFromを、DKIMは署名対象（ヘッダFromを含む）を、DMARCはヘッダFromを基準に2つの認証結果を統合評価します。

SPF：送信元IPアドレスをDNSで照合する

仕組み：ドメインの「正規の送信元リスト」を公開する

SPF（Sender Policy Framework）は、「このドメインのメールを送ってよいサーバーのIPアドレス一覧」をDNSのTXTレコードで公開し、受信側が照合する仕組みです（RFC 7208）。

検証の流れはシンプルです。受信メールサーバーは、SMTP接続してきた相手のIPアドレスと、エンベロープFromのドメインを取得します。次にそのドメインのDNSへSPFレコードを問い合わせ、接続元IPがリストに含まれていれば「pass」、含まれていなければ「fail」などの判定を下します。

SPF検証フロー：送信サーバーからのメールを受けた受信サーバーが、送信側ドメインのDNSへSPFレコードを問い合わせ、接続元IPアドレスを許可リストと照合する図

レコード構文：試験でも実務でも読めるべき1行

SPFレコードは次のような1行のTXTレコードです。

v=spf1 ip4:203.0.113.0/24 include:_spf.example.net -all
  • v=spf1：SPFのバージョン宣言。必ず先頭に置きます。
  • ip4:203.0.113.0/24：許可する送信元IPアドレス（CIDR表記可）。ip6: でIPv6も指定できます。
  • include:_spf.example.net：他ドメインのSPFレコードを参照します。クラウドメールサービス（Google Workspace、Microsoft 365など）を使う場合、ベンダー指定のincludeを記述するのが定番です。
  • -all：上記に一致しなかった場合の指示です。-all（fail：認証失敗として扱う）と ~all（softfail：失敗寄りだが弱い表明）の違いは試験でも問われます。+all はすべて許可を意味し、SPFを無意味化する誤設定なので実務では厳禁です。

実務上の重要な制約として、SPF検証時のDNSルックアップ回数は10回までと定められています（RFC 7208）。includeを多段に重ねると上限を超えて「permerror」となり、認証が機能しなくなります。複数のクラウドサービスからメールを送る企業では意外と現実的な問題で、SPFレコードの棚卸しと平坦化（フラット化）が必要になるケースがあります。

SPFの2つの限界

SPFには構造的な限界が2つあり、これがDKIM・DMARCの存在理由になっています。

第一に、SPFが検証するのはエンベロープFromであり、受信者が目にするヘッダFromは検証しません。攻撃者が「エンベロープFrom＝攻撃者のドメイン（SPFはpass）、ヘッダFrom＝正規ドメイン」というメールを送れば、SPF単独では見抜けません。

第二に、メール転送に弱いことです。受信したメールを別のアドレスへ転送すると、送信元IPは転送サーバーのものに変わります。転送サーバーのIPは元ドメインのSPFレコードに載っていないため、正規のメールなのにSPFがfailする「誤判定」が起きます。

DKIM：電子署名でメールの正当性と完全性を保証する

仕組み：秘密鍵で署名し、DNSの公開鍵で検証する

DKIM（DomainKeys Identified Mail）は、送信サーバーがメールのヘッダと本文から計算した署名を DKIM-Signature: ヘッダとして付与し、受信サーバーがDNSに公開された公開鍵で検証する仕組みです（RFC 6376）。公開鍵暗号方式による電子署名の応用そのもので、SC試験的には「暗号分野とメール認証の交点」にあたります。

DKIMが保証するのは次の2点です。

  1. 送信ドメインの正当性：署名に使われた秘密鍵を持つのは、DNSに公開鍵を登録できるドメイン管理者だけです。署名が検証できれば、そのドメインの管理下で送信されたメールだと確認できます。
  2. メールの完全性：署名対象のヘッダや本文が配送途中で改ざんされると署名検証が失敗します。つまり改ざん検知の機能も持ちます。
DKIMの署名・検証フロー：送信サーバーが秘密鍵で署名を付与し、受信サーバーがDNSから取得した公開鍵で署名を検証する図

セレクタ：1ドメインで複数の鍵を使い分ける仕組み

DKIMの公開鍵は セレクタ名._domainkey.ドメイン名 というDNSレコードに置かれます。たとえばセレクタが s2026 なら s2026._domainkey.example.co.jp です。どのセレクタを使ったかは DKIM-Signature: ヘッダの s= タグで受信側に伝えられます。

セレクタの存在意義は鍵の使い分けと鍵ローテーションです。「自社メールサーバー用」「メール配信サービス用」で別の鍵を使ったり、定期的に新しい鍵へ切り替えたりする際、セレクタを変えるだけで並行運用できます。午後試験で「セレクタの役割を述べよ」と問われたら、「DNS上で複数の公開鍵を区別して公開し、署名検証時にどの鍵を使うかを指定するための識別子」と答えられるようにしておきましょう。

DKIMの限界

DKIMにも限界があります。メーリングリストが件名に [ML-name] を追記したり本文にフッタを付けたりすると、署名対象が書き換わり検証が失敗します（転送・加工に対する脆さ）。また、SPFと同様に「ヘッダFromと署名ドメインが一致しているか」まではDKIM自身は要求しません。攻撃者が自分のドメイン（attacker.example）で正しくDKIM署名しつつ、ヘッダFromに正規ドメインを書くことは可能です。この穴を塞ぐのが、次のDMARCの「アライメント」です。

DMARC：アライメント検証とポリシー制御で穴を塞ぐ

DMARCの本質は「ヘッダFromを基準にした統合評価」

DMARC（Domain-based Message Authentication, Reporting, and Conformance、RFC 7489）は、しばしば「SPFとDKIMの結果を使ってポリシーを適用する仕組み」と説明されます。それは正しいのですが、SC試験の論述で核心になるのはアライメント（alignment：ドメインの一致検証）という概念です。

DMARCは、受信者が実際に目にするヘッダFromのドメインを基準に、次の2つを評価します。

  • SPFアライメント：SPFがpassし、かつエンベロープFromのドメインがヘッダFromのドメインと一致するか
  • DKIMアライメント：DKIM署名が検証成功し、かつ署名ドメイン（d=タグ）がヘッダFromのドメインと一致するか

どちらか一方でも成立すればDMARCはpassです。SPF・DKIM単独では放置されていた「認証は通っているが、表示上の差出人は別ドメイン」というなりすましを、アライメントが初めて検出可能にします。ここがDMARCの最大の貢献です。

なお一致の判定には2モードあります。relaxed（緩和：組織ドメインが一致すればよい。mail.example.co.jpとexample.co.jpは一致扱い）と strict（厳格：完全一致のみ）で、既定はrelaxedです。

DMARCのアライメント検証フロー：SPF・DKIMの認証結果をヘッダFromのドメインと照合し、不一致時はnone/quarantine/rejectのポリシーを適用する図

DMARCレコードとポリシーの段階的引き上げ

DMARCレコードは _dmarc.ドメイン名 のTXTレコードとして公開します。

v=DMARC1; p=quarantine; rua=mailto:dmarc-report@example.co.jp; aspf=r; adkim=r
  • p=：ポリシー。none（何もしない・監視のみ）→quarantine（隔離）→reject（拒否）の3段階です。
  • rua=：集計レポート（Aggregate Report）の送付先。各受信プロバイダから「あなたのドメインを名乗るメールの認証結果統計」がXMLで日次送付されます。
  • aspf= / adkim=：アライメントモードの指定（r=relaxed / s=strict）。

導入は必ず p=none で開始し、レポートを数週間〜数か月分析して「正規のメール送信経路がすべて認証を通っているか」を確認してから quarantine→reject へ引き上げます。いきなりrejectにすると、把握していなかった正規送信経路（営業部門が契約していたメール配信サービスなど）からのメールが消失する事故につながります。この「段階的引き上げ」と「レポートによる可視化」は、午後試験で運用手順を書かせる問題の定番論点です。

転送問題の最終回答：ARC

DMARCをもってしても、メーリングリストや転送サービスの問題は残ります。転送でSPFは壊れ、本文加工でDKIMも壊れると、正規のメールがDMARC failとなり、rejectポリシーでは届かなくなってしまいます。

この問題に対する比較的新しい解決策がARC（Authenticated Received Chain、RFC 8617）です。転送サーバーが「転送を受け付けた時点での認証結果」をARCヘッダとして署名付きで記録し、それを連鎖（チェーン）させていきます。最終受信サーバーは、自分のところでDMARCがfailしても、信頼できる転送経路のARCチェーンを遡って「元の送信時点では認証passだった」ことを確認し、受け入れ判定に活かせます。GmailやMicrosoft 365はすでにARCを実装しています。SC試験でも近年の動向問題として出題されうる、押さえておきたいキーワードです。

DNSレコード設定例：SPF・DKIM・DMARCを1か所で見比べる

3技術はいずれもDNSへのレコード登録が設定の中心です。ここまで各節で断片的に登場したレコードを、1か所に並べて見比べられるよう整理します。設定はどれも「DNSにTXTレコードを1行（DKIMは公開鍵のみ長め）追加する」という共通の形をとります。

3技術のDNSレコードを並べて見る

example.co.jp というドメインで3技術を設定した場合の例です（値はいずれもドキュメント用の例示値です）。

; SPF：ドメイン直下のTXTレコード
example.co.jp.                 IN TXT "v=spf1 ip4:203.0.113.0/24 include:_spf.example.net -all"

; DKIM：セレクタ名._domainkey サブドメインのTXTレコード（公開鍵を公開）
s2026._domainkey.example.co.jp. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...（公開鍵が続く）"

; DMARC：_dmarc サブドメインのTXTレコード（ポリシーを宣言）
_dmarc.example.co.jp.          IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.co.jp; aspf=r; adkim=r"

レコードを置く「場所」が3技術で異なる点に注目してください。SPFはドメイン直下、DKIMは セレクタ名._domainkey のサブドメイン、DMARCは _dmarc のサブドメインです。どこに何を置くかが問われる午後問題もあるため、この対応は押さえておきます。

設定手順と学び始めに間違えやすいポイント

実際の設定手順は次の流れになります。先ほど述べたとおり、DMARCが認証結果を材料にするため、SPF・DKIMを先に整えてからDMARCへ進みます。

  1. SPF：自社が使う送信サーバー・クラウドサービスの送信元をすべて洗い出し、ip4: や include: で列挙してドメイン直下にTXTレコードを1行登録する。
  2. DKIM：送信側（メールサーバーや配信サービス）で鍵ペアを生成し、公開鍵を セレクタ名._domainkey のTXTレコードとして登録、秘密鍵で署名するよう送信側を設定する。
  3. DMARC：SPF・DKIMが両方安定して通ることを確認してから、_dmarc に p=none でレコードを登録し、集計レポート（rua=）を受けながら段階的にポリシーを引き上げる。

学び始めの人がつまずきやすい点を挙げておきます。第一に、-all と ~all の取り違えです。「とりあえず緩くしておこう」と ~all や、最悪 +all にしてしまうと、SPFの防御効果が骨抜きになります。第二に、SPFレコードを複数行に分けて登録してしまう誤りです。1ドメインのSPFは原則1レコードにまとめる必要があり、複数のSPFレコードが存在すると「permerror」で認証が機能しなくなります。第三に、DKIMの秘密鍵と公開鍵の取り違えです。DNSに公開するのは必ず公開鍵で、秘密鍵は署名する送信側だけが持ちます。この基本を外すと署名検証がすべて失敗します。

実例で読む：Googleから届いたDMARC集計レポート

ここからは実物を見てみましょう。筆者は運営する別ドメイン（本記事では example.jp と表記します）をエックスサーバー（XSERVER）で運用しており、サーバーパネルからSPF・DKIM・DMARCを設定しました。するとある日から、noreply-dmarc-support@google.com という差出人で「Report domain: example.jp Submitter: google.com Report-ID: 7889646052985XXXXXX」という件名のメールが届くようになりました。

正直に言うと、初めて受け取ったときは何のメールなのかよく分かりませんでした。ZIPファイルが添付された英語の機械的なメールですから、知らなければ不審なメールと疑ってもおかしくありません。しかしSC試験の勉強でDMARCのレポート機能（rua= タグ）を学んでいたおかげで、「これがあの集計レポートか」と理解できました。逆に言えば、勉強していなければ自社ドメインのなりすまし被害にも、設定ミスで他社に迷惑をかけていることにも気づけないわけです。この分野を学ぶ重要性を日々痛感しています。

このメールの正体は、DMARCレコードの rua= で指定した宛先に送られてくる集計レポート（Aggregate Report）です。Gmailなどの受信プロバイダが「あなたのドメインを名乗るメールをこれだけ受け取り、認証結果はこうだった」という統計を、原則1日1通、圧縮されたXMLファイル（Googleの場合はZIP形式）で送ってきます。添付ファイル名 google.com!example.jp!1780963200!1781049599.zip も「報告組織!対象ドメイン!集計開始!集計終了」という規約に沿っています。末尾の数字はUNIXタイムスタンプで、この例は2026年6月9日（UTC）の24時間分を意味します。

実際に届いたXMLの中身がこちらです（※ドメイン名・IPアドレス・Report-ID・サーバーホスト名の数字部分は、プライバシー保護のため加工しています。IPアドレスにはRFC 5737のドキュメント用アドレスを使用しています）。

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>7889646052985XXXXXX</report_id>
    <date_range>
      <begin>1780963200</begin>
      <end>1781049599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.jp</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.25</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.jp</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.jp</domain>
        <result>pass</result>
        <selector>default</selector>
      </dkim>
      <spf>
        <domain>svXXXXX.xserver.jp</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

report_metadata：誰が・いつの分を報告しているか

org_name と email はレポートの報告元（ここではGoogle）、date_range は集計期間です。本記事で学んだ知識がそのまま使われていることが分かります。

policy_published：受信側が参照したポリシーの控え

p=reject・sp=reject（サブドメインへのポリシー）・pct=100（適用割合100%）と、このドメインは最終段階のrejectまで引き上げ済みです。adkim=r・aspf=r はアライメントモードがどちらもrelaxed（既定値）であることを示します。受信側のGoogleが「DNSからこう読み取りましたよ」と控えを返してくれているわけです。

record：1レコード＝ある送信元IPからのメールの認証結果

ここが本記事のハイライトです。よく見ると、一見矛盾した記載があります。

  • auth_results の spf は result=pass（検証対象ドメインは svXXXXX.xserver.jp）
  • policy_evaluated の spf は fail

これは矛盾ではありません。auth_results は生の認証結果、policy_evaluated はアライメント込みのDMARC評価です。エックスサーバーでは、サーバー上のプログラムから自動送信されるメール（お問い合わせフォームの通知など）の場合、配送エラー処理のためエンベロープFromにサーバーのホスト名（svXXXXX.xserver.jp）が使われます。送信元IP（198.51.100.25）はそのドメインのSPFレコードに載っているため生のSPFはpassしますが、ヘッダFrom（example.jp）とドメインが一致しないため、SPFアライメントとしてはfailになるのです。

実例レポートの判定図：SPFは生の検証がpassでもヘッダFromとの不一致でアライメント不成立、DKIMは署名ドメインが一致してアライメント成立、片方成立のためDMARC全体はpassとなる流れ

一方のDKIMは、署名ドメイン（d=example.jp、セレクタは default）がヘッダFromと一致し、アライメント成立です。DMARCは「どちらか一方が成立すればpass」なので全体はpassとなり、disposition は none、つまりp=rejectのポリシー下でも処置なしで正常配信されました。

この1通のレポートに、本記事で解説した「生の認証結果とアライメントの区別」「2経路のうち1つ通ればよい」という設計がすべて詰まっています。実務上の教訓も明確です。レンタルサーバーやメール配信サービス経由の送信ではSPFアライメントが構造的に成立しにくいため、自ドメインでのDKIM署名設定が実質的な生命線になります。もしこの環境でDKIMを設定し忘れていたら、p=rejectの下で自分の正規メールがすべて拒否されていたところです。

3技術の役割分担を1枚の表で整理する

ここまでの内容を試験直前に思い出せる形で整理します。

観点SPFDKIMDMARC
検証対象エンベロープFromのドメインと送信元IP電子署名（署名ドメインと本文・ヘッダの完全性）ヘッダFromと両者のアライメント
使う仕組みDNSのTXTレコード（許可IPリスト）公開鍵暗号による署名＋DNSの公開鍵DNSのTXTレコード（ポリシー宣言）
レコードの場所ドメイン直下セレクタ名._domainkey_dmarc
強み実装が容易転送でIPが変わっても有効・改ざん検知表示上のなりすまし検出・ポリシー制御・レポート
弱み転送で壊れる・ヘッダFrom未検証本文加工で壊れる・ヘッダFromとの一致は不問SPF/DKIMの整備が前提・転送問題は残る（→ARC）

この表を暗記するのではなく、前節の実例レポートと突き合わせながら「自分のドメインならどうなるか」を考えてみてください。3技術の役割分担が、知識ではなく実感として定着するはずです。

SC試験での出題パターンと対策

メール認証はSC試験で繰り返し出題されてきた定番分野です。たとえば令和6年度 秋期 午前II 問10では、「送信ドメイン認証が失敗したときの処理方針を、送信側のドメイン管理者が指定するための仕組みはどれか」が問われ、正解はDMARCでした。DKIM（署名による改ざん検証）、SPF（送信元IPの検証）、SMTP-AUTH（送信時のユーザー認証）を並べ、「失敗時の処理方針を送信側が指定する」というDMARC固有の役割を選ばせる、連携の理解を突く良問です。出題のされ方は大きく3パターンに整理できます。

パターン1：午前IIでの仕組みの正誤判定。 「SPFの仕組みはどれか」「DKIMに関する記述として適切なものはどれか」という形式です。選択肢には「受信側が送信元IPをDNSの情報と照合する＝SPF」「電子署名を検証する＝DKIM」「S/MIMEやPGP（利用者間のエンドツーエンド暗号化・署名）」が混ざって出ます。「サーバー間の送信ドメイン認証（SPF/DKIM）」と「利用者間の暗号化・署名（S/MIME/PGP）」を混同させる選択肢が定番のひっかけです。

パターン2：午後での設定・運用問題。 SPFレコードの空欄補充（-all と ~all の選択理由）、DMARC導入手順（noneから始める理由）、メール配信サービス追加時にSPF/DKIMをどう設定するか、といった実務寄りの問題です。本記事のレコード構文が読み書きできれば対応できます。

パターン3：限界と補完関係の論述。 「SPFで検知できないなりすましをDMARCがどう検知するか」を問う問題です。解答の核は本記事で繰り返した一点、すなわち「SPFはエンベロープFromしか見ないが、DMARCはヘッダFromとのアライメントを検証する」です。これを自分の言葉で2〜3文で書けるよう練習しておきましょう。

また、BECとの複合問題（組織的対策と技術的対策の組み合わせ）も想定されます。アカウント乗っ取り型BECには3技術が無力である点（正規アカウントからの送信は認証をすべて通過する）まで言及できると、論述の完成度が上がります。

【演習】SPF・DKIM・DMARC理解度チェック（全10問）

メール認証に関する問題は、SC試験では「SPF・DKIMの仕組みを選ぶ午前II問題」と「DMARCのアライメントや導入手順を説明する午後問題」の両方で出題が想定されます。選択肢には、S/MIMEとの混同、SPFとDKIMの検証対象の入れ替え、-all と ~all の取り違えといった、本記事で解説したポイントを突くひっかけが定番として登場します。以下の練習問題で本記事の理解度を確認してみましょう。

【練習問題】SPF・DKIM・DMARC理解度チェック（全10問）

まとめ：3技術は「層」で理解する

SPF・DKIM・DMARCは並列の3技術ではなく、役割の異なる層の積み重ねです。SPFが「送信元IPの照合」、DKIMが「電子署名による正当性と完全性の保証」という認証結果を作り、DMARCが「受信者の目に映るヘッダFromとのアライメント検証」と「ポリシー制御・レポート」で全体を統括します。さらに転送問題への回答としてARCが加わり、メール認証のエコシステムは今も進化を続けています。

試験対策としての最優先事項は、「エンベロープFromとヘッダFromの区別」を出発点に、各技術が何を検証して何を検証しないのかを自分の言葉で説明できるようになることです。本記事の関係図・比較表・DNSレコード設定例を白紙に再現できれば、午前II・午後のどちらにも対応できます。

実務の観点でも、メール送信者のガイドライン施行以降、メール認証は「設定していないとメールが届かない」時代に入りました。筆者のもとに届いたDMARCレポートを読み解けたのは、まさにSC試験の勉強のおかげです。試験勉強がそのまま実務スキルになる、投資効率の高いテーマです。確実に得点源にしましょう。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

”
FREE PDF
SC午後記述
テンプレート集
登録特典
メール講座 登録で無料プレゼント
「知っているのに書けない」を、型で解消するPDF
設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。SC午後の記述で手が止まらなくなる1冊です。
設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し
無料でPDFを受け取る →

＋おまけ：毎日1通の無料メール講座つき。登録した日が「1日目」、図解と論理で16週間かけて基礎も固まります。

登録無料·いつでも配信停止
自社のセキュリティ対策に不安はありませんか？
BKサクセスでは、専任の情シスがいない中小企業様向けに、伴走型のセキュリティ対策支援を行っています。
まずは無料相談から、お気軽にご連絡ください。
✉️ セキュリティ対策について相談する（無料）

▼ 本気で難関資格を狙うなら、攻略法から

  • この記事を書いた人

Kenta Banno

元CIOの窓際サラリーマン（50代）。プライム上場企業の片隅で、情報処理安全確保支援士の合格を目指して奮闘中！ 現在はAI（Gemini/Claude）を「壁打ち相手」として徹底活用し、日々の学習の備忘録とアウトプットを兼ねて記事を投稿しています。同じ資格を目指す初学者の参考になれば嬉しいです。

-11. ログ分析とインシデント対応