カード決済を扱うすべての事業者が遵守すべきセキュリティ基準であるPCI DSSは、DMARCを必須の管理策として名指ししているわけではありません。ただし2025年3月31日以降、同基準のバージョン4.0.1は自動化されたフィッシング対策を義務付けており、PCI Security Standards Councilはそのガイダンスの中で、フィッシング対策要件を満たす方法としてDMARC、SPF、DKIMを挙げています。カード決済を扱うのであれば、DMARCは「任意」から「当然備えるもの」へと位置づけが変わったと考えるべきです。基準が必須として名指ししているわけではない、という点も含めてです。
「PCI DSSはDMARCを必須にしている」と書くベンダーのブログ記事は珍しくありません。この主張は正確とは言えず、その違いはPCI監査の場面で意味を持ちます。本記事では、要件5.4.1が何を定めているのか、その中でDMARCがどこに位置づくのか、そしてDNSとコンプライアンスを管理する担当者が何をすべきかを説明します。ウェブサイトを通じてカード決済を受け付けているのであれば、この作業を担うのはIT・セキュリティ部門か、ドメインを管理する代理店です。
リンクをクリックすると、目的のセクションに移動できます。
名指しではしていません。PCI DSSバージョン4.0.1は同基準の現行版で、組織に自動化されたフィッシング対策の仕組みを導入することを義務付けています。要件本文の中では特定の技術を名指ししていません。技術名が登場するのはガイダンスの中であり、PCI Security Standards Councilはそこで、DMARC、SPF、DKIMといったなりすまし対策の管理策は「フィッシング攻撃者が当該組織のドメインを偽装し、従業員になりすますことを防ぐのに役立つ」と記しています。
つまりPCIのガイダンスはDMARCを推奨していますが、必須の管理策として列挙しているわけではありません。実務上、ここでの「推奨」と「必須」の差はわずかです。SPF、DKIM、DMARCはドメインのなりすましを止めるための標準的で文書化された手段なので、自動化されたフィッシング対策の仕組みを探す審査担当者は、これらが導入されていることを期待します。実務的な助言はシンプルです。DMARCを導入してください。審査担当者がそれを確認するからです。一方で、基準がDMARCを名指しで必須にしていると主張してはいけません。実際には名指ししておらず、審査担当者はその違いを承知しているからです。
該当するルールは要件5.4.1です。従業員をフィッシング攻撃から検知し保護するためのプロセスと自動化された仕組みを導入していなければならない、という内容です。ここで鍵になる言葉は「自動化された」です。セキュリティ啓発トレーニングだけではこの要件を満たしません。基準が求めているのは、注意喚起された従業員ではなく、稼働している技術的な管理策だからです。
5.4.1は将来適用される要件として公開され、組織が準備を進める間は任意とされていました。その猶予期間は2025年3月31日に終了しました。それ以降、この要件は完全に有効であり、PCI DSS審査の際に審査担当者が確認する対象です。もはやベストプラクティスとして先送りできるものではありません。
ガイダンスはさらに、フィッシング対策の管理策を、カードデータを保存・処理するシステムだけでなく、組織全体に適用することを推奨しています。DMARCはこれを既定で実現します。1つのDMARCポリシーがドメイン上のすべてのアドレスに適用されるため、システムごとに個別に拡張する必要がありません。
基準がDMARCを名指ししていない以上、これは当然出てくる疑問です。要件5.4.1は従業員をフィッシングから守ることが目的なので、その一部はほかのツールでも満たせます。セキュアメールゲートウェイ、フィッシング対策フィルター、リンクや添付ファイルのスキャン、自動化されたセキュリティ啓発トレーニングなどです。カード決済を扱う事業者の多くは、すでにこれらのいくつかを運用しているでしょうし、引き続き使うべきです。
ただし、これらのツールが検査するのは、自社の受信トレイに届くメールだけです。攻撃者がFromアドレスにあなたのドメインを偽装して、顧客やパートナー、従業員にフィッシングを仕掛けるのを止める力はありません。そうしたドメインのなりすましを止める実用的な方法は、メール認証だけです。SPF、DKIM、DMARCを組み合わせて機能させることです。これに代わる本当の手段はありません。だからこそPCIのガイダンスは3つすべてを名指ししており、要件本文がそれらを明記していなくても、審査担当者はそれらが導入されていることを期待するのです。
DMARCレコードを公開することと、DMARCを適用することは別物です。そして、この要件が本来目指している水準に多くの事業者が届いていないのは、まさにこの点です。
p=noneのDMARCレコードはモニタリングのみのモードで動作します。認証に失敗したメールについて受信サーバーに報告させたうえで、そのまま配送させる設定です。可視性は得られ、それ自体は役に立ちますが、あなたのドメインを名乗る偽装メッセージは依然として受信トレイに届きます。何もブロックされません。フィッシング対策の管理策として、p=noneのレコードが防ぐ攻撃はゼロです。
偽装メールをブロックするには、DMARCを適用モードにする必要があります。p=quarantineは失敗したメッセージを迷惑メールに振り分け、p=rejectはそれらを完全に拒否します。誰かがあなたのドメインを偽装して顧客や従業員にフィッシングを仕掛けるのを止めるのは、この「適用」です。PCIは必須のポリシーレベルを名指ししていないので、これは基準に書かれた一文ではなく、私たちの読み方です。とはいえ、何もブロックしないDMARCレコードを、フィッシング対策の管理策として審査担当者に説明するのは困難です。
ここが、多くのドメインが無防備になっている箇所です。DMARCeyeの2026年第1四半期業界レポートでは、DMARCを公開しているドメインのうち、36.7%がp=none、36.8%がp=quarantine、26.5%がp=rejectでした。3分の1以上が、モニタリングのみに設定されているために何もブロックしないDMARCレコードを公開しています。適用ギャップの詳細な内訳では、モニタリングから先へ進まないドメインがどれだけあるか、その全数値を扱っています。
下のフォームにドメインを入力すると、現在のDMARCポリシーと、それが適用設定になっているかを確認できます。
まず、この作業の責任者を明確にしてください。DMARCレコードを公開し、設定を強化していく作業は、マーケティングではなく、DNSとメール認証の作業です。規模の大きい企業ではIT・セキュリティ部門が担います。小規模事業では、たいていドメインを管理している人に回ってきます。ITの委託先、ウェブホスト、あるいはメールとDNSを運用している代理店です。PCIコンプライアンスの責任を負っているが自分ではDNSを管理していない場合、あなたの役割は適切な担当者に作業を割り当て、審査の前に完了していることを確認することです。
技術的な手順は、順番に次のとおりです。
SPFとDKIMを公開します。DMARCはこの両方に依存します。p=noneでDMARCレコードを公開し、配送に影響を与えずにレポートの収集を開始します。p=quarantineへ、続いてp=rejectへ進みます。これがフィッシング対策の意図を満たす設定です。避けるべき落とし穴は、送信元を洗い出す前にp=rejectへ飛びついてしまうことです。早すぎる段階で適用に切り替えると、正当なメールが、つまり顧客が待っている決済の領収書なども含めて、ブロックされ始めます。DMARC実装の完全ガイドでは、適用への移行を一段階ずつ解説しています。
事業者をDMARCの適用へと押し進めている力は、PCI DSSだけではありません。2024年以降、GoogleとYahooは大量送信者にDMARCの公開を求めており、Microsoftもその後、OutlookとHotmail宛ての大量送信者に同じ水準を求めるようになりました。主要なメールボックスプロバイダーと決済基準は、いまや同じことを求めています。自社のメールを認証し、他者が自社ドメインを偽装するのを止めることです。
カード決済を扱い、なおかつマーケティングメールやトランザクションメールも送る事業者にとっては、1つのプロジェクトで両方の義務をカバーできます。PCIのために導入するDMARCの適用は、受信側プロバイダーが期待する管理策と同じものです。受信側の事情については、GoogleとYahooの送信者要件に関するガイドで詳しく扱っています。
PCI DSS v4.0.1は、DMARCを必須の管理策のリストに加えたわけではありません。加えたと言う人がいたら、その言葉は疑ってかかるべきです。同基準が実際に行ったのは、フィッシング対策を義務化し、それを提供する手段としてDMARC、SPF、DKIMを指し示したことです。最も重要なのは適用です。p=noneのDMARCレコードは問題を記録するだけですが、p=quarantineやp=rejectはそれを解決します。
DMARCeyeは、ドメインが受け取ったDMARCレポートを解析し、どの送信元が正当で、いつ適用に進めば安全かを平易な言葉で示します。モニタリングからコンプライアンスへの一歩が、顧客が頼りにしているメールを壊さずに済むようにするためです。