【徹底解説】なりすましメール対策の要！SPF・DKIM・DMARCの仕組みと設定手順

ビジネスにおけるコミュニケーションの基盤として、電子メールは今なお最も重要なツールです。しかし、その重要性と引き換えに、メールは常にサイバー攻撃の標的となっています。特に、取引先や実在する企業を装って偽のメールを送りつける「なりすましメール」は、フィッシング詐欺やマルウェア感染（Emotetなど）の入り口として、年々その手口が巧妙化しています。

情報処理安全確保支援士（SC）試験においても、メールセキュリティは午前Ⅱ・午後試験共に頻出の超重要テーマです。

「なぜ、なりすましは簡単に行われてしまうのか？」「SPF、DKIM、DMARCは具体的にDNSにどう記述するのか？」「メール転送時に認証が失敗するのはなぜか？」

これらの問いに即答できない場合、午後の記述式問題で苦戦することになります。本記事では、セキュリティ担当者が押さえておくべき実務知識と、試験で問われる技術的詳細を融合させ、送信ドメイン認証の「実体」を徹底的に解説します。単なる用語の暗記ではなく、メールが届く裏側のロジックを完全に理解していきましょう。

1. なぜ「なりすまし」は可能なのか？ SMTPの脆弱性

現代のセキュリティ技術を理解するためには、まず「なぜ守る必要があるのか」、その攻撃の起点となるプロトコルの弱点を知る必要があります。電子メールの送信に使われるSMTP (Simple Mail Transfer Protocol) は、インターネット黎明期の「性善説」に基づいて設計されており、送信元の身元を厳格に確認する機能を持っていませんでした。

郵便封筒と便箋の違い（EnvelopeとHeader）

メールの仕組みは、よく郵便物に例えられます。この例えは、情報処理安全確保支援士試験で頻出の「エンベロープ」と「ヘッダー」の違いを理解する上で非常に重要です。

郵便の封筒と便箋を例にしたEnvelope FromとHeader Fromの違いを示す図解

Envelope From（エンベロープ・フロム）

SMTP通信のMAIL FROMコマンドで指定されるアドレスです。メールサーバー（MTA）が配送のために参照する「封筒の裏書き（差出人）」にあたります。配送エラーメール（バウンスメール）の返送先となります。

Header From（ヘッダー・フロム）

メールデータ内のFromヘッダーに記載されるアドレスです。メールソフト（MUA）上で受信者が「差出人」として目にする「便箋の署名」にあたります。

情報処理安全確保支援士試験のツボ

SMTPの仕様上、この2つは一致している必要がありません。攻撃者は、Envelope Fromを自分の管理下にあるドメイン（攻撃用サーバー）にしつつ、Header Fromに「ceo@bank.example」のような信頼できるアドレスを記述してメールを送信します。受信者は通常、メールソフト上のHeader Fromしか見ないため、簡単になりすましに騙されてしまうのです。

この「詐称」を見抜くために、受信側サーバーが「本当にそのドメインの管理者から送られてきたのか？」を検証する仕組みが必要になります。それが、これから解説する3つの送信ドメイン認証技術です。

なりすましメールの具体的な手口

攻撃者は、自分で立てたメールサーバーから、SMTP通信を使って任意のHeader Fromアドレスを設定してメールを送信できます。技術的な知識があれば、数十分で実行可能です。受信側のメールサーバーは、送信元の正当性を確認する術を持たないため、そのまま配送してしまいます。

この根本的な問題に対処するため、DNS（Domain Name System）を活用した認証の仕組みが考案されました。ドメインの正当な管理者だけがDNSレコードを設定できることを利用し、「このドメインからメールを送信できるのは、これらのサーバーだけです」という情報を公開するのです。

無料メール講座登録特典FREE PDF

SC午後記述テンプレート集

設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。「知っているのに書けない」を解消する1冊です。

設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し

無料でPDFを受け取る →

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

2. SPF（Sender Policy Framework）：IPアドレスによる検証

SPFは、最も普及している基本的な認証技術であり、「送信元IPアドレスのホワイトリスト」アプローチを採用しています。

SPFの仕組み

ドメインの管理者は、あらかじめ自社のドメインを管理するDNSサーバーに、「このドメインのメールを送っても良いIPアドレス（メールサーバー）」のリストをSPFレコード（TXTレコード）として公開しておきます。

受信側サーバーは、以下のフローで検証を行います。

SMTP接続をしてきた送信元サーバーのグローバルIPアドレスを確認する
SMTP通信のEnvelope Fromのドメインを取り出す（ここが重要です。Header Fromではありません）。
※ただし、配送エラー通知などでEnvelope Fromが空（MAIL FROM: <>）の場合は、SMTP通信のEHLO/HELOコマンドで申告されたドメインを使用します。
特定したドメインのDNSサーバーに問い合わせを行い、SPFレコードを取得する
取得したレコード内に、送信元のIPアドレスが含まれているかを確認する
- 含まれていれば「Pass（合格）」
- 含まれていなければ「Fail（不合格）」や「SoftFail」など（このほか Neutral・None・TempError・PermError といった結果もあります）

SPFレコードの構文と読み方（試験対策）

午後試験では、SPFレコードの中身を読み解く力が問われやすい傾向にあります。各タグの意味を正確に把握しておきましょう。

記述例:

example.com.  IN  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all"

タグ	意味と解説
v=spf1	SPFのバージョン1であることを宣言します（必須）。
ip4:xxx	指定したIPv4アドレスからの送信を許可します。CIDR表記（/24など）も可能です。
include:xxx	指定した別ドメインのSPFレコードを参照（インクルード）します。GmailやMicrosoft 365などのクラウドサービスを利用する場合に必須となります。
a / mx	ドメインのAレコードやMXレコードで指定されているIPアドレスを許可します。
-all	Hard Fail。上記以外のIPからの送信を「明確に拒否（認証失敗）」します。
~all	SoftFail。上記以外からの送信は失敗とするが、受信拒否まではしない（迷惑メールフォルダに入れるなど）。移行期間によく使われます。
+all	どのようなIPからの送信も許可する（テスト用以外では設定してはいけません）。

SPF設定の実務ポイント

複数のメール配信システムを利用している企業では、includeディレクティブを複数記述することで、各サービスのSPFレコードを統合できます。ただし、DNS参照を伴う項目（include・a・mx・ptr・exists・redirect）の合計は10回までという上限があり、includeの入れ子先の参照も合算されるため、includeの多用には注意が必要です（詳細は第6章）。

また、ip4やip6で直接IPアドレスを指定する場合、サーバーのIP変更時にSPFレコードの更新も必要になります。クラウドサービスのようにIPアドレスが頻繁に変わる環境では、includeを使った方が管理が楽になります。

SPFの限界と弱点

SPFは導入が容易ですが、構造的な弱点があります。それは「メール転送」に弱いことです。

自動転送（Envelope Fromを書き換えずに再送する転送）を経由する場合、受信側から見ると「転送サーバー」が送信元となります。しかし、元のドメインのSPFレコードには、転送サーバーのIPアドレスなど記載されていません。そのため、正規のメールであっても、転送を経由することで送信元IPが変わり、SPF認証に失敗（Fail）してしまうことがあります。

この問題は、SPFの設計思想に起因します。SPFはEnvelope Fromのドメインと送信元IPの関係のみを検証するため、途中でメールが転送されると、その関係性が崩れてしまうのです。

なお、メーリングリストは通常Envelope Fromを自分のbounceアドレスに書き換えるため、SPF自体は通りますが、DMARCのSPFアライメントが合わなくなります（第7章ケース2）。

対策として、転送サーバー側でSRS（Sender Rewriting Scheme）を使い、Envelope Fromを転送サーバーのドメインに書き換える方法があります。ただし、SRSでSPFは通るようになっても、Envelope Fromのドメインが転送サーバーのものに変わるため、DMARCのSPFアライメントは合いません。

3. DKIM（DomainKeys Identified Mail）：電子署名による検証

SPFが「どこから来たか（経路）」を検証するのに対し、DKIMは「どのドメインが署名（責任を表明）したか」と「改ざんされていないか（完全性）」を検証します。公開鍵暗号方式を利用して、メールヘッダーに電子署名を付与する技術です。

DKIMの仕組み

DKIMは、送信側サーバーと受信側サーバーの間で、秘密鍵と公開鍵を使って検証を行います。

送信側の処理

メール送信サーバーは、まずメールの「本文」からハッシュ値を計算します（これがDKIM-Signatureヘッダーの bh= タグの値になります）。
署名対象の「ヘッダー（件名や宛先など）」に、先ほど作成した bh= を含む作成途中のDKIM-Signatureヘッダー自身を加えて、全体のハッシュ値を計算します。
その全体のハッシュ値を、サーバーが持つ「秘密鍵」で暗号化して（RSAの場合）署名します（これが b= タグの電子署名データとなります）。
完成したDKIM-Signatureヘッダーをメールに付与して送信します。

受信側の処理

メールを受信したら、DKIM-Signatureヘッダーを確認します
ヘッダー内に記載された「ドメイン（d=）」と「セレクタ（s=）」を元に、DNSサーバーから「公開鍵」を取得します
取得した公開鍵を使って、電子署名を検証します（RSAの場合は署名を復号して元のハッシュ値を取り出すイメージ）
同時に、受信したメールから改めてハッシュ値を計算します
「復号したハッシュ値（RSAの場合）」と「計算したハッシュ値」が一致すれば、そのドメインの秘密鍵で署名されたものであり、署名後に改ざんされていないことが確認できます（Pass）

DKIMの署名作成から検証までの流れを示す図解、秘密鍵による署名と公開鍵による検証

DKIMシグネチャの詳細解説

DKIMヘッダーは暗号化された文字列の羅列に見えますが、試験ではパラメータの意味が問われます。

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
  c=relaxed/relaxed; q=dns/txt;
  h=from:to:subject:date;
  bh=abcdef12345...;
  b=xyz7890...;

d= (Domain): 署名を行ったドメイン。検証の起点となります
s= (Selector): セレクタ。一つのドメインで複数の鍵ペアを使い分けるための識別子です。例えば、部署ごとに鍵を変えたり、定期的な鍵交換（ローテーション）を行うために使われます。DNSへの問い合わせ先は[セレクタ]._domainkey.[ドメイン名]となります
a= (Algorithm): 署名作成に使ったアルゴリズム（例：rsa-sha256）
c= (Canonicalization): 正規化方式。header/bodyの順で指定し、省略時の既定値はsimple/simpleです
- simple: ヘッダーや本文の空白などを厳密に扱う。少しの変更でも認証失敗になる
- relaxed: 連続する空白を一つにまとめるなど、柔軟に扱う。転送や中継で空白や折り返しが変わっても署名が壊れにくいため、実務ではrelaxedを使うのが慣行です（仕様上の推奨ではなく運用上の慣行です）
h= (Headers): 署名対象に含めたヘッダーフィールドのリスト。ここに列挙されたヘッダーが改ざんされると、署名検証が失敗します
bh= (Body Hash): メール本文のハッシュ値
b= (Signature): 電子署名データそのもの

セレクタの戦略的活用

セレクタは、単なる識別子以上の役割を果たします。組織内で複数の部署や用途別にメールサーバーを運用している場合、それぞれに異なるセレクタと鍵ペアを割り当てることで、セキュリティインシデント発生時の影響範囲を限定できます。

例えば、マーケティング部門のメールサーバーが侵害された場合、そのセレクタに対応する鍵だけを無効化すれば良く、他の部門のメール送信には影響しません。また、定期的な鍵のローテーション（例：3〜6ヶ月ごとに新しいセレクタに切り替え）により、長期的な鍵の漏洩リスクを低減できます。

DKIMのメリットと限界

DKIMの最大のメリットは、メール転送に強いことです。転送サーバーがメールのヘッダーや本文を書き換えない限り、署名は有効なままだからです。

一方で、DKIM単体では「Header From（差出人）」の詐称を完全には防げません。なぜなら、攻撃者が「自分のドメイン（attacker.example）」で正当な署名を作成して送った場合、DKIMの検証自体は「attacker.exampleからの正当な署名である」としてPassしてしまうからです（受信者はHeader Fromのexample.comしか見ていないのに）。

この問題を解決するのが、次に説明するDMARCのアライメント機能です。

4. DMARC：ポリシーと認証の統合

SPFとDKIMは強力ですが、それぞれ単独では不十分であり、「認証に失敗したメールをどう扱うべきか」という指示を受信側に与える機能がありませんでした。それを解決し、2つの技術を統合的に管理するのがDMARC (Domain-based Message Authentication, Reporting, and Conformance)です。

DMARCの3つの役割

DMARCは、DNSのTXTレコード（_dmarc.ドメイン名）として設定され、以下の役割を持ちます。

ポリシー宣言: DMARC評価に失敗した（アラインしたpassがない）メールを、受信側でどう扱ってほしいか（通す、隔離、拒否）を指示する
アライメント（Alignment）検証: 「Header Fromのドメイン」と、「SPF/DKIMで認証されたドメイン」が一致しているかをチェックする。これがなりすまし対策の決定打となります
レポート機能: 自ドメインを騙るメールがどれくらい送られているか、認証結果のレポート（RUA/RUF）を受信側から受け取る

最重要概念：DMARCのアライメント（Alignment）

ここが試験の山場であり、DMARCの核心です。DMARCが「合格（Pass）」となるためには、以下の条件を満たす必要があります。

条件: SPFまたはDKIMの、少なくともどちらか一方が「認証Pass」かつ「アライメントOK」であること。

SPFアライメント: Envelope Fromのドメインと、Header Fromのドメインが一致しているか
DKIMアライメント: DKIM署名のd=タグのドメインと、Header Fromのドメインが一致しているか

攻撃者が自分のドメインでDKIM署名をして送ってきた場合、DKIMの認証自体はPassしますが、Header From（詐称されたドメイン）と一致しないため、DKIMアライメントはNGとなり、DMARC全体として失敗させることができます。

アライメントモード：StrictとRelaxed

DMARCのアライメント検証には、2つのモードがあります。

Relaxed（緩和）モード（デフォルト）

組織ドメインが一致していればOKとします。例えば、Header Fromがuser@mail.example.comで、SPFのEnvelope Fromがbounce@marketing.example.comの場合、両方ともexample.comという組織ドメインを共有しているため、アライメントは成功します。

Strict（厳格）モード

完全一致を要求します。上記の例では、mail.example.comとmarketing.example.comは異なるため、アライメントは失敗します。

一般的には、Relaxedモードで運用することが推奨されます。Strictは、サブドメインを外部委託先等に委任していて、そのサブドメインの認証結果で親ドメインのHeader Fromをパスさせたくない場合などに使います。なお、サブドメインに別のポリシーを適用したい場合はアライメントモードではなくsp=タグの役割です。

DMARCレコードの設定例とポリシー

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

タグ	意味
p=	Policy（ポリシー）。認証失敗時の扱いを指定します。・`none`: 何もしない（監視モード）。ログ収集フェーズで使用・`quarantine`: 隔離。迷惑メールフォルダ等へ送る・`reject`: 拒否。受信を拒絶する（最も強力）
pct=	Percentage。RFC 7489でポリシーを適用するメールの割合（0〜100、既定は100）。初期導入時に`pct=10`などとして徐々に適用範囲を広げる運用が行われてきました。2026年5月のRFC 9989でpctは廃止扱い（historic）となり、テストモード`t=y`に置換されました。試験はRFC 7489準拠です
rua=	Reporting URI for Aggregate data。集計レポート（XML形式）の送付先URI。単なるメールアドレスではなく、「mailto:dmarc-reports@example.com」のようにURI形式で記述する必要があります。
ruf=	Reporting URI for Forensic data。失敗時の詳細レポート（フォレンジック）の送付先URI（mailto:形式）。プライバシーの観点から対応していないプロバイダも多いです
aspf= / adkim=	アライメントの厳格さ（`r`: relaxed / `s`: strict）。デフォルトは`relaxed`（組織ドメインの一致で可）
sp=	Subdomain Policy。サブドメインに対する個別のポリシーを指定できます
t=	Testing（RFC 9989で追加）。`t=y`のとき、`quarantine`は`none`相当、`reject`は`quarantine`相当で扱うよう受信側に求めます。同じくRFC 9989で、存在しないサブドメイン用の`np=`、パブリックサフィックスドメイン用の`psd=`も追加されました

DMARCポリシーの段階的強化レベルを示す図、none・quarantine・rejectの違い

RFC 9989（2026年5月）について

DMARCの仕様は、長らく試験でも基準となってきたRFC 7489（Informational）に代わり、2026年5月にRFC 9989（Standards Track）として改訂されました。集計レポートはRFC 9990、失敗レポートはRFC 9991に分離されています。pctはhistoric（廃止扱い）となりt=yに置換され、組織ドメインの判定もPublic Suffix ListからDNS Tree Walkへ変わりました。v=DMARC1の既存レコードは引き続き有効です。本記事の説明は試験で定番のRFC 7489準拠を基本とし、改訂点は補足として触れます。

DMARCレポートの活用

DMARCレポート（RUA）は、自ドメインを使ったメール送信の全体像を把握するための貴重な情報源です。レポートには以下の情報が含まれます。

送信元IPアドレス
メール送信数
SPF/DKIMの認証結果
アライメント結果
受信側のポリシー適用結果

これらのデータを分析することで、「知らないうちに使われていた社内のメール送信システム」や「委託先が勝手に使っているメール配信サービス」を発見できます。こうしたシャドーITを把握し、正規の送信元としてSPF/DKIMレコードに追加することが、DMARC導入成功の鍵となります。

5. 試験合格への戦略的学習ポイント

情報処理安全確保支援士試験でこの分野が得点源になるよう、間違いやすいポイントを整理します。

午前Ⅱ試験対策

3要素の区別

SPF = IPアドレス（Envelope From）
DKIM = 電子署名（Header/Body）
DMARC = ポリシー宣言＋アライメント（Header Fromとの一致）

この対応関係を即座に引き出せるようにしてください。

DNSレコード

すべてTXTレコードを使用することを覚えておきましょう（SPF専用のレコードタイプは廃止されました）。

認証フローの理解

午前問題では、「どの要素がどのタイミングで検証されるか」が問われやすい論点です。SPFはSMTPセッション中に検証でき、DKIMはメッセージ全体（ヘッダーと本文）が揃ってから検証します（DATA終了時点でSMTPセッション内に検証するMTAもあれば、受信後に処理するものもあります）。最後に、SPFとDKIMの結果を受けてDMARCがアライメントとポリシーを判定する、という順序を正確に把握しましょう。

メール配信プロセスにおけるSPF・DKIM・DMARC検証のタイミングを示すタイムライン図

午後試験（記述）対策

転送問題

「自動転送（転送設定）経由のメールが届かない、または迷惑メール扱いになる」というトラブルシューティング問題が出たら、SPFの転送における脆弱性を疑ってください。解答例としては「転送サーバーでEnvelope Fromが書き換わらないため、送信元IPとSPFレコードが不一致になる」といった記述が求められます。

DMARC導入シナリオ

いきなりp=rejectに設定すると、正規のメール（特に外部サービスからの委託メールや転送メール）まで届かなくなるリスクがあります。

解答の定石プロセス

p=noneで導入し、レポート（rua）を収集する
レポートを分析し、正規の未認証サーバー（シャドーITなど）を特定・SPF/DKIMに追加する
p=quarantineへ移行し、様子を見る
最終的にp=rejectへ移行する

この「段階的導入」の流れは、記述問題や穴埋め問題での頻出パターンです。

DNSレコード読解問題

午後試験では、実際のSPF/DKIM/DMARCレコードが提示され、「このレコードの意味を説明せよ」「不適切な設定を指摘せよ」といった形で問われやすい傾向があります。特に以下の点に注意しましょう。

SPFのDNS参照を伴う項目（include・a・mx・ptr・exists・redirect）の合計が10回を超えていないか（includeの入れ子先も合算。制限違反はPermError）
DKIMのセレクタが適切に運用されているか（鍵のローテーション戦略）
DMARCの段階的導入（p=none→quarantine→reject）が適切か。RFC 7489準拠の出題ではpctの使い方も問われる

6. 実装時の注意点とベストプラクティス

SPF実装のポイント

DNS問い合わせ回数の制限

SPFレコードの評価では、DNS参照を伴う項目（include・a・mx・ptr・exists・redirect）の合計が最大10回までしか許可されていません。includeの入れ子先の参照も合算され、ip4・ip6・allは数えません。11回目以降でSPF認証は「PermError」となり、DMARC上は「passしない」扱いです（結果としてSPFでのDMARC合格にはなりません）。また、存在しないドメインなど結果が空になる参照（void lookup）は2回までという制限もあります（RFC 7208 §4.6.4）。

大企業や複数のメール配信サービスを利用している組織では、この制限に引っかかりやすいため、以下の対策が必要です。

不要なincludeディレクティブを削除する
可能な限りip4やip6で直接指定する
SPF Flatteningツールを使用して、includeを展開する

SPF Flatteningの注意点

SPF Flatteningは、includeで参照している外部ドメインのIPアドレスリストを取得し、自ドメインのSPFレコードに直接記述する手法です。DNS問い合わせ回数は削減できますが、参照先のIPアドレスが変更された場合に自動追従できないという欠点があります。定期的な見直しが必要です。

DKIM実装のポイント

鍵長の選択

DKIMで使用するRSA鍵は、現在2048ビット以上が強く推奨されています。RFC 8301（2018年）により、署名者は最低でも1024ビット以上のRSA鍵を使用しなければならない（MUST）と定められ、1024ビット未満の鍵（512ビットなど）は使用禁止となりました。さらに同RFC内で、2048ビット以上のRSA鍵の使用が推奨（SHOULD）されています。現在ではセキュリティの観点から1024ビット鍵を脆弱とみなす受信サーバーも増えているため、実務上は2048ビット以上を選択するのがデファクトスタンダードです。なお、2048ビット鍵の公開鍵はTXTレコードの1文字列あたり255文字の制限に収まらないため、複数の文字列に分割して登録する必要があります（DNS事業者によっては自動で分割されます）。

鍵のローテーション

秘密鍵が漏洩した場合のリスクを最小化するため、定期的な鍵のローテーション（例：3〜6ヶ月ごと）が推奨されます。M3AAWGも少なくとも6か月ごとの交換を推奨しています。セレクタを活用することで、新旧の鍵を並行運用でき、無停止での切り替えが可能です。

署名対象ヘッダーの選択

h=タグで指定する署名対象ヘッダーは、改ざんされると困る重要なヘッダーを含める必要があります。最低限、from、to、subject、dateは含めるべきです。また、message-idやin-reply-toを含めることで、スレッドの改ざんも防げます。

DMARC実装のポイント

段階的なポリシー強化

前述の通り、DMARC導入は段階的に行うことが鉄則です。急激なポリシー強化は、正規メールの配信失敗を引き起こします。

推奨スケジュール（試験で定番のRFC 7489準拠）

第1週〜4週：p=none でレポート収集
第5週〜8週：レポート分析と未認証送信元の洗い出し
第9週〜12週：p=quarantine; pct=10 で小規模テスト
第13週〜16週：pctを段階的に引き上げ（25、50、75、100）
第17週以降：p=reject へ移行

2026年5月のRFC 9989ではpctが廃止扱いとなり、部分適用の段階導入はt=y（テストモード）に置き換わりました。t=yではquarantineがnone相当、rejectがquarantine相当として扱われます。新規に設計する場合は、pctによる割合指定を前提にせず、t=yで影響を確認してからtを外して本適用する流れを検討してください。試験ではRFC 7489準拠のpctによる段階導入の理解が基準となります。

サブドメインポリシーの活用

メインドメインとサブドメインで、メールの用途が大きく異なる場合（例：マーケティングメールはsubdomain.example.comから送信）、sp=タグでサブドメイン専用のポリシーを設定できます。これにより、サブドメインでの実験的な運用が可能になります。

複数の監視アドレス設定

rua=タグには、カンマ区切りで複数のURI（mailto:形式）を指定できます。社内の複数部門や、外部の DMARC 分析サービスに同時送信することで、レポートの見落としを防げます。

7. トラブルシューティング事例

ケース1：正規メールが迷惑メールフォルダに入る

症状: 社内から送信した正規のメールが、顧客側で迷惑メールとして分類される

原因の切り分け:

SPFレコードが正しく設定されているか確認（nslookup -type=txt ドメイン名）
メール送信サーバーのIPアドレスがSPFレコードに含まれているか確認
DKIM署名が付与されているか、メールヘッダーで確認
DMARCレコードのp=ポリシーが適切か確認

よくある原因:

新しく導入したメール配信システムのIPアドレスをSPFに追加し忘れている
クラウドサービスのincludeディレクティブが古いバージョンのまま
DKIM秘密鍵の更新時に、DNSの公開鍵を更新し忘れている

ケース2：メーリングリスト経由でメールが届かない

症状: メーリングリストに投稿したメールが、一部の参加者に届かない

原因: メーリングリストが件名・本文を改変してDKIM署名が無効になり、かつEnvelope Fromを自分のbounceアドレスに書き換えるためSPFは通るがHeader Fromとアラインせず、DMARCがfailとなる。投稿者ドメインがp=rejectを公開していると、受信側で拒否される

対策:

メーリングリストサーバーでARC署名を有効にする（有効な対策の一つ。受信側がARCを信頼する場合に効きます。RFC 8617はExperimentalです）
メーリングリストがHeader Fromを自ドメインのアドレスに書き換えて配信する、または本文・件名を改変せずDKIM署名を保ったまま配信する
一般ユーザーがメーリングリストに投稿するドメインではp=rejectを公開しない（RFC 9989もこうしたドメインでのp=rejectの公開を推奨していません）

ケース3：DMARCレポートが届かない

症状: rua=タグでレポート送信先を指定したが、レポートが一向に届かない

原因の切り分け:

_dmarc.ドメイン名のTXTレコードが正しく公開されているか確認
rua=タグのメールアドレスが受信可能な状態か確認
外部ドメインのアドレスを指定している場合、検証用DNSレコードが設定されているか確認

よくある原因:

rua=タグのメールアドレスが存在しない、または受信拒否設定になっている
外部ドメインのアドレスを指定する場合、レポート受信側（外部）のDNSサーバーに「自社のドメイン名._report._dmarc.外部ドメイン」のTXTレコードで許可設定が必要（多くの人が見落とすポイント）

8. まとめ：多層防御による信頼の確立

今回解説した3つの技術を、セキュリティの「層」としてイメージしてください。

SPF: 配送経路（IP）が正しいかを確認する「門番」
DKIM: 配送物（中身）が改ざんされていないかを確認する「封蝋（ふうろう）」
DMARC: 1と2の結果を統括し、詐称があった場合の処分を決める「指揮官」

これらは単独で完結するものではなく、3つを組み合わせることで初めて強固な「なりすまし対策」となります。

サイバーセキュリティの世界では、攻撃手法の進化に合わせて防御手法も進化します。しかし、メールにおけるなりすまし対策は、このSPF/DKIM/DMARCが世界的な標準（デファクトスタンダード）として確立しています。

自社のドメインが不正に使われ、取引先や顧客に被害を与えてしまうことは、企業の信頼失墜に直結します。「まだ設定していない」「設定したはずだが内容は把握していない」という方は、ぜひこの機会にnslookup -type=txt [ドメイン名]コマンドを叩き、自社の設定状況を確認してみてください。

実務で設定を確認し、その出力結果を読み解くことこそが、情報処理安全確保支援士試験合格への最短ルートであり、現場で通用するセキュリティエンジニアへの第一歩です。

最後に：継続的な学習の重要性

メールセキュリティは、一度設定すれば終わりではありません。新しい攻撃手法の登場、利用するクラウドサービスの変更、組織構造の変化など、様々な要因で設定の見直しが必要になります。

DMARCレポートを定期的にモニタリングし、異常な送信パターンや未知の送信元を早期に発見する体制を整えましょう。また、年に一度は、SPF/DKIM/DMARCの設定内容を包括的にレビューし、最新のベストプラクティスに適合しているか確認することをお勧めします。

情報処理安全確保支援士として、あるいはセキュリティ担当者として、組織のメールインフラを守ることは、組織全体の信頼性を守ることに直結します。本記事で学んだ知識を、ぜひ実務に活かし、試験合格と同時に、真に価値あるセキュリティ人材としての第一歩を踏み出してください。

【演習】送信ドメイン認証（SPF・DKIM・DMARC）理解度チェック（全10問）

午前Ⅱでは3技術の役割の区別、午後ではSPFレコードの読解やDMARCの段階導入、転送・メーリングリストで認証が失敗する理由が問われやすい分野です。定番のひっかけは、Envelope FromとHeader Fromの取り違え、-allと~allの違い、DMARCのアライメントの比較対象です。以下の練習問題で本記事の理解度を確認してみましょう。

【演習】送信ドメイン認証（SPF・DKIM・DMARC）理解度チェック（全10問）

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

参考資料

無料メール講座登録特典FREE PDF

SC午後記述テンプレート集

設問の文末から解答の「型」を割り出し、そのまま当てはめて書く。「知っているのに書けない」を解消する1冊です。

設問6タイプ分類頻出7テーマ減点10パターン時間配分＆見直し

無料でPDFを受け取る →

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

【徹底解説】なりすましメール対策の要！SPF・DKIM・DMARCの仕組みと設定手順

1. なぜ「なりすまし」は可能なのか？ SMTPの脆弱性

郵便封筒と便箋の違い（EnvelopeとHeader）

なりすましメールの具体的な手口

2. SPF（Sender Policy Framework）：IPアドレスによる検証

SPFの仕組み

SPFレコードの構文と読み方（試験対策）

SPF設定の実務ポイント

SPFの限界と弱点

3. DKIM（DomainKeys Identified Mail）：電子署名による検証

DKIMの仕組み

DKIMシグネチャの詳細解説

セレクタの戦略的活用

DKIMのメリットと限界

4. DMARC：ポリシーと認証の統合

DMARCの3つの役割

最重要概念：DMARCのアライメント（Alignment）

アライメントモード：StrictとRelaxed

DMARCレコードの設定例とポリシー

DMARCレポートの活用

5. 試験合格への戦略的学習ポイント

午前Ⅱ試験対策

午後試験（記述）対策

関連する最新キーワード

6. 実装時の注意点とベストプラクティス

SPF実装のポイント

DKIM実装のポイント

DMARC実装のポイント

7. トラブルシューティング事例

ケース1：正規メールが迷惑メールフォルダに入る

ケース2：メーリングリスト経由でメールが届かない

ケース3：DMARCレポートが届かない

8. まとめ：多層防御による信頼の確立

最後に：継続的な学習の重要性

【演習】送信ドメイン認証（SPF・DKIM・DMARC）理解度チェック（全10問）

参考資料