また最近は、自社でメールサーバを持たず、ISPなどが提供する法人向けASPサービスなどを利用している企業も多い。このような場合は、そのサービスで送信ドメイン認証をサポートしているかどうかを事前に確認しておく。IIJや@niftyといった大手のISPが送信ドメイン認証に対応するプランを公表しており、事業者間でも追随する動きを見せている。
●SPFレコードの公開
送信認証が失敗したときに受信者に受信拒否されてしまわないよう、SPFレコードで宣言しておく(方法については後述)。プレスリリース用のメールや販促のキャンペーンのメール送信などを外部の業者に依頼している場合は、それらのメールの送信に利用するサブドメインを作成し、その業者が利用できるようにする。
●メーリングリスト
自社でメーリングリストを運用している場合、まずメーリングリストに投稿されたメールの送信ドメイン認証を実施して、投稿者の確認をする。そして、その投稿メールをメンバーに再配布する際に、SPF/Sender IDであれば、エンベロープをメーリングリストにするか、またはPRAの書き換えを実施する。
DomainKeysであれば、そのメーリングリストのドメインで再署名を実施する。こうすれば、メーリングリストのメンバーはそのメーリングリストからのメールであることを確認することができる。
モバイルユーザーのサポートは、特に送信側において重要だ。出張先や自宅からいずれかのISPを使ってインターネットに接続してメールを送信する場合、前節でも説明したように自社のメールサーバを利用させる必要がある。そうしないと、送信ドメイン認証の仕組みが利用できないからだ。ただし現在、各ISPはOutbound Port 25番ブロックによる対策を実施する動きにあり(図14)、ISPに接続してそこからISP以外のメールサーバを使ってメールを送信しようとすると、一般に利用されている25番ポートが使えない可能性がある。
よって、25番ポート以外に本来のメールサブミッション用のポートである587番を利用するか、SMTP over SSLのポートを利用する。また、587番のポートをモバイルユーザーにオープンにする場合は、SMTP AUTHによる認証を必須とし、許可された送信者しかそのポートを利用できないようにしておく。同時に、STARTTTLSをサポートして通信路を暗号化し、SMTP認証時のパスワードの漏えいを防いでおく。
実際に運用し始めると、送信ドメイン認証が失敗する場合のチェックが必要となる。実際には認証が成功するはずなのに失敗しているようなケースでは、何が原因なのか調査する。
原因としては、先に説明した転送やモバイルユーザーの問題などが考えられる。それ以外に、サイト内部でも認証情報を壊してしまう原因がないかチェックし、認証成功するように電子メールの経路を改善していこう。
また、認証に成功するがスパム率の高いメールを送信してくるドメインは、ブラックリストに入れて次回からは受信を拒否するとよい。
■末政延浩
Copyright © ITmedia, Inc. All Rights Reserved.