DMARC ポリシー
概要
DMARC ポリシー は、DMARC レコードの p= タグで指定する設定で、認証に失敗したメールを受信サーバーがどう処理するかをドメイン所有者が宣言します。値は none、quarantine、reject の 3 種類で、RFC 7489（2015年）で定義されています。
ポリシーが p=none のままでは DMARC を設定していてもなりすまし対策として機能しません。p=reject まで強化してはじめて、自社ドメインをヘッダー From に使ったなりすましメールを受信側が拒否できるようになります。Google は 2024 年 2 月から、1 日 5,000 通以上を送信する大量送信者に DMARC レコードの設定を義務化しています。2025 年 11 月以降は非準拠トラフィックへの執行が段階的に強化されており、設定がない場合は正規メールが迷惑メールフォルダに振り分けられるリスクがあります。
仕組み
DMARC ポリシーの処理フローは次の通りです。
- 受信サーバーが SPF と DKIM の認証を実行する
_dmarc.ドメインの TXT レコードからp=タグのポリシーを取得する- SPF アライメントまたは DKIM アライメントのどちらかが pass なら DMARC pass（ポリシーは適用されない）
- 両方のアライメントが fail なら DMARC fail となり、
p=の値に応じてメールを処理する
3 種類のポリシー
p=none はポリシーを適用しません。認証に失敗してもメールは通常通り配送されます。rua= や ruf= で指定したアドレスへのレポートは送信されます。DMARC 導入初期のモニタリングフェーズで使います。
p=quarantine は認証失敗メールを迷惑メールフォルダに振り分けます。Gmail や Outlook は Spam または Junk フォルダに移動します。メールが失われるわけではなく、受信者が確認すれば閲覧できます。
p=reject は認証失敗メールを受信拒否します。SMTP レベルで拒否するか、受信後に破棄するかはプロバイダーの実装によりますが、受信者には届きません。最も強力な保護です。
pct タグによる段階適用
pct= タグでポリシーを適用するメールの割合（パーセンテージ）を指定できます。
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com"この設定では、DMARC fail になったメールのうち 10% に p=quarantine を適用し、残り 90% は p=none と同様に扱います。p=reject への移行時のリスクを段階的に下げる目的で使います。省略時のデフォルトは 100 です。本番環境では最終的に pct=100 で運用します。
サブドメインポリシー
sp= タグでサブドメイン（例: marketing.example.com）に別のポリシーを適用できます。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"sp= を省略した場合、サブドメインはルートドメインの p= を継承します。サブドメインから送信するサービスの認証設定が追いついていない場合、sp=none や sp=quarantine で移行期間を設けます。
設定例
段階的な導入パターンです。
モニタリングフェーズ（p=none）
最初の 2〜4 週間は p=none で運用します。
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"rua で指定したアドレスに集計レポートが届きます。正規の送信元がすべて pass しているか確認します。
quarantine への移行
問題がないことを確認したら p=quarantine に移行します。
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"pct=25 から始めて、問題がなければ pct=100 に引き上げます。
reject への移行
最終目標は p=reject です。
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"BIMI を有効にするには p=quarantine 以上が必要です。Gmail と Yahoo Mail でロゴを表示したい場合は p=reject が前提です。
確認方法
DMARC レコードのポリシーは dig で確認できます。
dig TXT _dmarc.example.com;; ANSWER SECTION:
_dmarc.example.com. 3600 IN TXT "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"v=DMARC1 で始まる行の p= タグでポリシーを確認します。pct= が省略されている場合はデフォルトの 100 です。
外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth 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": { "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true, "selector": "default" },
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
"exists": true
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}data.dmarc.exists が true であれば外部から DMARC レコードが確認できる状態です。data.dmarc.record フィールドでポリシーを含むレコード全体を確認できます。
よくある問題
DMARC ポリシーの運用で陥りやすい問題は、ポリシーの強化を先送りにすることと、レポートなしで強化に踏み切ることです。
p=none のまま長期間放置する
最も多いパターンです。p=none はメールの処理に影響しないため、なりすまし対策として機能しません。rua レポートを 2〜4 週間確認して正規送信元の認証が安定したら、p=quarantine に移行します。「いつか強化する」と先送りにすると、Google や Yahoo の義務化要件に抵触するリスクがあります。
rua を設定せずポリシーを強化する
レポートなしで p=quarantine や p=reject に移行すると、正規メールが失われても気づけません。rua= は必ず設定します。集計レポートは XML 形式で届くため、dmarcian、Valimail などのレポート解析サービスを使うと可読性が上がります。
pct を下げたまま本番運用する
pct=10 のまま放置すると、90% のなりすましメールはポリシー適用外です。段階適用は移行期間の一時的な設定です。問題がないことを確認したら pct=100 に引き上げます。
サブドメインの送信元を見落として p=reject にする
marketing.example.com や notifications.example.com などサブドメインから送信するサービスが SPF / DKIM を設定していない場合、p=reject への移行後にそれらのメールが拒否されます。移行前に rua レポートでサブドメインの認証状況を確認します。sp=quarantine で先行してサブドメインのみ段階移行するのも有効です。
p=reject で転送メールが壊れる
メール転送サービス（例: Google Groups、大学のメール転送）を経由すると、転送先で SPF が fail します。DKIM 署名が維持されていれば DMARC は通過しますが、転送先が DKIM を改変する場合（一部のグループウェアが Subject: を追加するなど）は DKIM も fail します。転送経路の影響は rua レポートで確認します。