セキュアメールゲートウェイの背後にあるメールアドレスを検証する方法
検証レポートを書き出したとき、大企業の優良な連絡先の多くが不明（unknown）として返ってきたことはないでしょうか。その場合、セキュアメールゲートウェイ（SEG）が間にあった可能性がかなりあります。症状はキャッチオールドメインとまったく同じですが、原因はゲートウェイです。
この違いが重要なのは、対処法が違うからです。そして、ゲートウェイの背後にある連絡先は、本当に連絡したい相手であることが多いからです。小さな会社がゲートウェイを使うことはあまりありません。銀行、保険会社、病院、大学、そしてFortune 500の大半は使っています。
検証が失敗するとき、検証ツールは何をしているのか
標準的な検証は、短いやり取りです。検証ツールは、ドメインのMXレコードに登録されたメールサーバーに接続します。あいさつをし、送信者を伝え、次に受信者を伝えて応答を待ちます。メールボックスの実際の一覧を持っているサーバーは、正直に答えます。存在するアドレスにはイエス、存在しないアドレスにはノーと答え、検証ツールはその答えを記録します。
セキュアメールゲートウェイは、実際のメールサーバーの前に置かれるフィルタリングの層です。そのドメイン宛てのメッセージは、すべて最初にゲートウェイに届きます。そこでマルウェア、フィッシング、ポリシー違反がないかスキャンされ、その後で内側に渡されます。Proofpoint、Mimecast、Barracuda、Cisco、そして十数社の小規模なベンダーは、すべてこの仕組みで動いています。
ゲートウェイには、どのメールボックスが存在するかを知る必要がありません。役割はフィルタリングで、宛先の一覧を調べることではないからです。そのため、検証ツールが特定の受信者について質問すると、ゲートウェイは受け入れます。実在するアドレスも、入力ミスのアドレスも、2019年に退職した人の名前も受け入れます。受け入れは入口で行われます。メールボックスが存在するかの判断はその奥で行われ、検証ツールはそこに届きません。
外から見ると、この動作はキャッチオールドメインと区別がつきません。同じやり取り、同じ応答、そして役に立たない同じ結果になります。
「リスクあり」で止めてはいけない理由
多くの検証ツールは、こうしたアドレスにラベルを付けて対応します。ラベルはベンダーによって違います。どのツールの書き出しを見ているかによって、risky、unknown、accept-all、catch-all、ok_for_allなどと表示されます。意味はどれも同じで、「判定できなかった」ということです。
その範囲では正直な答えです。問題はその後に起きることです。送信ツールはこうしたラベルを「どちらかといえばノー」として扱いがちで、多くの人もそれに従います。「かもしれない」のために送信者レピュテーションを賭けたい人はいないからです。その結果、これらのアドレスはキャンペーンから外され、そのまま忘れられます。
B2Bのリストでは、それが連絡先のおよそ30%にあたります。大企業が多いリストでは、さらに多くなります。お金をかけて連絡先を集め、さらにお金をかけて検証したのに、結果は「わからない」だったことになります。
ゲートウェイに対応したチェックは何が違うのか
簡単に言うと、ゲートウェイが答えられない質問をやめて、答えられる別の質問をします。
ゲートウェイは何も返さないわけではありません。製品、設定、個々のアドレスによって、一定のパターンで動作します。最終的にゲートウェイが転送するアドレスと、最終的に拒否するアドレスでは、応答のタイミングが違います。エラーコードとその正確な文言は、ベンダーやバージョンによって違います。多くの検証ツールが応答を待つのをやめる時点より後で、拒否を返すゲートウェイもあります。何を比べればよいかを知っていれば、同じドメインの実在するメールボックスとランダムな文字列とで、動作が違うゲートウェイもあります。
こうしたシグナルを読むには、まずゲートウェイの種類を特定し、汎用のチェックではなくその製品用に作ったチェックを適用します。ゲートウェイへの対応範囲が通常数字で示されるのはこのためです。Giggal.aiは15種類を検出します。Proofpoint、Mimecast、Barracudaもその中に含まれます。これに取り組んでいる他のツールが挙げるのは3種類か5種類です。一つも挙げていない検証ツールは、ほぼ確実に汎用の結果を返し、それにriskyのラベルを付けています。
限界についても正直にお伝えします。これは観察された動作からの推定で、宛先の一覧を調べるものではありません。そのため完全ではなく、誠実なベンダーなら完全だとは言いません。確実にできるのは、使えなかった大きなグループを、大部分が使えるグループに変えることです。これは完璧さとは違う、控えめな主張です。
リストのどれだけが影響を受けているかを調べる
ゲートウェイが原因かどうかを確かめるのに、ツールは必要ありません。必要なのは、リストにあるドメインのMXレコードです。
すべてのアドレスからドメイン部分を取り出し、重複を除きます。そしてそれぞれのMXレコードを調べます。Proofpointの背後にあるドメインは、pphostedまたはppe-hostedを含むホスト名を指しています。Mimecastのドメインはmimecast.comのホストを指し、通常は地域コードが付いています。Barracudaはbarracudanetworks.com、Ciscoはiphmx.comとして表示されます。Microsoft 365とGoogle Workspaceのドメインは、それぞれoutlook.comとgoogle.comのホストを指します。これらはゲートウェイではありません。ただし、キャッチオールとして設定されている場合はあります。
この一覧を、検証ツールが判定をあきらめたアドレスと突き合わせます。重なりが大きければ、原因はゲートウェイです。同じツールを何度実行し直しても、結果は変わりません。
このためのツールの選び方
これに対応できる検証ツールとできないツールは、三つの質問で見分けられます。
検出するゲートウェイの名前を挙げているか。ここで本当に取り組んでいるベンダーは、一覧か、少なくとも数を公開しています。それが販売している機能そのものだからです。製品名を挙げずに「高度な検出」とだけ書いている場合、たいていは検出であって判定ではありません。つまり、ゲートウェイがあることはわかっても、メールボックスが実在するかはわからないということです。
返すのは有効か無効か、それともラベルか。Mimecastの背後にあるアドレスで、出力がどうなるかを具体的に聞いてください。答えが「riskyのフラグと信頼度スコア」であれば、少し良くなったラベルを買ったにすぎません。
追加の処理が必要なアドレスで、料金はいくらか。ゲートウェイやキャッチオールの判定は、ベンダーにとって処理コストが高いため、多くは別の料金にしています。通常のクレジットの数倍を請求するベンダーもあります。別枠の小さな利用枠から差し引き、通常の枠より先に使い切るベンダーもあります。どちらも不当ではありませんが、大企業ドメインが40%のリストをアップロードする前に知っておくべきです。Giggal.aiはすべての検証を、1アドレスにつき一律1クレジットで請求します。差し引くのは、他のすべてと同じ残高からです。
実際の進め方
まず、今使っているツールでリストを検証し、書き出したファイルを保存します。risky、unknown、accept-allとして返ってきた行をすべて取り出します。それらのドメインのMXレコードを確認し、単なるキャッチオールではなくゲートウェイであるものがいくつあるかを調べます。次に、そのグループだけを、これに対応したツールで検証します。そして二つの書き出しを並べて比べます。
大事なのはこの比較です。当社を含め、この分野のどのベンダーも、料金ページでは似たような精度をうたっています。意味のある数字は一つだけです。使えないとされていた自社の連絡先のうち、いくつが使えるとわかったか。そして有効と判定されたアドレスが、実際に送信したときにメールを受け取ったかどうかです。
試してみたい場合、Giggal.aiではクレジットカードなしで1,000クレジットを無料で使えます。このクレジットは1アドレスずつの確認に限らず、一括アップロードにも使えます。このテストで意味のある結果を得るには、それが唯一の方法です。キャッチオールとアクセプトオール（accept-all）のドメインを検証する方法や、SEGの検証方法（英語）について、さらに詳しく読むこともできます。