組織ドメイン（Organizational Domain）

概要

組織ドメイン（Organizational Domain） は、DMARC の relaxed アライメントで使われるドメインの照合単位で、Public Suffix List（PSL）を基準に決定されます。RFC 7489（2015年）で定義されており、「ドメイン所有者が管理する最上位のドメイン」に相当します。

mail.example.com や bounce.example.com の組織ドメインは example.com です。DMARC の relaxed アライメントでは、ヘッダー From と認証ドメインの組織ドメインが一致していれば pass になります。bounce.example.com（エンベロープ From）と example.com（ヘッダー From）は組織ドメインが同じため、relaxed では pass します。

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

仕組み

組織ドメインは Public Suffix List を基準に「パブリックサフィックス + 1 ラベル」として算出され、DMARC の relaxed アライメントで照合単位になります。

組織ドメインの算出

組織ドメインの算出手順は次の通りです。

1. 対象ドメインのラベルを右から走査する
2. Public Suffix List に一致する部分をパブリックサフィックスとして特定する
3. パブリックサフィックスの直上 1 ラベルを加えた部分が組織ドメインになる

対象ドメイン	パブリックサフィックス	組織ドメイン
mail.example.com	.com	example.com
sub.example.co.jp	.co.jp	example.co.jp
a.b.example.co.uk	.co.uk	example.co.uk
user.github.io	.github.io	user.github.io
example.com	.com	example.com

.github.io や .azurewebsites.net のようなサービス提供ドメインも PSL に登録されているため、user.github.io の組織ドメインは user.github.io であり github.io にはなりません。

DMARC アライメントでの使われ方

DMARC の relaxed アライメント（デフォルト）では、次の 2 つの組織ドメインを比較します。

SPF アライメントの場合、エンベロープ From の組織ドメインとヘッダー From の組織ドメインを比較します。DKIM アライメントの場合、DKIM 署名の d= の組織ドメインとヘッダー From の組織ドメインを比較します。

組織ドメインが一致すればアライメント pass です。strict モードではこの組織ドメインの比較ではなく、完全一致を要求します。

Public Suffix List の更新

PSL は GitHub リポジトリ（publicsuffix/list）で管理されており、新しい TLD やサービスドメインの追加に伴い更新されます。DMARC の実装が古い PSL を使っていると、新しいパブリックサフィックスに対して組織ドメインの判定を誤ることがあります。受信側のプロバイダーは定期的に PSL を更新しています。

具体例

一般的なドメイン、国別コードドメイン、サービス提供ドメインでの組織ドメイン判定とアライメント結果を示します。

一般的なドメイン

ヘッダー From:     user@example.com        → 組織ドメイン: example.com
エンベロープ From:  bounce@mail.example.com → 組織ドメイン: example.com
→ relaxed アライメント: pass（組織ドメインが一致）

国別コードドメイン

ヘッダー From:     user@example.co.jp       → 組織ドメイン: example.co.jp
エンベロープ From:  bounce@mx.example.co.jp → 組織ドメイン: example.co.jp
→ relaxed アライメント: pass（組織ドメインが一致）

サービス提供ドメイン

ヘッダー From:     user@myapp.github.io      → 組織ドメイン: myapp.github.io
エンベロープ From:  bounce@other.github.io   → 組織ドメイン: other.github.io
→ relaxed アライメント: fail（組織ドメインが異なる）

.github.io がパブリックサフィックスであるため、myapp.github.io と other.github.io は別の組織ドメインとして扱われます。

確認方法

組織ドメインは DNS レコードとして直接公開されるものではなく、DMARC の実装が内部的に算出する値です。手元で確認するには、対象ドメインの DMARC レコードを取得して、どのレベルにポリシーが設定されているかを確認します。

dig TXT _dmarc.mail.example.com

サブドメインに DMARC レコードがなければ、受信サーバーは組織ドメインの DMARC レコードを参照します。

dig TXT _dmarc.example.com

;; ANSWER SECTION:
_dmarc.example.com.	3600	IN	TXT	"v=DMARC1;p=reject;aspf=r;adkim=r;rua=mailto:dmarc@example.com"

外部の視点からも確認したい場合は、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; aspf=r; adkim=r; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": { "record": null, "exists": false }
  },
  "error": null,
  "meta": { "responseTime": 123 }
}

aspf=r と adkim=r（またはタグ省略）であれば relaxed モードが適用されており、組織ドメインレベルのアライメント判定が行われています。

よくある問題

パブリックサフィックスの構造を誤解すると、DMARC アライメントの判定結果が意図と食い違います。

co.jp ドメインの組織ドメインを誤解する

example.co.jp の組織ドメインは example.co.jp であり、co.jp ではありません。.co.jp はパブリックサフィックスです。sub1.example.co.jp と sub2.example.co.jp は同じ組織ドメインですが、example.co.jp と other.co.jp は別の組織ドメインです。

サービス提供ドメインで DMARC アライメントが取れない

.github.io、.azurewebsites.net、.herokuapp.com などの PSL 登録ドメインでは、サブドメインごとに組織ドメインが異なります。これらのドメインで DMARC を設定しても、他のユーザーのサブドメインとはアライメントが成立しません。カスタムドメインを使って DMARC を設定する方が確実です。

PSL の更新遅れによる判定ずれ

新しい gTLD やサービスドメインが PSL に追加された直後は、古い PSL を使っている受信サーバーで組織ドメインの判定がずれる可能性があります。主要プロバイダー（Gmail、Microsoft 365）は PSL を定期更新しているため、一般的には数日から数週間で収束します。