RFC 5617: ADSP — 著者ドメイン署名慣行

Deprecated by DMARC Email Authentication Published March 2026

ELI5: あなたが会社を経営していて、送信するすべての手紙にろう印を押すと想像してください。ADSP は世界に次のように宣言する方法でした。「私たちからのすべての手紙には印があります。それなしで受け取ったら、それは偽造品です。」良いアイデアでしたが、アナウンスメカニズムが厳密すぎて、メーリングリスト、転送、またはサードパーティの送信者を適切に処理できませんでした。[DMARC](dmarc) は最終的により柔軟なアプローチで同じ問題を解決し、ADSP は廃止されました。

このしくみが存在する理由

DKIM (RFC 6376)はドメインが送信メッセージに署名することを可能にしますが、メッセージが有効な署名を欠いている場合に受信者が何をすべきかについては述べていません。ポリシーレイヤーがないと、受信者はbank.example.comからの署名なしメッセージが正当なもの(おそらく送信パスが常に署名するわけではない)なのか、詐欺的なもの(銀行になりすましたフィッシャー)なのかを知る方法がありません。

ADSPはこのギャップを埋めるための最初の試みでした。ドメイン所有者がDNSレコードを公開して署名の慣行を宣言することができました。

「unknown」 — ドメインはすべてのメッセージに署名する場合と、しない場合があります(ADSPレコードが存在しない場合のデフォルト)。
「all」 — ドメインはすべてのメッセージに著者署名で署名します(DKIM d=がFrom:ドメインと一致)。
「discardable」 — ドメインはすべてのメッセージに署名し、署名なしメッセージは破棄されるべきです。

2009年8月に公開されたADSPは採用が限定的で、2013年11月にRFC 5863によって「Historic」ステータスに移行しました。その後継であるDMARCはADSPの欠点に対処し、標準的なメール認証ポリシーメカニズムとなりました。

動作方法

DNSルックアップ

ADSPレコードはDNS TXTレコードとして_adsp._domainkey.<domain>で公開されます。受信者がFrom:ヘッダーがalice@example.comのメッセージを受け取ると、以下をルックアップします。

_adsp._domainkey.example.com. IN TXT "dkim=all"

ポリシー値

ポリシー	DNSレコード	意味
Unknown	`dkim=unknown`(またはレコードなし)	ドメインが一部またはすべてのメールに署名する可能性があります。署名なしメッセージについての主張はありません。
All	`dkim=all`	このドメインからのすべてのメールは著者署名で署名されます。署名なしメッセージは疑わしいですが、必ずしも偽造ではありません。
Discardable	`dkim=discardable`	すべてのメールが署名されています。署名なしメッセージは黙って破棄されるべきです。最も強力なポリシー。

著者署名対サードパーティ署名

ADSPの重要な概念は著者署名です。これはDKIM-Signatureヘッダー内のd=タグがFrom:ヘッダー内のドメインと完全に一致するDKIM署名です。これは、任意のドメインが署名することを許可する一般的なDKIMよりも厳密です。

; 著者署名(ADSPが気にするもの) From: alice@example.com DKIM-Signature: v=1; a=rsa-sha256; d=example.com; ... ; d=example.comがFromドメインと一致 → 著者署名:はい ; サードパーティ署名(ADSPが無視するもの) From: alice@example.com DKIM-Signature: v=1; a=rsa-sha256; d=esp-provider.com; ... ; d=esp-provider.comがFromドメインと一致しない → 著者署名:いいえ

これは、d=esp.comではなくd=yourdomain.comとしてメールに署名するESP(メールサービスプロバイダー)を使用していた場合、ADSPはそれらのメッセージを署名なしとして扱うということを意味しました。たとえ完全に有効なDKIM署名があったとしても。

検証フロー

メッセージを受信し、From:ヘッダードメインを抽出します。
d=がFromドメインと一致するDKIM-Signatureヘッダー(著者署名)を探します。
有効な著者署名が存在する場合、メッセージを通常通り受け入れます。
有効な著者署名が存在しない場合、_adsp._domainkey.<domain>のDNSをクエリします。
ポリシーを適用します。unknownはアクションを実行しないことを意味し、allは注意深く扱うことを意味し、discardableは拒否または黙って削除することを意味します。

主要な技術的詳細

ADSPが失敗した理由

ADSPの設計には、有意な採用を妨げた基本的な制限がありました。

メーリングリストが著者署名を破壊します。メーリングリストがメッセージを変更すると(フッターを追加する、件名を変更するなど)、DKIM署名が破壊されます。dkim=discardableの下では、受信者はメッセージを削除します。メーリングリストを使用するドメインは厳格なポリシーを安全に展開することはできません。
サブドメインカバレッジなし。ADSPはクエリされた正確なドメインにのみ適用されました。すべてのサブドメインについて個別にレコードを公開せずに、*.example.comのポリシーを設定する方法はありませんでした。
レポーティングメカニズムなし。ADSPは受信者がドメイン所有者に認証結果についてのフィードバックを送信する方法がありませんでした。データなしに、ドメイン所有者はより厳密なポリシーを展開する前にその影響を評価することができません。
段階的なロールアウトなし。唯一のオプションは「unknown」(保護なし)、「all」(曖昧)、または「discardable」(核選択肢)でした。DMARCの割合(pct=)タグと同等の段階的な実施がありませんでした。
SPFは考慮されていません。ADSPはDKIMのみを評価しました。SPFに合格したがDKIMを欠いているメッセージは、完全に認証されていない偽造と同じように扱われました。

ADSP対DMARC:主な相違点

機能	ADSP (RFC 5617)	DMARC (RFC 7489)
認証方法	DKIMのみ	DKIMまたはSPF(どちらか一方が合格可能)
アライメントモード	厳密のみ(Fromと完全一致)	厳密または緩い(サブドメイン許可)
サブドメインポリシー	なし	`sp=`タグ(サブドメイン用)
集約レポーティング	なし	`rua=`タグ(日次XMLレポート)
フォレンジックレポーティング	なし	`ruf=`タグ(失敗ごとのレポート)
段階的ロールアウト	なし	`pct=`タグ(メールの割合にポリシーを適用)
ポリシーアクション	unknown、all、discardable	none、quarantine、reject
DNS場所	`_adsp._domainkey.<d>`	`_dmarc.<d>`
ステータス	Historic(2013年廃止)	Active、広く展開されている

DNSレコード詳細

; ADSPレコード構文 _adsp._domainkey.example.com. IN TXT "dkim=discardable" ; 認識される唯一のタグは「dkim=」で、値は以下の通り: ; unknown - デフォルト、主張なし ; all - すべてのメールが著者署名されている ; discardable - すべてのメールが著者署名されている。署名なしの場合は破棄

一般的な間違い

2024年以降にADSPを展開する。ADSPはHistoricです。主要な受信者はADSPレコードをチェックしません。まだ公開されているものがある場合、それは何もしません。代わりにDMARCを展開してください。
ADSPとDMARCを混同する。どちらもDKIMのポリシーメカニズムですが、DMARCが現在の標準です。_adsp._domainkeyレコードを参照するドキュメントに遭遇した場合、それは古い情報です。
DNSに古いADSPレコードを残す。古いADSPレコードはDNSクエリ時間を消費し、デバッグ中に混乱を増加させます。ゾーン内に_adsp._domainkeyTXTレコードを見つけた場合、クリーンアップしてください。
「discardable」が最強のポリシーだと思う。全盛期でも、ADSPの「discardable」は非常に少数の受信者に尊重されました。採用が低すぎて、スプーフィングに対する有意な保護を提供しませんでした。
教訓を学ばない。ADSPは可視性なしでのオールオアナッシングであるために失敗しました。DMARCはレポーティング(rua=)と段階的なロールアウト(pct=)を追加したために成功しました。常に強制前に監視で開始してください。

配信性への影響

現在の影響なし。ADSPレコードは最新の受信者によってチェックされません。公開することは、配信、認証結果、またはスパムフィルタリングに影響を与えません。
DMARC展開への歴史的教訓。ADSPの失敗はDMARCの設計に直接影響を与えました。DMARC展開可能にするレポーティングおよび段階的なロールアウト機能は、ADSPがフィードバックなしのバイナリポリシーが非現実的であることを証明したため存在しています。
古いレコードをシグナルとして。DNSの古いADSPレコードは、ドメインのメールインフラストラクチャが積極的に維持されていないという軽度のシグナルです。受信者はこれを罰しませんが、認証デバッグ中に混乱を引き起こす可能性があります。
DMARCに移行してください。ドメインにADSPレコードはあるがDMARCレコードがない場合、直ちにDMARCを展開してください。p=noneとrua=レポーティングアドレスで始めて可視性を得てから、データに基づいてポリシーを厳しくしてください。