DMARCポリシーとは？none・quarantine・rejectの違いと正しい設定手順を解説
メール配信を運用するうえで、避けて通れないのが「DMARC（ディーマーク）」の設定です。特に2024年2月以降、Googleが1日5,000通以上のメールを送信する大量送信者に対してDMARC対応を義務化したことで、DMARCポリシーの理解と適切な設定は、すべてのメール送信者にとって必須の知識となりました。
しかし、「DMARCポリシーにはnone・quarantine・rejectの3種類があるけど、どう違うのか」「自社のドメインにはどのポリシーを設定すべきか」「そもそもDMARCレコードの書き方がよく分からない」こうした疑問を抱えるシステム管理者やエンジニアは少なくありません。
本記事では、DMARCポリシーの基礎から、3つのポリシーの違い、DNSレコードの具体的な書き方、そしてnoneからrejectまでの段階的な移行手順までを、実務に即した視点で徹底的に解説します。
目次
DMARCポリシーとは？仕組みと役割を理解する
DMARCポリシーを正しく設定するためには、まずDMARCの仕組み全体を理解しておくことが重要です。
DMARCの基本的な仕組み
DMARC（Domain-based Message Authentication, Reporting and Conformance）は、メールの送信元ドメインを認証し、なりすましメールからドメインを保護するための技術仕様です。DMARCは単独で機能するものではなく、既存の2つの認証技術「SPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）」の認証結果を利用して動作します。DMARCの動作フローは以下の通りです。
- 送信者がメールを送信する
- 受信側メールサーバーがSPFとDKIMの認証を行う
- 受信側メールサーバーが「アライメント（ドメインの一致確認）」をチェックする
- SPFまたはDKIMのいずれかが認証に合格し、かつアライメントもパスすればDMARC認証成功
- DMARC認証に失敗した場合、DMARCポリシーに基づいて受信側がメールを処理する
ここでの「アライメント」とは、メールのHeader-From（差出人として表示されるドメイン）と、SPFで認証されたReturn-PathドメインまたはDKIMの署名ドメイン（d=タグ）が一致しているかどうかを確認する仕組みです。
DMARCポリシーの役割
DMARCポリシーとは、DMARC認証に失敗したメールを受信側サーバーにどう処理してもらうかを、ドメイン所有者が指定するルールです。このポリシーはDNSのTXTレコードとして公開され、世界中の受信メールサーバーが参照できるようになっています。
重要なのは、DMARCポリシーはあくまで「要請（request）」であるという点です。受信側サーバーがポリシーに従うかどうかは、最終的にはそのサーバーの判断に委ねられます。ただし、GmailやMicrosoft 365をはじめとする主要なメールサービスは、DMARCポリシーを尊重して処理を行います。
3つのDMARCポリシーの違い｜none・quarantine・reject
DMARCポリシーには、none（監視）・quarantine（隔離）・reject（拒否）の3段階があります。それぞれの動作と特徴を正確に理解しておきましょう。
DMARCポリシー比較表
| ポリシー | 認証失敗時の処理 | セキュリティレベル | 推奨用途 |
|---|---|---|---|
| none | 何もしない（通常通り配信） | 低 | 導入初期の監視・レポート収集 |
| quarantine | 迷惑メールフォルダ等に隔離 | 中 | 段階的強化の中間段階 |
| reject | 受信を完全に拒否 | 高 | 最終的な到達目標 |
p=none（監視モード）
p=noneは、DMARC認証に失敗したメールに対して何もアクションを取らず、通常通り受信トレイに配信するポリシーです。「監視モード」とも呼ばれます。
このポリシーの最大の目的は、DMARCレポートを収集して、自社ドメインからのメール送信状況を可視化することにあります。DMARCレコードにruaタグでレポート送信先を指定しておくと、受信側サーバーから集計レポート（Aggregate Report）がXML形式で届きます。
p=noneが適している状況
最終的にはp=rejectを目指すべきではあるものの、いきなりp=rejectに設定するのはリスクもあります。そのため、以下のような状況ではまずp=noneで設定するのがよいでしょう。
- DMARC導入の初期段階で、まず現状把握をしたい場合
- SPF・DKIMの設定漏れがないか確認したい場合
- 正規のメール送信元（サードパーティサービス等）をすべて把握できていない場合
p=noneの注意点
p=noneはなりすましメールをブロックする効果が一切ありません。あくまでレポートを収集するための「準備段階」であり、長期間にわたってp=noneのまま放置することは、セキュリティ上のリスクを放置していることと同義です。
p=quarantine（隔離モード）
p=quarantineは、DMARC認証に失敗したメールを迷惑メールフォルダや隔離フォルダに振り分けるよう受信側サーバーに指示するポリシーです。
quarantineの利点は、なりすましメールが受信者の目に直接触れるリスクを大幅に低減しながらも、万が一の正規メールの誤判定に対するセーフティネットが残っている点です。隔離されたメールは、受信者が迷惑メールフォルダを確認すれば確認できるため、完全にメールが消えてしまうrejectとは異なります。
p=quarantineが適している状況
p=noneの次はp=quarantineに進みましょう。例えば、メールに企業ロゴを表示させるBIMIを導入する場合はp=quarantineかp=rejectが必須となります。つまり、p=quarantineの設定は、セキュリティ対策が適切に行われている一つの指標となります。
- p=noneでのレポート分析が完了し、主要な送信元のSPF・DKIM設定が整った段階
- rejectに移行する前のテスト期間として
- 正規メールの認証失敗リスクを最小化した後の中間ステップとして
p=reject（拒否モード）
p=rejectは、DMARC認証に失敗したメールを受信側サーバーが完全に拒否し、受信者に一切配信しないポリシーです。これはDMARCの最も厳格なセキュリティレベルです。
rejectを設定することで、自社ドメインを騙ったフィッシングメールやなりすましメールを受信段階で完全にブロックできます。攻撃者が偽のFrom:ヘッダーで自社ドメインを詐称したメールを送信しても、受信側サーバーがSMTPセッション中にリジェクトするため、エンドユーザーの受信トレイはもちろん、迷惑メールフォルダにすら届きません。
p=rejectが適している状況
最も強固なポリシーとなります。最終的にはp=rejectを目指すのがベストです。
- SPF・DKIMの設定が完全に整い、すべての正規メール送信元がDMARC認証をパスしている状態
- p=quarantineで十分な期間を経て、誤判定がないことが確認できた場合
- ブランド保護やコンプライアンス要件で厳格なメール認証が求められる場合
p=rejectの重大な注意点
設定に不備がある状態でrejectを有効にすると、正規のメール（システムからの自動送信メール、サードパーティ経由のメルマガ等）までブロックされてしまうリスクがあります。特に、メール配信サービスやSaaSツールなど、自社ドメイン以外のサーバーからメールを送信しているケースでは、それらのサービスに対してSPFのinclude:設定やDKIM署名の委任設定を事前に完了させておく必要があります。
企業ロゴを表示させる「BIMI」とは？
DMARCポリシーを quarantine または reject に設定することで利用可能になるのが、BIMI（ビミ）という仕組みです。BIMIを導入すると、受信者のメール一覧画面で、送信者名の横に自社の公式ロゴマークを表示させることができます。
- 視認性の向上：アイコンが並ぶ中で自社ロゴが目立ち、開封を促す
- 信頼の証：なりすまし対策を徹底している「安全なドメイン」であることの証明
- ブランド露出：メールを開封する前からユーザーの目にブランドロゴが触れる
BIMIの導入にはDMARCの厳格な運用（p=quarantine以上）が必須条件となっているため、セキュリティ強化がそのままマーケティング効果に直結する大きなメリットとなります。
BIMIについての詳細は、BIMIのメリットから導入までのステップ、失敗しないためのDMARC移行ロードマップ、BIMI設定チェックリストまでをまとめたBIMI完全ガイドを無料でご用意しましたのでご活用ください。BIMIについてのお問い合わせやご相談も可能ですのでお気軽にお問い合わせください。
DMARCレコードの設定方法｜DNSへの具体的な書き方
DMARCポリシーは、ドメインのDNSにTXTレコードとして追加することで設定します。ここでは、DMARCレコードの各タグの意味と、具体的な記述例を解説します。
DMARCレコードの主要タグ一覧
| タグ | 必須/任意 | 説明 | 設定例 |
|---|---|---|---|
v | 必須 | DMARCのバージョン（固定値） | v=DMARC1 |
p | 必須 | ポリシー（none/quarantine/reject） | p=quarantine |
rua | 推奨 | 集計レポートの送信先メールアドレス | rua=mailto:dmarc@example.com |
ruf | 任意 | 失敗レポート（フォレンジック）の送信先 | ruf=mailto:forensic@example.com |
sp | 任意 | サブドメインに適用するポリシー | sp=reject |
pct | 任意 | ポリシーを適用するメールの割合（0-100） | pct=50 |
adkim | 任意 | DKIMアライメントモード（s=strict/r=relaxed） | adkim=r |
aspf | 任意 | SPFアライメントモード（s=strict/r=relaxed） | aspf=r |
fo | 任意 | 失敗レポートの生成条件 | fo=1 |
DMARCレコードの記述例
DMARCレコードは、ドメインのDNS管理画面で以下のように設定します。
- ホスト名（レコード名）：
_dmarc.example.com（または_dmarc） - レコードタイプ： TXT
導入初期（監視モード）の記述例
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comこれは「DMARC認証に失敗しても何もしないが、集計レポートをdmarc-reports@example.comに送信してほしい」という意味です。
段階的強化（隔離モード・50%適用）の記述例
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.compct=50を指定することで、認証失敗メールの50%にのみquarantineを適用し、残りの50%にはポリシーが適用されず、受信サーバー側の判断に委ねられます。これにより、正規メールへの影響を限定しながら段階的にポリシーを強化できます。
最終目標（拒否モード）の記述例
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=sadkim=sとaspf=sを指定することで、DKIMとSPFのアライメントをstrict（完全一致）モードに設定し、より厳格な認証を実施できます。
よくある設定ミスと対策
DMARCレコードの設定では、以下のようなミスが頻繁に発生します。
① ホスト名の指定ミス
DMARCレコードのホスト名は必ず _dmarc で始まる必要があります。dmarc（アンダースコアなし）ではDMARCレコードとして認識されません。
② セミコロンの付け忘れ
各タグはセミコロン（;）で区切ります。スペースの有無は影響しませんが、セミコロンの付け忘れはレコード全体のパースエラーにつながります。
③ ruaタグのmailto:の付け忘れ
rua=dmarc@example.comのようにmailto:を省略すると、レポートが正しく送信されません。正しくはrua=mailto:dmarc@example.comです。
④ SPF・DKIMの設定不備のままポリシーを強化
DMARC認証はSPFとDKIMの結果に依存するため、これらの設定が不完全な状態でquarantineやrejectに移行すると、正規メールが迷惑メール扱いされたりブロックされたりする事故が発生します。
DMARCポリシーの段階的強化｜noneからrejectへの移行手順
DMARCの導入において最も重要なのは、いきなりrejectを設定するのではなく、段階的にポリシーを強化していくことです。ここでは、実践的な移行手順を解説します。
STEP 1：p=none で監視を開始する
まず、p=noneでDMARCレコードを公開し、レポートの収集を開始します。
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comこの段階では、メールの配信に一切影響を与えません。レポートを分析することで、以下の情報を把握できます。
- 自社ドメインからメールを送信しているすべてのIPアドレス（正規・不正の両方）
- SPFとDKIMの認証結果（pass/fail）
- アライメントの合否
DMARCレポートはXML形式で届くため、手動での解析は困難です。DMARCレポート解析ツールを活用して、認証状況を可視化することをおすすめします。目安期間は2〜4週間となります。
STEP 2：SPF・DKIMの設定を修正する
レポートの分析結果に基づき、認証に失敗している正規メール送信元を特定し、SPFレコードへのinclude:追加やDKIM署名の設定を行います。よくある修正対象は以下の通りです。
- メール配信サービス（ブラストメール、blastengineなど）
- CRM・MAツール（Salesforce、HubSpotなど）
- SaaS型サービスからの通知メール
- 社内の別サーバーからの自動送信メール
すべての正規メール送信元がSPFまたはDKIMの認証をパスし、アライメントも合格していることをレポートで確認できたら、次のステップに進みます。DMARCのアライメントについては以下の記事で詳しく解説していますので、参考にしてください。
related-post id=1228
STEP 3：p=quarantine を段階的に適用する
SPF・DKIMの設定が整ったら、ポリシーをquarantineに引き上げます。最初はpctタグで適用割合を限定し、問題がないことを確認しながら段階的に拡大します。
# Phase 1: 25%に適用
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com
# Phase 2: 50%に適用
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com
# Phase 3: 100%に適用
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com各フェーズでDMARCレポートを継続的に監視し、正規メールが誤って隔離されていないかを確認します。各フェース１～2週間を目安に進めるといいでしょう。
STEP 4：p=reject への最終移行
quarantineで100%適用しても問題がないことが確認できたら、最終的にp=rejectに移行します。
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.comrejectの設定後も、レポートの継続的な監視は必ず継続してください。新しいメール送信サービスを導入した場合や、システム構成が変更された場合に、正規メールが意図せずブロックされるリスクがあるためです。
Gmailガイドラインとの関係｜大量送信者のDMARC義務化
2024年2月、Googleは新しい「メール送信者のガイドライン」を施行し、1日5,000通以上のメールをGmailアカウントに送信する大量送信者に対して、DMARC認証の設定を義務化しました。
Gmailガイドラインで求められるDMARC要件
| 項目 | 全送信者 | 大量送信者 (5,000通/日以上) |
| SPF | ○ またはDKIM | ○ |
| DKIM | ○ またはSPF | ○ |
| DMARC | — | ○ (最低 p=none) |
| ワンクリック購読解除 | — | ○ |
| 迷惑メール率 | — | 0.3%未満 |
大量送信者は、最低でもp=noneのDMARCレコードを公開する必要があります。これは「DMARCポリシーを設定していること自体」が要件であり、必ずしもrejectやquarantineである必要はありません。
ただし、DMARCが未設定の場合、Gmailへのメール配信が遅延・拒否される可能性があるため、送信量に関わらずDMARCの設定は早急に行うべきです。
大量送信者の定義
Googleは「大量送信者」を、個人用Gmailアカウント宛に1日あたり約5,000通以上のメッセージを送信する送信者と定義しています。この5,000通は同一ドメインからの送信数であり、一度でもこの閾値を超えると大量送信者として分類されます。
Gmailガイドラインに対応するための最低限の設定
まだDMARCを設定していない場合、以下の手順で最低限の要件を満たすことができます。
- SPFレコードの設定：
自社のメールサーバーIPおよびメール配信サービスをinclude:で指定 - DKIMの設定：
メール配信サービスの管理画面からDKIM署名用のCNAMEレコードを取得し、DNSに追加 - DMARCレコードの公開：
v=DMARC1; p=none; rua=mailto:dmarc@example.comを_dmarc.example.comのTXTレコードとして追加
Gmail送信者ガイドラインについては以下の記事で詳しく解説していますので、参考にしてください。
メール配信の到達率を高めるならメール配信システムを活用する
DMARCポリシーを正しく設定することはメール到達率の向上に直結しますが、それと同時に、利用するメール配信インフラがSPF/DKIM/DMARCに標準対応しているかどうかも極めて重要です。送信ドメイン認証に完全対応したメール配信システムを利用することで、DMARC設定の負荷を大幅に軽減し、メール到達率が高いインフラを構築できます。
メール配信システムを使うメリット
メール配信の品質とセキュリティを同時に高めるために、専用のメール配信システムを利用するメリットは大きいです。
- SPF/DKIM/DMARC対応：
送信ドメイン認証にサービス側で標準対応しており、DNS設定の手順もサポートで案内してもらえる - 高い到達率：
国内ISP・キャリアに最適化された配信基盤により、迷惑メール判定を回避 - IPレピュテーション管理の自動化：
サービス側でIPアドレスの送信者評価を管理し、常に高い信頼性を維持
おすすめのメール配信システム「blastengine」
ブラストエンジン（blastengine）は、お客様のシステムとSMTPリレーやAPIで連携することで、トランザクションメールや一斉配信を簡単に行えるメール配信サービスです。DMARCをはじめとする送信ドメイン認証（SPF/DKIM/DMARC）に標準対応しており、設定に必要なDNSレコード情報もダッシュボードから確認できます。
- SPF/DKIM/DMARC対応：
最新のメール認証技術に対応し、なりすまし・迷惑メール判定を回避 - 99%以上の高いメール到達率：
国内キャリア・ISPへの個別送信ロジックで確実にメールを届ける - API連携・SMTPリレー：
既存システムへの組み込みが容易で、最短当日から利用開始可能 - バウンスメール自動対応：
エラーメール管理を自動化し、エンジニアの運用負荷を大幅に削減 - 業界最安クラスの料金：
初期費用無料、月額3,000円〜で大量配信も低コストで実現
DMARC認証に完全対応したインフラを使うことで、認証失敗によるメール不達のリスクを根本から解消できます。メールアドレス入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。
ブラストエンジン公式サイト：https://blastengine.jp/
おすすめのメール配信システム「ブラストメール」
ブラストメール（blastmail）は、15年連続で導入社数シェアNo.1を獲得している日本最大級のメール配信システムです。27,000社以上の導入実績に裏打ちされた高い到達率と、専門知識がなくても直感的に操作できるシンプルな管理画面が最大の特徴です。
- 迷惑メール判定対策（SPF/DKIM）：
Gmailガイドライン対応済みの配信基盤で、DMARC認証も安心 - 効果測定：
開封率・クリック率・エラーカウントを確認でき、次の施策にすぐ活かせる - HTMLメール作成（ノーコードエディタ）：
デザイン知識がなくてもプロフェッショナルなHTMLメールを作成可能 - 業界最安クラスの料金：
月額4,000円〜で配信通数無制限、充実のサポート体制
GUI操作でメルマガの作成・配信・効果測定まで完結するため、マーケティング担当者に最適なサービスです。
公式サイト：シェア1位のメール配信システム「ブラストメール」
まとめ
DMARCポリシーにはnone（監視）・quarantine（隔離）・reject（拒否）の3段階があり、最終的にはrejectを目指すのがセキュリティのベストプラクティスです。ただし、いきなりrejectを設定するのは危険です。段階的に以下の手順でポリシーを強化していきましょう。
- p=noneでDMARCレコードを公開し、レポートを収集する（2〜4週間）
- レポートを分析し、SPF・DKIMの設定漏れを修正する
- p=quarantineに引き上げ、pctタグで適用割合を段階的に拡大する
- 問題がなければp=rejectに最終移行する
2024年2月からのGmailガイドラインにより、大量送信者はDMARC設定が必須となっています。まだDMARCを設定していない場合は、まずp=noneのDMARCレコードを公開し、レポートの収集から始めることを最優先のアクションとしてください。
FAQ
- Q：DMARCポリシーをp=noneに設定するだけで、なりすましメール対策になりますか？
- A：いいえ、p=noneはなりすましメールをブロックする効果はありません。p=noneは監視モードであり、DMARC認証に失敗したメールも通常通り配信されます。ただし、DMARCレポートを収集できるようになるため、自社ドメインの不正利用状況を把握するための第一歩として非常に重要です。実際になりすましメールをブロックするには、p=quarantineまたはp=rejectへの移行が必要です。
- Q：DMARCポリシーをいきなりp=rejectに設定しても問題ありませんか？
- A：強く非推奨です。SPFやDKIMの設定漏れがある状態でp=rejectを有効にすると、正規のメール（メール配信サービス経由のメルマガ、SaaSツールからの通知メールなど）までブロックされ、業務に深刻な影響を及ぼす可能性があります。必ずp=none→p=quarantine→p=rejectの順番で段階的に移行し、各段階でDMARCレポートを確認して問題がないことを検証してから次のステップに進んでください。
- Q：DMARCレポートが大量に届いて分析が大変です。効率的に分析する方法はありますか？
- A：DMARCレポートはXML形式で届くため、手動での分析は確かに困難です。DMARCレポート解析ツールを利用することで、認証結果をグラフやダッシュボードで可視化し、どのIPアドレスから認証失敗が発生しているかを効率的に特定できます。また、集計レポート（rua）の送信先に専用の解析サービスのアドレスを指定する方法もあります。
- Q：Gmailの大量送信者ガイドラインに対応するために、最低限何をすればよいですか？
- A：1日5,000通以上をGmailに送信する大量送信者は、最低限SPF・DKIM・DMARCの3つの認証設定を行う必要があります。具体的には、①SPFレコードにメール送信サーバーを登録、②DKIM署名の設定、③DMARCレコードの公開（最低でもp=none）の3点です。さらに、マーケティングメールにはワンクリック購読解除機能の実装が求められ、迷惑メール率を0.3%未満に維持する必要があります。
