DMARC ポリシー段階的移行ガイド — p=none から p=reject へ安全に移行する手順
DMARC を p=none で運用しているドメインは、認証失敗メールを監視できていても、なりすましメールの配信を止められていません。Gmail は2024年2月からバルクセンダーに DMARC を必須化し、Outlook（Microsoft 365）も2025年5月から未認証メールの拒否を強化しています。p=none のままではこれらの要件を形式的に満たしていても、ドメインの保護としては不十分です。
このガイドでは、p=none → p=quarantine → p=reject への移行を pct タグで段階的に進める手順を解説します。なお、現在 IETF で策定中の DMARCbis（RFC 7489 の後継仕様）では pct タグが廃止される予定です。代わりに t=y（テストモード）が導入されますが、これは段階的適用ではなく、全メールに対してポリシーを評価しつつレポートのみを生成するモードです。DMARCbis が発行されるまでは、本ガイドの pct を使った段階的移行が有効な手法です。example.com の部分は実際のドメイン名に置き換えてください。
flowchart TD
A["p=none で運用開始"] --> B["集計レポート（rua）を\n2〜4 週間収集"]
B --> C{"正規送信元がすべて\n認証を通過しているか？"}
C -- No --> D["未認証の送信元を修正\n（SPF include / DKIM 設定）"]
D --> B
C -- Yes --> E["p=quarantine\npct=10 に変更"]
E --> F{"1〜2 週間のレポートで\n問題なし？"}
F -- No --> G["pct を維持して原因調査"]
G --> F
F -- Yes --> H["pct=50 → pct=100\nに段階的に引き上げ"]
H --> I["p=reject\npct=10 に変更"]
I --> J{"1〜2 週間のレポートで\n問題なし？"}
J -- No --> K["pct を維持して原因調査"]
K --> J
J -- Yes --> L["pct=50 → pct=100\nに段階的に引き上げ"]
L --> M["移行完了"]
チェックリスト一括コピー用
以下をコピーして手元のメモやIssueに貼り付ければ、そのまま確認リストとして使えます。
## DMARC ポリシー移行チェックリスト
### Step 1 現状確認
- [ ] DMARC レコードが存在し、`p=none` と `rua=` が設定されている
- `dig TXT _dmarc.example.com +short`
- [ ] SPF と DKIM が正しく設定されている
- [ ] 集計レポート（rua）が届いている
### Step 2 レポート分析
- [ ] 過去 2〜4 週間分のレポートを確認した
- [ ] SPF・DKIM 両方とも失敗している送信元を特定した
- [ ] 正規の送信元がすべて SPF または DKIM のアライメントを通過している
### Step 3 quarantine への移行
- [ ] pct=10 で quarantine を適用した
- [ ] 1〜2 週間分のレポートで誤検知がないことを確認した
- [ ] pct=50 に引き上げた
- [ ] pct=100 に引き上げた（または pct タグを削除した）
### Step 4 reject への移行
- [ ] pct=10 で reject を適用した
- [ ] 1〜2 週間分のレポートで誤検知がないことを確認した
- [ ] pct=50 に引き上げた
- [ ] pct=100 に引き上げた（または pct タグを削除した）
### Step 5 移行後の運用
- [ ] サブドメインポリシー（sp=）を設定した
- [ ] `fo` タグでフォレンジックレポートの条件を設定した
- [ ] 集計レポートの定期確認スケジュールを決めた（月次など）
### 一括確認（API）
- `curl "https://labee.dev/api/mail-auth?domain=example.com"`Step 1 現在の DMARC 設定を確認する
移行を始める前に、現在の DMARC レコードの状態を正確に把握します。p=none が設定されていること、rua= でレポート受信先が指定されていること、SPF と DKIM が正しく設定されていること。この3点が移行の前提条件です。
チェック項目
-
_dmarc.example.comに TXT レコードが存在し、p=noneが設定されている -
rua=でレポート受信先が指定されている - 集計レポート（rua）がレポート受信先メールアドレスに届いていることを確認した
- SPF レコードが存在し、
include:に利用中のメール送信サービスが含まれている - DKIM レコードが存在し、正しいセレクターで公開鍵が公開されている
確認コマンド
dig TXT _dmarc.example.com +short"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"p=none であること、rua= が存在することを確認します。rua= がない場合は、ポリシー移行を始める前にレポート受信先を追加してください。レポートなしでポリシーを強化すると、正規メールが拒否されても気づけません。
labee.dev の API でも同じ情報を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:_spf.google.com ~all",
"exists": true
},
"dkim": {
"mode": "auto",
"record": "v=DKIM1; k=rsa; p=MIIBIjAN...",
"exists": true,
"selector": "google",
"matches": [
{ "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjAN...", "exists": true }
],
"checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp", "mte1", "mte2", "pdk1", "pdk2", "mesmtp", "zoho"],
"exhaustive": false
},
"dmarc": {
"record": "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com",
"exists": true,
"source": "exact",
"domain": "example.com"
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 142 }
}data.dmarc.exists が true で、data.dmarc.record に p=none と rua= が含まれていることを確認します。data.spf.exists と data.dkim.exists も true である必要があります。
data.dmarc.source が organizational の場合、レコードは親ドメインから継承されています。サブドメイン固有のポリシーを設定するには、サブドメインに直接 DMARC レコードを追加してください。
Step 2 集計レポートを分析する
p=none の状態で rua= に届く集計レポート（Aggregate Report）は、どの IP アドレスが自ドメインを使ってメールを送信しているかを一覧で示します。ポリシーを強化する前に、このレポートを 2〜4 週間分 蓄積して分析します。
集計レポートは XML 形式（.xml.gz）で送られてきます。手動で読むこともできますが、dmarcian、Postmark DMARC Digests、EasyDMARC などの解析サービスを使うと視覚的に把握しやすくなります。
チェック項目
- 過去 2〜4 週間分の集計レポートを確認した
- SPF・DKIM 両方とも失敗している送信元 IP を特定した
- 正規の送信元（自社メールサーバー、利用中の SaaS）がすべて SPF または DKIM のアライメントを通過している
- 認識のない送信元 IP がないか確認した
レポートの読み方
集計レポートの XML には <record> 要素が送信元 IP ごとに含まれています。確認すべきフィールドは以下の3つです。
<source_ip>— メールを送信した IP アドレス<policy_evaluated>の<dkim>と<spf>— DMARC の評価結果（pass / fail）<auth_results>の<dkim>と<spf>— 個別の認証結果とドメイン
DMARC は SPF と DKIM のどちらか一方がアライメントを通過すれば pass になります。両方とも fail している送信元は、なりすましか、認証設定が漏れている正規サービスのどちらかです。
正規サービスの認証が漏れている場合は、ポリシー移行の前に SPF の include: 追加や DKIM の設定を行ってください。すべての正規送信元がアライメントを通過している状態が、次のステップに進む判断基準です。
Step 3 p=quarantine に移行する
レポート分析で正規送信元がすべてアライメントを通過していることを確認したら、p=quarantine への移行を開始します。pct タグを使い、対象メールの一部から段階的に適用範囲を広げます。
pct=10 は、認証に失敗したメールの 10% に quarantine ポリシーを適用します。残りの 90% は受信サーバーのローカルポリシーに従って通常どおり分類されます（RFC 7489 Section 6.6.4「apply local message classification as normal」）。
Step 4 で扱う p=reject の場合は挙動が異なります。p=reject; pct=10 では、非サンプル分の 90% に quarantine ポリシーに準じた処理が適用されます（RFC 7489 Section 6.6.4 SHOULD）。
チェック項目
- DMARC レコードを
p=quarantine; pct=10に変更した - 変更後 1〜2 週間分のレポートで正規メールが quarantine されていないことを確認した
-
pct=50に引き上げた - 再度 1〜2 週間のレポートを確認し、問題がないことを確認した
-
pct=100に引き上げた（またはpctタグを削除した）
段階適用の手順
DNS の TXT レコードを以下の順序で更新します。各段階で 1〜2 週間 はレポートを確認してから次に進んでください。
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.comレポートに問題がなければ pct=50 に変更します。
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.comさらに問題がなければ pct=100 に変更するか、pct タグ自体を削除します。RFC 7489 では pct のデフォルト値は 100 と定義されているため、省略すると全件に適用されます。
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com確認コマンド
各段階で DNS の変更が反映されたかを確認します。
dig TXT _dmarc.example.com +short"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"labee.dev の API でも確認できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:_spf.google.com ~all",
"exists": true
},
"dkim": {
"mode": "auto",
"record": "v=DKIM1; k=rsa; p=MIIBIjAN...",
"exists": true,
"selector": "google",
"matches": [
{ "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjAN...", "exists": true }
],
"checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp", "mte1", "mte2", "pdk1", "pdk2", "mesmtp", "zoho"],
"exhaustive": false
},
"dmarc": {
"record": "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com",
"exists": true,
"source": "exact",
"domain": "example.com"
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 115 }
}data.dmarc.record の p=quarantine と pct=10 が反映されていることを確認します。
Step 4 p=reject に移行する
p=quarantine を pct=100 で運用して問題がなければ、最終段階の p=reject に移行します。p=reject は認証に失敗したメールを受信サーバーが完全に拒否するポリシーです。quarantine と同様に pct タグで段階的に適用します。
チェック項目
- DMARC レコードを
p=reject; pct=10に変更した - 変更後 1〜2 週間分のレポートで正規メールが拒否されていないことを確認した
-
pct=50に引き上げた - 再度 1〜2 週間のレポートを確認し、問題がないことを確認した
-
pct=100に引き上げた（またはpctタグを削除した）
段階適用の手順
v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@example.comv=DMARC1; p=reject; pct=50; rua=mailto:dmarc-reports@example.comv=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com移行判断の基準
次の段階に進む判断は、集計レポートの数値に基づきます。
- 正規送信元の DMARC pass 率が 99% 以上 を維持している
- quarantine / reject されたメールに正規送信元のものが含まれていない
- 新しいメール送信サービスの追加予定がない（追加する場合は先に SPF / DKIM を設定する）
pass 率が 95% 未満 の場合は、ポリシーを引き上げる前に認証設定を見直してください。
確認コマンド
dig TXT _dmarc.example.com +short"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"labee.dev の API で最終状態を確認します。
curl "https://labee.dev/api/mail-auth?domain=example.com"{
"success": true,
"data": {
"spf": {
"record": "v=spf1 include:_spf.google.com ~all",
"exists": true
},
"dkim": {
"mode": "auto",
"record": "v=DKIM1; k=rsa; p=MIIBIjAN...",
"exists": true,
"selector": "google",
"matches": [
{ "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjAN...", "exists": true }
],
"checkedSelectors": ["google", "selector1", "selector2", "s1", "s2", "k1", "k2", "k3", "default", "dkim", "mail", "smtp", "mte1", "mte2", "pdk1", "pdk2", "mesmtp", "zoho"],
"exhaustive": false
},
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com",
"exists": true,
"source": "exact",
"domain": "example.com"
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 108 }
}data.dmarc.record が p=reject で pct タグが含まれていないことを確認します。これで DMARC ポリシーの移行は完了です。
Step 5 移行後の運用を整備する
p=reject への移行が完了したら、継続的な運用体制を整えます。サブドメインのポリシー設定、フォレンジックレポートの活用、定期的なレポート確認が主な作業です。
チェック項目
- サブドメインポリシー（
sp=）を設定した -
foタグでフォレンジックレポートの条件を設定した - 集計レポートの定期確認スケジュールを決めた（月次など）
サブドメインポリシー
DMARC レコードの sp= タグは、サブドメインに個別の DMARC レコードがない場合に適用されるポリシーです。組織ドメインが p=reject でも、sp= を設定していなければサブドメインにも p=reject が継承されます。メールを送信しないサブドメインには明示的に sp=reject を設定し、メール送信に使うサブドメインには個別の DMARC レコードを設定してください。
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.comフォレンジックレポート
ruf= タグを設定すると、認証失敗メールの個別レポート（Failure Report）を受信できます。fo タグでレポート生成の条件を指定します。
fo=0（デフォルト） — SPF と DKIM の両方が fail した場合のみfo=1— SPF または DKIM のどちらかが fail した場合fo=d— DKIM の署名検証が fail した場合fo=s— SPF の検証が fail した場合
fo=1 を設定すると、片方だけ fail しているケースも把握できるため、認証設定の漏れを早期に発見できます。
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1フォレンジックレポートにはメールヘッダーの一部が含まれるため、プライバシーの観点から送信を制限するプロバイダーもあります。Gmail はフォレンジックレポートを送信しません。
用語解説fo タグ（Failure Reporting Options）DMARC レコードの fo タグで、フォレンジックレポートの送信条件を指定する設定。認証失敗の原因特定に活用する。よくある設定ミス
pct を使わずに一気に p=reject へ変更する
p=none からいきなり p=reject に切り替えると、認証設定が漏れている正規サービスからのメールもすべて拒否されます。転送メールは SPF が fail しやすく、DKIM の署名が壊れるケースもあります。pct タグを使い、10% → 50% → 100% と段階的に適用範囲を広げることで、影響を最小限に抑えられます。
レポートを確認せずに pct を引き上げる
pct を引き上げるタイミングは、集計レポートの分析結果に基づいて判断します。各段階で最低 1〜2 週間 はレポートを確認してください。レポートを確認せずに引き上げると、正規メールの拒否に気づくのが遅れます。
新しいメール送信サービスを追加した後に認証設定を忘れる
マーケティングツールや CRM など、新たにメール送信サービスを追加した場合、SPF の include: と DKIM のセレクター設定を行わないと、そのサービスからのメールは DMARC fail になります。p=reject の状態でこれが発生すると、メールが届かなくなります。SendGrid、Amazon SES、Postmark などの主要なメール送信サービスでは、セットアップガイドに SPF と DKIM の設定手順が記載されています。新しいサービスを追加する際は、メール送信を開始する前に各サービスのガイドに従って認証設定を完了してください。
サブドメインの DMARC を見落とす
組織ドメインに p=reject を設定しても、サブドメインからの送信が想定と異なる動作をすることがあります。サブドメインに個別の DMARC レコードがない場合、組織ドメインのポリシーが継承されます。メールを送信するサブドメインには個別のレコードを設定し、送信しないサブドメインには sp=reject で明示的に拒否してください。
アライメントモードの不一致
DMARC のアライメントには relaxed（デフォルト）と strict の2種類があります。aspf=s や adkim=s を設定すると strict モードになり、SPF や DKIM のドメインが From ヘッダーのドメインと完全に一致する必要があります。サブドメインから送信している場合、strict モードではアライメントが fail する可能性があります。特別な理由がなければ、relaxed モード（デフォルト）のままにしてください。