電子メールの仕組みを徹底解説｜SMTP・POP3・IMAPからSPF・DKIM・DMARCまで

電子メールの基本的な流れ

まず、メールユーザーエージェント（MUA）と呼ばれるソフトウェアを使って、デバイス上でメールの読み書きを行います。GmailやApple端末の「メール」アプリなどがその代表例です。これらのプログラムは、ユーザーが実際に操作しているときだけ動作します。

通常、MUAはメール転送エージェント（MTA）と通信します。MTAは「メールサーバー」「MXホスト」「メールエクスチェンジャ」とも呼ばれ、メールを受け取り、保存する役割を担っています。

メールは、MUAを開いて受信確認をするまで、リモート側に保存されたままになります。メールの配信はメール配信エージェント（MDA）が担当し、MDAは通常MTAに同梱されています。

メール送受信を支えるプロトコル

かつてメールは、SMTP（Simple Mail Transfer Protocol：シンプルメール転送プロトコル）を使ってメールサーバーへ送信されていました。SMTPは電子メールのための標準的な通信プロトコルです。

現在でも、Microsoft Exchangeのような独自システムやGmailのようなWebメールサービスは、内部では独自のプロトコルを使用していますが、システム外へのメッセージ転送にはSMTPを使っています（例：GmailユーザーがOutlookクライアントにメールを送る場合など）。

一方、サーバーからのメールダウンロードには、長らくPOP3（Post Office Protocol バージョン3）が使われてきました。POP3はアプリケーション層のプロトコルで、IPネットワーク経由でユーザーのアプリケーションがメールサーバー上のメールボックスにアクセスできるようにするものです。接続してメッセージを取得し、クライアントのコンピュータに保存したうえで、サーバー上のメッセージを削除または保持することができます。

POP3は、ダイヤルアップなどの一時的なインターネット接続を前提に設計されました。接続時にメールを取得し、オフライン時でもメッセージを閲覧できる仕組みです。ダイヤルアップ接続が主流だった時代には、こちらの方が広く利用されていました。

現在では、IMAP（Internet Message Access Protocol）がPOP3にほぼ取って代わっています。IMAPでは複数のクライアントが同じメールボックスを共有・管理できます。つまり、デスクトップPC、ノートPC、スマートフォンなど、どの端末からアクセスしても、すべてのメッセージが同じ整理状態で表示されます。

やがて、Webメールが両者に取って代わりました。Webメールなら、ウェブサイトにログインするだけで、場所やデバイスを選ばずにメッセージを送受信できます。ただし、使用中はインターネット接続が必要です。ウェブサイト（Gmailなど）自体がMUAとして機能する場合、SMTPやIMAPのサーバー設定を意識する必要はありません。

メールはどうやって保護されているのか？

残念ながら、メールプロトコルには当初からセキュリティ機能は組み込まれていませんでした（初期のインターネットプロトコルの多くと同様です）。サーバーは、誰からのメッセージでも受け取り、最終宛先（Toフィールドの受信者）へルーティングできる他のサーバーに中継することだけを想定していました。

当然ながら、インターネットが少数の政府機関や研究グループのものから、世界中のほとんどの人があらゆる用途に使うインフラへと拡大すると、これは大きな問題になりました。たちまちスパムメールやフィッシングメールが、今もなお続く深刻な問題となったのです。

これに対し、私たちは次の2つの方向性で対策を進めてきました。

• 暗号化：他人のメッセージを読めないようにする
• 認証：メッセージが本当に送信者本人から来たことを検証する

多くの場所で採用されているのがTLS（Transport Layer Security：SSLの後継）です。TLSは伝送中の暗号化を提供する暗号化プロトコルで、メッセージが伝送されている間は保護されます。ただし、自分のコンピュータに保存されている間など、静止状態のデータは保護されません。

TLSにより、MTA間を移動する際にメッセージが盗み見られないことは保証されます。しかし、移動中に内容が改ざんされていないことまでは検証できません。

例えば、メールが複数のメールサーバーを経由して最終目的地に届く場合、TLSによってサーバー間の通信は暗号化されますが、各サーバーはメッセージ内容を改ざんできてしまいます。この問題に対処するため生まれたのが、SPF、DKIM、DMARCです。

SPF（Sender Policy Framework）とは

SPFにより、ドメインの所有者（google.comなど）は、DNSにTXTレコードを設定し、「そのドメインからメールを送信することを許可されたサーバー」を宣言できます。

仕組み

このレコードには、許可されたデバイス（通常はIPアドレス）が列挙され、末尾は次のいずれかのオプションで終わります。

• -all：チェックに失敗した場合（メールの送信元がリストされたデバイスのいずれでもない場合）、HardFailとなります。ほとんどのメールシステムはこれらのメッセージをスパムとして扱います。
• ?all：チェックに失敗した場合、結果は中立（Neutral）です。主にテスト用であり、本番ドメインでは通常使用されません。
• ~all：チェックに失敗した場合、SoftFailとなります。メッセージは疑わしいものの、既知の悪性であるとは限りません。一部のメールシステムはスパムとして扱いますが、大多数は扱いません。

SPFヘッダーは、メッセージを処理するサーバー自身にも役立ちます。例えば、ネットワークの境界にあるサーバーは、受信メッセージが送信者のSPFレコード内のサーバーから来ているべきだと判断でき、スパムをより早く排除できます。

しかしながら、SPFにはいくつかの重大な弱点があります。

1. 処理方法を指示しない：SPFはメールサーバーにメッセージの扱い方を指示しません。つまり、SPFチェックに失敗したメッセージでも配信される可能性があります。
2. Fromアドレスを検証していない：SPFレコードは、ユーザーが目にする「From」アドレスではなく「Return-Path」（エンベロープ送信者）を検証しています。これは手紙の返送先住所のようなもので、メールを処理するサーバーに返送先を伝えます（メールヘッダー＝サーバーがメールを処理するために使う技術情報に格納されます）。
   つまり、Fromアドレスに何を入力してもSPFチェックには影響しません。実際、両方のメールアドレスは攻撃者によって比較的容易に偽装可能です。暗号化が関与していないため、SPFヘッダーを完全に信用することはできません。
3. 常に最新の維持が必要：SPFレコードは常に最新の状態に保つ必要がありますが、大規模で変化の激しい組織では運用が難しくなります。
4. 転送で破綻する：例えばgoogle.comからのメールをbob@bobsburgers.comが転送すると、エンベロープ送信者は変更されません（Fromアドレスはgoogle.comのまま）。受信メールサーバーは「google.comを名乗りながらbobsburgers.comから送られてきている」と判断し、SPFチェックに失敗します。実際にはメールはgoogle.comから来ているのに、です。

DKIM（DomainKeys Identified Mail）とは

DKIMもSPFとよく似ています。送信ドメインのDNSにTXTレコードを使う点は同じですが、さらにメッセージ自体の認証も提供します。メッセージが転送中に改ざんされていないことの検証を目的とした仕組みです。

仕組み

送信ドメインは公開鍵／秘密鍵のペアを生成し、公開鍵をドメインのDNS TXTレコードに登録します。

次に、ドメインのメールサーバー（外部境界にあるサーバー、つまりドメイン外にメールを送信するサーバー。例：gmail.comからoutlook.comへ）が、秘密鍵を使ってヘッダーを含むメッセージ本文全体の署名を生成します。署名の生成には通常、テキストのハッシュ化と暗号化が行われます。

受信側のメールサーバーは、DNS TXTレコード内の公開鍵を使って署名を復号し、メッセージ本文と関連ヘッダー（送信者のインフラ内で作成されたヘッダー。例えば、gmail.comから外部のoutlook.comへ送信される前に、複数のGmailサーバーが処理した際に付与されたヘッダーなど）をハッシュ化します。

そして、2つのハッシュ値が一致するかを確認します。一致していれば、メッセージは改ざんされておらず（送信者の秘密鍵が漏洩していない限り）、名乗る送信者から正当に送られたものと考えられます。一致しなければ、メッセージは名乗る送信者からのものではないか、転送中に他のサーバーによって改ざんされたか、あるいはその両方の可能性があります。

DKIMは「このメールは転送中に改ざんされたか、名乗る送信者からのものではないか？」という非常に限定的な問いに対しては極めて有効です。しかし、それ以上のことはできません。このテストに失敗したメールの扱い方、どのサーバーが改ざんしたのか、どんな改ざんが行われたのかまでは教えてくれません。

また、DKIMは一部のISP（インターネットサービスプロバイダ）がドメインの評判を判定する際にも使われています（大量のスパムを送っていないか、エンゲージメントは低くないか、バウンス率はどの程度か、など）。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）とは

DMARCは本質的に、SPFとDKIMの検証結果をどう扱うかについてメールサーバーに指示を出す仕組みです。独自のテストは行いませんが、SPFとDKIMが実施するチェックの処理方法をメールサーバーに伝えます。

参加しているISPは公開されたDMARCレコードを参照し、DKIMまたはSPFの検証失敗への対処方法を決定します。例えば、なりすまされやすいブランドは、「DKIMまたはSPFに失敗したメッセージは破棄せよ」というDMARCレコードを公開するかもしれません。

多くの場合、ISPはドメイン管理者にアクティビティレポートも送信します。そこにはメールの送信元や、DKIM/SPFに合格したか失敗したかが含まれます。これにより、自分のドメインになりすます人物や、メッセージを改ざんする人物を把握できるようになります。

DMARCを実装するには、目的に応じたDMARCレコードを作成する必要があります。メールトラフィックを監視してすべての送信ソースを把握する段階から、DKIMまたはSPFに失敗したメールの拒否などの対応を依頼する段階まで、段階的に強化していくのが一般的です。

まとめ

これらのセキュリティ対策のどれひとつとして完璧なものはありませんが、組み合わせることで、世界中のメールシステムのセキュリティ向上に大きく貢献しています。

これらの対策を採用する組織が増えるほど（オープンソース実装を使うにせよ、商用製品に投資するにせよ）、すべての人にとってより安全な環境が実現します。そもそも、プロトコルや製品の開発後に後付けされるセキュリティは、最初から組み込まれたセキュリティよりも、コストが高く、効果が低く、実装も難しいものです。

しかし、現代のインターネットが依存しているプロトコルの大部分は、初期のインターネット――少数の愛好家、科学者、政府関係者のためのもの――向けに設計されました。建物、スマートデバイス、公共交通機関、さらには原子力発電所（！）まで動かす世界的ネットワーク向けではなかったのです。

したがって、インターネットが拡大し続ける限り、私たちが依存するシステムを守るために、継続的な適応と新しいセキュリティ手法の開発が求められます。