DMARC とは（ざっくり）
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、 メールの送信ドメインについて、 「本当にそのドメインから送られたメールか」を受信側が判断しやすくするためのDNS 上のルールです。 社内のウイルス対策や迷惑メールフィルタとは別レイヤーで、 インターネット上の誰でも DNS を引けば内容を読める設定です。
関連する用語は次の 3 つがセットで語られることが多いです。
- SPF — どのサーバーからそのドメインのメールを送ってよいか（送信元 IP の許可リスト）
- DKIM — メール本文・ヘッダに電子署名を付け、改ざんされていないかを確認する仕組み
- DMARC — SPF / DKIM の結果を踏まえ、認証に失敗したメールをどう扱うかを受信側に指示する
いずれも「社内 LAN のファイル共有」ではなく、 外部攻撃面のうち メール送信ドメインに関わる部分です。
DMARC がないと何が起きうるか
DMARC が未設定、または p=none（事実記録のみで拒否しない）のまま放置すると、
次のような被害が社内システムを侵害しなくても起きうる、と説明できます。
- 代表名義のなりすまし —
info@example.co.jpや社長名義で取引先に「振込先変更」を送る - 請求書・支払い催促の偽装 — 見慣れたドメインだから開封・リンククリックされやすい
- 社内への標的型メール — 人事・経理を装い、パスワード入力やファイル開封を促す
攻撃者は御社のメールボックスに侵入する必要はありません。 御社ドメインを From に見せかけたメールを送るだけで、 取引先や社員の受信トレイに届くことがあります。 受信側のメールサーバーが DMARC に基づいて拒否・隔離しない限り、 「見た目は正規ドメイン」のメールが通過しやすい状態が続きます。
「社内メールは安全」とは別の話
Microsoft 365 や Google Workspace の管理画面で二要素認証を入れ、 社内 PC にウイルス対策を入れている — それは内部または契約ベンダー側の対策です。 DMARC の有無は、第三者が御社ドメインを装って外に送れるかという別の問いです。
よくある誤解は次のとおりです。
- 「クラウドメールを使っているから SPF は自動で完璧」→ 実際の DNS レコードはご依頼・契約ごとに要確認
- 「迷惑メールはブロックされているから大丈夫」→ 社外向けのなりすましは御社の受信フィルタの外で起きうる
- 「IT ベンダーが全部見ている」→ メール認証 DNS はドメイン管理者・DNS 委任先の管轄であることが多い
外部攻撃面レビューでは、権限のない第三者が DNS から読める事実として SPF / DKIM / DMARC のレコード有無と内容を整理します。 社内設定の監査やメールボックスのログ調査とは同じ契約・同じ報告書に含まれるとは限りません。
外部から「見える」確認内容（例）
当社の攻撃面レビュー（契約スコープ内）で、メール認証まわりに触れる場合の例です。 目的は点数化ではなく、事実と優先して見るべき点の共有です。
| 観点 | 確認する内容（例） |
|---|---|
| SPF | TXT レコードの有無、許可する送信元の範囲、複数レコードの有無 |
| DKIM | セレクタ付き TXT の有無（利用中サービスに応じた代表セレクタ） |
| DMARC | _dmarc.example.co.jp の有無、p= の値（none / quarantine / reject）、レポート先 |
| 整合性 | 公式に使う送信ドメインとレコードの対応、サブドメイン方針（sp= 等） |
p=none は「認証失敗を記録するが拒否しない」設定で、
なりすましを止める段階にはまだ入っていない状態であることが多いです。
p=quarantine や p=reject は段階的に厳しくしていく方向の目安になります。
具体的な移行手順はメール基盤・DNS 管理者との調整が必要で、
本記事は一般説明にとどめます。
報告書でどう書くかの体裁例は、 サンプル（架空企業）のメール認証セクションを参照してください。
含まないこと（よくある誤解）
外部攻撃面レビューおよび本記事の説明範囲は、次を標準では含みません。
- Microsoft 365 / Google 管理画面へのログインや設定変更の代行
- 社内メールボックスの侵害調査・フォレンジック
- 実際になりすましメールを送って受信側の挙動を試す検証（別スコープ・要許可）
- 第三者ドメイン・無許可資産への調査
DNS の事実整理と、報告書で社内共有しやすい形にまとめることが中心です。 レコード変更やメール基盤のチューニングは、御社または契約ベンダーとの役割分担で進めます。
調査データは閉域環境内で扱います
御社からお預かりした .eml や調査結果の記録は、当社事業所内の閉域環境でのみ保管・処理します。 調査のためにインターネット上の公開情報（DNS 等）へ問い合わせる通信は発生しますが、 御社のデータを当社のクラウド・共有 SaaS・第三者の管理サーバーに載せる運用は行いません。
- 御社クラウドへの預け込みは不要 — メール管理画面のログインや調査用ポータルはお願いしません
- 調査画面のログインはお渡ししません — お渡しするのは読みやすい報告書（PDF 等）が中心です
- 他社顧客のデータと混在させない — ご依頼・契約ごとに閉域内で管理します
- 納品は基本メール — 常時公開のダッシュボードは提供しません
不審メール 1 通から送信インフラの事実整理を依頼する入口もあります。 詳細はご契約時にご説明します。
はじめ方の目安
すべてを一度に整える必要はありません。状況に応じた入口の例です。
- 不審メール 1 通 — ヘッダと送信ドメインの DNS 事実を整理（単発）
- 代表ドメイン 1 件のライト調査 — SPF / DMARC 含む公開情報のみ（能動スキャンなし）
- 攻撃面パッケージ — サブドメイン列挙から代表ポートまで、メール認証と合わせた地図づくり
メール認証だけを切り出すより、 外部攻撃面全体として地図を作ると、 古いサブドメインや Web 入口との優先順位を一緒に整理しやすくなります。 段階を上げる目安は、攻撃面 → 脆弱性診断 → 必要ならペンテストの順です （いずれも契約・スコープが異なります）。