--- title: "DMARC ポリシー解説: none と quarantine と reject の違い | DMARC Report" description: "DMARC ポリシー（p= タグ）は、認証に失敗したメッセージをどう扱うかを受信側メールサーバーに指示します。p=none、p=quarantine、p=reject の違いと、完全な強制へ安全に移行する方法を解説します。" image: "https://dmarcreport.com/images/og-default.png" canonical: "https://dmarcreport.com/ja/dmarc-porishi/" --- DMARC ポリシー # あなたのドメインに最適な DMARC ポリシーを選ぶ **DMARC ポリシー（`p=` タグ）は、DMARC 認証に失敗したメッセージをどう扱うかを受信側メールサーバーに指示します。**選択肢は none、quarantine、reject の 3 つで、すべてのドメインは監視から完全な強制へと同じ道をたどるべきです。各ポリシーは[DMARC レコード](/ja/dmarc-rekodo/)で公開します。メール認証が初めての方は、まず[DMARC とは](/ja/dmarc-toha/)からご覧ください。 [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489) によれば、ポリシーは SPF アライメントと DKIM アライメントの両方が失敗した場合にのみ適用されます。どちらか一方が通過してアライメントすれば、ポリシーに関係なくメッセージは DMARC を通過します。 [ DMARC ポリシーを確認する → ](/ja/tools/dmarc-checker/) [タイムラインを見る](#policy-progression) 3 つのポリシー ## none、quarantine、reject 各ポリシーは強制への道のりの一段階です。まず可視性から始め、自信を築き、それから強制します。 `p=none` 監視のみ すべてを可視化し、何もブロックしません。 受信側のメールサーバーは、DMARC に失敗したメッセージに対して一切の強制措置を取りません。それでもドメイン所有者に集計レポートは送信され、そのドメインからメールを送信しているすべてのソースを完全に可視化できます。 レコード例 `v=DMARC1; p=none; rua=mailto:dmarc@example.com` メリット - 正規メールの配信にリスクがまったくありません - 集計レポートによりすべての送信ソースを完全に可視化できます - 必須の最初のステップ — 強制する前に必ず監視する必要があります - 一括送信者向けの Google/Yahoo の最低要件を満たします 制限 - スプーフィングやフィッシングに対する保護はまったく得られません - 攻撃者は依然としてあなたのドメインを装ってメールを送信でき、そのまま配信されます - 受信側でのドメインレピュテーションは向上しません 使うべきタイミング 必ずここから始めてください。rua= レポートとともに p=none を展開し、少なくとも 90 日間監視します。この期間を利用して、すべての正規送信者を特定し、その SPF/DKIM 設定を修正し、強制へ移行する前にアライメントを確認します。 失敗したメールに何が起こるか 1 メールが SPF + DKIM のアライメントに失敗 2 受信側が DMARC ポリシーを確認: p=none 3 メールは通常どおり受信トレイに配信される 4 集計レポートがドメイン所有者に送信される `p=quarantine` 迷惑メールへ振り分け 疑わしいメールは迷惑メールへ。正規メールはそのまま流れます。 DMARC に失敗したメッセージは、受信者の迷惑メールフォルダまたは迷惑メールフォルダに振り分けられます。メッセージ自体は残っており — 受信者が探せば見つけられます — 疑わしいものとして明確に印が付けられます。これはセーフティネットとなる強制ステップです。 レコード例 `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com` メリット - 能動的な保護 — スプーフィングされたメッセージが受信トレイから排除されます - 設定不備の送信者に対するセーフティネット（メッセージは失われません） - メールセキュリティを重視していることを受信側に示せます - 強制への移行期における適切な中間段階です 制限 - 認証が壊れている正規送信者は迷惑メールに振り分けられてしまいます - 受信者が迷惑メールフォルダを確認せず、メールを見逃す可能性があります - 一部の受信側は実運用上 quarantine を reject と同等に扱います 使うべきタイミング p=none で 90 日以上運用し、すべての正規送信者を特定して認証を通過させた後に移行します。集計レポートで、承認済みのすべてのソースについて SPF/DKIM のアライメントが一貫して通っていることが確認できてから移行してください。 失敗したメールに何が起こるか 1 メールが SPF + DKIM のアライメントに失敗 2 受信側が DMARC ポリシーを確認: p=quarantine 3 メールは迷惑メールフォルダへ振り分けられる 4 集計レポートがドメイン所有者に送信される `p=reject` 完全にブロック 完全な強制。スプーフィングされたメールは一切届きません。 DMARC に失敗したメッセージは SMTP レベルで拒否されます — 受信者の目に触れることはなく、送信サーバーにはバウンスが返されます。これは最も強力な保護であり、すべてのドメインが目指すべき最終目標です。 レコード例 `v=DMARC1; p=reject; rua=mailto:dmarc@example.com` メリット - ドメインのスプーフィングとフィッシングに対する最大の保護 - 攻撃者はあなたのドメインを装ったメールを配信できません - 受信側メールサーバーに対する最も高いドメインレピュテーションのシグナル - BIMI（Brand Indicators for Message Identification）の対象となります 制限 - 設定不備の正規送信者は完全にブロックされます — 迷惑メールにも入りません - アライメントを壊すメール転送チェーンは失敗します - 展開前に徹底した監視が必要です 使うべきタイミング p=quarantine で 90 日以上運用し、集計レポートがクリーンになった後に移行します。すべての正規送信者が一貫して SPF または DKIM のアライメントを通過している必要があります。p=none から p=reject までの完全な道のりは通常 9〜18 か月かかります。 失敗したメールに何が起こるか 1 メールが SPF + DKIM のアライメントに失敗 2 受信側が DMARC ポリシーを確認: p=reject 3 メールは SMTP レベルで拒否され、配信されない 4 集計レポートがドメイン所有者に送信される 道のり ## 完全な強制への道 すべてのドメインは同じ進め方をたどります。かかる期間は複雑さによって異なり — 送信者が多いほど設定に時間がかかります。最初のレコードから完全な p=reject までは **9〜18 か月**を見込んでください。 `p=none` ### フェーズ 1: 監視 最低 90 日 p=none と rua= レポートを設定して DMARC レコードを公開します。集計レポートを分析し、あなたのドメインからメールを送信しているすべてのソースを特定します。すべての正規送信者について SPF と DKIM を修正します。 `p=quarantine` ### フェーズ 2: 隔離 最低 90 日 p=quarantine へ移行します。pct=10 から始め、段階的に引き上げます。新たに影響を受けた送信者がいないかレポートを監視します。残っている認証の問題を修正します。 `p=reject` ### フェーズ 3: 拒否 継続的 すべての正規メールが通過するという確信をもって p=reject へ進みます。監視は継続してください — 新しい送信者、IP の変更、ベンダーのアップデートによって、いつでも認証が壊れる可能性があります。 ### 合計期間: 9〜18 か月 送信者が少ない組織は、より早く p=reject に到達できる場合があります。数十のサードパーティサービスを抱える複雑な環境では、より長い時間がかかります。重要なのはデータに基づいた判断です — 監視フェーズを決して飛ばさないでください。 段階的な展開 ## `pct=` タグ: セーフティネット付きの強制 `pct=` タグは、失敗したメッセージのうち強制措置を受ける割合を制御します。割合の対象外となったメッセージは、ポリシーが `p=none` であるかのように扱われます。これにより、問題を監視しながら強制を段階的に展開できます。 例 `v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com` 失敗したメッセージの 25% が隔離されます。残りの 75% は通常どおり配信されます。 `pct=10` 失敗したメッセージの 10% に強制措置を適用します。残りの 90% は p=none として扱われます。初期テストに最適です。 2〜4週間 `pct=25` 25% に引き上げます。新たに影響を受けた正規送信者がいないか、集計レポートを監視します。 2〜4週間 `pct=50` 失敗したメッセージの半分が強制措置を受けるようになります。ほとんどの問題はこの段階で表面化します。 2〜4週間 `pct=100` 完全な強制。DMARC アライメントに失敗したすべてのメッセージが、公開されたポリシーの措置を受けます。pct= を指定しない場合のデフォルト値です。 恒久的 DNS TXT Records \_dmarc.example.com `v=DMARC1; p=reject; sp=quarantine; rua=...` example.com p=reject \*.example.com sp=quarantine メインドメインは完全に強制されています。サブドメインは設定中の間、隔離されています。 サブドメインポリシー ## `sp=` タグ: サブドメインの制御 `sp=` タグは、サブドメイン用に別の DMARC ポリシーを設定します。これがないと、サブドメインはメインドメインの `p=` ポリシーを継承します。メインドメインは強制の準備ができているが、サブドメインにはもう少し時間が必要な場合に便利です。 - sp=none — サブドメインは設定中に監視されます - sp=quarantine — サブドメインは中間的な強制を受けます - sp=reject — サブドメインは完全に強制されます（p=reject のときの sp= 省略と同じ） - sp= の省略 — サブドメインは p= ポリシーを継承します これは避けましょう ## よくある DMARC ポリシーの間違い これらは DMARC 展開で最もよく見られる誤りです。どれも、適切な監視と段階的なアプローチによって防ぐことができます。 ### 強制が早すぎる p=none で少なくとも 90 日間運用せずに p=reject へ進むと、正規メールがブロックされます。マーケティングプラットフォーム、CRM ツール、チケット管理システムは、適切に設定されていないと DMARC に失敗しがちです。 ### 強制後の監視を怠る DMARC は設定して終わりではありません。新しい送信ソース、IP の変更、ベンダーのアップデートによって、いつでも認証が壊れる可能性があります。継続的な監視により、配信に影響が出る前に問題を検出できます。 ### サードパーティ送信者を無視する あなたの代わりにメールを送信するすべてのサービス — Mailchimp、HubSpot、Salesforce、Zendesk — には、SPF include または DKIM 署名を設定する必要があります。1 つでも漏れると強制時に失敗が発生します。 ### サブドメインを忘れる sp= タグがない場合、サブドメインはメインドメインのポリシーを継承します。しかし、サブドメインの送信者を確認せずに p=reject を強制すると、正規のサブドメインメールをブロックしてしまう可能性があります。sp= を明示的に設定してください。 ### rua= なしで公開する rua= レポートのない DMARC レコードは、目隠しで飛んでいるようなものです。認証結果への可視性がなく、スプーフィングを検出する手段もなく、強制の判断を下すためのデータもありません。 ### 厳密なアライメントが必要なのに緩和アライメントを使う 緩和アライメント（デフォルト）では、mail.example.com が example.com とアライメントできます。ほとんどの組織ではこれで正しいのですが、高セキュリティのドメインでは、サブドメインの悪用を防ぐために厳密なアライメントが必要になる場合があります。 FAQ ## DMARC ポリシーに関するよくある質問 ### 最適な DMARC ポリシーは何ですか? 最適な DMARC ポリシーは p=reject で、ドメインのスプーフィングに対する最大の保護を提供します。ただし、p=reject には段階的なアプローチで到達する必要があります。まず p=none から始め（90 日以上監視）、次に p=quarantine へ移行し（90 日以上）、その後 p=reject を強制します。いきなり reject に進むと正規メールがブロックされてしまいます。 ### 強制する前に p=none にどのくらいとどまるべきですか? p=none には最低 90 日間 — 丸一四半期 — とどまってください。これにより、すべての正規送信ソースを特定し、その認証を修正するのに十分な集計レポートのデータが得られます。サードパーティ送信者が多い組織では、さらに長い期間が必要になる場合があります。p=reject までの完全な道のりは通常 9〜18 か月かかります。 ### p=quarantine は十分な保護になりますか? quarantine は、スプーフィングされたメッセージが受信トレイに届かなくなるため、p=none から見て意味のある一歩前進です。ただし、それらは依然として迷惑メールフォルダに存在します。完全な保護のためには p=reject が目標です — スプーフィングされたメッセージの配信を完全に防ぎます。一部のコンプライアンスフレームワーク（PCI DSS v4.0 など）は、明確に p=reject を要求しています。 ### p=reject を設定して正規送信者が失敗した場合、どうなりますか? その正規送信者のメールは拒否されます — 受信者には届きません。だからこそ、強制する前に p=none と p=quarantine での監視が不可欠なのです。pct= タグを使って強制を段階的に展開すれば（最初は pct=10）、すべてのメールに影響が及ぶ前に設定不備を検出できます。 ### ドメインとサブドメインで異なるポリシーを設定できますか? はい。sp=（サブドメインポリシー）タグを使えば、サブドメインに別のポリシーを設定できます。たとえば、メインドメインには p=reject を強制しつつ、まだ設定中のサブドメインには sp=none を維持することができます。sp= が設定されていない場合、サブドメインはメインドメインのポリシーを継承します。 ### pct= タグとは何で、どのように使うべきですか? pct= タグは、失敗したメッセージのうち強制措置を受ける割合を制御します。pct=10 では、失敗したメッセージの 10% のみが quarantine または reject され、残りは p=none として扱われます。数週間かけて 10 → 25 → 50 → 100 と段階的に増やすことで、完全な強制へ安全に移行できます。 ## 現在の DMARC ポリシーの動きを確認しましょう 無料トライアル — 集計レポートを監視し、送信者を特定し、強制への道のりを計画します。 [無料トライアルを始める](https://app.dmarcreport.com/signup?plan=free) ## 多くのチームが強制のために DMARC Report を信頼しています ![G2 Leader - DMARC](https://media.mailhop.org/dmarcreport/images/g2-badges/DMARC_Leader_Leader.png) Rated 4.8/5 on G2 · 469 verified reviews ![G2 Momentum Leader - DMARC](https://media.mailhop.org/dmarcreport/images/g2-badges/DMARC_MomentumLeader_Leader.png) ZK Zunaid K. Director 5/5 ### "Essential tool for email delivery" This tool helps us to implement DMARC reporting for our domains in an easy to use manner. 8/8/2024Verified on G2 VU Verified User in Information Technology and Services 5/5 ### "Best security tool for your own domains" The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind. 8/31/2022Verified on G2 LH Larry H. Research & Development Manager 5/5 ### "Good tool to buy" I have used many tools for monitoring DMARC reports. But DMARC Report is a good tool to use. It helps avoid sending emails to spam. 8/30/2022Verified on G2 [Read all 469 reviews on G2 →](https://www.g2.com/products/dmarc-report/reviews) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"471","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"DMARC Report","url":"https://dmarcreport.com","description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","publisher":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"最適な DMARC ポリシーは何ですか?","acceptedAnswer":{"@type":"Answer","text":"最適な DMARC ポリシーは p=reject で、ドメインのスプーフィングに対する最大の保護を提供します。ただし、p=reject には段階的なアプローチで到達する必要があります。まず p=none から始め（90 日以上監視）、次に p=quarantine へ移行し（90 日以上）、その後 p=reject を強制します。いきなり reject に進むと正規メールがブロックされてしまいます。"}},{"@type":"Question","name":"強制する前に p=none にどのくらいとどまるべきですか?","acceptedAnswer":{"@type":"Answer","text":"p=none には最低 90 日間 — 丸一四半期 — とどまってください。これにより、すべての正規送信ソースを特定し、その認証を修正するのに十分な集計レポートのデータが得られます。サードパーティ送信者が多い組織では、さらに長い期間が必要になる場合があります。p=reject までの完全な道のりは通常 9〜18 か月かかります。"}},{"@type":"Question","name":"p=quarantine は十分な保護になりますか?","acceptedAnswer":{"@type":"Answer","text":"quarantine は、スプーフィングされたメッセージが受信トレイに届かなくなるため、p=none から見て意味のある一歩前進です。ただし、それらは依然として迷惑メールフォルダに存在します。完全な保護のためには p=reject が目標です — スプーフィングされたメッセージの配信を完全に防ぎます。一部のコンプライアンスフレームワーク（PCI DSS v4.0 など）は、明確に p=reject を要求しています。"}},{"@type":"Question","name":"p=reject を設定して正規送信者が失敗した場合、どうなりますか?","acceptedAnswer":{"@type":"Answer","text":"その正規送信者のメールは拒否されます — 受信者には届きません。だからこそ、強制する前に p=none と p=quarantine での監視が不可欠なのです。pct= タグを使って強制を段階的に展開すれば（最初は pct=10）、すべてのメールに影響が及ぶ前に設定不備を検出できます。"}},{"@type":"Question","name":"ドメインとサブドメインで異なるポリシーを設定できますか?","acceptedAnswer":{"@type":"Answer","text":"はい。sp=（サブドメインポリシー）タグを使えば、サブドメインに別のポリシーを設定できます。たとえば、メインドメインには p=reject を強制しつつ、まだ設定中のサブドメインには sp=none を維持することができます。sp= が設定されていない場合、サブドメインはメインドメインのポリシーを継承します。"}},{"@type":"Question","name":"pct= タグとは何で、どのように使うべきですか?","acceptedAnswer":{"@type":"Answer","text":"pct= タグは、失敗したメッセージのうち強制措置を受ける割合を制御します。pct=10 では、失敗したメッセージの 10% のみが quarantine または reject され、残りは p=none として扱われます。数週間かけて 10 → 25 → 50 → 100 と段階的に増やすことで、完全な強制へ安全に移行できます。"}}]}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://dmarcreport.com/"},{"@type":"ListItem","position":2,"name":"学ぶ","item":"https://dmarcreport.com/ja/dmarc-toha/"},{"@type":"ListItem","position":3,"name":"DMARC ポリシー","item":"https://dmarcreport.com/ja/dmarc-porishi/"}]} ```