Labee Dev Toolbox
技術ノートガイド用語解説
無料で試す
  1. ホーム
  2. / 技術ノート
  3. / DMARC の organizational domain とは — サブドメインのメール認証で親ドメインが重要な理由
メール認証

DMARC の organizational domain とは — サブドメインのメール認証で親ドメインが重要な理由

2026年4月29日 公開 2026年4月29日 更新 8分で読めます

サブドメインから送信したメールに DMARC レコードを設定していない場合、受信サーバーは親ドメイン（organizational domain）の DMARC ポリシーを自動的に参照します。このフォールバックの仕組みを正しく理解していないと、意図しないポリシーがサブドメインに適用され、メールの配信に影響します。この記事では、organizational domain の算出方法、sp= タグとの優先順位、dig と API を使った確認手順を解説します。

サブドメインの DMARC はどこを参照するのか

RFC 7489 Section 3.2 は、受信サーバーが DMARC ポリシーを検索する手順を定めています。受信サーバーはヘッダー From のドメインに対して _dmarc.{ドメイン} の TXT レコードを問い合わせます。レコードが見つからなければ、organizational domain（組織ドメイン）の _dmarc.{組織ドメイン} にフォールバックします。

mail.example.com からメールを送信した場合の検索順序は次のとおりです。

  1. _dmarc.mail.example.com を問い合わせる
  2. レコードがなければ、organizational domain である example.com の _dmarc.example.com を問い合わせる
  3. ここにもなければ、DMARC ポリシーなしとして扱う

この検索は最大 2 回の DNS クエリで完了します。サブドメインに明示的な DMARC レコードを設定していない組織は、親ドメインのポリシーがサブドメインのメール認証に直接影響している状態です。

Public Suffix List が organizational domain を決める

organizational domain の算出には Public Suffix List（PSL）が使われます。PSL は Mozilla が管理するパブリックサフィックスのデータベースで、.com、.co.jp、.github.io などの「個人や組織が直接登録できない」ドメインを定義しています。organizational domain は「パブリックサフィックス + 1 ラベル」（eTLD+1）として算出されます。

送信元ドメインパブリックサフィックスorganizational domain
mail.example.com.comexample.com
mail.example.co.jp.co.jpexample.co.jp
app.example.ne.jp.ne.jpexample.ne.jp
sub.example.tokyo.jp.tokyo.jpexample.tokyo.jp
user.github.io.github.iouser.github.io

日本のドメインでは .co.jp、.ne.jp、.ac.jp、.tokyo.jp などのマルチラベル TLD に注意が必要です。mail.example.co.jp の organizational domain は example.co.jp であり、co.jp にはなりません。.co.jp はパブリックサフィックスであり、登録単位ではないためです。PSL にこれらのサフィックスが正しく登録されていることで、受信サーバーは example.co.jp を organizational domain として正確に判定できます。

sp= タグの優先順位

親ドメインの DMARC レコードに sp= タグが含まれている場合、サブドメインへのフォールバック時に適用されるポリシーは p= ではなく sp= です。

親ドメインに次の DMARC レコードが設定されているとします。

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com

この設定では、example.com 自体から送信されたメールには p=reject が適用されますが、mail.example.com のようなサブドメインから送信されたメールには sp=none が適用されます。

sp= が省略されている場合は p= の値がサブドメインにも適用されます。つまり、p=reject で sp= がなければ、サブドメインにも reject が適用されます。

優先順位を整理すると次のとおりです。

サブドメインの DMARC親ドメインの sp=親ドメインの p=適用されるポリシー
あり（p=quarantine）——quarantine（サブドメイン自身の p=）
なしsp=nonep=rejectnone（親の sp=）
なし省略p=rejectreject（親の p= で代替）

親ドメインで p=reject を設定しつつ、メール送信用のサブドメインでは段階的に運用を始めたい場合、sp=none を設定しておくことで、サブドメインのメールを reject せずに集計レポートだけを受け取れます。

dig で確認する

手元の dig コマンドでフォールバックの挙動を確認できます。example.com を自分のドメインに置き換えて実行してみてください。

サブドメインの DMARC レコードを問い合わせます。

dig TXT _dmarc.mail.example.com +short

何も返らなければ、サブドメインに DMARC レコードは設定されていません。organizational domain の DMARC レコードを問い合わせます。

dig TXT _dmarc.example.com +short
"v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com"

レコードが返れば、受信サーバーはこのポリシーを mail.example.com に適用します。sp=none が含まれているため、サブドメインには none ポリシーが適用されます。sp= がなければ p=reject がそのままサブドメインにも適用されます。

.co.jp ドメインの場合は organizational domain の特定に注意します。

# サブドメインの DMARC を確認
dig TXT _dmarc.mail.example.co.jp +short

# organizational domain の DMARC を確認
dig TXT _dmarc.example.co.jp +short

_dmarc.co.jp を問い合わせるのは誤りです。co.jp はパブリックサフィックスであり organizational domain ではありません。

Labee API で外部視点から確認する

dig はローカルのリゾルバーを経由するため、キャッシュの影響を受けます。外部のリゾルバーからフォールバックの結果を確認するには、Labee Dev Toolbox のメール認証 API が使えます。example.com を自分のドメインに置き換えて実行してみてください。

curl "https://labee.dev/api/mail-auth?domain=mail.example.com"

サブドメインに DMARC レコードがなく、親ドメインにフォールバックした場合は次のレスポンスが返ります。

{
  "success": true,
  "data": {
    "spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
    "dkim": {
      "mode": "auto",
      "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...",
      "exists": true,
      "selector": "google",
      "matches": [
        { "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "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; sp=none; rua=mailto:dmarc@example.com",
      "exists": true,
      "source": "organizational",
      "domain": "example.com"
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 142 }
}

source フィールドの値でフォールバックの有無を判別できます。

  • "source": "exact" はサブドメイン自身に DMARC レコードが存在する状態です
  • "source": "organizational" は organizational domain にフォールバックした状態です。domain フィールドにフォールバック先のドメインが表示されます
  • "source": null はどこにも DMARC レコードが見つからなかった状態です

サブドメインに自身の DMARC レコードが存在する場合は次のレスポンスになります。

curl "https://labee.dev/api/mail-auth?domain=mail.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=MIIBIjANBgkqh...",
      "exists": true,
      "selector": "google",
      "matches": [
        { "selector": "google", "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "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:d@example.com",
      "exists": true,
      "source": "exact",
      "domain": "mail.example.com"
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 95 }
}

コマンドラインを使わずに確認したい場合は、Labee Dev Toolbox のメール認証チェック画面 にドメインを入力すると、DMARC を含む 4 項目の状態を GUI で確認できます。

サブドメインに明示的な DMARC を設定すべきか

source: "organizational" が返った場合、サブドメインに独自の DMARC レコードを設定すべきかは運用要件で判断します。

サブドメイン専用の DMARC を設定すべきケースは次のとおりです。

  • サブドメインと親ドメインで異なるポリシー強度が必要な場合。親が p=reject でもサブドメインでは p=quarantine で段階的に移行したいケース
  • サブドメイン固有の rua= 宛先に集計レポートを送りたい場合。メール配信サービスを使うサブドメインのレポートを、親ドメインの管理者とは別に受け取りたいケース
  • 親ドメインの DMARC に sp=none が設定されていて、特定のサブドメインだけは p=reject にしたい場合

フォールバックのまま運用して問題ないケースもあります。

  • 親ドメインの p= と sp= のポリシーがサブドメインの要件を満たしている場合
  • 集計レポートを親ドメインの rua= で一元管理している場合
  • サブドメインからメールを送信しない場合。フォールバック先の p=reject がなりすまし防止として機能します

DMARCbis の DNS Tree Walk（将来の方向性）

RFC 7489 の organizational domain 判定は PSL に依存しています。PSL の更新が遅れると判定がずれ、PSL に登録されていない新しいサフィックスでは organizational domain を正確に算出できません。

この課題に対して、IETF の DMARC ワーキンググループは draft-ietf-dmarc-dmarcbis-41 で「DNS Tree Walk」と呼ばれる新しい検索方式を提案しています。DNS Tree Walk では、PSL を参照する代わりに、サブドメインから 1 ラベルずつ上位に向かって _dmarc.{ドメイン} を問い合わせます。最大 8 クエリ の上限が設けられており、過度な DNS 負荷を防ぎます。

_dmarc.a.b.c.example.com    → なし
_dmarc.b.c.example.com      → なし
_dmarc.c.example.com        → なし
_dmarc.example.com          → v=DMARC1; p=reject ...（発見）

DNS Tree Walk が実装されれば、PSL への依存が解消され、新しい TLD やサービスドメインでも即座に正しい判定が行えるようになります。

draft-ietf-dmarc-dmarcbis-41 はまだ Internet Draft の段階であり、RFC として発行されていません。Gmail、Microsoft 365、Yahoo Mail など主要プロバイダーの実装もありません。現時点では RFC 7489 のフォールバック方式と PSL による organizational domain 判定が標準の動作です。DMARCbis の進捗は IETF の Datatracker で追跡できます。

SPF・DKIM・DMARC をまとめて確認する手順はこちらにまとめています。

技術ノートSPF・DKIM・DMARC を外部から確認する方法 — dig と API で設定漏れを検出するdig コマンドと外部 API を使って、SPF・DKIM・DMARC の設定状況を外部視点から確認する手順を解説します。DKIM セレクターの自動検索、Gmail のバルクセンダー要件との照合、よくある設定漏れパターンの特定方法も紹介します。labee.dev

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す

Pro プラン（準備中）

DNS 変更の自動検知・SSL 期限アラート・複数ドメイン管理など、継続して確認し続けるための機能を準備中です。

関連記事

メール認証

SPF・DKIM・DMARC を外部から確認する方法 — dig と API で設定漏れを検出する

dig コマンドと外部 API を使って、SPF・DKIM・DMARC の設定状況を外部視点から確認する手順を解説します。DKIM セレクターの自動検索、Gmail のバルクセンダー要件との照合、よくある設定漏れパターンの特定方法も紹介します。

2026-04-01 ・ 7分
メール認証

DKIM セレクタの見つけ方 — プロバイダー別の命名規則と自動検知の限界

DKIM セレクタ名はメールサービスごとに異なります。Google Workspace、Microsoft 365、SendGrid、AWS SES など主要プロバイダーのセレクタ命名規則と、dig・API を使った確認方法、自動検知できないケースの対処法を解説します。

2026-04-22 ・ 8分
DNS

DNS 変更後の反映確認、dig だけで大丈夫？

DNS レコードを変更した後、dig コマンドだけでは正確な反映状況がわかりません。キャッシュの仕組みと、外部から確認する具体的な方法を解説します。

2026-04-10 ・ 6分
コンテンツ 技術ノート ガイド 用語解説
ツール ツール一覧 API Reference
Labee 日本語トップ Labee LLC
© 2026 Labee LLC . All rights reserved.
ホーム ブログ ガイド 用語集