2024年から続くDMARCの現在地：なぜ今「ポリシー強化」が迫られているのか？
Google・米Yahoo!要件から始まった「形だけの導入（p=none）」
2024年2月、米Googleおよび米Yahoo!が発表した「メール送信者の新要件」は、世界中のITインフラ担当者や情報システム部門に大きな衝撃を与えました。1日5,000通以上のメールを送信する事業者に対し、SPFやDKIMの適切な設定とともに、送信ドメイン認証技術「DMARC（ディーマーク）」の導入が義務付けられたためです。
この要件発表を受け、国内でも数多くの企業が急ピッチでDNSレコードにDMARC設定を追加しました。しかし、当時求められていた最低条件は「DMARCポリシーが設定されていること」であったため、多くの企業は最も影響の少ない「p=none（何もしない・監視モード）」で設定を完了させました。
「とりあえずGoogleに怒られないように設定した」「エラーが出ないように監視モードにしておいた」という企業の多くが、そのまま設定を見直すことなく、現在に至るまで「p=none」の状態で放置してしまっているのが実情です。
経産省・警察庁・総務省による金融・ECへの要請強化
しかし、DMARCを取り巻くセキュリティ要求は、2024年のGoogle要件だけで終わったわけではありません。激増するフィッシング詐欺やブランド偽装被害を食い止めるため、日本政府や各省庁による企業への要請は年々厳格化しています。
経済産業省、警察庁、総務省は連名で、クレジットカード会社や大手EC事業者等に対し、なりすましメール対策の抜本的強化を指示しました。その中で明確に打ち出されたのが、「単にDMARCを導入するだけでなく、ポリシーを『quarantine（隔離）』または『reject（拒否）』へ引き上げること」という強い要請です。
※参考：経済産業省「クレジットの安全・安心な利用に関する周知・犯罪の抑止等」
政府統一基準の改定：政府機関や民間サプライチェーンへの波及
さらに決定打となったのが、内閣サイバーセキュリティセンター（NISC）およびデジタル庁が所管する「政府機関等の対策基準策定のためのガイドライン」の最新改定です。
改定基準において、政府機関等が送信する電子メールのなりすまし防止策として、DMARCポリシーを最終的に「reject（受信拒否）」へ移行することが基本対策事項として明記されました。未使用ドメインは直ちにrejectを設定し、稼働中のドメインについてもDMARCレポートを分析した上で、quarantineを経て1年以内にrejectへ移行する具体的な運用手順が定められています。
※参考：内閣サイバーセキュリティセンター（NISC）「政府機関等の対策基準策定のためのガイドライン」改定資料
政府機関や金融機関にとどまらず、それらの委託先や取引先である民間企業に対しても、サプライチェーンリスク対策の一環として「正当な送信ドメイン認証の確立とDMARCポリシーの強化」を求める動きが急速に広がっています。
そもそもDMARCとは？「p=none」を放置する危険性と3つのポリシー
SPF・DKIM・DMARCの役割の違い
DMARCの重要性を正しく理解するために、まずは送信ドメイン認証を支える3つの技術の役割を整理しておきましょう。
- SPF（Sender Policy Framework）： メールを送信してきたサーバの「IPアドレス」が、ドメイン所有者の許可したものかどうかを検証する仕組み。
- DKIM（DomainKeys Identified Mail）： 送信メールに電子署名を付与し、途中で文面や添付ファイルが改ざんされていないかを検証する仕組み。
- DMARC（Domain-based Message Authentication, Reporting, and Conformance）： SPFやDKIMの認証に失敗した（なりすましが疑われる）メールを、受信側サーバで「どのように処分すべきか」をドメイン所有者が宣言・指示する仕組み。
どれほどSPFやDKIMを設定していても、DMARCという「指示書」が存在しなければ、受信側のメールサーバは偽装メールをどのように扱えばよいか判断できません。
3つのポリシー（none / quarantine / reject）の決定的な違い
DMARCポリシーには、安全性のレベルに応じて以下の3段階が用意されています。
| ポリシー設定 | モード名 | 受信側サーバへの指示内容 | 自社ブランドの防御効果 |
|---|---|---|---|
| p=none | 監視モード | 認証に失敗しても「何もしないでそのまま受信箱へ通してほしい」と指示。レポートのみ収集。 | なし（素通り） |
| p=quarantine | 隔離モード | 認証に失敗したメールを「迷惑メールフォルダ等へ隔離してほしい」と指示。 | 中（受信箱は保護） |
| p=reject | 拒否モード | 認証に失敗したメールを「完全に受信拒否（破棄）してほしい」と指示。 | 最高（偽メール完全遮断） |
「p=none」のままでは自社の看板を使った偽メールを1通も防げない
ここで重要な落とし穴となるのが、「p=none を設定しているだけでは、自社を騙るなりすましメールを1通たりとも防ぐことはできない」という事実です。
攻撃者があなたの会社のドメイン（例：`@company.co.jp`）を送信元アドレス（Header-From）に偽装し、取引先や顧客へウイルス付きメールや偽の請求書を送ったとします。受信側のサーバはDMARCレコードを確認しますが、そこに「p=none（何もしないで）」と書かれているため、認証失敗を認識しながらも、悪質なメールをそのまま相手の受信箱へ届けてしまいます。
その結果、取引先が詐欺被害に遭った場合、「なぜ貴社ドメインからの偽メールが届いたのか」「セキュリティ管理はどうなっているのか」と厳しく責任を追及されることになります。p=none はあくまで現状を調べるための「助走期間」の設定であり、安全対策としてのゴールではないのです。
なぜ多くの情シスは「p=reject」への引き上げを躊躇するのか？
p=rejectにすれば自社ドメインの偽装メールを世界中から一掃できるにもかかわらず、なぜ多くの企業がnoneのまま放置してしまうのでしょうか。そこには、情報システム部門を悩ませる深刻な「現場のリスク」が存在します。
最大の恐怖：「正当な自社メールが相手に届かなくなる」リスク
情シス担当者が最も恐れているのは、ポリシーをrejectに変更した瞬間、「自社の社員やシステムが送信した正規の業務メールまで相手に届かなくなってしまうトラブル」です。
もし営業担当者が送った重要な見積書メールや、顧客向けの重要なお知らせが相手のサーバで一斉に受信拒否されれば、深刻な業務停止や売上機会の損失、信用の失墜に繋がります。「安全になるかもしれないが、業務メールが届かなくなるリスクがあるなら、noneのままにしておいた方が怒られない」という心理的ブレーキが働いてしまうのです。
社内に散らばる「隠れ送信元」の把握が困難
現代の企業において、メールを送信しているのは社内のメールサーバ（Microsoft 365やGoogle Workspace等）だけではありません。社内の各部署が独自に導入した以下のような外部SaaSやシステムから、自社ドメイン名を使ったメールが大量に送信されています。
- マーケティング部門が使うメルマガ配信スタンド（配配メール、Marketoなど）
- 営業部門が使うSaaSツール（Salesforce、HubSpot、kintoneなど）
- 人事・総務部門が使う勤怠管理システムや労務手続きクラウド
- Webサイトのお問い合わせフォームやECサイトの自動返信スクリプト
- 複合機（スキャナ）からのメール送信機能
これらの外部サービスについて、DNS側でSPFレコードの追記やDKIM署名の連携設定を行わないままDMARCをrejectに切り替えると、受信側サーバから「正規の許可を得ていないなりすましメール」とみなされ、すべて即座に破棄されてしまいます。
DMARCレポート（XML形式）が難解で解読できない
DMARCを設定すると、世界中の受信サーバ（GoogleやMicrosoftなど）から「貴社のドメイン名を名乗るメールが何通届き、認証結果がどうだったか」を知らせるレポート（DMARCレポート）が毎日送られてきます。
しかし、このレポートは機械処理用の「複雑なXML形式のデータ」で送られてくるため、人間がテキストエディタで開いても内容を直感的に把握することができません。「どのサービスからのメールが認証に失敗しているのか」を自力で分析・特定するには膨大な専門知識と工数がかかり、結果としてレポートメール自体が未読のまま放置されてしまうのです。
業務を止めずに安全に「p=reject」へ移行する4つの実践ステップ
正規メールの誤遮断を防ぎながら、安全・確実に「p=reject」へ到達するためには、正しい順序に沿った段階的移行が不可欠です。政府ガイドラインや専門機関でも推奨されている4つのステップをご紹介します。
ステップ1：社内のメール送信経路を徹底的に洗い出す（棚卸し）
まずは、自社ドメインを差出人としてメールを送信しているすべてのシステム・サービスを一覧化します。情シスが把握している基幹メールシステムだけでなく、各事業部が個別に契約しているSaaSやクラウドツールを網羅的にヒアリングします。
ステップ2：DMARCレポートの分析ツールを導入し、不整合を特定する
DMARCレコードにレポート送信用のアドレス（ruaタグ）を指定し、届いたXMLレポートをグラフィカルに可視化できる「DMARCレポート分析ツール・サービス」を導入します。
レポートを可視化することで、「Salesforceからの送信メールでSPFのアライメント（ドメイン一致）が失敗している」「古いWebフォームのSPF設定が漏れている」といった具体的な問題箇所が瞬時に判明します。
ステップ3：SPF・DKIMの設定を修正し、認証成功率を100%に近づける
レポートで特定された外部送信システムに対し、正しいSPFレコードの追加（include設定）や、独自ドメインによるDKIM署名を設定していきます。正規の業務メールがすべてDMARC認証をパスする（Passになる）状態を作り上げます。
ステップ4：ポリシーを段階的に引き上げる（none → quarantine → reject）
すべての正規メールがPassになったことを確認したら、DNSのレコードを一気に変更するのではなく、段階的に引き上げます。
- quarantineの割合適用： まずは `p=quarantine; pct=25`（失敗メールの25%だけを隔離）のように設定し、業務に悪影響が出ていないかを数週間確認します。
- quarantineの100%適用： 影響がないことを確認したら `pct=100`（すべて隔離）へ移行します。
- rejectへの完全移行： 最後に `p=reject` を設定し、自社ドメインの完全な防御を完成させます。
見落としがちな盲点：送信側（自社）だけでなく「受信側の防御」も固める重要性
DMARCのポリシーをrejectに引き上げることは、自社のドメインが悪用されるのを防ぎ、取引先や社会に対する責任を果たす上で不可欠な取り組みです。
しかし、企業のセキュリティ全体を俯瞰したとき、もう1つの重大な死角が存在します。それは、「自社のDMARCを強固にしても、取引先がDMARCを設定していなければ、取引先を装ったなりすましメールは防げない」という点です。
取引先アカウントの乗っ取りや類似ドメイン詐欺の脅威
攻撃者は、自社のドメインを偽装できないと分かると、以下のような別のアプローチで攻撃を仕掛けてきます。
- 類似ドメイン（タイポスクワッティング）： 本物のドメインが `example.co.jp` であるのに対し、`examp1e.co.jp` や `example-corp.com` といった酷似した別ドメインを取得してメールを送ってくる。
- 取引先のアカウント乗っ取り： セキュリティの甘いサプライヤーの正規メールアカウントに侵入し、本物のメールアドレスから請求書の偽口座情報を送ってくる（BEC：ビジネスメール詐欺）。
これらは自社のDNS設定（送信側のDMARC）だけでは防ぐことができません。自社を守るためには、送信側の設定（DMARC reject化）と並行して、「社内に届く悪質なメールを受信側で徹底的に検知・遮断するメールセキュリティ体制」を確立することが不可欠です。
送受信の両面からメールセキュリティを盤石にする当社ソリューション
サイバーソリューションズ株式会社では、自社ドメインの信頼性を守る送信側のセキュリティ強化から、巧妙化する標的型攻撃やフィッシングを防ぐ受信側の多層防御まで、企業のメール環境を一元的に保護するクラウドサービスを提供しております。
受信メールの境界防御となりすまし排除「MAILGATES Σ」
「MAILGATES Σ」は、最新のサイバー攻撃を企業の入口で確実にシャットアウトするクラウド型メールセキュリティゲートウェイです。
- 厳格な送信ドメイン認証とAIふるまい検知： 受信メールのSPF/DKIM/DMARC認証を厳格にチェックするだけでなく、AIを活用した高度な文面・ヘッダ分析により、類似ドメインやフリーメールを使ったなりすましメールを正確に判定・遮断します。
- サンドボックス解析による未知の脅威対策： 添付ファイルや本文内URLを安全な仮想環境で動的に解析し、ゼロデイ攻撃や新種のマルウェアを水際でブロックします。
- メール無害化機能（CYBERMAIL Σ ST）： 自治体や重要インフラ企業向けに、HTMLメールのテキスト化や添付ファイルのマクロ除去など、完全な無害化処理を提供します。
Microsoft 365 / Google Workspace に安心をアドオン「Cloud Mail SECURITYSUITE (CMSS)」
「Cloud Mail SECURITYSUITE (CMSS)」は、既存のクラウドメール環境に後付け導入できる総合メールセキュリティサービスです。
- 実効性の高いメール誤送信防止： 送信前の自己チェック画面表示、送信一時保留（タイマー機能）、上長承認ワークフローにより、うっかりミスによる宛先間違いや情報漏洩を防止します。
- 安全な脱PPAP（添付ファイルの自動Webダウンロード化）： 添付ファイルを自動でクラウドストレージへ分離し、安全なダウンロードURLに変換。万が一の誤送信時も後から権限を失効できます。
- 全送受信メールの監査・長期保管： 送信されたメールログや添付ファイルを安全に保持し、有事の際の証跡確認とコンプライアンス遵守を実現します。
まとめ：DMARCの「p=none」から脱却し、盤石なメールセキュリティ体制へ
2024年のGoogle要件対応をきっかけに導入されたDMARCですが、「p=none」のまま放置しておくことは、自社のブランド悪用を放置し、サプライチェーン全体に対して無防備な状態を晒し続けることと同義です。
政府機関の最新基準や業界ガイドラインが示す通り、今やDMARCは「導入しただけ」で満足するフェーズを終え、「安全にp=rejectへ引き上げる運用フェーズ」へと突入しています。
社内のメール送信経路を正しく可視化し、適切なステップを踏めば、業務メールを止めることなく安全にrejectへ到達することは十分に可能です。そして、送信側のDMARC強化と合わせて、受信側のゲートウェイ対策（MAILGATES Σ）や誤送信・脱PPAP対策（CMSS）を整えることこそが、企業価値を守る真のメールセキュリティ戦略となります。
DMARCの設定やポリシー引き上げに関するお悩み、クラウドメールのセキュリティ強化をご検討中の企業様は、ぜひお気軽にサイバーソリューションズへご相談ください。
