DMARCのサブドメインポリシー: sp=が役立つときと、害になるとき

注文確認メールをmail.example.comから、ニュースレターをmarketing.example.comから送っている場合、これらのアドレスはメインドメインのサブドメインです。メインドメインをなりすましから守るためにDMARCを有効にすると、サブドメインも通常は同時に保護されます。サブドメインはメインドメインのポリシーに自動で従うからです。ただしDMARCeyeのQ1 2026データセットでは、DMARCを完全に有効にしているドメインの13件に約1件で、メインドメインは固めたまま、サブドメインを露出させてしまう小さな設定ミスが見つかりました。

本記事では、DMARCeyeのQ1 2026業界レポートから明らかになったサブドメインポリシーの傾向を読み解きます。レポート全文と方法論は以下からダウンロードできます。

sp=タグの役割

DMARCレコードは、自分のドメインを名乗るメールを受信側がどう扱うかを指示する、DNSに記載される短いテキストです。中心となる設定はp=タグで、メインドメインに適用するポリシーを決めます。ポリシーは3段階です。

• p=noneは、受信側にレポートだけを送らせ、メールはすべて配送する設定です(まだ保護はかかりません)。
• p=quarantineは、認証に失敗したメールを迷惑メールフォルダに振り分けます。
• p=rejectは、認証に失敗したメールを完全にブロックします。

sp=タグは同じ考え方をサブドメインに適用したものです。同じ3つの値を取ります。sp=を一切設定しなければ、サブドメインはp=の値にそのまま従います。つまりメインドメインがp=rejectで、sp=を設定しなければ、すべてのサブドメイン(mail.example.com、support.example.com、その他保有しているもの)もp=rejectになります。これが仕様どおりの挙動です(RFC 7489 §6.3を参照)。

sp=を明示的に設定するのは、サブドメインをメインドメインと違う扱いにしたい場合だけです。よくある理由は2つあります。サブドメインがメインドメインとは別のベンダー経由でメールを送っている場合か、サブドメインに対してメインドメインより早く(あるいは遅く)強制適用したい場合です。

Q1ドメインにおけるsp=の設定状況

DMARCeyeのQ1 2026監視サンプルに含まれる数千ドメインを見ると、sp=の分布はメインのp=ポリシーによって大きく異なります。

3つのパターンが目を引きます。

• 大半のドメインはsp=を一切設定していない。p=noneのドメインの86.67%、p=quarantineの78.59%、p=rejectの65.15%が、レコードにsp=を含めていません。先に説明したとおり、これがデフォルトの挙動で、サブドメインは自動的にメインドメインのポリシーに従います。
• 意図的にサブドメインを弱めているドメインもある。p=rejectのドメインの6.62%がsp=noneを、さらに0.94%がsp=quarantineを設定しています。合わせると、メインドメインを厳格に守りながら、サブドメインの保護はゆるい、もしくはまったくない強制適用ドメインが7.56%にのぼります。
• サブドメインを先に保護する目的でsp=を使う例はほぼない。p=noneのドメインのうちsp=rejectを設定しているのは0.42%にすぎません。これは賢いやり方です(メインドメインは監視のみのモードに置いてデータを集める一方、サブドメインのなりすましメールは即座にブロックする)。それでもほとんど使われていません。

sp=を設定すると役立つとき

sp=を明示的に設定することが正しい選択になる場面は2つあります。

サブドメインで別のメール配信サービスを使っている場合。marketing.example.comはあるツール(たとえばニュースレター配信プラットフォーム)経由で、メインドメインは別のツール(トランザクションメールの送信プロバイダ)経由で送っているなら、それぞれの認証設定は別物です。特に新しいプロバイダを導入している最中は、片方に厳しいDMARCポリシーを、もう片方にゆるいものを当てたいことがあります。sp=を設定すれば、メインドメインに手を入れずにサブドメインだけ別のポリシーにできます。

サブドメインを先に保護したい場合。送信量が多いドメイン(またはなりすまし狙いのリスクが高いドメイン)では、レポートを数週間観察してから完全な強制適用に進みたくなることがあります。この場合、メインドメインをp=none(監視のみ)に置きつつ、sp=rejectを設定してサブドメインだけは即座に完全保護する、という選択肢があります。サブドメインは正規の送信元が少なく、構成も明確なことが多いため、先に強制適用しても安全な場合がよくあります。Q1のデータでは、p=noneドメインの0.42%がこのパターンを使っています。

sp=を設定すると害になるとき

注意すべきなのは逆のケースです。メインドメインには厳格なポリシー(p=reject)がかかっているのに、サブドメインがゆるい、もしくは無防備(sp=noneまたはsp=quarantine)になっている状態です。原因は通常、次のいずれかです。

• 強制適用を有効にしたところ、あるサブドメインで失敗が出始め、そのサブドメインの認証問題を直す代わりに、失敗を止めるためにsp=をゆるめた。
• 初期導入のとき不意打ちを避けようとsp=noneを設定し、その後しっかり締め直すために戻ってこなかった。
• あるツールがsp=をp=に合わせて出力していたDMARCレコードを、後から誰かが何らかの理由で手動で弱めてしまった。

結果はどの場合も同じです。メインドメインは完全に保護されているのに、すべてのサブドメインがなりすましメールをそのまま受け入れる状態になります。DMARCレコードを見れば、誰でもこの隙間にすぐ気づきます。

弊社のQ1データセットでは、強制適用ドメインの7.56%がこの設定になっています。完全な強制適用に到達しているなら、自分のDMARCレコードでまず確認すべきはこの点です。

自分のドメインに必要な設定を判断する

3つの短い質問で考えていきましょう。

1. メインドメインからメールを送っていますか?送っているなら、時間をかけてp=rejectに向かうことになります。sp=をレコードから外しておくのがデフォルトで、ほとんどの企業ではそれで十分です。サブドメインは自動でメインのポリシーに従います。
2. メインドメインとは別のメール配信サービスを使っているサブドメインはありますか?あるなら、それぞれに独自のポリシーを当てられるよう、sp=を別途設定することを検討してください。
3. サブドメインをメインドメインより先に(または別の形で)保護したいですか?そうであればsp=を明示的に設定します。サブドメインをメインドメインよりゆるくしたいケースはほぼありません。その場合はsp=をp=と同じ値に揃えるか、外しておくのが正解です。

DNSにすでにsp=を宣言しているなら、p=より弱くなっていないか確認してください。p=rejectとsp=noneの組み合わせが、まさに気をつけたい設定ミスです。DMARC監視をまだ始めていない場合は、DMARCeyeの無料プランが1ドメインをカバーし、sp=を設定していればその値を含めて、自分のレコードの中身をそのまま見せてくれます。今このドメインに何が設定されているかを確認するには、以下から:

DMARCbisで変わる点

DMARCbisはDMARC標準のアップデート版で、2026年中の発行が見込まれています。sp=の挙動は変わりません。設定しなければ、サブドメインは引き続きメインのポリシーを継承します。

新しくnp=というタグが追加されます。これは、そもそも存在しないサブドメインに対するポリシーを制御するタグです。今のところ、スパマーがmadeup.example.com(自分が作ったことのないサブドメイン)を名乗ってメールを送ると、受信側はメインドメインのポリシーにフォールバックします。np=を使えば、こうした架空のサブドメインに対してより厳格なポリシーを個別に当てられるようになります。DMARCbisが正式版になったあとサブドメインの保護をさらに強化したいなら、注目すべきタグはこれです。

実務上のまとめ

大半のドメインにとって、sp=をレコードに含めないのが正解です。デフォルトの挙動が自動でサブドメインを保護します。

例外は実在しますが具体的です。サブドメインがメインドメインと違うメール配信サービスを使っている場合、あるいはメインドメインより先にサブドメインを保護したい場合です。どちらの場合も、sp=を意図して、正しい値で設定してください。

自分のDMARCレコードがp=rejectで、sp=がそれより弱い値になっているなら、これがその設定ミスです。何を直すよりも先に、まずこれを直してください。DMARCeyeは監視対象の全ドメインのsp=設定を追跡し、無料プランでは1ドメインをカバーします。