この記事の要点
- SPF は送信元のサーバが、DKIM はメールの署名が、そのドメインのものとして正しいかを確かめ、DMARC は両者の結果を「差出人（From）のドメイン」と突き合わせて扱いを決める仕組みです。
- DMARC の中心は、From のドメインと、SPF・DKIM で認証されたドメインが一致すること（アライメント）を求める点です。
- 認証に失敗したメールの扱いは、ドメインの持ち主が p=none（指定なし）・quarantine（隔離）・reject（拒否）で宣言します。
- DMARC は RFC 7489（2015年3月）で公開され、2026年5月に標準化の区分の RFC 9989 に置き換えられました（2026年9月時点）。モバイルシステム技術テキスト第11版の改版の要点にも挙がっています。
DMARC・SPF・DKIMは、ひと言でいうと何か？
三つとも、メールの送信元のドメインがなりすまされていないかを、受信側が確かめるための仕組み（送信ドメイン認証）です。どれもドメインの持ち主が DNS に情報を公開し、受信側のメールサーバがそれを参照して判定します。
MCPC の公式テキストのページでは、『モバイルシステム技術テキスト 第11版』（2026年2月発刊、第42回から適用）の改版の要点として、なりすまし防止のための送信ドメイン認証 DMARC の記述が加わったことが示されています（2026年9月27日確認）。
3つは、それぞれ何を確かめるのか？
違いは「何を材料に、どのドメインを確かめるか」です。次の表で、見る場所と弱点をセットで押さえてください。
| 観点 | SPF | DKIM | DMARC |
|---|---|---|---|
| 規格 | RFC 7208（2014年4月） | RFC 6376（2011年9月） | RFC 7489（2015年3月）→ RFC 9989（2026年5月） |
| 確かめること | 送信したサーバの IP アドレスが、そのドメインで許可されたものか | メールに付いた電子署名が正しく、途中で書き換えられていないか | From のドメインと、SPF・DKIM で認証されたドメインが一致するか |
| DNS に公開するもの | 送信を許可するサーバの一覧 | 署名を検証するための公開鍵 | ポリシー（失敗時の扱い）と報告の送り先 |
| 対象のドメイン | エンベロープの送信者（MAIL FROM）など | 署名に書かれたドメイン（d=） | 利用者が目にする From のドメイン |
| 弱点 | 転送されると送信元の IP が変わり失敗しやすい | 途中で本文やヘッダが変わると失敗する | SPF・DKIM がないと働かない |
← 表は横にスクロールできます →
SPF と DKIM だけでは、「認証されたドメイン」と「利用者が見る From のドメイン」が別でも合格になってしまいます。攻撃者が自分の持つドメインで SPF を通し、From には実在の企業のドメインを書く、というなりすましを防げません。この穴を埋めるのが DMARC です。
DKIM の署名は公開鍵暗号の仕組みを使います。署名と検証の鍵の向きは共通鍵暗号と公開鍵暗号の違い、DNS の問い合わせの流れはDNSの仕組みとはで確認できます。
アライメントとポリシーは、何を意味するのか？
RFC 7489 は、アライメントを「From のアドレスのドメインが、SPF または DKIM（あるいは両方）で認証されたドメインと一致すること」と説明しています。SPF と DKIM のどちらか一方でも、認証に成功し、かつアライメントが取れていれば DMARC は合格です。
一致の判定には二つのモードがあり、DKIM は adkim、SPF は aspf というタグで指定します。relaxed（r、初期値）は組織のドメインが同じなら一致、strict（s）はドメイン名が完全に同じ場合だけ一致とみなします。
| 認証されたドメイン | relaxed（r） | strict（s） |
|---|---|---|
| example.jp | 一致 | 一致 |
| mail.example.jp（サブドメイン） | 一致（組織のドメインが同じ） | 不一致 |
| example-mail.com（別の組織） | 不一致 | 不一致 |
← 表は横にスクロールできます →
ポリシーは、DNS の「_dmarc.ドメイン名」に TXT レコードとして公開します。p=none は特別な処理を求めず結果の報告だけを受け取る段階、p=quarantine は疑わしいメールとして迷惑メールフォルダなどに隔離するよう求める段階、p=reject は受信を拒否するよう求める段階です。一般には none で報告を見て、正規のメールが失敗していないことを確かめてから段階的に強めます。
2026年5月に公開された RFC 9989 は、RFC 7489 を置き換え、DMARC を標準化の区分（Standards Track）に位置付けました。p の3つの値とアライメントの考え方は引き継がれ、適用する割合を指定する pct タグが削除され、存在しないサブドメインに対するポリシーを示す np タグと、試験運用中であることを示す t タグが加わっています（2026年9月時点）。
モバイル2級ではどの範囲で、どう問われそうか？
MCPC の公式ページでは、モバイルシステム技術検定2級（100問・100分・4者択一）の出題カテゴリに「情報セキュリティ管理」があり、比率は9%と示されています（2026年9月27日確認）。当サイトでは、公式テキスト第11版の第11章「情報セキュリティ」がこの範囲に当たると推定しています（章名からの当サイトの判断で、公式の発表ではありません）。
4択では、次のような観点が考えられます。出題頻度は公表されていないので、特定の型が多いとは言えません。
- 仕組みの対応：説明文が SPF・DKIM・DMARC のどれに当たるかを選ばせる。
- ポリシーの意味：none・quarantine・reject のそれぞれの扱いを問う。
- アライメント：From のドメインとの一致が必要であることを問う。
- 公開場所：これらの情報が DNS に公開されることを問う。
試験全体の形式・日程・受検料はモバイルシステム技術検定2級とはにまとめています。
どこで取り違えやすいのか？
略語が並ぶため、「何を見るか」を入れ替えた選択肢に注意します。
| 取り違え | 正しい考え方 | 確認する問い |
|---|---|---|
| SPF はメールに署名する | 署名は DKIM。SPF は送信サーバの IP を確かめる | 材料は IP か、署名か |
| DMARC はメールを暗号化する | DMARC は認証結果の扱いを決める仕組みで、暗号化はしない | 中身を隠す機能か |
| SPF と DKIM の両方の合格が必要 | どちらか一方が合格し、アライメントが取れればよい | 条件は「かつ」か「または」か |
| p=none で隔離される | none は処理を求めず報告を受けるだけ。隔離は quarantine | 受信側に何を求めているか |
| 設定はメールサーバの中だけで完結 | ポリシーや公開鍵は DNS に公開する | 受信側はどこを参照するか |
| DMARC があればフィッシングはなくなる | 防げるのは自社ドメインをそのまま使うなりすまし。似たドメインは防げない | From は本物のドメインか、似たドメインか |
← 表は横にスクロールできます →
似たドメインや SMS を使った誘導への備えは、マルウェアとフィッシングの手口で整理しています。
確認問題1：説明に当てはまる仕組みを選べるか？
メールを送信したサーバの IP アドレスが、そのドメインの持ち主が DNS で公開した「送信を許可するサーバ」に含まれるかを確かめる仕組みとして、最も適切なものはどれか。
- DKIM
- SPF
- DMARC
- S/MIME
正解：2。送信元の IP アドレスを、DNS に公開された許可の一覧と照らし合わせるのは SPF です。
1はメールに付けた電子署名を、DNS に公開した公開鍵で検証する仕組みです。3は SPF・DKIM の結果と From のドメインの一致を確かめ、失敗時の扱いを宣言する仕組みです。4はメール本文の暗号化や署名を利用者の証明書で行う方式で、送信サーバの IP は確かめません。
確認問題2：ポリシーの意味を選べるか？
DMARC のポリシーで p=reject を指定したときの意味として、最も適切なものはどれか。
- 認証に失敗したメールは受け取りを拒否するよう、受信側に求める
- 認証に失敗したメールは迷惑メールなどに隔離するよう、受信側に求める
- 特別な処理は求めず、認証の結果の報告だけを受け取れるようにする
- 認証に成功したメールだけを暗号化して配送するよう、受信側に求める
正解：1。reject は、DMARC の判定に失敗したメールを拒否するよう受信側に求める、最も強いポリシーです。
2は quarantine の説明です。3は none の説明で、導入の最初の段階でよく使われます。4は DMARC にない機能で、DMARC はメールを暗号化しません。
確認問題3：アライメントと公開場所を判断できるか？
次の記述ア・イの正誤の組合せとして、正しいものはどれか。
ア：DMARC では、SPF か DKIM のどちらかで認証に成功し、そのドメインが From のドメインと一致すれば合格となる。
イ：DMARC のポリシーは送信側のメールサーバの設定ファイルだけに書き、DNS には何も公開しない。
- ア：正 イ：正
- ア：正 イ：誤
- ア：誤 イ：正
- ア：誤 イ：誤
正解：2。アはアライメントの考え方として正しい記述です。イは誤りで、ポリシーは「_dmarc.ドメイン名」の TXT レコードとして DNS に公開し、受信側がそれを参照します。
1と3はイを正しいとしている点、4はアまで誤りとしている点で当てはまりません。
新しく加わった範囲をほかの用語でも試したい場合は、登録不要のモバイル2級の無料お試し20問で、本番と同じ4択の形式と解説を確認できます。
よくある質問
RFC 7489 と RFC 9989 のどちらで覚えればよいですか？
仕組みの中心（アライメントと none・quarantine・reject のポリシー）はどちらも同じです。第11版のテキストは2026年2月発刊で RFC 9989 の公開より前のため、まず共通する考え方を押さえ、タグの追加・削除のような細部は補足として知っておくのが確実です。
DMARC を設定すれば、なりすましメールは届かなくなりますか？
防げるのは、自社のドメインを From にそのまま使うなりすましで、しかも受信側が DMARC を確認し、ポリシーが quarantine や reject になっている場合です。よく似た別のドメインを使うメールは、DMARC では防げません。
メールを転送すると DMARC に失敗するのはなぜですか？
転送すると送信元のサーバが変わるため、SPF が失敗しやすくなります。本文やヘッダが変わらなければ DKIM の署名は検証できるので、DKIM のアライメントで合格できることがあります。
出典・参考
- [1]MCPC モバイルシステム技術検定［2級］（出題カテゴリと比率、確認 2026-09-27）
- [2]MCPC 公式テキスト（第11版の改版の要点、確認 2026-09-27）
- [3]RFC 7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)（確認 2026-09-27）
- [4]RFC 9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)（2026年5月、確認 2026-09-27）
- [5]RFC 7208 Sender Policy Framework (SPF)（確認 2026-09-27）
- [6]RFC 6376 DomainKeys Identified Mail (DKIM) Signatures（確認 2026-09-27）
本番と同じペースで腕試し
記事の次は、本番形式の問題で。
公式の出題カテゴリの比率どおりに組んだ無料お試しを、登録不要・カード不要で解けます。続きの模試と章別ドリルは買い切りで、月額はかかりません。
あわせて読みたい
当サイトは、モバイルコンピューティング推進コンソーシアム（MCPC）とは関係のない個人が運営する非公式の学習教材です。掲載している問題はすべて当サイトのオリジナルで、実際の試験問題・過去問題・再現問題ではありません。試験の日程・受検料・出題範囲は公式サイト（https://www.mcpc-jp.org/license/ ）で必ず確認してください。合格を保証するものではありません。合格の目安は当サイトの推定です。技術・制度の記述は「最終確認日」時点のものです。