「自社ドメインを名乗る迷惑メールが取引先に届いている」：ある日突然、こんな連絡を受けたら何から手を付けるべきでしょうか。メールの送信元アドレス（From）は、実は技術的には誰でも自由に名乗れます。この「なりすまし放題」の仕組みを是正するために生まれたのが、SPF・DKIM・DMARCというメール認証（送信ドメイン認証）の3技術です。
2024年2月にGoogleが「メール送信者のガイドライン」を施行し、Gmail宛てに1日5,000通以上送信する事業者にはSPF・DKIM・DMARCの3点セットが事実上の必須要件となりました。もはやメール認証は「大企業のオプション」ではなく、メールを送るすべての組織にとっての基礎インフラです。そしてSC試験では、この3技術は午前II・午後を通じて最頻出クラスのテーマです。
前回の記事「ビジネスメール詐欺（BEC）の手口と対策」では、BEC対策の文脈で3技術の概要を紹介しました。本記事はその深掘り編です。レコードの構文、DMARCのアライメント、転送問題とARCまで、午後試験の論述で「書ける」レベルを目指して解説します。
この記事で学べること
- メール認証の大前提：エンベロープFromとヘッダFromの違い
- SPFのレコード構文・検証の仕組み・DNSルックアップ10回制限
- DKIMの電子署名の仕組みとセレクタの役割
- DMARCのアライメント（strict/relaxed）とポリシー制御・レポート機能
- メール転送で認証が壊れる問題とARCによる解決
- Googleから実際に届いたDMARC集計レポート（XML）の読み方
- SC試験での出題パターンと午後試験で書けるべき論点
大前提：メールには「Fromが2つ」ある
SPF・DKIM・DMARCの理解でつまずく最大の原因は、この大前提を飛ばしてしまうことです。電子メールには送信者情報が2つ存在します。
1つ目は「エンベロープFrom」です。SMTP通信の MAIL FROM コマンドで指定される送信者アドレスで、配送エラー（バウンスメール）の返送先として使われます。封書に例えるなら「封筒の差出人欄」です。郵便局（メールサーバー）はこちらを見て配送処理を行います。
2つ目は「ヘッダFrom」です。メールデータ内の From: ヘッダに書かれたアドレスで、メールソフトが「差出人」として画面に表示するのはこちらです。封書に例えるなら「便箋に書かれた署名」です。受信者が目にするのはこちらだけです。
![エンベロープFrom（封筒の差出人＝SMTPのMAIL FROM、サーバーが参照）とヘッダFrom（便箋の署名＝From:ヘッダ、受信者が参照）の比較図]](https://bksuccess.net/wp-content/uploads/2026/06/spf-dkim-dmarc-alignment_01-1024x572.jpg)
重要なのは、この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」などの判定を下します。
レコード構文：試験でも実務でも読めるべき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点です。
- 送信ドメインの正当性：署名に使われた秘密鍵を持つのは、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レコードとポリシーの段階的引き上げ
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試験でも近年の動向問題として出題されうる、押さえておきたいキーワードです。
実例で読む：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になるのです。
一方のDKIMは、署名ドメイン（d=example.jp、セレクタは default）がヘッダFromと一致し、アライメント成立です。DMARCは「どちらか一方が成立すればpass」なので全体はpassとなり、disposition は none、つまりp=rejectのポリシー下でも処置なしで正常配信されました。
この1通のレポートに、本記事で解説した「生の認証結果とアライメントの区別」「2経路のうち1つ通ればよい」という設計がすべて詰まっています。実務上の教訓も明確です。レンタルサーバーやメール配信サービス経由の送信ではSPFアライメントが構造的に成立しにくいため、自ドメインでのDKIM署名設定が実質的な生命線になります。もしこの環境でDKIMを設定し忘れていたら、p=rejectの下で自分の正規メールがすべて拒否されていたところです。
3技術の役割分担を1枚で整理する
ここまでの内容を試験直前に思い出せる形で整理します。
| 観点 | SPF | DKIM | DMARC |
|---|---|---|---|
| 検証対象 | エンベロープFromのドメインと送信元IP | 電子署名（署名ドメインと本文・ヘッダの完全性） | ヘッダFromと両者のアライメント |
| 使う仕組み | DNSのTXTレコード（許可IPリスト） | 公開鍵暗号による署名＋DNSの公開鍵 | DNSのTXTレコード（ポリシー宣言） |
| 強み | 実装が容易 | 転送でIPが変わっても有効・改ざん検知 | 表示上のなりすまし検出・ポリシー制御・レポート |
| 弱み | 転送で壊れる・ヘッダFrom未検証 | 本文加工で壊れる・ヘッダFromとの一致は不問 | SPF/DKIMの整備が前提・転送問題は残る（→ARC） |
この表を暗記するのではなく、前節の実例レポートと突き合わせながら「自分のドメインならどうなるか」を考えてみてください。3技術の役割分担が、知識ではなく実感として定着するはずです。
SC試験での出題パターンと対策
メール認証はSC試験で繰り返し出題されてきた定番分野です。出題のされ方は大きく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技術が無力である点（正規アカウントからの送信は認証をすべて通過する）まで言及できると、論述の完成度が上がります。
練習問題
問1（午前II想定） 送信ドメイン認証技術SPFの仕組みとして、最も適切なものはどれか。
ア. 送信者がメールに付与した電子署名を、受信側がDNSから取得した公開鍵で検証する イ. 受信側が、SMTP接続元のIPアドレスを、エンベロープFromのドメインのDNSに登録された許可リストと照合する ウ. 送信者と受信者が共有した秘密鍵で、メール本文を暗号化して送受信する エ. 受信側が、ヘッダFromのドメインと電子署名のドメインの一致を検証し、不一致時はドメイン所有者の宣言したポリシーを適用する
問2（午後想定） DMARCを新規導入する際、ポリシーを p=none から開始することが推奨される理由を、DMARCのレポート機能に触れながら60字以内で述べよ。
問3（午後想定） SPFとDKIMの両方で認証がpassしているにもかかわらず、DMARCではfailと判定された。考えられる原因を40字以内で述べよ。解答と解説
問1：イ。 アはDKIM、ウはメール認証ではなく共通鍵暗号による暗号化の説明、エはDMARC（DKIMアライメント＋ポリシー適用）の説明です。
問2：解答例「正規の送信経路が認証に失敗していないかを集計レポートで確認し、正規メールが隔離・拒否される事故を防ぐため。」（53字）
問3：解答例「SPF・DKIMの認証ドメインがいずれもヘッダFromのと一致していないため。」（38字相当・アライメント不成立）。攻撃者が自ドメインでSPF/DKIMを通しつつヘッダFromで正規ドメインを騙るケースが典型です。
【演習】SPF・DKIM・DMARC理解度チェック（全10問）
メール認証に関する問題は、SC試験では「SPF・DKIMの仕組みを選ぶ午前II問題」と「DMARCのアライメントや導入手順を説明する午後問題」の両方で出題が想定されます。選択肢には、S/MIMEとの混同、SPFとDKIMの検証対象の入れ替え、-all と ~all の取り違えといった、本記事で解説したポイントを突くひっかけが定番として登場します。以下の練習問題で本記事の理解度を確認してみましょう。
まとめ：3技術は「層」で理解する
SPF・DKIM・DMARCは並列の3技術ではなく、役割の異なる層の積み重ねです。SPFが「送信元IPの照合」、DKIMが「電子署名による正当性と完全性の保証」という認証結果を作り、DMARCが「受信者の目に映るヘッダFromとのアライメント検証」と「ポリシー制御・レポート」で全体を統括します。さらに転送問題への回答としてARCが加わり、メール認証のエコシステムは今も進化を続けています。
試験対策としての最優先事項は、「エンベロープFromとヘッダFromの区別」を出発点に、各技術が何を検証して何を検証しないのかを自分の言葉で説明できるようになることです。本記事の比較表と図解を白紙に再現できれば、午前II・午後のどちらにも対応できます。
実務の観点でも、メール送信者のガイドライン施行以降、メール認証は「設定していないとメールが届かない」時代に入りました。筆者のもとに届いたDMARCレポートを読み解けたのは、まさにSC試験の勉強のおかげです。試験勉強がそのまま実務スキルになる、投資効率の高いテーマです。確実に得点源にしましょう。
本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。
参考資料
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 8617: The Authenticated Received Chain (ARC) Protocol
- Google: メール送信者のガイドライン
- Google: DMARCレポートについて
- IPA: ビジネスメール詐欺対策特設ページ
- 総務省: 迷惑メール対策（送信ドメイン認証技術の導入状況）