Sender ID：送信者側の設定作業：送信ドメイン認証技術解説（4/4 ページ）

[末政延浩，＠IT]

SPFレコードを公開する場合の注意点

　実際にSPFレコードを記述する場合に注意すべき点を挙げる。

　現時点ではSPFおよびSender IDは、普及が進んでいるとはいえ過渡期であるため、全くメールを送信しないことを宣言するケースを除いて、レコードの末尾には「~all」を使う。

　これは「このドメインからの正当なメールでも送信ドメイン認証が成功しない場合があるかもしれません」というような意味を持つ。こうすることで、何らかの原因により受信側が認証に失敗した場合でも、受信拒否されないようになる。

　例えば、IPベースの送信ドメイン認証には、図3に示すように転送時に認証が失敗してしまう問題もある。「~all」を使っておけば、そのような問題が生じてもメールを受信拒否されずに済むはずである。

図3　IPアドレスベースの送信認証での問題点
[e-mail]から[e-mail]に届いたメールが[e-mail]に転送された場合、送信MTAのIPアドレスが2.2.2.2になりa.comのSPFレコードとマッチしないため認証が失敗する

　もう1つ注意すべき点は、メールを送信する可能性があるサーバを確実に把握しておくことである。例えば、営業部のスタッフがメールサーバの管理者に連絡することなく、キャンペーン用のメールを第三者に委託して送信させるようなケースなどがあるので注意しよう。

---

　今回はSender IDおよびSPFでの送信側の設定について説明した。後編は受信側の設定について説明する。

　繰り返しになるが、IPベースの認証方式では送信側でSPFレコードを公開するだけでも意味がある。ライセンス問題がクリアになったいま、可能であれば積極的にSPFレコードを公開していこう。

Index

Sender ID：送信者側の設定作業

Page1

IPアドレスベースの送信ドメイン認証

Sender ID、使っても大丈夫？

送信側のベネフィット、受信側のベネフィット

Page2

送信側での準備

チェック対象とされる送信ドメイン

SPFレコードの記述法

Page3

SPFレコードの定義

SPFレコードのサンプル

Page4

SPFレコードを公開する場合の注意点

Profile

末政 延浩

センドメール株式会社

テクニカルディレクター

ISPや企業のメールシステムの構築およびコンサルティングに従事。インターネット電子メールシステムの安全性を高めるため送信ドメイン認証技術の利用の拡大を望む

[an error occurred while processing this directive]