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

» 2005年10月27日 10時00分 公開
[末政延浩@IT]
前のページへ 1|2|3|4       

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

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

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

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

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

図3 IPアドレスベースの送信認証での問題点 図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レコードを公開していこう。

Index

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

Page1

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

Sender ID、使っても大丈夫?

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


Page2

送信側での準備

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

SPFレコードの記述法


Page3

SPFレコードの定義

SPFレコードのサンプル


Page4

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


Profile

末政 延浩


センドメール株式会社

テクニカルディレクター


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


[an error occurred while processing this directive]
前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。