DMARC対応はしているが、まだp=none

1. p=noneが「安全」ではない理由

このセクションのポイント: p=noneは「全てのメールを受信する」という意味ではありませんが、なりすましメールを阻止する効果もありません。DMARCを設定したという安心感だけが残り、実際の防御は機能していない状態です。

p=noneの本当の意味

p=noneは、「全てのメールをそのまま受信する」という指定ではありません。
正確には、「DMARC未設定時の従来の処理を変更しない」という意味です。
RFC7489には、以下のように記されています。

To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing.

ドメイン所有者が既存のメール処理に影響を与えずにDMARCフィードバックを受け取るため、"p=none"のポリシーはメール処理を変更すべきではありません。

つまり、p=noneでは、受信側のメールサーバは従来どおりの処理（SPF・DKIMの個別判定やコンテンツフィルタなど）を行うだけで、DMARCとしての強制力はありません。

p=noneで起きていること

p=noneのドメインでは、以下の状態が日常的に発生しています。

なりすましメールが受信者に届いている

DMARC認証に失敗したメール（＝なりすましの可能性が高いメール）が、受信者の受信箱や迷惑メールフォルダに到達しています。
p=noneでは、受信側にメールの拒否や隔離を指示していないためです。

ドメイン所有者が被害に気づかない

RUAレポートを設定していても、分析していなければ、自社ドメインがなりすましに使われていることを把握できません。
多くの場合、取引先やお客様から「御社から不審なメールが届いた」と連絡を受けて初めて気づきます。

「DMARC対応済み」という誤った安心感

DMARCレコードを設定したこと自体に安心してしまい、ポリシー強化が先送りされるケースが非常に多いです。
しかし、p=noneのDMARCは、鍵を閉めていない金庫と同じです。

2. 攻撃者の視点 — なぜp=noneが狙われるのか

このセクションのポイント: 攻撃者はDMARCポリシーを事前に確認しています。p=rejectのドメインは攻撃しても無駄ですが、p=noneのドメインは「やりたい放題」の標的です。

攻撃者はDMARCレコードを確認している

攻撃者がなりすましメールを送る際、最初に行うのはターゲットドメインのDMARCレコードの確認です。
DMARCレコードはDNSに公開されているため、誰でも簡単に確認できます。

攻撃者にとって、ドメインのDMARCポリシーは以下のように映ります。

p=reject のドメイン → 「攻撃しても無駄」

なりすましメールを送っても、受信側で拒否されるため、攻撃が成功しません。
攻撃者はコストパフォーマンスを重視するため、p=rejectのドメインは攻撃対象から除外します。

p=quarantine のドメイン → 「効果が薄い」

なりすましメールが迷惑メールフォルダに振り分けられるため、攻撃の成功率が低下します。
ただし、迷惑メールフォルダを確認する受信者もいるため、完全には防げません。

p=none のドメイン → 「格好の標的」

なりすましメールがそのまま受信者に届く可能性が高いです。
さらに、p=noneのままということは、そのドメインの管理者がセキュリティ対策に積極的でないことを示唆しており、攻撃者はより大胆に攻撃を仕掛けてきます。

DMARCレコードなし → 「同様に標的」

DMARCが未設定のドメインも、p=noneと同様に攻撃対象となります。

2025年に多発したセキュリティ侵害の共通点

2025年、国内の多くの企業でなりすましメールを起点としたセキュリティ侵害が発生しました。
これらの企業に共通していたのは、DMARCポリシーがp=noneであったことです。

特に深刻だったのは、Microsoft365のExchange OnlineのDirect Send機能が悪用される事例です。
Direct Sendは、アプリケーションからメールを送信するための機能ですが、この機能を悪用し、正規のMicrosoft365環境から不正なメールを送信する攻撃が行われました。
p=noneのドメインでは、このような攻撃を防ぐ手段がありませんでした。

RUAレポートの受信先も見られている

攻撃者は、DMARCレコードのruaタグも確認しています。
RUAレポートの送信先が自社ドメインのメールアドレスのみの場合、攻撃者は「レポートを分析していない可能性が高い」と推測します。
なぜなら、XML形式のRUAレポートを手動で分析するのは非常に手間がかかるため、実際には確認されていないケースが多いからです。

一方、商用のDMARCレポート分析サービスのアドレスがRUAに設定されている場合、「このドメインはきちんと監視している」というシグナルになります。
これだけでも、攻撃者に対する一定の抑止力となります。

3. p=quarantineの落とし穴

このセクションのポイント: 段階的移行としてp=quarantineを経由するのが一般的ですが、p=quarantineには「送信側が問題に気づけない」という致命的な欠点があります。弊社ではp=noneから直接p=rejectへの移行を推奨します。

一般的な段階移行の問題点

多くのDMARC導入ガイドでは、以下の段階的な移行が推奨されています。

Phase 1

p=none → モニタリング開始

Phase 2

p=quarantine → 認証失敗メールを隔離

Phase 3

p=reject → 認証失敗メールを拒否

この段階的アプローチは理にかなっているように見えますが、実運用上、p=quarantineには以下の問題があります。

送信側が問題に気づけない

p=quarantineでは、認証に失敗したメールは受信者の迷惑メールフォルダに振り分けられます。
しかし、送信側にはエラーが返されないため、メールが正常に配信されたのか、迷惑メールフォルダに入ったのか区別できません。
結果として、正規のメールが迷惑メールフォルダに入ったまま、長期間気づかないという事態が発生します。

なりすましメールが依然として届く

迷惑メールフォルダに入ったなりすましメールは、受信者が確認してしまう可能性があります。
過去の分析データから、p=quarantineではなりすましメールの減少効果が限定的であることがわかっています。

移行が長期化しやすい

p=quarantineの段階で「特に問題が起きていないから」と、p=rejectへの最終移行が先送りされるケースが非常に多いです。
この間もなりすましの被害リスクは残ったままです。

弊社の推奨：p=noneから直接p=rejectへ

弊社では、事前準備を整えたうえで、p=noneから直接p=rejectへ移行することを推奨しています。

問題の即時発見

p=rejectでは、DMARC認証に失敗したメールはSMTPセッション中に拒否されます。
送信側に即座にエラーが通知されるため、設定不備を素早く発見・修正できます。

なりすましの迅速な排除

p=rejectに設定すると、2〜3週間程度で、自社ドメインのなりすましメールは全体の1%未満にまで激減します。
攻撃者は、送っても無駄なドメインを攻撃対象から外すためです。

信頼性の向上

p=rejectは、ドメイン所有者が「認証を正しく行い、責任を持っている」ことの証です。
メール受信側からの信頼度が向上し、正規メールの到達率が改善する効果もあります。

4. p=rejectへの移行手順

このセクションのポイント: p=rejectへの移行は、事前にSPF・DKIMを全送信経路で正しく設定し、RUAレポートで現状を把握してから実施します。

Step 1：RUAレポートの分析

移行の第一歩は、現在のRUAレポートを分析して、自社ドメインの「メール送信の全体像」を把握することです。

RUAレポートからは、以下の情報が得られます。

正規の送信経路

自社のメールサーバ、マーケティング配信ツール（SendGrid、Amazon SESなど）、SaaS製品からの通知メールなど、自社が利用している全ての送信経路を特定できます。

認証結果の状況

各送信経路でSPF・DKIM・DMARCのどれが合格し、どれが失敗しているかを確認できます。
p=rejectに移行する前に、失敗している経路の設定を修正する必要があります。

不正な送信元

自社が利用していないIPアドレスからの送信は、なりすましの可能性があります。
これらを把握しておくことで、p=reject後に正規のメールが影響を受けないことを確認できます。

RUAレポートはXML形式で送られるため、手動で分析するのは現実的ではありません。
商用のDMARCレポート分析サービスを利用することを強く推奨します。

Step 2：全送信経路のSPF・DKIM整備

RUAレポートの分析結果をもとに、認証に失敗している送信経路のSPF・DKIMを修正します。

よくある修正ポイントは以下のとおりです。

SPFレコードへの送信サーバ追加漏れ

マーケティングツールやSaaS製品が利用するメールサーバのIPアドレスまたはinclude先が、SPFレコードに含まれていないケースです。

DKIM署名の未設定

外部のメール配信サービスやSaaS製品で、DKIM署名が有効になっていないケースです。
多くのサービスでは、DNSにCNAMEレコードを追加することでDKIM署名を有効化できます。

DKIM署名ドメインのAlignment不一致

DKIM署名のd=タグに記載されたドメインが、送信サービスのデフォルトドメインのままで、自社ドメインと一致していないケースです。
自社ドメインでDKIM署名を行うように設定変更が必要です。

SPFレコードのDNSルックアップ数超過

SPFレコードでは、DNSルックアップは10回までという制限があります。
includeを多用すると、この制限に抵触してSPF検証が失敗します。
SPFレコードの最適化が必要です。

Step 3：Alignmentの確認

SPF・DKIMが合格していても、DMARC Alignmentが合格しなければ、DMARCは不合格となります。
各送信経路で以下を確認してください。

DKIMベースのAlignment

DKIM署名のd=タグのドメインが、ヘッダーFromのドメイン（またはそのサブドメイン）と一致していること。

SPFベースのAlignment

Envelope From（Return-Path）のドメインが、ヘッダーFromのドメイン（またはそのサブドメイン）と一致していること。

DMARCではSPFまたはDKIMのいずれかでAlignmentが一致すれば合格となるため、全ての送信経路でDKIMベースのAlignmentを合格させることが最も確実な方法です。
DKIMは転送されても有効であるため、SPFが失敗する転送メールのケースにも対応できます。

Step 4：p=rejectへ変更

全ての正規送信経路でDMARC認証が合格していることを確認したら、DNSのDMARCレコードを更新します。

変更前（例）：

v=DMARC1; p=none; rua=mailto:dmarc_agg@example.com;

変更後（例）：

v=DMARC1; p=reject; rua=mailto:dmarc_agg@example.com; adkim=s; aspf=s;

adkim=sとaspf=sを指定することで、Alignmentを厳格モード（Strict）に設定し、サブドメインのなりすましも防止できます。
必要に応じて、サブドメインポリシーsp=rejectも設定してください。

5. 移行前に確認すべきチェックリスト

このセクションのポイント: p=rejectへの移行前に、以下の項目を一つずつ確認してください。漏れがあると、正規のメールが届かなくなる可能性があります。

6. 移行後に起こること

このセクションのポイント: p=rejectに移行すると、2〜3週間でなりすましメールが激減します。同時に、設定不備のメールはエラーとなるため、迅速な対応が可能です。

なりすましメールの激減

p=rejectに設定すると、2〜3週間程度で、自社ドメインのなりすましメールは全体の1%未満にまで減少します。
これは、p=rejectに設定したドメインに共通して見られる現象です。
攻撃者は効率を重視するため、拒否されるドメインへの攻撃を早期に中止します。

設定不備の即時発見

p=rejectでは、DMARC認証に失敗したメールはSMTPセッション中に拒否されます。
送信側にエラーが返されるため、「実はSPFの設定漏れがあった」「DKIMが有効になっていなかった」といった問題を、即座に発見・修正できます。
p=quarantineでは、この問題を検知できないまま、メールが迷惑メールフォルダに入り続けるリスクがあります。

DMARCコンプライアンス率の向上

RUAレポートで確認できるDMARCコンプライアンス率（全受信メールに対するDMARC合格の割合）は、p=reject設定後、通常99%を超えます。
これは、なりすましメールが拒否されることで、集計対象の母数からなりすましメールが除外されるためです。

DMARCでは防げない攻撃への対応

p=rejectに設定しても、攻撃者が全く無関係のドメインを使い、自社を装ったなりすましメールを送る手法は防げません。
多くのメールクライアントが送信元の名前だけを表示し、メールアドレスを表示しない仕様を悪用した攻撃です。

この限界を超えるためには、BIMI（Brand Indicators for Message Identification）の実装が有効です。
BIMIにより、正規のメールにブランドロゴを表示することで、受信者が視覚的に正規メールを識別できるようになります。

継続的なRUAレポートの監視

p=rejectに設定した後も、RUAレポートの継続的な監視は不可欠です。

新たな送信経路の検知

社内で新しいSaaSツールやメール配信サービスの利用が開始された場合、RUAレポートで認証失敗として検知できます。

攻撃の監視

なりすましメールがどの地域から、どの程度送信されているかを継続的に把握できます。
Webサイトへの攻撃との相関分析にも活用できます。

DNSパフォーマンスの確認

SPF・DKIM・DMARCはDNSに依存しているため、DNSの遅延がTemperrorの原因になることがあります。
RUAレポートでこれらのエラーを確認し、DNS側の対策を講じることができます。

FAQ

Q1. p=noneのままだと、具体的にどのような被害が出ますか？

A. 自社ドメインを騙ったフィッシングメールやビジネスメール詐欺（BEC）が、取引先やお客様に届き続けます。
実際に2025年には、p=noneのまま運用していた企業がなりすましメール起点の攻撃を受け、事業停止に追い込まれた事例が複数報告されています。

Q2. p=quarantineを経由せず、いきなりp=rejectにしても大丈夫ですか？

A. はい、事前にSPF・DKIMを全送信経路で正しく設定していれば問題ありません。
むしろ、p=rejectの方が設定不備を即座に発見できるため、安全に移行できます。
p=quarantineでは、問題が迷惑メールフォルダの中に隠れてしまい、発見が遅れるリスクがあります。

Q3. p=rejectに移行するとメーリングリストに影響はありますか？

A. ARC（Authenticated Received Chain）の実装や、メーリングリスト側でのFrom書き換えが行われていれば問題ありません。
Gmail/Google WorkspaceおよびMicrosoft365は、自社ドメインのDKIMを設定していれば自動でARCが有効になります。
また、Google Groupsは、送信元ドメインがp=rejectであれば、ヘッダーFromとReturn-Pathをグループのアドレスに書き換えてくれます。

Q4. p=rejectにしたら、なりすましメールは完全になくなりますか？

A. 完全にはなくなりません。
しかし、自社ドメインのなりすましメールは2〜3週間程度で全体の1%未満にまで激減します。
攻撃者が全く無関係のドメインを使って、名前だけ自社を装うケースについては、BIMIの実装で対応可能です。

Q5. RUAレポートの分析は自社で行えますか？

A. 技術的には可能ですが、現実的ではありません。
RUAレポートはXML形式で、1日に数十〜数百通届くこともあります。
手動で解析するのは非常に手間がかかるため、商用のDMARCレポート分析サービスの利用を強く推奨します。
弊社のMailDataサービスでは、RUAレポートの自動分析と視覚的なダッシュボードを提供しています。

Q6. 移行作業はどのくらいの期間がかかりますか？

A. 送信経路の数や設定状況によりますが、一般的には1〜4週間程度です。
送信経路が少なく、SPF・DKIMが既に正しく設定されている場合は、数日で完了することもあります。
弊社のサービスをご利用いただければ、RUAレポートの分析から設定変更の助言、移行後の監視まで一貫してサポートいたします。