相手が送信ドメイン認証に対応していない場合、送られたメールは通常のメールと全く同じように処理されます。検証はされないものの、ヘッダーに付与されたDKIMやDomainKeysの電子署名はそのまま相手側から目で確認することができます。
送信ドメイン認証は送信側、受信側双方が対応していない限り検証もできないわけですから、現状の普及率ではスパムフィルターの代わりにはなりません。自分でスパムメールを受け取らないためには別途専用のスパムフィルターが必要です。それについてはお勧めのスパムフィルターもありますので、導入支援のページでご紹介します。
方法は基本的に二つあります。一つは直接MTAに変更を加えて対応する方法。技術情報ページでSendmailを例にとって説明していますが、MTAによって対応方法は違います。Postfixでもsid-milter、dk-milter、dkim-milterが使えるようですが、qmailはかなりツギハギだらけになる模様。調べたところ、qmail-dkパッチやqmail-spfパッチはあるものの、DKIM用はどうやらKyle Wheelerという人のDKIM-Wrapperがあるようなのですが、現物はまだ未確認です。この他、もし商用のMTAソフトを使っている場合は、その開発元に対応してもらう以外ありません。
ということで、なかなかMTAに変更を加えて対応するのが難しい場合にお勧めなのが、既存のMTAをそのままに、そこからのSMTPルート上に送信ドメイン認証用のサーバーを構築する方法です。これなら対応が難しいMTAを運用していたとしてもとりあえずそれとは別に構築できますので、その部分だけ外部に委託することも可能です。
この場合の問題は、（1）どこのサーバーから発信し（SPF、Sender IDの場合）、（2）どこのサーバーで署名し（DKIM、DomainKeysの場合）、そして（3）どのサーバーで受信（受信側認証）するかです。もしレンタルサーバー業者が送信ドメイン認証に対応していればこれらは業者側のサーバーで処理されますが、そうでない場合は何か対応を考えなくてはなりません。
とりあえずレンタルサーバー業者を変えずに、自前で対応するのでもない方法として、上記の全てを処理する送信ドメイン認証用のサーバーを外部に提供して貰うことは技術的に可能ですので、もし詳細をお知りになりたければ導入支援のページからお問い合わせ下さい。
この場合は送信ドメイン認証に対応したメールサービスを提供しているISPを探すしかありません。確かBiglobeがDKIMなどにも対応していたと思いますが、その他にもあると思いますので調べてみてください。
Authentication-Results:というヘッダーに記述されます。それぞれの認証方法の結果は以下のように表示されます。
【SPF】| Authentication Results | 認証 | 認証結果 | 意味 |
| spf=pass | ○ | ○ | 正しく認証された |
| spf=neutral | ○ | △ | 詐称されているかどうか判断出来ない |
| spf=softfail | ○ | △ | 詐称の可能性がある |
| spf=fail | ○ | × | 詐称されている |
| spf=temperror | × | なし | 認証処理エラーのため認証出来ず |
| spf=permerror | × | なし | 認証登録情報に誤りがある |
| Authentication Results | 認証 | 認証結果 | 意味 |
| sender-id=pass | ○ | ○ | 正しく認証された |
| sender-id=neutral | ○ | △ | 詐称されているかどうか判断出来ない |
| sender-id=softfail | ○ | △ | 詐称の可能性がある |
| sender-id=fail | ○ | × | 詐称されている |
| sender-id=temperror | × | なし | 認証処理エラーのため認証出来ず |
| sender-id=permerror | × | なし | 認証登録情報に誤りがある |
| Authentication Results | 認証 | 認証結果 | 意味 |
| dkim=pass | ○ | ○ | 正しく認証された |
| dkim=neutral | × | なし | 公開鍵が存在しない等の理由で認証出来ず |
| dkim=softfai | ○ | △ | 詐称の可能性がある |
| dkim=hardfail | ○ | × | 詐称されている |
| dkim=temperror | × | なし | 認証処理エラーのため認証出来ず |
| dkim=permerror | × | なし | メールに From:, Sender: 等のフィールドが無い |
| Authentication Results | 認証 | 認証結果 | 意味 |
| domainkeys=pass | ○ | ○ | 正しく認証された |
| domainkeys=neutral | × | なし | 公開鍵が存在しない等の理由で認証出来ず |
| domainkeys=softfail | ○ | △ | 詐称の可能性がある |
| domainkeys=hardfail | ○ | × | 詐称されている |
| domainkeys=temperror | × | なし | 認証処理エラーのため認証出来ず |
| domainkeys=permerror | × | なし | メールに From:, Sender: 等のフィールドが無い |
はい、結論から先に言うと、送信ドメイン技術にもそれぞれ得手不得手があり、これを理解することによって複数を上手く組み合わせるヒントになります。（Sender IDはPRAによる認証を前提に書いています。MFROMの場合はSPFと変わらないのでSPFを読み替えて下さい。）
（※これはあくまでもサーバーレベルのSMTP転送、例えば一つのアドレスから別のアドレスへ転送設定がされているような場合の話です。一旦ユーザーが受け取ったメールを転送ボタンを押して転送するのは技術的には普通の送信なのでこれに含みません。）
SPFの場合、転送により最終的に接続してくるサーバーのIPアドレスが変わるので、基本的には認証に失敗します。ただし、転送サーバーが何らかの理由でSPFレコードに書かれている場合は別ですが、可能性は低いでしょう。
Sender IDの場合、転送サーバーがResent-Fromヘッダーをつけ、そのサーバーのドメインがSender IDに対応していれば認証は成功します。ただし、認証する相手が元々の送信者ではなく、転送者になる点で、主旨が違って来ますが。
DKIMの場合、電子署名はオリジナルの送信者のもので、基本的にはIPアドレスは関係ないので認証に成功します。ただし、署名にReceivedヘッダーを入れた場合は、Receivedヘッダーが変化するので失敗します。RFC4871には電子署名にReceivedヘッダーは含めるべきではない（SHOULD NOT）と書いてあるので通常入れることはありませんが、入れてはならない（MUST NOT）ではないので運用者によっては可能性はゼロではありません。
SPFの場合、メーリングリストがリストのアドレスをEnvelope-Fromにしていて、そのドメインのSPFレコードにリストのサーバーがあれば認証に成功します。ただし、リストによっては投稿者のアドレスをそのままEnvelope-Fromに通すことも可能なので、その場合はメール転送の場合と同じ理由で失敗します。
Sender IDの場合、ヘッダー上のFromは元々の投稿者のものなので、直接接続してくるリストのサーバーIPアドレスと不整合を起こし、認証に失敗します。ただし、リストのサーバーがSenderやResent-Fromにリストのアドレスを書き込んでくれれば認証できます。
DKIMの場合、電子署名に含めたヘッダーに変更があれば即座に認証失敗となります。多くのメーリングリストがSubjectに通し番号などの変更を加えるため、認証に失敗するケースが多いです。ただし、電子署名にSubjectを入れない、またはリスト自体がSubjectをそのまま通せばこれを回避することも可能です。しかし、本文を変更するようなリストの場合、その回避は難しいです。
今のところはないようです。しかし、仕組みから考えてメールソフト上で電子署名を検証することは可能ですし、それがあれば普及の大きな助けになるかもしれません。誰かが作ってくれるといいのですが。（例えばMソフトさんとか。笑）
はい、確かに以前その問題は話題になりました。マイクロソフト社がSender IDの受信側認証を行う場合は同社とのライセンス契約が必要と主張していた問題です。しかし、最終的にこの問題はマイクロソフト社がSender IDに関わる技術をOpen Specification Promiseの下で提供すると発表し、一応の収束を見ています。
マイクロソフト社のOSPページ→http://www.microsoft.com/interop/osp/default.mspx