ここまでで、送信ドメイン認証がかなり普及していることを説明してきた。この流れに沿い、一般企業などでも自社サイトでSPFレコードを公開する場合、どのように進めていくべきだろうか。
もちろん、企業でのメールシステム運用形態はさまざまで、一概に「こうだ」と言うことはできない。そこで、以下のような代表的な例を考え、それぞれに応じた導入方法を見てみよう。
1)ASPなどが提供するサービスを利用し、メールシステム全体を運用している
2)自社でメールシステムを所有し、運用している。しかし業務連絡以外の用途には利用していない
3)自社でメールシステムを所有しているが、広告/営業用のメールの送信は外部の業者に委託している
4)自社でメールシステムを所有しており、かつパブリックなメーリングリストを運用している
1)メールシステム全体をASPなどが提供するサービスで運用している場合
SPFレコードはDNSを利用して公開する。このケースではたいていの場合、ASP側がDNSを管理しているため、利用しているASPにSPFレコードを公開可能かどうか確認し、可能であれば依頼する必要がある。
2)自社でメールシステムを持っている。業務での連絡以外の用途には利用していない場合
DNSも自社で管理している場合、そのDNSサーバにおいて、適切なSPFレコードをTXTレコードとして公開すればいい。SPFレコードとしては、自社のメールサーバの中でも、メールがインターネットに送出される最前部にあるゲートウェイMTAのIPアドレスのリストを定義することになるだろう。DNSの管理をISPなどに委託している場合は、TXTレコードの公開が可能かどうか確認する必要があるだろう。
3)自社でメールシステムを持っているが、広告メールや営業用のメールの送信を外部の業者に委託している場合
自社のメールシステムから送信するメールについては、前節に説明したとおりだ。だが、外部の業者に委託してメールを送信している場合は、その業者への送信用のMTAのIPアドレスを問い合わせる必要があるだろう。自社のメールシステムと区別するために、それらのメールの送信用にサブドメインを利用し、そのサブドメイン用のSPFを公開するのも良い。SPFレコードは業者のメール送信用のMTAのIPアドレスのリストを含むことになる。
4)自社でメールシステムを持っている。パブリックなメーリングリストを運用している
この場合は、メーリングリストに投稿されたメールがメーリングリストの参加者に再配布される場合が問題になる。メーリングリストのシステムを変更し、再配布する際のエンベロープ送信者をそのメーリングリストのシステムのアカウントに変更するとともに、Sender IDでの認証を可能にするために、「Resent-sender:」や「Sender:」ヘッダを利用してメーリングリストの管理用アドレスなどを指定する必要がある。
これ以外にもさまざまな形態が考えられるし、解決方法もいろいろあるが、まずは、自社からインターネットに送信される可能性のあるメールサーバの実際のアドレスを徹底的に調べるところから始めていこう。
Copyright © ITmedia, Inc. All Rights Reserved.