SPFレコードを公開する場合の注意点
実際にSPFレコードを記述する場合に注意すべき点を挙げる。
現時点ではSPFおよびSender IDは、普及が進んでいるとはいえ過渡期であるため、全くメールを送信しないことを宣言するケースを除いて、レコードの末尾には「~all」を使う。
これは「このドメインからの正当なメールでも送信ドメイン認証が成功しない場合があるかもしれません」というような意味を持つ。こうすることで、何らかの原因により受信側が認証に失敗した場合でも、受信拒否されないようになる。
例えば、IPベースの送信ドメイン認証には、図3に示すように転送時に認証が失敗してしまう問題もある。「~all」を使っておけば、そのような問題が生じてもメールを受信拒否されずに済むはずである。
図3 IPアドレスベースの送信認証での問題点
a@a.comからb@b.comに届いたメールがb@c.comに転送された場合、送信MTAのIPアドレスが2.2.2.2になりa.comのSPFレコードとマッチしないため認証が失敗する
もう1つ注意すべき点は、メールを送信する可能性があるサーバを確実に把握しておくことである。例えば、営業部のスタッフがメールサーバの管理者に連絡することなく、キャンペーン用のメールを第三者に委託して送信させるようなケースなどがあるので注意しよう。
今回はSender IDおよびSPFでの送信側の設定について説明した。後編は受信側の設定について説明する。
繰り返しになるが、IPベースの認証方式では送信側でSPFレコードを公開するだけでも意味がある。ライセンス問題がクリアになったいま、可能であれば積極的にSPFレコードを公開していこう。
Profile
末政 延浩
テクニカルディレクター
ISPや企業のメールシステムの構築およびコンサルティングに従事。インターネット電子メールシステムの安全性を高めるため送信ドメイン認証技術の利用の拡大を望む
Copyright © ITmedia, Inc. All Rights Reserved.