DMARCポリシーとは何ですか？なし、検疫、拒否

メール詐欺は、今日の組織が直面するサイバー脅威の中でも、最も根強く、甚大な被害をもたらすもののひとつです。 ベライゾン・データ侵害調査レポートによると、フィッシングは依然としてデータ侵害の主な原因であり、ほとんどの攻撃は偽装されたメールドメインから始まっています。

DMARCポリシーは、最初の防衛ラインとなります。これは RFC 7489で定義されているDMARC（Domain-based Message Authentication, Reporting, and Conformance）は、メールの認証チェックに失敗した場合に受信メールサーバーがどう対応すべきかを指示するメール認証プロトコルです。これがないと、攻撃者はあなたのドメインを自由になりすまし、顧客、従業員、パートナーを標的にすることが可能になります。

このガイドでは、DMARCポリシーとは何か、利用可能な3つのポリシーオプション、正しい実装と適用方法、そして多くの企業が十分な保護を受けられない原因となっているよくある落とし穴を回避する方法について解説します。

DMARCポリシーとは何ですか？

DMARCポリシーとは、DNSに公開される一連の指示であり、DMARC認証に失敗したメールを、受信メールサーバーがどのように処理すべきかを指定するものです。 DMARC認証に失敗したメールメールをどのように処理すべきかを指示するものです。平たく言えば、これはDMARCプロトコルの強制層であり、あなたのドメインから送信されたと主張する認証されていないすべてのメッセージの運命を決定します。

DMARCポリシーがなければ、メールドメインは事実上、無防備な状態となります。サイバー犯罪者は、貴社から送信されたように見せかけた詐欺メールを送り、顧客や従業員を標的としたフィッシング攻撃を仕掛けてくる可能性があります。

DMARCポリシーはどのように機能するのでしょうか？

DMARCポリシーは、メールがDMARC認証に失敗した際に、受信メールサーバーが従うべき明確なルールブックを提供することで機能します。ここでは、送信から受信トレイに至るまでの具体的なプロセスを解説します。

認証フローの手順：

1. ある送信者が、あなたのドメインから送信されたと偽ってメールを送信します。
2. 受信メールサーバーは、メッセージに対してSPFおよびDKIMの認証チェックを実行します。
3. メッセージがいずれかのチェックを通過し、かつドメインが「From」ヘッダーと一致する場合、DMARC認証に合格し、受信者の受信トレイに届く。
4. メッセージがDMARCチェックに失敗した場合、サーバーはあなたの DMARCレコード を読み取ります。
5. 公開されているDMARCポリシーに基づき、サーバーは認証されていないメッセージを配信、隔離、または拒否します。
6. 受信サーバーは、DMARCレコードで指定されたアドレス宛てに、DMARC集計レポートを送信します。

DMARCは、認証されたドメインが「From」ヘッダーに記載されたドメインと一致しているかどうかも確認します。これは「識別子の整合性（identifier alignment）」と呼ばれ、攻撃者が類似ドメインを利用して基本的なメール認証チェックをすり抜けるという抜け穴を塞ぐ役割を果たします。

整合性が取れていない場合、悪意のある攻撃者は、あるドメインではSPFを通過させつつ、受信者が実際に目にする「From」アドレスでは全く別のドメインを偽装することが可能になります。

DMARCを設定する前に

DMARCレコードを設定する前に、SPFおよび／またはDKIMを導入し、少なくとも48時間稼働させておく必要があります。これらが導入されていない場合、DMARCポリシーを検証する対象が存在しないことになります。

また、以下の点についても理解しておく価値があります レコードの公開を開始する前に 。設定ミスのあるDNS TXTレコードは、DMARCの失敗の最も一般的な原因の一つだからです。

おすすめ記事： メールフィッシングとDMARCの統計：2026年のセキュリティ動向

3つのDMARCポリシーオプション

ポリシーには、p=none、p=quarantine、p=reject の3つのオプションがあります。それぞれが異なるレベルの DMARCの適用レベルを表しています。適切なタイミングで適切なオプションを選択することこそが、真に保護されている組織と、単にそう思っているだけの組織とを分けるのです。

1. p=なし

p=none は、最も緩やかな DMARC ポリシー設定です。これは、DMARC 認証に失敗したメールに対して、受信サーバーが何の措置も講じないよう指示するものです。すべてのメッセージは、認証に合格したか失敗したかにかかわらず、通常通り受信者の受信箱に配信されます。ブロックされることもなければ、不審なメールとしてフラグが立てられることもありません。

その唯一の役割は、 DMARC集計レポートを生成することのみです。これにより、どの送信者があなたのドメインを名乗ってメールを送信しているか、認証を通過したメッセージや失敗したメッセージの数がどれくらいか、そしてどのIPアドレスがあなたのドメインをなりすましている可能性があるかを確認できます。

p=none は、電子メールのなりすましに対して全く保護機能を提供しません。その理由は以下の通りです：

• 許可されていないメールが依然として配信されている
• 詐欺メールが依然として受信箱に届いている
• 攻撃者はあなたのドメインを自由に利用することができます

これは正しい出発点ではありますが、最終目標ではありません。多くの企業は「p=none」の段階から先に進まず、結果として全く無防備な状態に置かれています。もし御社の DMARCポリシーが 、ドメインは依然として無防備な状態のままです。

2. p=隔離

p=quarantine は、暫定的な適用ポリシーです。これは、受信メールサーバーに対し、認証に失敗したメッセージを不審なものとして扱い、受信トレイではなく受信者のスパムフォルダまたは迷惑メールフォルダに振り分けるよう指示するものです。

DMARC認証を通過したメールには一切影響がありません。認証されていないメッセージのみが不審なものとみなされ、受信トレイから除外されます。

その 隔離ポリシー は、厳格な適用を維持しつつ、安全策も提供します。正当なメール送信元が設定ミスによりDMARCチェックに失敗し始めた場合でも、メールは即座に拒否されるのではなく、スパムフォルダに振り分けられます。これにより、問題を発見して修正し、メールの配信に支障をきたすことを防ぐことができます。

DMARCレポートを徹底的に分析し、既知の正当な送信者すべてが適切に認証されていることを確認してから、p=quarantine に移行してください。

3. p=棄却

p=reject は、最も厳格な DMARC ポリシーであり、メールセキュリティのゴールドスタンダードです。これは、受信サーバーに対し、認証されていないメッセージをすべて拒否するよう指示するものです。不正なメールは、受信トレイやスパムフォルダ、その他の場所にも一切届きません。

完全なp=reject停止 ドメインのなりすまし を未然に防ぎ、ブランドの評判を守り、メールボックスプロバイダーに対してドメインの信頼性を示すことで、正当なメールの受信トレイへの到達率を向上させることができます。

ただし、p=reject 設定は容赦がありません。このポリシーに切り替える前に適切に認証されていない正当なメール送信元からのメールは、すべて拒否されます。この変更を行う前に、すべての正当な送信者がホワイトリストに登録され、DMARC 認証を通過していることを確認する必要があります。

知っておくべきその他のDMARCポリシータグ

p=タグが最も注目されがちですが、DMARCレコードには、ポリシーの動作に直接影響を与えるその他の設定項目がいくつか含まれています。これらを無視してしまうことが、DMARCレコードを公開した後でも、組織の保護体制に不備が生じてしまう原因の一つとなっています。

sp= (サブドメインポリシー)

sp=タグは、DMARCポリシーがサブドメインにどのように適用されるかを制御します。ルートドメインにポリシーを設定しているものの、 sp= を省略すると、サブドメインはデフォルトでルートドメインのポリシーを継承します。ほとんどの場合、これで問題ありませんが、サブドメインに異なるレベルの適用を適用したい場合は、これを明示的に設定する必要があります。

たとえば、ルートドメインが p=reject に設定されているものの、サブドメインについてはまだ完全な適用を行う準備が整っていない場合、sp=quarantine を設定することで、そのサブドメインに対してより緩やかなポリシーを適用することができます。

pct=（パーセンテージタグ）

pct=タグは、受信サーバーに対し、ポリシーを適用すべき失敗したメッセージの割合を指定します。省略された場合、デフォルト値は100になります。このタグは、p=quarantineからp=rejectへの移行時に特に有用です。

すべてのトラフィックを一括で切り替えるのではなく、pct=10 または pct=25 から開始し、レポートを確認しながら徐々にスケールアップしていくことができます。

adkim= および aspf=（アライメントモード）

これら2つのタグは、DMARCがDKIMおよび SPF のドメイン整合性をどの程度厳格にチェックするかを制御します。2つのオプションは r（relaxed：緩和）と s（strict：厳格）です。緩和された整合性ではサブドメインの一致も認められるため、mail.yourdomain.com は yourdomain.com に対する整合性チェックを通過することになります。

厳密な配置には完全一致が必要です。ほとんどの組織では、これらのタグを省略した場合のデフォルト設定である「緩やかな配置」を使用すべきです。

fo=（障害報告オプション）

fo=タグは、いつ DMARCフォレンジックレポート が生成されるタイミングを制御します。デフォルト値は 0 で、これは SPF とDKIM の両方が失敗した場合にのみレポートが送信されることを意味します。fo=1 に設定すると、SPF または DKIM のいずれかが失敗した際にレポートが送信されます。

fo=s または fo=d を設定すると、それぞれ SPF または DKIM の失敗に関するレポートが生成されます。トラブルシューティングの可視性を高めるには、fo=1 を設定するのが最も有効です。

DMARCポリシーの比較：p=none 対 p=quarantine 対 p=reject

3つのDMARCポリシーオプションを並べて比較すれば、選択が容易になります。現在の段階に最適なポリシーを決定する際の参考として、こちらをご活用ください。 DMARC導入の。

ほとんどの組織は、これを段階的なプロセスとして捉えるべきです。まず p=none から始め、DMARC レポートを分析し、設定ミスを修正して p=quarantine に移行し、正当なメール送信元がすべて確認されたら、最終的に p=reject へと移行します。

p=none から p=reject へ変更する方法

p=none から完全な DMARC ポリシーの適用への移行は段階的なプロセスであり、各段階でレポートを慎重に分析する必要があります。この移行を急ぐことが、正当なメールがブロックされてしまう最も一般的な原因です。

ステップ1：p=noneレコードを公開し、データの収集を開始する

まず、p=none および有効な rua= アドレスを指定した DMARC レコードを公開してください。これにより、監視モードになります。

すべてのメールメッセージは通常通り配信され続けますが、ドメインから送信している送信者、認証に合格または不合格となったメッセージ、および関連するIPアドレスが記載されたDMARC集計レポートの受信が始まります。

ステップ2：DMARCの集計レポートを分析する

集計レポートの生データはXMLファイルとして提供されるため、手作業で読み解くのは容易ではありません。 DMARCレポートアナライザー を使用して、読みやすいダッシュボードに変換してください。

自社ドメインから送信されるすべての正当なメール送信元、予期せずDMARCチェックに失敗しているIPアドレス、既知の正当な送信元におけるSPFおよびDKIMの整合性エラー、および自社ドメインを偽装しようとしている不正な送信元を確認してください。

ポリシーを変更する前に、少なくとも2～4週間はこれらのDMARC認証の結果を監視してください。PowerDMARCの集計レポート機能を使えば、経時的な傾向を簡単に追跡できます。

ステップ3：SPFとDKIMの不整合を修正する

DMARCチェックに失敗している正当なメール送信元については、その根本原因を調査し、修正してください。一般的な修正方法としては、SPFレコードに不足しているIPアドレスを追加すること、サードパーティのメールサービスに対してDKIM署名を設定すること、および転送メールフローの設定ミスを修正することが挙げられます。

DMARCレポートを定期的に監査することで、これらの問題が配信障害に発展する前に発見することができます。

ステップ4：正当な送信者をすべてホワイトリストに登録する

適用ポリシーを実施する前に、すべての正当なメール送信元が、一貫してDMARC認証を通過している必要があります。この段階で送信元が1つでも認証を通過していない場合、p=rejectを適用すると、それらのメールは拒否されることになります。

ステップ5：p=quarantineを10～25パーセントに設定する

pct=タグを使用して、まず失敗したメッセージの一定割合に新しいポリシーを適用してください。最初は pct=25 で p=quarantine を設定し、レポートを注意深く監視してください。

正当なメールがスパムフォルダに振り分けられるようになった場合は、作業を進める前に、その送信者の設定を修正する必要があります。

ステップ6：p=隔離を100％にスケールする

25％の失敗メッセージが本当に不正なものであると確信できたら、pct=を100まで引き上げ、監視を継続してください。

ステップ7：p=reject に移動する

p=quarantine が正常に動作し、正当なメールが誤って捕捉されることなく100％の精度で処理されるようになったら、完全な適用に移行する準備が整います。これ以降、認証されていないメッセージはすべて、配信前にブロックされるようになります。

PowerDMARCの ホスト型DMARC サービスなら、この移行プロセス全体を代行し、各段階で手動によるDNS設定の変更を必要とせずに、ポリシーの更新を自動化します。

DMARCレポート：集計レポートと詳細レポート

DMARCレポートを活用することで、ポリシーを有効な情報収集ツールへと変えることができます。レポートを確認しなければ、誰がドメインを利用しているのか、何が失敗しているのか、あるいは対策が機能しているのかどうかを把握することはできません。

レポートには2種類あり、それぞれ全く異なる目的を果たします。

DMARCポリシーにおけるよくあるエラーとその修正方法

DMARCの導入は複雑になりがちで、わずかな設定ミスが大きな影響を及ぼすことがあります。ここでは、最もよくあるエラーとその迅速な解決方法をご紹介します。

DMARC TXTレコードが存在しない、または形式が不正です

誤ったホスト名で公開したり、v=DMARC1 タグが欠落していたり、重複したレコードを作成したりすると、受信サーバーはポリシーを完全に無視してしまいます。ホスト名に関するよくある間違いとしては、_dmarc.yourdomain.com の代わりに dmarc.yourdomain.com を使用してしまうことが挙げられます。

修正方法： DNSの変更を行う前と後に、PowerDMARCのDMARCレコードチェッカーでレコードを検証してください。

SPFとDKIMが一致していません

認証されたドメインが「From」ヘッダーと一致しない場合、SPFとDKIMの両方が通過しても、メッセージはDMARCの検証に失敗します。これは、DMARCの実装において最も誤解されがちな失敗要因の一つです。

修正方法： DMARCレコード内のadkim=およびaspf=のアライメント設定を確認してください。多くの組織にとって、アライメントを「Relaxed」に設定するのが適切なデフォルトであり、これにより、ドメインが完全に一致しなくてもサブドメインの一致が認められます。

強制措置への移行後に正当なメールが配信できなくなる

これは、ほとんどの場合、監視段階で見逃されていた正当な送信者が、より厳格なポリシーによって現在捕捉されていることを意味します。

対処法： 調査中は、pct=の値を低く設定してp=quarantineに戻してください。集計レポートから問題のある送信元を特定し、そのSPFまたはDKIMの設定を修正して、一貫して通過することを確認してから、段階的に元の設定に戻してください。

SPF DNS 検索の制限を超過しました

SPFレコードは10件までです DNS 照会。十分な数のサードパーティ製プラットフォームを経由すると、この制限を超過し、SPFが失敗し、正当なメールに対して直接DMARCエラーが発生する連鎖反応を引き起こします。

解決策： SPFレコードを監査し、自動化されたSPF管理機能を利用してレコードを簡素化し、ルックアップ制限内に収めるようにしてください。

報告先アドレスが設定されていません

有効な rua= アドレスがない場合、ポリシーは展開されているものの、それが機能しているかどうか、何が失敗しているのか、あるいはドメイン内でなりすまし行為が行われているかどうかを把握することはできません。

対処法： 導入当初から常に有効な rua= アドレスを含めるようにしてください。複数のドメインを管理している場合は、一元化されたレポートプラットフォームを使用して、DMARCの集計レポートを一箇所に集約してください。

PowerDMARCでドメインを保護しましょう

DMARCポリシーの有効性は、その実装の質に左右されます。技術的な手順自体は単純明快です。しかし、レポートの分析、設定ミスの修正、正当な送信者のホワイトリスト登録、そして安全に強制適用に移行するという継続的な作業において、多くの組織は十分な成果を上げられていません。

PowerDMARCは、このプロセス全体を管理しやすくするために設計されています。最初のDMARCレコードの作成から、p=rejectの完全な適用に至るまで、このプラットフォームがすべての段階を管理します。ホスト型ポリシー管理、自動レポートダッシュボード、リアルタイムの脅威アラートに加え、すべてのドメインにわたるSPFおよびDKIMの監視機能も備えています。

PowerDMARCを導入している組織は、p=noneからp=rejectへの移行をより迅速に行い、正当なメールへの影響を最小限に抑えつつ、自社ドメインを使用するすべての送信者を完全に可視化できます。

ドメインはあなたのブランドそのものです。無防備なままにしておかないでください。

デモを予約する 今すぐデモをご予約いただき、メールの完全な認証と適用に向けた第一歩を踏み出しましょう。

よくあるご質問

1. デフォルトのDMARCポリシーとは何ですか？

デフォルトのDMARCポリシーは存在しません。DMARCレコードが存在しない場合、受信サーバーはDMARCチェックを実行しません。初めてDMARCレコードを作成する際は、監視を目的として、p=none から始めることをお勧めします。

2. DMARCポリシーはメールの配信率に影響を与えることがありますか？

はい、DMARCポリシーを適切に導入すれば、認証済みのドメインはメールプロバイダーからより信頼されるため、配信率を10～15％向上させることができます。しかし、導入方法が間違っていると、正当なメールが隔離されたり、拒否されたりする原因となります。

3. SPF、DKIM、DMARCの違いは何ですか？

SPFは送信サーバーの正当性を確認し、DKIMは暗号署名によってメッセージの完全性を保証します。一方、DMARCはSPFとDKIMの結果を基に、ポリシーの適用とレポート機能を提供します。

4. より厳格な方針に移行する前に、p=noneの状態をどのくらいの期間維持すべきですか？

包括的なDMARCレポートを収集するには、少なくとも30日間はp=noneの設定を維持してください。複数のメール送信元を持つ複雑な組織の場合、すべての正当な送信者が特定され、適切に認証されるよう、60～90日間を目安としてください。

5. どのDMARCポリシーが最適ですか？

p=reject は、許可されていないすべてのメールの配信をブロックするため、最も強力なポリシーです。とはいえ、いきなり p=reject に移行するのはリスクが伴います。推奨されるアプローチは、まず p=none から始めてメールのトラフィックを監視し、正当な送信者をすべて特定したら p=quarantine に移行し、正当なメールがすべて適切に認証されていると確信できた場合にのみ p=reject を適用することです。

6. DMARCポリシーを修正するにはどうすればよいですか？

DMARCポリシーを更新するには、DNS管理コンソールでDMARC TXTレコードを直接編集し、p=タグの値を変更してください。より簡単な方法をお探しの場合は、PowerDMARCの「Hosted DMARC」をご利用いただければ、ワンクリックでポリシーを更新できます。

7. DMARCチェックに失敗したメールを拒否するために、どのDMARCポリシーを使用しますか？

p=reject を指定してください。これにより、受信メールサーバーは、DMARC 認証に失敗したメッセージを即座にブロックするよう指示されます。そのメールは、受信者の受信トレイにもスパムフォルダにも届きません。認証に失敗したメールを完全にブロックするのではなく、スパムフォルダに振り分けたい場合は、代わりに p=quarantine を指定してください。

• について
• 最新記事

マイサム・アル・ラワティ

サイバーセキュリティ専門家PowerDMARC

マイサムは技術起業家であり、サイバーセキュリティの専門家であり、15年以上の業界経験を持つPowerDMARCのCEO兼創設者である。Maithamはマンチェスター大学でグローバルMBAを取得し、CISSP、CISM、CRISC、ISC2 CCSPなど様々な専門資格を持つ。

最新記事 by Maitham Al Lawati(全て見る)

• フィッシングメールとDMARC統計：2026年メールセキュリティ動向 - 2026年1月6日
• 2026年に「SPFレコードが見つかりません」を修正する方法 - 2026年1月3日
• SPF パーエラー：DNS ルックアップが多すぎる場合の修正方法 - 2025年12月24日