DMARCレポートの見方と初動対応：なりすまし疑いをどう確認するか
チュートリアル 初級

DMARCレポートの見方と初動対応：なりすまし疑いをどう確認するか

チュートリアル 初級

DMARCレポートで自社ドメインのなりすまし疑いを見つけたとき、SPF/DKIMのアライメント、正規送信元、DNS設定、エスカレーション条件を確認する手順を整理する。

13 分で読める
CyberLens編集部
#DMARC#SPF#DKIM#メールセキュリティ#フィッシング#初動対応

冒頭要約

DMARCレポートは、自社ドメインを使ったメールが SPF・DKIM・DMARC の観点でどう評価されたかを確認するための運用データです。fail があるだけで攻撃確定とは言えませんが、正規送信元では説明できない失敗が増えた場合は、なりすましや設定漏れの初動確認が必要です。

2026年5月にはDMARCの中核仕様とレポート仕様が RFC 9989、RFC 9990、RFC 9991 として整理されました。実務では仕様番号を暗記するより、誰が自社ドメインを使って送っているか、どの送信元が失敗しているか、ポリシーを強める前に何を確認するかを決めておくことが重要です。

この記事では、DMARCレポートを受け取った情シス、SaaS管理者、開発者が、攻撃手順に踏み込まずに、防御・確認・初動対応へつなげるための見方を整理します。

この記事の対象

この記事は、Google Workspace、Microsoft 365、MAツール、CRM、問い合わせフォーム、送信代行サービスなど、複数のサービスから自社ドメインのメールを送っている組織向けです。仕組みから確認したい場合は メール認証（SPF・DKIM・DMARC） を先に読むと理解しやすくなります。

DMARCレポートとは：攻撃アラートではなく送信元の観測データ

DMARCは、表示上の送信元ドメイン（From）と、SPFまたはDKIMで認証されたドメインが整合しているかを見る仕組みです。Microsoft Learnの説明でも、DMARCはSPFまたはDKIMのどちらかが条件を満たせば通過し、両方が条件を満たせない場合に失敗すると整理されています。

DMARCレポートは、この判定結果を受信側メールサーバーからドメイン所有者へ返すためのデータです。Google Workspaceのヘルプでは、レポートを定期的に確認することで、どのサーバーや第三者送信者が自社ドメインで送っているか、どの程度DMARCを通過しているか、失敗したメールに受信側がどう対応したかを把握できると説明しています。

つまり、DMARCレポートで見るべきことは「失敗があるか」だけではありません。

見る項目実務上の意味
送信元IP・送信元サービス正規のメール基盤、SaaS、送信代行サービスか
SPF結果送信元ホストがSPFで認可されているか
DKIM結果メールが期待するドメインで署名されているか
アライメント認証されたドメインと表示上のFromドメインが整合しているか
dispositionnone、quarantine、reject など受信側がどう扱ったか
件数の変化失敗の増加が一時的な転送・設定変更・なりすまし疑いのどれか
DMARC failだけで攻撃と断定しない

正規のメール転送、メーリングリスト、SaaSの送信設定漏れ、DKIM未設定の代行配信でもDMARC失敗は起きます。逆に、攻撃の可能性を過小評価してよいわけでもありません。送信元台帳、DNS設定、受信ログ、報告件数を合わせて判断します。

読者別の影響：誰が何を確認するか

DMARCレポートはプロトコル仕様の資料ではなく、運用判断の材料です。同じレポートでも、見るべき観点は担当によって異なります。

読者まず見ること放置したときのリスク
情シス・メール管理者正規送信元台帳、DNSレコード、DMARCポリシー、失敗件数の推移正規メールが届かない、またはなりすましを長期間見落とす
SaaS管理者MA、CRM、請求、採用、問い合わせフォームなどの送信代行設定SaaSからの正規通知がDMARCに失敗し、顧客や社員に届きにくくなる
開発者自社アプリの送信ドメイン、Return-Path、DKIM署名、送信基盤アプリ通知が迷惑メール化し、パスワードリセットや通知の信頼性が下がる
CSIRT・SOC失敗元、件数急増、フィッシング報告、受信側ログ、影響範囲なりすましキャンペーンの初動把握や社内注意喚起が遅れる

メール認証は一度設定して終わりではありません。新しいSaaSを導入する、問い合わせフォームを変える、MAツールを追加する、ドメインを増やす、といった変更のたびに、DMARCレポートの見え方も変わります。

まず確認すること：DMARCレポート初動チェックリスト

DMARCレポートで不明な失敗や件数増加を見つけたら、次の順番で確認します。ここでは、攻撃者向けの探索や再現ではなく、管理者が自社環境を確認するための観点に限定します。

1. 対象ドメインと期間を固定する

  • 対象が主ドメイン、サブドメイン、送信専用ドメインのどれかを確認する。
  • レポート期間を1日、7日、30日などで揃え、単日の揺れと継続傾向を分ける。
  • 直近のDNS変更、SaaS追加、メール基盤移行、マーケティング配信の有無を確認する。

2. 正規送信元台帳と照合する

  • Google Workspace、Microsoft 365、SendGrid、Mailchimp、HubSpot、問い合わせフォームなど、正規の送信元を台帳化する。
  • レポート上の送信元IPや送信元名が、台帳上のサービスと説明できるか見る。
  • 説明できない送信元は、いきなりブロックではなく、件数、宛先傾向、時刻、社内報告の有無を確認する。

3. SPFとDKIMのどちらで通過できているか見る

  • SPFが通っていても、FromドメインとアライメントしていなければDMARC通過とは限らない。
  • DKIMが通っていても、署名ドメインが別ドメインならアライメントが成立しない場合がある。
  • Microsoft Learnが整理しているように、DMARCはSPFまたはDKIMの整合で通過し得るため、片方の失敗だけで即断しない。

4. ポリシーを強める前に正規メールの失敗を潰す

  • p=none で観測している段階では、失敗元の正体を分類する。
  • 正規送信元のDKIM未設定、SPF include漏れ、サブドメインの扱いを修正する。
  • 失敗理由を説明できない送信元が残る状態で quarantine や reject へ急に進めない。

5. なりすまし疑いとして扱う条件を決める

  • 正規送信元台帳に存在しない送信元から継続的に失敗が出ている。
  • 失敗件数が急増し、同時期にフィッシング報告や不審な問い合わせがある。
  • Fromドメインが役員、請求、採用、サポートなど信頼されやすい用途に見える。
  • 受信側で quarantine や reject が増えており、ブランド毀損や顧客混乱につながる恐れがある。

この条件に当てはまる場合は、フィッシング確認チェックリスト や フィッシング報告テンプレート と接続し、メール本文、件名、報告件数、受信者、ログを合わせて見ると判断しやすくなります。

初動対応：やること、やらないこと、記録すること

DMARCレポートは大量のXMLや集計データとして届くため、最初にすべてを完璧に読み解こうとすると止まります。初動では、正規送信元の確認、設定漏れの切り分け、なりすまし疑いのエスカレーションを分けます。

やること

  • DMARCレポート用の専用メールボックスまたは集約ツールを用意し、担当者個人の受信箱に依存しない。
  • 正規送信元台帳に、サービス名、用途、送信ドメイン、Return-Path、DKIM署名ドメイン、担当者を記録する。
  • pass と fail を件数だけで見ず、どの送信元がどの条件で失敗しているかを見る。
  • DNSのSPF、DKIM、DMARCレコード変更は、変更日時、目的、承認者、ロールバック手順を残す。
  • なりすまし疑いがある場合は、受信者からの報告、メールゲートウェイ、SIEM、SaaS監査ログを同じ時系列で見る。

やらないこと

  • 失敗があるからといって、いきなり p=reject にしない。
  • 正規SaaSの送信失敗を放置したままポリシーを強化しない。
  • DMARCレポートだけで「攻撃者が誰か」「被害が出た」と断定しない。
  • 失敗レポートやメールヘッダーに個人情報・本文断片が含まれる可能性を無視して共有しない。
  • DNSレコード例をそのまま本番に貼り付けない。必ず自社の送信元に合わせて検証する。

記録すること

対象ドメイン:
確認期間:
現在のDMARCポリシー:
失敗が増えた送信元:
正規送信元台帳との照合結果:
SPF結果:
DKIM結果:
アライメント結果:
直近のDNS・SaaS・メール基盤変更:
関連する社員/顧客報告:
暫定対応:
次に確認する担当者:

判断基準：いつエスカレーションするか

DMARCレポートは日々届くため、すべてを重大インシデントにすると運用が続きません。次の条件に当てはまる場合は、通常の設定確認からCSIRTや管理者判断へ上げます。

優先度条件推奨対応
高正規送信元では説明できないDMARC失敗が急増し、同時期にフィッシング報告がある受信メール、報告件数、送信元、メールゲートウェイログを集め、注意喚起とブロック判断へ進む
高役員、請求、採用、サポートなど信頼されやすいFromドメインで不審な失敗が続くなりすまし疑いとしてブランド・法務・広報を含む連絡体制を確認する
中正規SaaSのメールがDMARCに失敗し、顧客や社員に届きにくくなっているSaaS側のDKIM、SPF include、送信ドメイン設定を修正し、再送信前に検証する
中p=quarantine や p=reject へ移行予定だが、未分類の失敗が残っているポリシー強化を延期し、送信元台帳と失敗分類を先に完了する
低転送やメーリングリスト由来と説明でき、件数が限定的記録し、必要に応じてARCや送信経路の見直しを検討する

特に注意したいのは、正規メールの失敗と、なりすまし疑いの失敗が同じレポートに混ざることです。運用では「正規送信元の設定漏れ」「説明できる転送」「説明できない送信元」「フィッシング報告と一致する送信元」に分けて扱うと、意思決定がぶれにくくなります。

よくある誤解

「DMARC failはすべて攻撃」とは限らない

転送、メーリングリスト、SaaSの設定漏れ、DKIM未設定の送信代行などでも失敗は発生します。まずは正規送信元台帳で説明できるかを確認します。

「SPFがpassなら安全」とは限らない

SPFは送信元ホストの認可を扱いますが、DMARCではFromドメインとのアライメントが重要です。SPFが通っていても、表示上のFromと整合しなければDMARCの観点では失敗になり得ます。

「DKIMがあればSPFは不要」とは限らない

DKIMはメールの署名と署名ドメインの検証に強みがあります。一方で、送信元サービスの整理やメール経路の棚卸しにはSPFの確認も役立ちます。実務では両方を見て、どちらでDMARCを通過しているのかを把握します。

「p=rejectにすれば完了」とは限らない

p=reject は強いポリシーですが、正規メールが失敗している状態で設定すると、必要な通知や顧客メールまで届かなくなる可能性があります。Googleのヘルプも、レポートを見ながら none から quarantine、reject へ検討する流れを示しています。

実務で使う確認フロー

DMARCレポートを毎日見る担当者がいない組織では、次の流れから始めると運用に乗せやすくなります。

  1. DMARCレポートの受信先を、個人ではなく共有メールボックスや専用ツールにする。
  2. 主要ドメインごとに、現在のDMARCポリシー、SPF、DKIM、送信元台帳を1枚にまとめる。
  3. 7日分のレポートを見て、件数が多い送信元を正規・不明・転送・要確認に分類する。
  4. 正規送信元で失敗しているものは、SaaS管理者や開発者へ設定修正を依頼する。
  5. 不明な送信元で件数が多いものは、受信者報告、メールゲートウェイ、Webフォーム、顧客問い合わせと突き合わせる。
  6. 未分類の失敗が減ってから、p=none から quarantine、必要に応じて reject へ段階的に進める。
  7. 変更後は、配信失敗、問い合わせ増加、ヘルプデスク報告、DMARCレポートの変化を確認する。

メールヘッダーを個別に読む練習をしたい場合は、メールヘッダー解析 で Authentication-Results のSPF、DKIM、DMARC結果を確認できます。フィッシング文面の判断練習は フィッシングメール判定ミニCTF から始められます。

関連用語・関連ページ

公式情報・参考情報

チュートリアル

MFA疲労攻撃の初動対応：プッシュ通知を承認したかもしれない時に確認すること

MFAプッシュ通知を誤って承認したかもしれない時に、本人確認、サインインログ、セッション失効、MFA再登録、番号一致・パスキー移行までを確認する実務手順を整理する。

続きを読む
チュートリアル

心当たりのないパスワードリセットメールの確認方法と初動対応

心当たりのないパスワードリセットメールが届いたとき、本物か不審かをどう確認し、リンクを押さずにアカウント・SaaS・ログを守るかを実務チェックリストで整理する。

続きを読む
チュートリアル

フィッシングメールの見分け方 2026年版 ─ 迷ったときの確認チェックリスト

フィッシングメールを開く前に確認すべき送信元、URL、添付ファイル、ログイン画面、AI生成文面の違和感を整理。個人と企業で使える実践チェックリストを紹介する。

続きを読む
ESC
↑↓ で選択 Enter で開く ⌘K で開閉 全ページ検索を開く → Powered by Pagefind