あなたのドメインに最適な
DMARC ポリシーを選ぶ
DMARC ポリシー（p= タグ）は、DMARC 認証に失敗したメッセージをどう扱うかを受信側メールサーバーに指示します。選択肢は none、quarantine、reject の 3 つで、すべてのドメインは監視から完全な強制へと同じ道をたどるべきです。各ポリシーはDMARC レコードで公開します。メール認証が初めての方は、まずDMARC とはからご覧ください。
RFC 7489 によれば、ポリシーは SPF アライメントと DKIM アライメントの両方が失敗した場合にのみ適用されます。どちらか一方が通過してアライメントすれば、ポリシーに関係なくメッセージは DMARC を通過します。
none、quarantine、reject
各ポリシーは強制への道のりの一段階です。まず可視性から始め、自信を築き、それから強制します。
p=none 監視のみ すべてを可視化し、何もブロックしません。
受信側のメールサーバーは、DMARC に失敗したメッセージに対して一切の強制措置を取りません。それでもドメイン所有者に集計レポートは送信され、そのドメインからメールを送信しているすべてのソースを完全に可視化できます。
v=DMARC1; p=none; rua=mailto:dmarc@example.com - 正規メールの配信にリスクがまったくありません
- 集計レポートによりすべての送信ソースを完全に可視化できます
- 必須の最初のステップ — 強制する前に必ず監視する必要があります
- 一括送信者向けの Google/Yahoo の最低要件を満たします
- スプーフィングやフィッシングに対する保護はまったく得られません
- 攻撃者は依然としてあなたのドメインを装ってメールを送信でき、そのまま配信されます
- 受信側でのドメインレピュテーションは向上しません
必ずここから始めてください。rua= レポートとともに p=none を展開し、少なくとも 90 日間監視します。この期間を利用して、すべての正規送信者を特定し、その SPF/DKIM 設定を修正し、強制へ移行する前にアライメントを確認します。
メールが SPF + DKIM のアライメントに失敗
受信側が DMARC ポリシーを確認: p=none
メールは通常どおり受信トレイに配信される
集計レポートがドメイン所有者に送信される
p=quarantine 迷惑メールへ振り分け 疑わしいメールは迷惑メールへ。正規メールはそのまま流れます。
DMARC に失敗したメッセージは、受信者の迷惑メールフォルダまたは迷惑メールフォルダに振り分けられます。メッセージ自体は残っており — 受信者が探せば見つけられます — 疑わしいものとして明確に印が付けられます。これはセーフティネットとなる強制ステップです。
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - 能動的な保護 — スプーフィングされたメッセージが受信トレイから排除されます
- 設定不備の送信者に対するセーフティネット（メッセージは失われません）
- メールセキュリティを重視していることを受信側に示せます
- 強制への移行期における適切な中間段階です
- 認証が壊れている正規送信者は迷惑メールに振り分けられてしまいます
- 受信者が迷惑メールフォルダを確認せず、メールを見逃す可能性があります
- 一部の受信側は実運用上 quarantine を reject と同等に扱います
p=none で 90 日以上運用し、すべての正規送信者を特定して認証を通過させた後に移行します。集計レポートで、承認済みのすべてのソースについて SPF/DKIM のアライメントが一貫して通っていることが確認できてから移行してください。
メールが SPF + DKIM のアライメントに失敗
受信側が DMARC ポリシーを確認: p=quarantine
メールは迷惑メールフォルダへ振り分けられる
集計レポートがドメイン所有者に送信される
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 か月かかります。
メールが SPF + DKIM のアライメントに失敗
受信側が DMARC ポリシーを確認: p=reject
メールは SMTP レベルで拒否され、配信されない
集計レポートがドメイン所有者に送信される
完全な強制への道
すべてのドメインは同じ進め方をたどります。かかる期間は複雑さによって異なり — 送信者が多いほど設定に時間がかかります。最初のレコードから完全な 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= を指定しない場合のデフォルト値です。
恒久的v=DMARC1; p=reject; sp=quarantine; rua=... メインドメインは完全に強制されています。サブドメインは設定中の間、隔離されています。
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 とアライメントできます。ほとんどの組織ではこれで正しいのですが、高セキュリティのドメインでは、サブドメインの悪用を防ぐために厳密なアライメントが必要になる場合があります。
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 Report を信頼しています
Rated 4.8/5 on G2 · 469 verified reviews
Zunaid K.
Director
"Essential tool for email delivery"
This tool helps us to implement DMARC reporting for our domains in an easy to use manner.
Verified User in Information Technology and Services
"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.
Larry H.
Research & Development Manager
"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.