DMARCbisの説明 - 何が変わり、どう準備すべきか
by
最終更新日: 5 読了時間：5分
最終更新日：2026年4月
ステータス: インターネット技術タスクフォース (IETF) インターネットドラフト（ラストコール）
DMARCbisは、RFC 7489で定義されたオリジナルのDMARC仕様の待望の更新版です。これによって、DMARCの動作構造に変更が加えられ、旧来の要素が削除されるとともに、ドメインの整合性やポリシーの取り扱いに関する長年の曖昧さが解消されます。
このアップデートは業務に支障をきたすものではありませんが、ドメイン境界の決定方法、サブドメインへのポリシーの適用方法、および特定のタグの解釈や削除方法に変更が加えられます。
このガイドでは、変更点、変更のない点、そして今後行うべきことについて説明します。
主なポイント
- DMARCbisは、オリジナルのDMARCプロトコルの後継として更新されたもので、明確性と整合性の向上を目指している。
- これは、組織ドメインを識別するために、より信頼性の高いDNSツリーウォークでパブリックサフィックスリスト（PSL）を再定義するものである。
- pct、rf、riのようなタグは、実装を簡素化し混乱を減らすために非推奨となっている。
- 「psd」、「np」、「t」などの新しいタグが導入され、パブリックサフィックスドメインを明確に定義し、ポリシーの継承管理を支援します。
- 下位互換性を確保するため、DMARCレコードのバージョンは変更されません（v=DMARC1）。
- 有効なベースドメインレコードを持つ既存のDMARC設定は、直ちに変更することなく機能し続けます。
- PowerDMARCは、レコード管理を自動化し、専門家によるガイダンスを提供し、すべてのドメインにわたって可視性を提供することにより、移行を簡素化することができます。
DMARCbisとは何ですか？
DMARCbisは、IETFによって策定された「ドメインベースのメッセージ認証、報告、および適合性（DMARC）」の改訂仕様です。
オリジナルのDMARC仕様（RFC 7489）は、情報文書として公開されました。
DMARCbisは「提案標準」として推進されており、これはより強い合意形成と、より明確な実装指針が示されていることを意味します。
今回のアップデートは、以下の3つの分野に重点を置いています：
- ドメインの評価方法における曖昧さを解消する
- 使用されていないタグを非推奨とすることで、プロトコルを簡素化する
- ドメイン所有者がポリシーの継承をより細かく制御できるようにする
重要な点として、DMARCbisではv=DMARC1の設定は変更されないため、既存のレコードは引き続き機能します。
DMARCbisは何を置き換えるのでしょうか？
DMARCbis は、以下の機能を統合し、置き換えます：
RFC 7489 – オリジナルのDMARC仕様
RFC 9091 – パブリックサフィックスドメイン（PSD）DMARC拡張機能
これは重要な点です。なぜなら、PSDの処理が「psd」タグを通じてコア仕様に組み込まれたためです。Public Suffix Listのような外部依存関係はもはや必要ありません。ドメインの境界はDNS内で直接定義されます。
DMARCbisの主な変更点は何ですか？
1. DNSツリー探索がパブリックサフィックスリストに取って代わる
DMARCbisは、パブリックサフィックスリスト（PSL）を「DNSツリーウォーク」と呼ばれるDNS固有の手法に置き換えます。サードパーティのリストに依存する代わりに、DNSを直接探索することで組織のドメインを特定します。
仕組み：
このドメインを見てみましょう：mail.marketing.example.com
受信サーバーは、以下の順序でDMARCレコードを確認します：
- mail.marketing.example.com
- マーケティング.example.com
- example.com
- .com
各レベルで、psdタグが付いたDMARCレコードを検索します：
- psd=n → これは組織ドメインです → 停止
- psd=y → これはパブリックサフィックスです → 停止
- psd=u または指定なし → 上へ進む
検索は最大8階層まで行われます。
このアプローチにより、外部リストへの依存が解消され、ドメイン所有者がドメインの境界を管理できるようになり、システム間で動作の予測可能性が高まります。
2. 非推奨タグ：「pct」、「rf」、「ri」
DMARCbis は以下のタグを削除します：
- 「pct」（パーセンテージに基づく適用を行うためのパーセンテージタグ）
- 「rf」（法医学報告書フォーマット）
- 「ri」（報告間隔）
これらは一貫して使用されることはほとんどなく、明確なメリットもないまま複雑さを増すだけだった。
pctタグに関する注記：一部の組織では、DMARCポリシーを段階的に適用するためにpctを使用していました。このタグの削除によりプロトコルは簡素化されますが、段階的な導入メカニズムも失われることになります。
PowerDMARCの見解：段階的な適用は依然として重要ですが、受信側のサポート状況に左右されるのではなく、運用面での対応を行うべきです。
3. 新たに追加されたタグ：「psd」、「np」、「t」
「psd」（パブリックサフィックスドメイン）
「psd」タグはドメインの種類を明示的に定義し、DNSツリー探索がどこで停止するかを制御します：
- psd=y → パブリックサフィックスドメイン（例：TLD運営事業者）
- psd=n → 組織ドメイン
- psd=u → 不明（省略時のデフォルト動作）
「np」（存在しないドメインに関するポリシー）
「np」タグは、存在しないサブドメインに対するポリシーを定義し、未使用または未登録のサブドメインの悪用を防止します。
例：np=reject
「t」（テストモード）
tタグは、ドメインがテストモードであることを示します。
- ポリシー（「p」、「sp」、「np」）を上書きしません
- あくまで参考情報です
- 受取人は、これを受け入れるかどうかを選択できます
集計レポート（RUA）の変更点
DMARCbisでは、集計レポート機能を専用の仕様として分離しています。これにより現在のレポート機能に支障をきたすことはありませんが、将来的な変更が示唆されています。
主な示唆：
- 報告形式については、別のIETFドラフトで現在精査が進められている
- 一貫性を高めるために、XMLの構造が変更される可能性があります
- 報告のあり方は、今後ますます標準化されていくでしょう
メーリングリストとp=rejectに関するガイドライン
DMARCbisには、メーリングリストに関するより明確な指針が含まれています。
メーリングリストに積極的に投稿しているユーザーがいるドメインについては、p=reject を使用しないことをお勧めします。これは、以下の理由により、正当なメールが拒否されてしまうためです：
- メーリングリストでは、メッセージが変更されることがよくあります
- これにより、DKIM署名が破損します
- SPFの整合は通常、失敗します
実践的なポイント：
ユーザーが公開メーリングリストに参加している場合、その影響を十分に理解していない限り、厳格な拒否ポリシーは避けるべきです。
ユーザーが公開メーリングリストに参加している場合、その影響を十分に理解していない限り、厳格な拒否ポリシーは避けるべきです。
DMARCbisで変わらない点は何か？
DMARCbisは下位互換性があります。つまり、正式に導入された後も、最新の更新が適用されていない既存のDMARCレコードは、引き続き正常に機能します。以下は、変更されない点です：
- v=DMARC1 を使用している既存のレコードは引き続き機能します
- SPFおよびDKIMの整合メカニズムに変更はありません
- 「p」、「sp」、「rua」、「ruf」といった主要なタグは、依然として中心的な役割を果たしている
変更前と変更後：DMARCレコードの例
以前（旧レコード）：
v=DMARC1;p=quarantine; pct=100; rf=afrf; ri=86400; rua=mailto:[email protected]
（DMARCbis準拠後の）：
v=DMARC1; p=quarantine; rua=mailto:[email protected]; np=reject; psd=n
DMARCレコードの公開方法について学びましょう。
誰が何をすべきか？
| ドメイン所有者 | 電子メールサービスプロバイダー（ESP） | メール受信者 |
|---|---|---|
| ● 非推奨タグの削除 ● サブドメインおよび存在しないドメインに関するポリシーの見直し ● メーリングリストの利用による影響の評価 | ● DNSツリー探索の検証ロジックを更新 ● 新しいタグ（「np」、「psd」、「t」）に対応 | ● ツリーウォークアルゴリズムを実装する ● レポート内容を更新された仕様に合わせる |
DMARCbisへの対応にはどのように備えればよいでしょうか？
直ちに対応が必要なわけではありませんが、早期に準拠しておくことで将来のリスクを軽減できる点は重要です。DMARCbisへの対応準備として、以下の簡易チェックリストをご活用ください：
- ✓非推奨タグを削除：‘pct’、‘rf’、‘ri’
- ✓ベースドメインに有効なDMARCレコードが設定されていることを確認する
- ✓サブドメインポリシーの動作を確認する
- ✓使用されていないサブドメインには「np」を追加することを検討してください
- ✓PSDがドメイン構造にどのように適用されるかを理解する
- ✓p=rejectがメーリングリストのユーザーに影響を与えるかどうかを評価する
- ✓集計レポート形式の更新状況を監視する
PowerDMARCでDMARCbisをご利用ください
PowerDMARCは、DMARCbisへの移行を全面的にサポートする体制が整っています。仕様の変更に伴い、お客様の設定が中断なく準拠し続けるよう確実にサポートいたします。具体的なサポート内容は以下の通りです：
- DMARCbis 互換レコード生成ツール：当社の生成ツールは、新しい np、psd、t タグをすでにサポートしており、pct、rf、ri などの非推奨タグには削除フラグを付与するため、どのタグを残し、どのタグを削除すべきか迷う必要がありません。
- 自動更新機能付きホステッドDMARC：当社のホステッドDMARCサービスをご利用の場合、仕様の確定に合わせてレコードを更新いたします。DMARCbisが「ラストコール」から「提案標準」に移行すると、設定が自動的に更新されます。
- すべてのドメインにわたる一元的な可視化：非推奨タグに関する警告、専門家の推奨事項、ツールチップなどを通じて、何が機能し、何が問題を引き起こしているかをリアルタイムで把握できます。
- サブドメインおよび存在しないドメインに関するポリシーの見直し：DMARCbisは、存在しないサブドメインに対して「np」ステータスを導入しました。当社のプラットフォームは、サブドメインの効果的な監査と管理を支援し、攻撃者が悪用しうる脆弱性を解消します。
- 新しい変更内容の解釈と導入に関する専門的なサポート：当社のサポートチームは24時間365日体制で、変更内容の解釈や移行計画の策定をお手伝いいたします。よくある問題に関する迅速なガイダンスが必要な場合は、組み込みのDMARC AIアシスタントもご利用いただけます。
DMARCbis対応のNo.1DMARCソフトウェアソリューションでドメインを保護しましょう
最終的な感想
DMARCbisは、透明性を高め、実装を簡素化し、ドメイン所有者がポリシーの適用方法をより細かく制御できるようにします。これらの変更は緊急性を要するものではありませんが、重要なものであるため、組織は認証体制を見直す際に、今後の更新内容を考慮に入れる必要があります。今から準備をしておくことで、メール認証の設定を安定させ、予測可能な状態に保ち、次期バージョンの標準規格に準拠させることができます。
朗報です！DMARCbisへの移行を、ご自身だけで進める必要はありません。当社の専門家チームが、技術的な知識がなくても、業界の変化やメール送信者の要件にスムーズに対応できるようサポートいたします。今すぐお問い合わせください！
よくあるご質問
DMARCbisはすでに公開されていますか？
いいえ。現在、IETFのラストコール段階にあり、提案標準となる見込みです。
DMARCbisは下位互換性がありますか？
はい、DMARCbisは下位互換性があるため、既存のDMARCレコードは引き続き機能します。したがって、急いで対応したり、慌てたりする必要はありません。
今すぐDMARCレコードを更新する必要がありますか？
現時点では、DMARCレコードを直ちに更新する必要はありません。ただし、将来的な互換性を確保するため、非推奨となったタグを削除することをお勧めします。
DMARCbisはSPFやDKIMに影響を与えますか？
DMARCbisは、DMARCによる整合性評価とポリシーの適用方法のみを変更するものであり、SPFやDKIMの認証には影響しません。
ドメインとメールセキュリティのエキスパートPowerDMARC
ユネスはPowerDMARCのオペレーションチームリーダーで、メール認証とセキュリティの専門知識を持つ。マイクロソフト認定のAzureアドミニストレーターアソシエイトであり、CompTIA A+やその他多くの資格を持っています。
最新記事 by Yunes Tarada(全て見る)
- DMARCbisの解説 – 変更点と準備方法 - 2026年4月16日
- SOAシリアル番号の形式が無効です：原因と解決方法 - 2026年4月13日
- Gmailで安全なメールを送信する方法：ステップバイステップガイド - 2026年4月7日
