SIDF（Sender ID Framework / 送信者IDフレームワーク）

SIDF（Sender ID Framework）とは何ですか？

SIDF（Sender ID Framework）は、なりすましとフィッシングを防ぐためにMicrosoftが開発したメール認証プロトコルです。SPF（Sender Policy Framework）の拡張として設計され、DNSレコードを使って、メールメッセージが特定のドメインの認可されたメールサーバーから来ているかどうかを検証します。SIDFは今日ではほぼ使われなくなっていますが、ドメインベースの認証標準の初期の発展において重要な役割を果たしました。

SPFと同様に、SIDFは送信メールサーバーのIPアドレスを検証することで、偽装された送信者アドレスを減らすことを目指していました。ただし、SMTP伝送時に使われるエンベロープ送信者と、ユーザーに表示される可視のFromヘッダの両方を分析することで、SPFの機能を拡張しました。これは、技術的に誰がメッセージを送信したかだけでなく、誰が送信したように見えるかも検証しようとする試みでした。

SIDFの仕組み

SIDFは、SPFと同様にDNSのTXTレコードを照会して送信者の身元を確認します。これらのレコードは通常、v=spf1またはspf2.0で始まります。受信メールサーバーは、送信者のIPアドレスをDNSレコードで定義された認可済みリストと照合します。

Sender IDレコードの例:

このレコードでは、各要素は次の意味を持ちます。

• spf2.0/praはプロトコルのバージョンとスコープを指定します（PRAはPurported Responsible Address、つまり検証対象となるヘッダアドレスを意味します）。
• ip4:192.0.2.0/24は認可された送信者を列挙します。
• -allは、それ以外のすべての送信元からのメールを拒否するよう受信側に指示します。

送信メールサーバーのIPアドレスが、ドメインのレコード内の認可された送信者と一致すれば、SIDFの検証は通過します。一致しない場合、そのメッセージは失敗と判定され、受信側のポリシーに応じてフィルタリングされたり拒否されたりすることがあります。

SIDFの限界とその遺産

SPFの改善を目指したものの、SIDFはいくつかの課題に直面しました。最も大きな問題は、既存のSPF標準との非互換性でした。多くの組織は、SPFとSIDFのレコードを別々に維持するか、検証の衝突を招くリスクを負うかの選択を迫られました。さらに、SIDFがPurported Responsible Address（PRA）を確認するアプローチは、メッセージが転送システムやメーリングリストを経由すると、しばしば一貫しない結果につながりました。

2010年代後半までに、ほとんどのメールボックスプロバイダーやメールセキュリティシステムは、SPF、DKIM、DMARCを優先してSIDFを非推奨にしました。これらの新しいプロトコルは、送信者の身元とメッセージ認証の間のアライメントをより適切に実現し、独立したSender ID検証の必要性をなくしました。

SIDFはもはや積極的にサポートされていませんが、これを理解することは、メール認証がどのように進化してきたかという歴史的な背景を知る手がかりになります。SIDFは、可視の送信者情報を技術的な認証データと結び付けようとした最初の試みの1つであり、DMARCのような現代の標準への道を開きました。

SIDFとDMARCeye

DMARCeyeは、SPF、DKIM、DMARCといった現在の認証プロトコルに重点を置いていますが、その分析エンジンはDNSに残っているSIDFのようなレガシーレコードも検出できます。こうした古い設定は、放置すると混乱や軽微な互換性の問題を引き起こすことがあります。

DMARCeyeは、古い、または使われていないSPF2.0のエントリを検出し、管理者がDNSを現代の標準に適合させるよう更新するのを支援します。認証をSPF、DKIM、DMARCのみに依拠させることで、組織はレガシープロトコルの衝突なしにメール検証を効率化し、到達性を高められます。

ご自身のSPFレコードを確認しましょう：

DMARCeyeの無料トライアルに登録して、メールドメインを保護しましょう。

DMARCおよび関連用語について詳しくは、DMARCeye用語集をご覧ください。