Tweet

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

　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レコードを公開していこう。

4/4

Index
Sender ID：送信者側の設定作業
	Page1 IPアドレスベースの送信ドメイン認証 Sender ID、使っても大丈夫？ 送信側のベネフィット、受信側のベネフィット
	Page2 送信側での準備 チェック対象とされる送信ドメイン SPFレコードの記述法
	Page3 SPFレコードの定義 SPFレコードのサンプル
	Page4 SPFレコードを公開する場合の注意点

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

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード