注文確認メールをmail.example.comから、ニュースレターをmarketing.example.comから送っている場合、これらのアドレスはメインドメインのサブドメインです。メインドメインをなりすましから守るためにDMARCを有効にすると、サブドメインも通常は同時に保護されます。サブドメインはメインドメインのポリシーに自動で従うからです。ただしDMARCeyeのQ1 2026データセットでは、DMARCを完全に有効にしているドメインの13件に約1件で、メインドメインは固めたまま、サブドメインを露出させてしまう小さな設定ミスが見つかりました。
本記事では、DMARCeyeのQ1 2026業界レポートから明らかになったサブドメインポリシーの傾向を読み解きます。レポート全文と方法論は以下からダウンロードできます。
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つあります。サブドメインがメインドメインとは別のベンダー経由でメールを送っている場合か、サブドメインに対してメインドメインより早く(あるいは遅く)強制適用したい場合です。
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=を明示的に設定することが正しい選択になる場面は2つあります。
サブドメインで別のメール配信サービスを使っている場合。marketing.example.comはあるツール(たとえばニュースレター配信プラットフォーム)経由で、メインドメインは別のツール(トランザクションメールの送信プロバイダ)経由で送っているなら、それぞれの認証設定は別物です。特に新しいプロバイダを導入している最中は、片方に厳しいDMARCポリシーを、もう片方にゆるいものを当てたいことがあります。sp=を設定すれば、メインドメインに手を入れずにサブドメインだけ別のポリシーにできます。
サブドメインを先に保護したい場合。送信量が多いドメイン(またはなりすまし狙いのリスクが高いドメイン)では、レポートを数週間観察してから完全な強制適用に進みたくなることがあります。この場合、メインドメインをp=none(監視のみ)に置きつつ、sp=rejectを設定してサブドメインだけは即座に完全保護する、という選択肢があります。サブドメインは正規の送信元が少なく、構成も明確なことが多いため、先に強制適用しても安全な場合がよくあります。Q1のデータでは、p=noneドメインの0.42%がこのパターンを使っています。
注意すべきなのは逆のケースです。メインドメインには厳格なポリシー(p=reject)がかかっているのに、サブドメインがゆるい、もしくは無防備(sp=noneまたはsp=quarantine)になっている状態です。原因は通常、次のいずれかです。
sp=をゆるめた。sp=noneを設定し、その後しっかり締め直すために戻ってこなかった。sp=をp=に合わせて出力していたDMARCレコードを、後から誰かが何らかの理由で手動で弱めてしまった。結果はどの場合も同じです。メインドメインは完全に保護されているのに、すべてのサブドメインがなりすましメールをそのまま受け入れる状態になります。DMARCレコードを見れば、誰でもこの隙間にすぐ気づきます。
弊社のQ1データセットでは、強制適用ドメインの7.56%がこの設定になっています。完全な強制適用に到達しているなら、自分のDMARCレコードでまず確認すべきはこの点です。
3つの短い質問で考えていきましょう。
p=rejectに向かうことになります。sp=をレコードから外しておくのがデフォルトで、ほとんどの企業ではそれで十分です。サブドメインは自動でメインのポリシーに従います。sp=を別途設定することを検討してください。sp=を明示的に設定します。サブドメインをメインドメインよりゆるくしたいケースはほぼありません。その場合はsp=をp=と同じ値に揃えるか、外しておくのが正解です。DNSにすでにsp=を宣言しているなら、p=より弱くなっていないか確認してください。p=rejectとsp=noneの組み合わせが、まさに気をつけたい設定ミスです。DMARC監視をまだ始めていない場合は、DMARCeyeの無料プランが1ドメインをカバーし、sp=を設定していればその値を含めて、自分のレコードの中身をそのまま見せてくれます。今このドメインに何が設定されているかを確認するには、以下から:
DMARCbisはDMARC標準のアップデート版で、2026年中の発行が見込まれています。sp=の挙動は変わりません。設定しなければ、サブドメインは引き続きメインのポリシーを継承します。
新しくnp=というタグが追加されます。これは、そもそも存在しないサブドメインに対するポリシーを制御するタグです。今のところ、スパマーがmadeup.example.com(自分が作ったことのないサブドメイン)を名乗ってメールを送ると、受信側はメインドメインのポリシーにフォールバックします。np=を使えば、こうした架空のサブドメインに対してより厳格なポリシーを個別に当てられるようになります。DMARCbisが正式版になったあとサブドメインの保護をさらに強化したいなら、注目すべきタグはこれです。
大半のドメインにとって、sp=をレコードに含めないのが正解です。デフォルトの挙動が自動でサブドメインを保護します。
例外は実在しますが具体的です。サブドメインがメインドメインと違うメール配信サービスを使っている場合、あるいはメインドメインより先にサブドメインを保護したい場合です。どちらの場合も、sp=を意図して、正しい値で設定してください。
自分のDMARCレコードがp=rejectで、sp=がそれより弱い値になっているなら、これがその設定ミスです。何を直すよりも先に、まずこれを直してください。DMARCeyeは監視対象の全ドメインのsp=設定を追跡し、無料プランでは1ドメインをカバーします。