DMARCを「quarantine（隔離）」に設定していても、なりすましメールが受信箱に届く理由とは
2026年6月、フィッシング対策協議会はDMARCポリシーを「reject（拒否）」に設定することを推奨しました。
https://www.antiphishing.jp/report/guideline/antiphishing_guideline2026.html
この背景の1つには、DMARCを導入し、ポリシーを「quarantine（隔離）」に設定していれば、なりすましメールは迷惑メールフォルダに振り分けられ、安全だと考えている方は多いのではないでしょうか。
しかし、実際には、quarantineポリシーだけでは防ぎきれないケースが存在します。
今回は、当社で実際に発生した「quarantine（隔離）」設定をすり抜けきた事例をもとに、そのメカニズムと注意すべきポイントを解説します。
当社の受信ＢＯＸで実際に起きたこと
当社が運用する自社ドメイン宛に、そのドメイン自身を差出人として偽装したメール、いわゆる自己なりすましメールが届きました。
問題は、そのメールが迷惑メールフォルダではなく、転送先のGoogle Workspaceの受信BOXに「認証済み」として届いたことです。
認証結果に見えた矛盾
受信直後のヘッダーを確認すると、次のような結果でした。
dkim=nonespf=softfaildmarc=fail (policy=quarantine)
DMARCの認証自体は明確に失敗しています。ところが最終的にGoogle Workspaceの受信BOXでは、次のように表示されていました。
dkim=passspf=passdmarc=passarc=pass
同じメールであるにもかかわらず、認証結果が失敗から成功へと変化してしまっていたのです。
なりすましメールでなぜこのようなことが起きるのか
再認識して欲しい。quarantineは「拒否」ではない
原因は、quarantineが「拒否（reject）」ではなく、あくまで「隔離を推奨する」ポリシーであるという点にあります。
DMARCの認証に失敗しても、受信サーバーがSMTP接続の段階でメールを拒否するとは限りません。
quarantineポリシーの場合、多くのサーバーは、いったんメールを受信するという判断を下します。
受信からGmail転送までの流れ
今回のケースでは、外部の不正なIPアドレスから、自社ドメインを騙ったメールが送信されたところから話が始まります。
SPFはsoftfail、DKIMはnoneという結果になり、DMARCとしては明確にfailと判定されました。
しかしポリシーがquarantineであったため、受信サーバーはこのメールを拒否せず、そのまま受信を継続しています。
このとき受信サーバーは、受信した時点での認証結果を、ARC（Authenticated Received Chain）と呼ばれるヘッダーに記録します。
ARCは本来、メーリングリストや転送処理を経由することで認証情報が変化してしまうメールについて、受信側が正しく状況を把握できるようにするための仕組みです。
その後、受信ボックスに設定されていた転送ルールにしたがって、このメールはGmailなど外部のアドレスへ転送されます。
転送の際、受信サーバー自身のドメインで新たにDKIM署名が付与される点が、今回のポイントです。
最終的にGoogle Workspace側では、転送元サーバーのSPFとDKIMが正しく通っていること、そしてARCチェーンが有効であることを確認し、結果としてdmarc=passと判定してしまいました。
最初の送信元では認証に失敗していたにもかかわらず、途中のサーバーによる正規の転送処理が、あたかも認証済みメールであるかのような見た目を作り出してしまったのです。
想定外！ARCの仕組みが「抜け道」になり得る
ARCそのものは、転送によってSPFが崩れてしまうことを補うための、有用かつ正当な技術です。今回のケースでも、ARCは仕様通りに正しく機能していました。
問題は、最終的な着地点だけを見たときの見え方にあります。
最初はDMARC failだったメールが、正規の転送処理を経ることで、結果的にDMARC passとして受信箱に着地してしまう。
この「途中経過が見えづらくなる」という性質こそが、今回のような事象を生み出す落とし穴だと言えます。
quarantineだけでは不十分な理由
段階的な運用の中での注意点
多くのDMARC導入ガイドでは、まずnoneから始め、次にquarantine、最終的にrejectへと段階的に引き上げていく運用が推奨されています。この進め方自体は正しいアプローチです。
ただし、今回のケースが示しているのは、quarantineがあくまで受信サーバーに対する「リクエスト」であり、強制力を持つ拒否ではないという点です。
特に、自社ドメイン宛のなりすましメールが自社の受信サーバーを経由し、さらに外部へ転送されるという構成では、途中の正規処理によって認証結果が上書きされたように見えてしまうことがあります。
受信側の設定や転送経路次第で、最終的な見え方が変わってしまう点には注意が必要です。
rejectへの移行という選択肢
ポリシーをrejectに引き上げれば、外部の受信サーバーに対してSMTP段階での拒否を強く要求できるため、今回のような着地は起こりにくくなります。
ただし、reject化は正規メールを誤って遮断してしまうリスクも伴うため、SPF・DKIM・DMARCレコードの整備状況を十分に検証したうえで、慎重に移行を進める必要があります。
最後に
DMARCのquarantineは、最終防衛ラインではなく、あくまで通過点にすぎません。転送設定やARCの仕組みが絡むと、最初にfailしたメールが、最終的にpassとして受信箱に届いてしまうケースがあることを、今回の事例は示しています。
だからこそ、定期的にメールヘッダーを確認し、DMARC・SPF・DKIMの実際の認証結果をチェックする習慣が重要になります。
そして可能であれば、自社の運用状況を見極めながら、段階的にrejectへの移行を検討していくことをおすすめします。
DMARCは「設定したら終わり」という仕組みではありません。実際のメールフローや転送経路まで含めて動作を確認することで、初めて自社の防御レベルを正しく把握できるのです。
関連商品
-
DMARC/25 Analyze
-
AutoSPF
-
ベアメール – SPFホスティング
-
ベアメール – DMARCレポート分析機能
-
PowerDMARC
-
dmarcian
