Cyberkern
メールの安全性4 分出典確認日 29.09.2026

メールドメインを守る:SPF・DKIM・DMARC

3つの仕組みが何を確認するのか、IT担当者や委託先に何を依頼すべきかを解説します。

送信元の一覧を作る

会社のドメインを使ってメールを送れるのは誰でしょうか。経理、営業、IT部門と一緒に整理しましょう。通常のメールボックスだけでなく、請求ソフト、メールマガジン配信、お問い合わせフォーム、チケット管理、スキャナーなども対象になります。購入したライセンスの一覧だけでなく、実際に使われているサービスを確認してください。

送信サービスごとに、用途、相手に表示される送信元アドレス、提供事業者、社内の担当者を記録します。DNSレコードの変更権限を持つ人と、変更の記録場所も確認します。この一覧を作業の依頼書とし、後にサービスを追加・廃止するときの基準にします。

他の業務用ドメインも含めてください。メール送信に使わない登録済みドメインにも、送信元のなりすまし対策が必要です。英国のNCSCは、組織が持つすべてのドメインを考慮するよう勧めています。 [5]

SPF・DKIM・DMARCが確認すること

SPFは、送信サーバーがSMTPエンベロープの技術的な送信ドメインから送ることを許可されているか確認します。このドメインは、受信者に表示される送信元ドメインと異なる場合があります。許可するサーバーはDNSで指定します。

DKIMは、署名したドメインとメッセージを結び付けます。受信側はDNSに公開された鍵で暗号署名を検証します。署名はメッセージの指定された部分を対象とし、メールの暗号化や特定の人物の本人確認を行うものではありません。

DMARCが合格するには、SPFまたはDKIMが成功し、認証されたドメインが表示上のFromドメインと整合している必要があります。厳格な整合ではドメインの完全一致が必要で、緩和された整合では組織ドメインが同じであれば認められます。無関係なドメインでSPFやDKIMが合格しても十分ではありません。 [1] [2] [3]

ポリシーは根拠を持って選ぶ

p=noneは、DMARC失敗に対する特別な処理を求めません。p=quarantineは不審なメールとしての扱いを、p=rejectは受信拒否を求めます。実際の処理は受信側のメールサービスが判断します。どの設定も、正規メールの到達を保証するものではありません。

IT担当者と観測期間を決め、要求したレポートを確認する体制を整えましょう。月次請求や頻度の低い配信も含められる長さが必要です。何も起きなかった1週間だけでは、そうした業務について十分に分かりません。不明な送信サービスは、許可や停止を決める前に調査を依頼してください。 [4]

IT担当者・委託先に求める証拠

設定と日常業務を結び付けた、次の受入確認をお勧めします。各送信サービスについて、簡潔な証拠の記録を求めましょう。緑のチェックが3つ並んだ画面だけでは、請求システムやお問い合わせフォームが正しく送信できるとは確認できません。

  • 送信サービス、ドメイン、社内担当者の最新の一覧。
  • 各サービスからの実際のテストメールと、受信側のSPF・DKIM・DMARC判定の記録。
  • 単なる合格表示ではなく、実際に検証されたドメインと整合の証拠。
  • 必要な転送設定やメーリングリストを別途テストし、問題があれば記録すること。
  • 根拠を示した目標ポリシー、変更日、配送に問題が起きた場合の具体的な復旧手順。
  • レポート、未解決の点、事業者変更後の再確認を担当する人。

それでも防げない攻撃

似た綴りの別ドメインは、そのドメイン自身のSPF・DKIM・DMARC検証に合格できます。見慣れた表示名だけでも本人とは確認できません。メール認証によって、メッセージの内容まで信頼できるようになるわけではありません。

DMARCは、正規のメールボックスの乗っ取りも防ぎません。乗っ取った攻撃者は、許可済みのサービスから送信できます。不審な支払い指示や振込先変更は、事前に把握している別の連絡手段で確認してください。 [6] [7]

保守も依頼範囲に含める

作業を終える前に担当を決めましょう。マーケティング用ソフトの追加、ウェブ制作・運用事業者の変更、会計システムの入れ替えがあれば、送信元一覧を見直します。何を追加・削除し、何をテストし、何が未解決なのかを記録しておけば、担当者が変わっても設定を理解できます。

関連記事

出典・参考資料

  1. IETF · RFC 7208: Sender Policy Framework (SPF)
  2. IETF · RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
  3. IETF · RFC 9989: DMARC, May 2026
  4. Microsoft Learn · DMARC policy and deployment
  5. NCSC · Email security and anti-spoofing
  6. Microsoft Learn · Spoofing and impersonation
  7. Microsoft Learn · Limits of anti-spoofing protection

公開日:

一次資料の確認日:29.09.2026。

出典と、内容が適用される範囲・限界を記事内に示しています。

関連するセキュリティ検査

セキュリティ分析

サービス内容を見る

お問い合わせ

認証情報や機密情報は送信しないでください。

* 必須項目