メールセキュリティ強化策
なりすましメールを防止する
送信ドメイン認証 その1
情報セキュリティG 新井 全勝
はじめに
送信ドメイン認証は最近注目されている技術です。
広義の迷惑メールに対して、従来は「注意せよ」「気をつけよ」といった精神論的な対策しか講じられませんでした。これを技術的手法によって自動的に摘出・処置し、可視化する仕組みへと昇華させたのが、送信ドメイン認証技術です。その概略をご紹介します。
この技術は独自ドメインのメールを所有する会社などのメール責任者には必要な知識・技術です。
迷惑メールの概況
『迷惑メール白書2022–2024』によれば、2023年度の日本国内における迷惑メールの状況は、2018年度までの減少傾向を経て、現在は横ばいで推移しています。具体的には、国内ISP（Internet service provider）が取り扱う国内着信メールのうち、迷惑メールの占める割合は、2023年3月時点では、国内着信メールの約39％が迷惑メールと判定されており、前年同月比で3ポイント増加しています。ただし、2019年4月時点と比較すると、依然として低い水準にあります。
しかし、迷惑メールの「被害」は拡大し「質」は悪化しています。一通の迷惑メールが連鎖的に新たな迷惑メールを生み出す構造が指摘されており、単なるスパムではなく、社会的リスクの温床となりつつあります。
なりすましメールの構造と迷惑メールとの関係性
送信元メールアドレスを偽装し、あたかも正規の企業や知人からのメールであるかのように見せかけることで、受信者の判断力を試す。これは、技術的な偽装であると同時に、社会的な欺瞞でもあります。
総務省やJPCERTの報告によれば、なりすまし型の迷惑メールは年々増加傾向にあり、特にフィッシング詐欺やマルウェア拡散の温床となっています。
迷惑メールの中でも、特に「なりすまし」は、単なるスパムを超えて、信頼の構造を破壊する行為として位置づけられます。
このような状況に対し、技術的な対策として注目されているのが、送信ドメイン認証技術です。
Googleのメール送信者ガイドライン
グーグルは、Gmailのメール送信者ガイドラインを2023年10月に発表し、2024年2月に改訂案を発表し、2024年2月からガイドラインに沿った運用を始めました。
このガイドラインの主要な技術が送信ドメイン認証です。多くの送信者を抱えるグーグルが先導したことの効果は大きく、yahoo、Microsoft、Appleなどが追随し、業界の事実上の標準となりつつあります。
以下で、そのガイドラインに沿って、①送信ドメイン認証の要素、②メール送信者の分類、③メール送信者別モデル構成、④送信ドメイン認証における認証後のタスクと流れ、⑤メール管理者の役割について説明します。
送信ドメイン認証の要素
メールの送信者から発信されたメールは、ドメイン（exam1.com）の送信サーバ、複数の中継サーバ、ドメイン（exam9.com）の受信サーバを経由して受信者に渡されます。
インターネット内では、メールアドレス 注1）は使用されず、パソコン、スマホ、サーバなどの機器に付けられた識別番号IPアドレス 注2）によって機器に接続されます。
送信ドメイン認証では、送信者から発信されたメールが、受信サーバに届いたときに本来のものか否かを検証します。
インターネットの規格に定められたSPF、DKIM、DMARCという3つの技術を組み合わせた認証・管理モデルで、それぞれ異なる技術的アプローチを採用していますが、いずれも「送信元メールアドレスのドメイン」を認証の核とする点で共通しており、これらを総称して送信ドメイン認証と呼びます。
SPF（Sender Policy Framework）
役割は、受信サーバにおいて、送信元IPアドレスを使用して送信サーバの真正性を認証することです。
- 認証に使う送信サーバのIPアドレスは、事前にその送信サーバに対応するDNS 注2）に登録しておく。
- 受信サーバに配置されるSPFは、メールの受信時、送信元サーバのIPアドレスと送信元サーバに対応するDNSから取得したIPアドレスとを照合し、受信したメールは本来の送信サーバ（ドメインexam1.com）から送られたメールであることを検証する。
DKIM（DomainKeys Identified Mail）
役割は、受信サーバに置いて、電子署名とその暗号化によって受信メールの真正性を認証することである。
- 受信メールのヘッダや本文に付加される電子署名などの復号に使用する公開鍵は、送信サーバに対応するDNSに事前に登録しておく。
- 送信サーバは、送信者から受信したメールに、電子署名を作成し秘密鍵で暗号化し付加して送信する。
- 受信サーバに配置されるDKIMは、メールの受信時、送信元サーバに対応するDNSから取得した公開鍵で電子署名を復号し、メール本文と照合し改ざんされていないこと、すなわち本来の送信者が発信したメールであることを検証する。
DMARC（Domain-based Message Authentication, Reporting and Conformance）
SPF/DKIMの認証結果と送信ドメインのヘッダ間整合性認証結果に基づき、総合的最終的な認証判定を行う。また、認証不合格メールの処置や集約レポートの報告を行う。
詳細は後述する「送信ドメイン認証における認証後のタスクとその流れ」のDMARCのタスクを参照してください。
注1） メールアドレス：アカウント名とドメイン名を「＠」で連接したもので、<アカウント名>＠<ドメイン名>の形式をしている。人間向けの名称で憶えやすいという特徴がある。例：a＠exam1.com
注2） IPアドレス：インターネットに接続されたパソコン、スマホなどの機器を識別するための番号。住所アドレスに喩えられる。
注3） DNS（Domain Name System）サーバ: インターネットの世界（サイバースペース）では、メールアドレスやURLで対象にアクセスするのではなくIPアドレスに基づいて機器に接続する。
DNSは、メールアドレスやURLのドメイン名とIPアドレスの対を管理し、メールアドレスやURLという名称をIPアドレスに変換する役割をもつサーバである。送信サーバ、受信サーバ、Webサーバなどのドメインに対応して設置される。
メール送信者の分類：一括送信者と一般送信者
1日あたり特定の受信ドメインに対してメールを送信する送信量を基準にして分類します。
- 一括送信者（bulk senders）：1日あたり特定の受信ドメインに対して5,000通以上のメールを送信する送信者
- 一般送信者（non-bulk senders）：それ以下の送信者
ここでいうメール送信者とは、メールを送信する個人ではなく同一ドメインのメールアドレスを使用してメールの送信をする人の全体を示します。
それ故、上記のメール送信量とは、特定の受信ドメインに対して同一ドメインから送信される1日あたりの送信量を指します。
一括送信者は、単なる大量送信者ではなく、構造的に継続的な配信を行う組織的な送信者であります。以下に代表的な例を挙げます。
- 企業のマーケティング部門やCRMシステムである。キャンペーン、請求通知、予約確認などを顧客に定期的に送信する。ただし、送信先が多数のドメインに分散するため、特定の受信ドメインに5000件以上送るケースは例外的である。
- メール配信サービスプロバイダー（ESP）である。複数の企業に代わって大量のメールを送信する中継的存在であり、送信総数は多いが、特定の受信ドメインに集中することは稀である。
- メディア、自治体、大学などの団体である。ニュースレター、イベント通知、緊急連絡などを登録者に一括配信するが、受信者が多様なドメインに分散している場合が多い。
- 大企業の社内通知システムである。勤怠、承認、セキュリティ警告などを社内ドメインに集中して送信する場合、1日あたり5000件を超えることがある。これは特定ドメインに対する集中送信の典型例である。
一括送信者は、送信ドメイン認証を通じて、なりすましやスパムのリスクを低減し、受信者の信頼性を確保する責任を負います。送信量が多いという事実は、単なる技術的要件ではなく、通知設計における倫理的判断を伴うものです。
この分類は、下記に示す技術的要件と倫理的責任の重みを配慮したものと考えられます。
メール送信者別認証・管理モデルの最小構成
メール送信者の種別によって、認証・管理モデルの最小技術的構成は異なります。
- 一般送信者は、SPF/DKIMのどちらか一方の装備が必須。DMARCは任意。
- 一括送信者は、SPF,DKIM,DMARCの装備が必須。
一般送信者は技術的構成の選択の柔軟性を与えられているが、管理上から見ると問題があります。
送信ドメイン認証における認証後のタスクと流れ
SPF/DKIMの認証後の役割はDMARCが主体となり、その内容は下記の通りです。
- SPF/DKIMは、認証結果を「pass」と「fail」などで示す。
以後は、DMARCの役割である。
- ヘッダー間整合性認証
メールには、受信時に表示される送信元メールアドレス（from）や宛アドレスアドレス（to）などを保持するメールヘッダ、SPFやDKIMが認証に使用する、それぞれのヘッダがメール本文に付加されている。
受信サーバ（DMARC）は、メールの受信時、それらのヘッダ内の送信ドメインとメールヘッダ内の送信ドメインを照合してヘッダ間の整合性を検証する。
- 総合的最終的認証判定
SPF/DKIMの認証結果とヘッダ間整合性の認証結果に基づき、メール送信者別に送信ドメイン認証としての総合的最終的な認証判定を行う。
- 一般送信者の場合、SPF認証とSPFに関わるヘッダ間整合性認証が共に「pass」であるか、またはDKIM認証とDKIMに関わるヘッダ間整合性認証が共に「pass」であるか、どちらかの条件が成立する場合、最終的に「pass」と判定される。
- 一括送信者の場合、すべての認証結果が「pass」のときのみ、最終的に「pass」と判定される。
- 判定後の処理
- 最終的に「pass」と判定されたメールは、受信サーバのメールボックス経由で受信者に渡される。
- 「fail」と判定されたメールは、事前に送信サーバに対応するDNSに登録された処置指示（ポリシーと呼ばれる）を取得し、それに従って隔離や削除などの処置が行われる。
- 集約レポートの配信
SPF/DKIM認証、ヘッダ間整合性認証、最終認証などの認証結果をIPアドレス別に集約したレポートを、事前に送信サーバに対応するDNSに登録した管理者用メールアドレスを取得しそれに配信する。
上記の最終判定条件の分化から、認証・管理モデルは構成だけでなく品質も問われていることが窺えます。これは、一括送信者のほうが、より大きなメール配信の信頼性を確保する必要があることを示している、と考えられます。
上記に基づいて一般送信者モデルを見直すと、その最小構成モデルでは、SPFまたはDKIMで認証しても認証結果の最終的判定が行えないので、受信者には正当なメールだけでなく、なりすましメールも渡ってしまいます。
また、メール送信者側に集約レポートの報告が行えないので迷惑メールの状況の把握ができず管理不能となります。目的をよく考慮してモデル要素の選択を行うことが必要と思われます。
メール管理者の役割
独自ドメインのメール管理者は、次の管理業務が必要です。
- SPF、DKIM、DMARCで使用する各種管理情報を送信サーバに対応するDNSに登録する。
- 受信サーバの管理会社から配信される集約レポートを解析し、送信ドメインの認証状況を把握し適切な処置をとることが必要である。集約レポートの解析ツールはWebサイトに掲載されており、視覚的に把握しやすい。
おわりに
本稿では、送信ドメイン認証全般について概説しました。
この技術は今後ますます普及していくものと思われます。
独自ドメインのメール管理者にとっては必要不可欠の知識・技術と考えられます。
メール使用者は、なりすまし対策としての知識として把握して安心して使える土壌を醸成していただきたいと思います。
なお、本資料の作成には、Microsoft のAIツールCopilotの支援を得ています。
次回は、SPFの構成例とDNS設定の実際について掘り下げます。