サブドメインにDMARCは必要？spタグの設定と継承の仕組み

診断で「example.jp のDMARCが適用されます」と表示された場合、そのサブドメインの設定漏れではありません。上位のドメインのポリシーがそのまま適用されている状態です。

先に結論を書きます。

• サブドメインには、たいていDMARCレコードを追加する必要がありません。上位のドメインの p がそのまま適用されます
• 追加が必要になるのはサブドメインだけ別の扱いにしたいときです
• 落とし穴が2つあります。サブドメイン自身のレコードに書いた sp は使われません。sp や np の値を1文字間違えるとそのタグだけでなくレコード全体が効かなくなります
• いま何が適用されているかは、メール認証の診断にサブドメインを入力すると確認できます

この記事は、サイトを運営していてDNSのレコードを自分で追加したことはあるが、DMARCのタグの意味までは追っていない方に向けて書いています。mail.example.jp や www.example.jp のようなサブドメインを診断にかけた結果の読み方から、sp を書くかどうかの判断までを扱います。

用語をここで揃えます。すでにご存じの場合は読み飛ばしてください。

サブドメインにDMARCレコードを追加しなくてよい理由

DMARCのポリシーは、書いた名前だけに効くものではありません。RFC 9989 セクション4.7 の p タグの定義が、次のように書いています。

The policy applies to the domain queried and to subdomains, unless the subdomain policy is explicitly described using the "sp" or "np" tags.

(このポリシーは、問い合わせたドメインとそのサブドメインに適用される。sp または np タグでサブドメインのポリシーを明示している場合を除く)

sp の側からも同じことが定められています。同節は「If both the "sp" tag is absent and the "np" tag is either absent or not applicable, the policy specified by the "p" tag MUST be applied for subdomains」(sp タグが無く np タグも無いか適用対象でない場合、サブドメインには p タグのポリシーを適用しなければならない)としています。

つまり example.jp に v=DMARC1; p=reject を1本置いてあれば mail.example.jp にも www.example.jp にも p=reject が適用されます。サブドメインごとにレコードを増やす作業は要りません。

診断がこの状態を「要修正」ではなく参考情報として表示するのはこのためです。表示される文言には、そのサブドメインに実際に適用されるタグが入ります。

どのサブドメインを見ればよいか

DMARCが見るのはメールの差出人アドレス(From ヘッダー)のドメインです。Webサイトのアドレスに使っている www や、MXレコードが指しているメールサーバーの名前ではありません。

たとえば info@mail.example.jp から送っているなら、確認する名前は mail.example.jp です。サイトが www.example.jp で公開されていてもそこからメールを送っていないなら、www のDMARCを気にする必要はありません。

いまの状態と適用されるポリシーの対応

自分のケースを先に選んでください。

下から2行目に当てはまる場合は、この記事の「値を1文字間違えると上位のポリシーごと効かなくなります」を読んでください。診断はこの場合だけ、継承の表示を参考情報ではなく「要修正」に切り替えます。

spを書くのはサブドメインだけ扱いを変えたいときです

sp は任意のタグです(RFC 9989 セクション4.7 が OPTIONAL と定めています)。書けば上位の p の代わりにサブドメインへ適用され、書かなければ p が適用されます。値は p と同じ none / quarantine / reject の3つで、意味も p と同じです(同節)。

どの値でも、最終的にどう処理するかは受信側の判断です。reject と書けば必ず拒否されるわけではありません。

書く理由になるのは次の2つです。

• サブドメインから別のサービスでメールを送っていて、そちらの送信元をまだ把握できていない。この場合は sp を p より弱くして、認証から漏れた正規のメールが止まらないようにします
• 使っていないサブドメインを名乗るなりすましを止めたい。この場合は sp を p より強くします

どちらにも当てはまらないなら sp は書かなくてかまいません。実測でも、sp を書いているドメインの多くが、書かなくても同じ結果になる値を書いていました。Majestic Millionに掲載されている .jp ドメイン19,065件のうち、DMARCレコードが見つかったのは10,114件で、そのうち sp を持つのは692件(6.8%)、さらにその692件のうち509件(73.6%)は sp の値が p と同じでした(2026-08-01に測定。データは/data/jp-dmarc-policy-2026-08-01.json、測定は scripts/measure-dmarc-policy.mjs)。この母集団は被リンクの多い順に並んだ一覧からの抽出で、.jp 全体の無作為抽出ではありません。

509件が p と同じ値だったことは、sp を書くのが誤りだという意味ではありません。上の RFC の規定と合わせて読むとその509件は sp の行を消しても受信側の扱いが変わらない、ということです。

なお sp は組織ドメイン自身には適用されません。RFC 9989 セクション4.7 は「It applies only to existing subdomains of the message's Organizational Domain in the DNS hierarchy and not to the Organizational Domain itself」(DNS階層上、そのメッセージの組織ドメインの既存のサブドメインにのみ適用され、組織ドメイン自身には適用されない)と定めています。example.jp 宛のなりすましを止めるのは p の側です。

spで止められる範囲

sp が効くのはメールの From のドメインがそのサブドメインになっているメールです。差出人の表示名だけを本物に似せたメールや、example-jp.com のようによく似た別のドメインから送られたメールは、DMARCの対象外です。別のドメインにどんなポリシーを置くかは、そのドメインの持ち主しか決められません。

自分のドメインの下の名前を勝手に名乗られることは sp と np で止められます。その外側は別の対策の話になります。

書くときの形

組織ドメインのレコードに1項目足すだけです。example.jp の _dmarc に置くTXTレコードは、次のような形になります。

v=DMARC1; p=none; sp=reject; rua=mailto:{報告の宛先}

{報告の宛先} はレポートを受け取るメールアドレスです。ここに入れる値は運用する方が決めるものなので、この記事では埋めていません。自分のドメインの現在の値をもとにした設定値は、メール認証の診断が生成します。レポートの受け取り方そのものは、DMARCレポートを受け取る設定で扱っています。

診断は sp と np について、貼れる設定値を生成しません。none / quarantine / reject のどれを意図しているかは、そのドメインの運用を知らないと決められないためです。値の候補を勝手に選んで提示すると意図と違うポリシーをそのまま貼らせることになります。

サブドメイン自身のレコードに書いたspは、そのドメインには効きません

ここは仕様を読まないと気づけない箇所です。_dmarc.mail.example.jp に sp=quarantine と書いてもmail.example.jp から送るメールにその sp は使われません。使われるのは同じレコードの p です。

理由は sp の定義にあります。上で引いたとおり sp は組織ドメインの既存のサブドメインにだけ適用され、組織ドメイン自身には適用されません(RFC 9989 セクション4.7)。sp は、自分より下の名前へ向けた指定です。

sp を書かずに p を書いた場合は、期待どおりに動きます。_dmarc.mail.example.jp に v=DMARC1; p=reject を置けば mail.example.jp にはその p=reject が適用されます。上位のレコードより自分のレコードが優先されるためです(RFC 9989 セクション4.10.1 が、適用するレコードの優先順位を「Author Domain」「その組織ドメイン」「その公開サフィックスドメイン」の順としています)。

さらに下のサブドメインには効くことがあります

では _dmarc.mail.example.jp の sp は、a.mail.example.jp には効くのでしょうか。効く場合と効かない場合があります。同節に次の注記があります。

Note that "sp" will be ignored for DMARC Policy Records published on subdomains of Organizational Domains and PSDs due to the effect of the DMARC policy discovery (Section 4.10.1).

(組織ドメインおよび公開サフィックスドメインのサブドメインに公開されたDMARCポリシーレコードでは sp は無視されることに注意。ポリシー探索の作用による)

条件は「そのレコードの名前が組織ドメインとして選ばれるか」です。mail.example.jp が組織ドメインに選ばれれば、その sp は a.mail.example.jp に効きます。example.jp にもDMARCレコードがあるとそちらが組織ドメインに選ばれて、mail.example.jp の sp は無視されます。どちらになるかの決まり方は、次の見出しで扱います。

psd=n をそのレコードに書けば、その名前が組織ドメインであることを確定させられます(RFC 9989 セクション4.7 の psd の n)。大きな組織でDNSの管理を部門ごとに分けている場合の指定で、通常の運用では使いません。

まとめると、sp を書く場所は、まとめて扱いを決めたい範囲の頂点にあたるレコードです。example.jp の配下をまとめて決めたいなら _dmarc.example.jp に書きます。

存在しないサブドメインにはnpが適用されます

np はDNS上に存在しないサブドメイン専用の指定です。RFC 9989 セクション4.7 は「It applies only to non-existent subdomains of the Organizational Domain queried and not to either existing subdomains or the domain itself」(問い合わせた組織ドメインの存在しないサブドメインにのみ適用され、既存のサブドメインにもドメイン自身にも適用されない)としています。np を書かなければ sp が使われ、sp も無ければ p が使われます。

ここでの「存在しない」には決まった意味があります。RFC 9989 セクション3.2.13 は「if the response code received for a query for a domain name is NXDOMAIN, then the domain name and any possible subdomains do not exist」(あるドメイン名への問い合わせに対する応答コードが NXDOMAIN であれば、そのドメイン名とその下のあらゆるサブドメインは存在しない)と定めています。

つまりAレコードを持っていないだけの名前は、ここでいう存在しないサブドメインではありません。MXレコードやTXTレコードだけを持つ名前もDNS上には存在します。問い合わせに NXDOMAIN が返る名前だけが np の対象です。診断もこの区別を使い、名前の応答が NXDOMAIN のときにだけ np を適用対象として表示します。

もう1つ、np が働かなくなる構成があります。ワイルドカードのレコード(*.example.jp のような指定)を置いているとどんな名前を引いても応答が返るため、NXDOMAIN になりません(RFC 1034 セクション4.3.3)。この場合、存在しないサブドメインという状態がそもそも作られないので、np は使われず、既存のサブドメインと同じ扱い(sp、無ければ p)になります。使っていない名前を守るために np を置くなら、ワイルドカードを併用していないかを先に確認してください。

np は実測ではほとんど使われていません。上と同じ測定では、DMARCレコードが見つかった10,114件のうち np を持つのは8件(0.1%)でした。使っていないサブドメインを名乗るなりすましを止めたい場合に効きますが、既存のサブドメインには効かないため、sp の代わりにはなりません。

値を1文字間違えると上位のポリシーごと効かなくなります

sp=drop のように、決められていない値を書いた場合を考えます。「その行だけ読み飛ばされる」と思われがちですが、そうはなりません。RFC 9989 セクション4.10.1 は、次のように定めています。

If a retrieved DMARC Policy Record does not contain a valid "p" tag, or contains an "sp" or "np" tag that is not valid, then: If a "rua" tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containing "p=none" was retrieved and continue processing. Otherwise, the Mail Receiver applies no DMARC processing to this message.

(取得したDMARCポリシーレコードが有効な p タグを含まない場合、または有効でない sp もしくは np タグを含む場合: rua タグがあり、構文上有効な報告先URIを少なくとも1つ含んでいればメール受信者は p=none を含むレコードを取得したものとして扱い、処理を続けなければならない。そうでなければメール受信者はこのメッセージにDMARCの処理を適用しない)

結果は rua の状態で2つに分かれます。

どちらの場合も p=reject と書いてあってもその指示は使われません。上の行なら、なりすましメールは検出されるだけで受信箱にそのまま届きます。下の行ではDMARCを設定していないのと同じ状態になります。影響はサブドメインだけにとどまりません。

診断が sp と np の値の誤りを「要修正」として出すのはこの帰結があるためです。値が正しければ何も出ません。

実測では、sp の値が決められていないものは1件もありませんでした(上と同じ測定。sp を持つ692件のうち0件)。滅多に起きない状態ですが、起きたときに気づけないので診断が見ています。

有効な p タグを含まないレコードも、上の引用のとおり同じ扱いになります。p の書式そのものは、この記事では扱いません。書式の誤りでレコード全体が働かなくなる場合は、DMARCレコードの書式エラーで扱っています。

適用されるのはいちばん近い上位のレコードとは限りません

上位を探す動きには順序が決まっています。RFC 9989 は、公開サフィックスの一覧表を使う方式をやめ、DNSを1段ずつ上へ問い合わせる方式(DNS Tree Walk)に変えました(セクション4.10)。RFC 9989 は2026年5月に RFC 7489 と RFC 9091 を置き換えたもので、この点が変わっています。

決まり方は2段に分かれています。まず セクション4.10.2 の規則で組織ドメインを決め、次に セクション4.10.1 が「Author Domain のレコード」「組織ドメインのレコード」「公開サフィックスドメインのレコード」の順で、適用するものを選びます。サブドメイン自身にレコードが無ければ、適用されるのは組織ドメインのレコードです。

その組織ドメインは、いちばん近い上位ではありません。RFC 9989 セクション4.10.2 の選択規則は、psd の指定が無い場合について「Otherwise, select the DMARC Policy Record found at the name with the fewest number of labels」(それ以外の場合、ラベル数が最も少ない名前で見つかったDMARCポリシーレコードを選ぶ)としています。

同節が挙げている例で確かめられます。a.mail.example.com からのメールについて、mail.example.com と example.com の両方にDMARCレコードがあり、a.mail.example.com と com には無い場合、組織ドメインは example.com になります。適用されるのは example.com のレコードで、mail.example.com のほうではありません。

DNSの管理を部門ごとに分けていて、途中の階層にもDMARCレコードを置いている場合は、ここを取り違えると意図と違うポリシーで運用していることになります。psd=n をそのレコードに書いてあればそこが組織ドメインになるので、話は変わります。

もう1つ、名前の長さにも上限があります。ラベルが9段以上ある名前では、上位の探索は末尾7段からしか始まりません(RFC 9989 セクション4.10 の手順4)。多数のラベルを持つ名前で受信側に大量の問い合わせをさせる攻撃を防ぐための制限です。8段目より上に置いたレコードは、受信側の問い合わせ対象に入りません。

psdはyとnで役割が違います

psd は、そのレコードを公開している名前の立場を示す指定です。既定値は u で、通常は書きません。

値を間違えた場合の扱いは sp と np とは違います。RFC 9989 セクション4.8 は「Syntax errors in the remainder of the record MUST be discarded in favor of default values (if any) or ignored outright」(レコードの残りの部分にある構文エラーは、既定値があればそれを採用して破棄し、なければそのまま無視しなければならない)としています。psd には既定値 u があるため、psd=yes のような値は u として扱われ、レコード全体は生きています。セクション4.10.1 が挙げている失格の条件に psd は入っていません。

診断が psd の値の誤りを「要修正」ではなく参考情報として出すのはこの違いによるものです。実測では psd=y を持つドメインは10,114件のうち1件でした。

変更したあとの確認と戻し方

sp を足したり値を変えたりしたあとは、次の順で確認してください。

1. DNSに反映されたか。診断にサブドメインを入力し、表示される文言に意図した sp= または p= が入っていることを見ます。値が変わっていないときは、DNSが反映されないときの確認方法で権威サーバーの値と比べて切り分けてください
2. 実際のメールで通っているか。そのサブドメインから自分宛にメールを1通送り、届いたメールの認証結果(Authentication-Results)に dmarc=pass が出ることを見ます

2番目については、範囲に注意してください。dmarc=pass は、そのメールが認証を通ったことを示すだけです。認証に失敗したメールが reject や quarantine として扱われるかどうかは、これでは確かめられません。認証に失敗している送信元を洗い出すには集約レポートを使います(DMARCレポートが届かない原因)。

sp を強めた結果、サブドメインから送っている正規のメールが届かなくなった場合は、sp の行を消してください。消せば上位の p に戻ります。戻すときに知っておくことが2つあります。

• 上位の p は変わりません。sp を消す作業で、組織ドメイン側の設定に影響は出ません
• すぐには戻りません。受信側が変更前の値をキャッシュしている間は古い値で判定されます。かかる時間はレコードのTTLで決まります

すぐに戻したい場面が来ることが分かっている場合は、sp を足す前にTTLを短くしておくと戻すまでの時間が短くなります。TTLの考え方はDNSが反映されないときの確認方法で扱っています。

自分のドメインで確認する

いまサブドメインに何が適用されているかは、メール認証の診断にそのサブドメインを入力すると確認できます。上位のドメインから継承している場合は、どの名前のレコードが適用されるかと適用されるタグを表示します。sp や np の値に誤りがある場合は、その帰結も表示します。