第6章

6.1.1.2 サーバ共用型

ホスティングサービスでの対応

表６－２）。
専用型とは異なり、割り当てられたメールサーバ共用型は、複数の契約ドメイン（企サーバから送信されるメールには、共用して業）に対して、１つ又は１つの集合体のメーいる他社ドメインからのメールも混在するこ

ルサーバを「共用」で割り当てる形でメールとになります。

送受信機能を提供するサービス形態です（図図表６－２

サーバ共用型のホスティング事業者の例

6.1.1.3 ゲートウェイ型

MX サーバのみ提供し、メールデータを蓄積するメールボックス機能や投稿サーバなどの機

ゲートウェイ型は、契約ドメイン（企業）能は提供しません。反対に、ゲートウェイ型に対して、MX サーバやフィルタリングサーのうち送信メールサーバの場合、契約企業のバ、投稿サーバを割り当てる形で、主に迷惑メールサーバが設定するリレー先サーバ（あメール対策機能やウイルス対策機能、監査機るいは投稿サーバ）を提供し、MX サーバは能などを提供するサービス形態です（図表６提供しません。

－３、図表６－４）。
ゲートウェイ型のうち受信メールサーバの場合、ホスティング事業者はゲートウェイ用

71

第6章

6.1.2 DNS サーバによる分類

ホスティングサービスでの対応

DNS ホスティング型は、契約企業ドメインの DNS サーバを、ホスティング事業者側がメールホスティングサービスは、DNS サー代行して管理する形態です。ホスティング事

バの管理により、「DNS 自社管理型」、「DNS業者は、契約企業のメールサーバとともにホスティング型」、「DNS 提供型」の 3 つに分

DNS サーバの管理も行います。

類できます。
6.1.2.3 DNS 提供型6.1.2.1 DNS 自社管理型

DNS 提供型は、契約企業ドメインの DNSDNS 自社管理型は、契約企業ドメインのサーバのみをホスティング事業者が代行してDNS サーバを、契約企業自身で管理する形態管理する形態です。ホスティング事業者は、です。ホスティング事業者は、契約企業のメ契約企業の DNS サーバは管理しますが、メールサーバは管理しますが、DNS サーバの管ールサーバの管理は行いません。

理（MX レコードや TXT レコードの登録・更新・削除）は行いません。

この場合には、DNS 自社管理型とも異なり、契約企業、メールサーバのみを管理するホスティング事業者、DNS サーバのみを管理する

6.1.2.2 DNS ホスティング型ホスティング事業者の三者が登場します。

73第6章

6.3 受信側の対応

ホスティングサービスでは、ホスティング事業者の設備で受信側の対応を行うことが必

ホスティングサービスでの対応ことが推奨されます。
6.3.1.2 契約企業への説明とメールクライアント側へのフィルタリング指導要です。第３章で紹介した一般的な対応のほか、以下のような事項についての対応を行うことが必要です。

契約企業に対して、契約ドメイン宛の受信メールの判定結果及びフィルタリングによって得られる効果を報告します。ホスティング

6.3.1 認証結果の解説と利用方法の提示

事業者は、メールクライアント側で設定すべきフィルタリング条件の設定をサポートする

送信ドメイン認証技術による認証結果をとよいでしょう。

Authentication-Results ヘッダに記録する場合には、契約企業に対して Authentication-Res6.3.2 認証結果によるフィルタリング実施

ults ヘッダに関する説明を行い、必要であればメールクライアント側での適切なフィルタリングの指導を行うことが必要です。

メールクライアント側のフィルタリングでは、ホスティング事業者の設備コストは直ちホスティング事業者は、第３章を参考にしに効果がでるとはいえませんが、今後送信側た説明資料を準備することが推奨されます。

の対応が進むとエンドユーザ側での様々な活用が進むと予想されております。

6.3.1.1 判定結果の確認

ホスティング事業者は、メールの隔離、拒否、破棄などのサーバ側でのフィルタリング契約企業にフィルタリングの指導をする準機能を準備することが推奨されます。サーバ

備として、該当ドメイン宛の受信メールのう側のフィルタリング機能を実装するにあたっ

ち、適切に送信ドメイン認証が実施された割ては、以下の点について考慮することが必要合を調査します。受信メールの多くが fail /です。

softfail と判定されているドメインのうち、契約企業とやり取りをされている顧客が含まれ6.3.2.1 フィルタリング利用を選択できる機能の提る場合は、フィルタリングのホワイトリスト供対象を講じることが考えられます。この場合には、該当するドメインをリスト化して、契特にサーバ共用型の場合には、フィルタリ約企業に確認してもらうことが推奨されます。

ング機能を利用する契約企業と利用しない契受信メールの多くが neutral / none と判定

約企業が共存する場合が想定されますので、されている契約企業の場合は、フィルタリン

ホスティング事業者は、契約ドメインごとにグによる効果が低いため、この指導は見送る

フィルタリング設定の有効・無効を管理する

79

第 6 章 ホスティングサービスでの対応ことが必要です。
6.3.2.3 なりすましメールの措置を選択できる機能6.3.2.2 ドメイン単位のホワイトリスト機能の提供の提供

6.3.2.1 で解説したとおり、送信元ドメインフィルタリング結果で送信者情報が偽装さによってはすべてのメールの送信元に対してれているメール（なりすましメール）である

送信ドメイン認証技術に対応していない場合と判定された場合には、それらのメールは何があります。言い換えれば、認証結果が fail /らかの措置（隔離、ラベリング、拒否等）がsoftfail であっても受信すべき送信元ドメイとられることが推奨されます。ホスティングンが存在することになります。このため、ホ事業者は、このような措置として複数の選択

スティング事業者は、各契約ドメインごとに、肢を用意し、契約企業にリスクと効果をかんホワイトリスト機能を提供し、必要なメールがみて、設定してもらうことが推奨されます。

の不達を防ぐことが必要です。

ホスティング事業者の用意する措置としては、以下のようなアクションが考えられます。
仕様

特徴

X ヘッダ又は Subject ヘッダなどになりすましと認識できる目印を記録する

・受信すべきメールの不達を防止することができるが、契約企業のユーザがメールクライアントでフィルタリング設定をする手間が生じる

隔離して受信ごみ箱や迷惑メールボックスなど、受信箱とは別の場所に受信する・受信すべきメールの不達を防止することができるが、隔離されていることで False Positive が発生した場合にユーザが受信を見落とす可能性がある・ゲートウェイ型では提供できないSMTP で拒否するなりすましメールと判定された時点で、SMTP 応答で該当メールを拒否する・なりすましメールが契約企業のユーザに着信しなくなるが、ホワイトリストが適切に設定されていない場合には、メール不達が生じる

NDR をメールサーバで破棄なりすましメールと判定されたメールのうち、NDR については SMTP レスポンスを正常応答したのち、メールサーバ内で破棄する

・不要な NDR によるコストが軽減されるが、通常のメールについては他の施策と組み合わせて実装する必要がある

ヘッダに目印を記録

図表６－１１80

なりすましメールの措置の例