責任を確認するには、対象となるエージェントのアイデンティティが正確で信頼のおけるものでなくてはなりません。したがって、アイデンティティの認証は、評価の取り組みにとっては必須条件です。ただし、認証だけでは正当な評価は保証されません。スパム送信者も自分のアイデンティティを登録して正当化できるからです。

初期のスパム対策のアイデンティティ方式では、フィルタを実行しているサーバに直接送信を行っているクライアントSMTP MTAのIPアドレスを使用します。アドレスは基盤となるネットワーク・サービスによって提供されるため、信頼されていました。しかし、スパム発信者はIPアドレス空間を盗むことに長けてきています。たとえば、割り当て済みでありながら未使用のIPアドレス・ブロックを使用する経路を通知するというような方法を使います。また、IPアドレスは、ホストがインターネットへの接続を変えるたびに変わり、作成者ではなく運営者に属します。このため、電子メールの評価時にはIPアドレスはあいまいで信頼できないものとなります。

最近では、より安定しており、ADMDの権限境界にもなじみやすい、ドメイン名の使用が中心となっています。中継されるメッセージの有効性確認にドメイン名を使用する取り組みには、大きく分けて２つの方向があります。１つは、アイデンティティを、メッセージを処理する経路上のシステムに関連付けます。こうした「パス登録」方式には、Sender Policy Framework、Sender-IDおよびCertified Server Validationがあります。もう一方の方式は、ドメイン名をメッセージ・オブジェクトに関連付けます。これには、Domain-Keys Identified MailおよびBounce-Address Tag Validationが含まれます。

Sender Policy Framework（SPF）［16］は、進化してきており、複数のアイデンティティに対応しようとしています。主にRFC 2821のMailFromコマンド内のドメイン名を使用します。その名前を、DNS（Domain Name System）に照会し、直前の中継点のMTAのIPアドレスがその名前で登録されているか確認します。経路上の任意のSMTPサーバがこの照会を行う可能性があるため、SPFでは、メッセージのすべての配送経路上のすべてのMTAがDNSに含まれている必要があります（しばしばこのモデルを単純化して境界MTAの間でのみ使用することがありますが、しかしこのような大幅な制約はSPFでは規定されていません。むしろ、このモデルは通常、一般化して使用するものと位置づけられています）。SPFのソフトウェア面のオーバーヘッドはとても小さいですが、経路の数が増加し経路が変化するにつれて管理面のオーバーヘッドは大きくなる可能性があります。加えて、送信SPFのDNS構成によっては、受信者ごとの照会の数が膨大なることもあります。最後に、RFC 2821 MailFromコマンドの役割は、Notification Handlerアドレスを指定することです。このアドレスは、他の送信元情報とまったく異なる可能性があるため、経路上のすべてのMTAを登録することが問題となります。そのため、SPFは、第三者の転送サービスを経由する場合などに、転送トラフィックに関して大きな管理上の問題を抱えています。

Sender-ID（SID）［17］では、SPFに似たモデルを使用しますが、RFC 2822のSenderフィールド（あるいは、SenderフィールドがなければRFC 2822のFromフィールド）にある送信元アドレスのドメイン名に基づきます。SIDとSPFはともに2004年にIETFでの標準化を目指しましたが、作業部会の取り組みは、参加者の大枠での統一的コンセンサスの欠如と知的所有権の主張をめぐる懸念に起因して、失敗に終わりました。

Certified Server Validation（CSV）［18］は、現在のクライアント／サーバSMTP中継点のみを対象とします。クライアントは、RFC 2821のEHLOコマンドの中に運営者のドメイン名を指定します。サーバはこの名前を使用してDNSに照会を行います。その後、SMTPクライアントのIPアドレスの有効性を確認し、メールを送信する権限がドメイン名管理者によってクライアントに与えられているかどうかを判断します。CSVでは、クライアントのドメイン名に関して評価サービスを照会する標準の仕組みも規定しています。

DomainKeys Identified Mail（DKIM）［19］では、伝送中のメッセージに適用される責任確認が可能なドメイン名を規定しています。公開鍵暗号を使用してメッセージにデジタル署名を加え、書名のドメイン名がRFC 2822のFromフィールドのドメイン名と異なる場合の指針を提供します。

DKIMドメイン名検証は、メッセージ・コンテントの長期的な保護を中心とする［20、21］などの強力な認証方式とは大きく異なる目標を持っています。またDKIMでは、そのパラメータ情報によってDKIMに対応していない受信者ユーザ・エージェントが影響を受けないように、メッセージ・ボディではなく、特別なRFC 2822ヘッダ・フィールドにパラメータ情報を置きます。公開鍵暗号の計算処理コストは比較的高いですが、電子メールの処理は一般に入出力に左右されるため、現実にはDKIMを使用しても、サーバの総合的なメッセージ処理能力に対して与えるインパクトは小さいようです。

Bounce Address Tag Validation（BATV）［22］では、バウンスなどの誤配送処理通知（misdirected handling notices）の問題に対応します。RFC 2821のMailFromバウンス・アドレスに作成者がデジタル署名を加えられるようにします。作成者のバウンス・エージェントが、バウンスになりすましたメッセージを受信したとき、エージェントはそのアドレスの有効性を検証できます。メーリング・リスト・ソフトウェアなどの電子メールの中継者がメールボックス部分の「中核」を知ることができるように、形式については標準化が必要です。署名セマンティックスの作成者が、署名セマンティックスの唯一の消費者なので、対称鍵に基づくものを含め、任意の署名アルゴリズムが使用できます。利便性を考慮し（および、存在証明として）、BATVの仕様にはすでに使用されているアルゴリズムの例が記載されています。