企業のDMARC ポリシーを10秒で読む方法（そしてそれが教えてくれないこと）

1つのDNSルックアップで、企業が世界中のメールサーバーに対して、その名前で送信された偽造メールに何をしてほしいのかを知ることができます。このレコードは公開されており、コマンドはワンラインです：dig +short TXT _dmarc.example.com。返ってくるのは短い設定文字列で、その中には1つの指令 — p=none、p=quarantineまたはp=reject — があり、そのドメインを使用するメッセージが認証に失敗した場合のドメイン所有者の希望を示しています。

現在の仕様であるRFC 9989は、2026年5月にIETF Standards Track文書として公開され、より古いRFC 7489に置き換わりました。これら3つの値をほぼ簡潔に定義しています：

• p=none — 「ドメイン所有者は希望を表明していません。」
• p=quarantine — 「ドメイン所有者はそのようなメールを疑わしいと判断します。メールが正当である可能性がありますが、認証の失敗は重大な懸念を生じさせます。」
• p=reject — 「ドメイン所有者はそのようなすべての失敗を、そのドメイン名の使用が正当でないことを明確に示す指標と判断します。」

これらの言葉をもう一度読んでください。というのは、それらはDMARCのほとんどの説明が認めるより弱いからです。ポリシーは受信側が考慮するために送信側が公開した希望です。これは受信側が実行する義務のある指令ではありません。RFC 9989は1つの文でそう述べています：「いかなるメッセージの最終的な処理も常に局所的ポリシーの問題であり、メール受信者の裁量に任されています。」同じセクションでは結果の両面を追加しています — 受信者は「DMARC検証チェックに合格したメッセージであっても拒否またはシャントル処理することができます」し、「『拒否』の公開ポリシーだけを理由にメッセージを拒否してはいけません」。これは、正当なメール（DMARCが説明できない方法で送信されたもの）とメーリングリストが破壊されないようにするためです。

では、p=noneは実際に何を白状しているのか？通常非難されるより少なくです。仕様の用語では、これはモニタリングモードです：ドメイン所有者は集約レポートを収集し、「DMARC検証に失敗したメッセージについて処理上の希望を表明していない」一方で、DMARCをデプロイする受信者は「依然として」ドメインの使用を検証することができます。それが受信側で何かをオフにするわけではありません。あなたのプロバイダーのスパムフィルタリング、評判スコアリング、URLチェック、添付ファイル分析は別個のメカニズムで、送信側が公開したものに関わらず実行されます。p=noneドメインに到達した偽造メッセージはそのレコードであなたのインボックスに昇格させられることはありません。それは単に受信者に対して表明された希望のない状態で配信され、受信者が判断します。

誤解の他半分は逆の方向に走っています。DMARCはフィッシングメールの危険な部分を読みません。その独自の仕様は意図的に範囲外であるものをリストしており、「コンテンツ分析」はその言葉でそのリストに載っています。また、DMARCが「視覚的に似たドメイン名またはRFC5322.Fromの人間が読める表示名の悪用に対応していない」と述べています — これらは2つのトリックで、ほとんどのブランド偽装メールを運んでいます。そしてパスの価値について：「DMARC パスそれ自体では、受信者のインボックスへの配信が安全または望ましいであろうことを保証しません。」正しく認証されたメッセージが使い捨てドメインから来ている場合、DMARCをクリーンにパスします。DMARCはFrom:ヘッダーのドメインを使用することを許可されていた者を答えます。それ以上ではありません。

これは2024年の大量送信者ルールが、この記事の最初のバージョンを含めて、定期的に誤って報告されている場所です。Googleの送信者ガイドラインでは、Gmail アカウントへ1日5,000件以上のメッセージを送信する送信者は「送信ドメインのDMARC メール認証を設定する」ことが求められ、次に同じ息で言います：「DMARC強制ポリシーをnoneに設定できます。」Yahooの独自のSender Hubはお互いにコピーすると想定するのではなく別に読む必要があり、要件を「少なくともp=none - DMARCが合格する有効なDMARCポリシーを公開」と述べており、数値的な音量閾値を公開していません。どちらの要件セットも2024年2月から有効になりました。どちらも誰かをp=noneから強制的に移動させません。両方が実際に強制するのは、そろっている認証です：Googleは「送信者のFrom:ヘッダーのドメインはSPFドメインまたはDKIMドメインのいずれかと一致する必要があります」と要求し、Yahooは緩和されたアラインメントが許容可能であると言います。重大度ではなく、アラインメントがゲートです。

これはドメインがモニタリングに留まる実際の理由を残し、それは臆病ではなく運用上のものです。quarantineまたはrejectに移動するということは、まず給与、チケッティング、マーケティング、文書化されていないサポートデスクなど、あなたの名前でメールを送信するすべてのサービスを見つけ、それぞれが一致するように認証することを意味します。標準自体はこれを遅くする危険を認めています：第三者の送信者はDMARCによって導入されたり除外されたりしておらず、転送とメーリングリストは送信者の過失なくアラインメントを壊す可能性があり、仕様はそれらの失敗モードについてRFC 7960のためにレシーバーを指します。p=noneを公開し、レポートを読む組織は、仕様が説明する順序で作業を行っています。p=noneを公開し、レポートを無視する組織は行っていません。外側から、レコード単独ではどちらの2つを見ているかを知ることはできません。

ターミナルは必要ありません。無料ルックアップツール — dmarcianのドメインチェッカー、MXToolboxのDMARC チェック — はレコードをフェッチしてあなたのためにポリシーを印刷します。あなたの銀行、給与プロバイダー、あなたが飛ぶ航空会社について行ってください。答えを読むだけで、それは何です：ドメインの所有者による意図のステートメント、あなたのメール プロバイダーが独自に行う決定への多くの入力の1つ、1つの特定の種類の偽造について。これは10秒で読むことができる本当に有用なものです。それはその次のメッセージがそのブランドからであると主張しているかどうかが安全であるかについての判決ではありません。

修正、2026年10月20日。この記事の以前のバージョンはp=noneを偽造品をインボックスに配信するものとして説明し、p=rejectをスプーフィングされたメッセージをブロックする唯一の設定として説明し、2024年のGoogleとYahooの大量送信者ルールが送信者をp=noneから強制的に移動させたと述べており、強制の数字を約3分の1のドメインとして引用しました。ポリシーの説明はRFC 9989に対して修正されました；GoogleとYahooの両方は実際にはp=noneを受け入れ、上記の独自のドキュメントから引用されています；そして強制の数字は、基礎となるレポートがそのサンプルまたは分母を公開していないために削除されました。この記事は現在、DMARCが検査しないものも述べています。