サブドメインポリシー(Subdomain Policy)
概要
サブドメインポリシー(Subdomain Policy) は、DMARC レコードの sp= タグで指定する設定で、サブドメインから送信されたメールが DMARC 認証に失敗した場合の処理を、親ドメインのポリシー(p=)とは別に宣言します。RFC 7489(2015年)で定義されています。
sp= を省略すると、サブドメインは親ドメインの p= を継承します。example.com の DMARC レコードが p=reject であれば、marketing.example.com や support.example.com にも reject が適用されます。サブドメインごとに送信インフラの整備状況が異なる場合、sp= で段階的な移行が可能です。
攻撃者は random.example.com のような実在しないサブドメインをヘッダー From に使ってなりすましを試みることがあります。sp=reject はこのパターンも防ぎます。
仕組み
sp= タグの値は、サブドメインに個別の DMARC レコードがない場合に適用され、pct= タグの影響も受けます。
ポリシーの適用順序
受信サーバーがメールの DMARC ポリシーを取得するとき、次の順序で DNS を確認します。
- ヘッダー From のドメイン(例:
news.example.com)で_dmarc.news.example.comの TXT レコードを引く - レコードが存在すればそのポリシーを適用する
- レコードが存在しなければ、組織ドメイン(
example.com)の_dmarc.example.comを引く - 組織ドメインのレコードに
sp=があればその値を適用する sp=がなければp=の値をサブドメインに適用する
サブドメインに独自の DMARC レコードを設定すると、それが最優先になります。sp= よりも個別のレコードが優先されます。
3 つの値
sp= タグには p= と同じ 3 つの値を指定できます。
sp=none はサブドメインのメールにポリシーを適用しません。サブドメインの送信元調査が完了するまでの暫定設定です。
sp=quarantine はサブドメインからの認証失敗メールを迷惑メールフォルダに振り分けます。
sp=reject はサブドメインからの認証失敗メールを受信拒否します。使われていないサブドメインのなりすましも防ぎます。
pct タグとの組み合わせ
pct= タグは p= と sp= の両方に影響します。pct=50 を指定すると、親ドメインとサブドメインの両方で、認証失敗メールの 50% にポリシーが適用されます。pct を p= と sp= で個別に制御することはできません。
設定例
親ドメインとサブドメインのポリシーを段階的に使い分ける代表的なパターンを示します。
親ドメインは reject、サブドメインは quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com"
親ドメイン example.com の認証は完了しているが、サブドメインの送信サービスはまだ移行中という段階で使います。
親ドメインは reject、サブドメインは none
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com"
サブドメインの送信元がまだ把握できていない場合のモニタリング設定です。rua レポートでサブドメインの認証状況を確認してから sp=quarantine や sp=reject に引き上げます。
親ドメインもサブドメインも reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
すべての送信元の認証設定が完了した最終形です。sp=reject は明示指定していますが、sp= を省略しても p=reject が継承されるため動作は同じです。意図を明確にする目的で記述します。
特定サブドメインに個別ポリシーを設定
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
marketing.example.com だけ個別のポリシーを適用する場合、サブドメインに直接 DMARC レコードを設定します。この場合、親ドメインの sp= より個別レコードが優先されます。
確認方法
親ドメインの DMARC レコードで sp= タグを確認するには dig を使います。
dig TXT _dmarc.example.com
;; ANSWER SECTION:
_dmarc.example.com. 3600 IN TXT "v=DMARC1;p=reject;sp=quarantine;rua=mailto:dmarc@example.com"
sp=quarantine がサブドメインに適用されるポリシーです。タグが存在しなければ p= の値が継承されます。
サブドメインに個別の DMARC レコードがあるかも確認します。
dig TXT _dmarc.marketing.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; sp=quarantine; rua=mailto:dmarc@example.com",
"exists": true
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}
data.dmarc.record フィールドで sp= タグの有無と値を確認できます。
よくある問題
sp= の設定漏れや、個別レコードとの優先順位の誤解がサブドメインのなりすまし被害につながります。
sp タグを設定せずにサブドメインが悪用される
sp= を省略して p=none で運用すると、サブドメインにも none が継承されます。攻撃者は invoice.example.com や payment.example.com のような架空のサブドメインをヘッダー From に使い、フィッシングメールを送信できます。親ドメインの p= を強化するか、sp=reject を明示的に設定してサブドメインのなりすましを防ぎます。
サブドメインの送信元を把握していない
sp=reject に移行する前に、組織内のすべてのサブドメインからの送信状況を確認する必要があります。rua レポートにはサブドメインの認証結果も含まれます。marketing、notifications、support など各チームが独自に使っているサブドメインが SPF と DKIM を設定しているか確認します。
サブドメインの個別レコードと sp タグの優先順位を誤解する
_dmarc.sub.example.com にレコードが存在すれば、親ドメインの sp= は無視されます。サブドメインの個別レコードに p=none が設定されていると、親ドメインが sp=reject でもそのサブドメインには none が適用されます。個別レコードの棚卸しを定期的に行います。