【ITニュース解説】Return-Path and From are different fields and receivers read both

メールの送信は、私たちが普段目にしている以上に、複雑な仕組みの上で成り立っている。特に、メールが確実に相手に届くようにするためには、単に宛先と本文を設定するだけでは不十分だ。メールの信頼性を高め、スパムとして扱われないようにするために、裏側で機能している重要な仕組みがある。それは、メールが持つ二つの異なる「送信元情報」と、それらを検証する認証技術だ。

私たちがメールソフトで見る「差出人（From）」は、メッセージのヘッダー情報に含まれるもので、ユーザーが直接目にするメールの送信元を示す。例えば「From: hello@example.com」とあれば、私たちはそのメールがexample.comから送られてきたものだと認識する。しかし、メールが実際にインターネットの経路を辿って相手のサーバーに届く際には、これとは別の「送信元情報」が使われる。これは「エンベロープセンダー」と呼ばれ、郵便で例えるなら封筒に書かれた差出人のようなものだ。このエンベロープセンダーは、SMTP（Simple Mail Transfer Protocol）というメール送信プロトコルにおいて「MAIL FROM」コマンドで指定され、メールが受信サーバーに届くと「Return-Path」というヘッダーに記録される。

なぜこのように二つの異なる送信元情報が存在するのだろうか。それは、それぞれの情報が異なる役割を担っているためだ。Fromヘッダーは受信者が誰からメールが来たのかを識別するための情報である一方、エンベロープセンダー（Return-Path）は、主に技術的な目的、特にメールが相手に届かなかった場合の「バウンスメール（不達通知）」の送り先として、また、後述するSPFといったセキュリティ認証のチェック対象として利用される。

この二つの送信元情報が、それぞれの役割に応じて正しく機能しているかを検証するために、SPF、DKIM、DMARCという三つの重要なメール認証技術が利用されている。

まず、**SPF（Sender Policy Framework）**について説明する。SPFは、メールを送信したサーバーのIPアドレスが、そのメールのエンベロープセンダー（Return-Path）のドメインによって許可されているかどうかを検証する仕組みだ。例えば、エンベロープセンダーがbounce@provider.comであれば、SPFはそのprovider.comというドメインが、実際にメールを送ってきたIPアドレスからの送信を許可しているかどうかを確認する。これにより、第三者がprovider.comを偽ってメールを送る「なりすまし」を防ぐ。

次に、**DKIM（DomainKeys Identified Mail）**だ。DKIMは、メールのヘッダーや本文の一部にデジタル署名を付与することで、メールが送信中に改ざんされていないこと、そして指定されたドメインの所有者によって送られたものであることを証明する。この署名にはd=というパラメータがあり、これがDKIMの認証対象となるドメインを示す。受信サーバーは、このd=ドメインのDNSレコードに公開されている公開鍵を使って署名を検証する。

そして、これら二つの技術をさらに発展させたのが**DMARC（Domain-based Message Authentication, Reporting & Conformance）**だ。DMARCは、SPFとDKIMの検証結果に基づき、メールのFromヘッダーのドメインと、SPFまたはDKIMで認証されたドメインのどちらか一方が「アライン（一致）」していることを要求する。もしこのアラインメントが満たされない場合、受信サーバーはDMARCポリシーに従って、メールを拒否したり、隔離（スパムフォルダへ移動）したり、単にレポートを生成するなどの処理を行う。この「アラインメント」が、メールがスパムとして扱われるかどうかを分ける重要なポイントとなる。

ここで、よくあるメール設定の誤りについて考えてみよう。例えば、あなたがexample.comという独自のドメインを持っていて、メールサービスプロバイダ（例: provider.com）を経由してメールを送信していると仮定する。このとき、Fromヘッダーをhello@example.comと設定し、一方でエンベロープセンダー（Return-Path）がプロバイダの管理するbounce@provider.comになっているケースが頻繁に見られる。

この状況では、SPFはエンベロープセンダーであるprovider.comに対して行われるため、プロバイダが正しく設定していればSPF認証は「pass」するだろう。同様に、DKIMもprovider.comで署名されていれば「pass」する可能性がある。しかし、DMARCのチェックでは問題が発生する。Fromヘッダーのドメインはexample.comであるのに対し、SPFとDKIMの認証対象ドメインはprovider.comだ。これらが「アライン」しないため、DMARC認証は「fail」となり、結果としてメールは受信サーバーによってスパムと判断されやすくなってしまう。見た目上はエラーが出ていなくても、メールが届かない、スパムフォルダに入ってしまうといった問題が起こる原因の多くがここにある。

この問題を解決するためには、いくつかの方法がある。一つは、自分のドメイン（example.com）でDKIM署名を行い、Return-Pathも自分で管理できるsubdomain.example.comのようなサブドメインを使用する方法だ。こうすれば、Fromヘッダー、DKIM署名ドメイン、Return-Pathドメインのすべてがexample.comに関連付けられ、DMARCのアラインメント条件を満たしやすくなる。もう一つは、Fromヘッダーもエンベロープセンダーも、すべてプロバイダのドメイン（provider.com）で統一してしまう方法だ。この場合、送信元がexample.comに見えなくなるというトレードオフがあるが、認証の複雑さを避けることができる。

また、エンベロープセンダー（Return-Path）は、メール運用において極めて重要な役割を担っている。先ほども触れたように、メールが何らかの理由で相手に届かなかった場合、その不達通知であるバウンスメールは、Fromヘッダーのアドレスではなく、このReturn-Pathに送られてくる。もしReturn-Pathが「ブラックホール」、つまり実際には存在しない、あるいは誰も確認しないアドレスに設定されていると、あなたは送ったメールが相手に届いていないことに永遠に気づかない。その結果、存在しないアドレスに対してメールを送り続け、無駄なリソースを消費するだけでなく、送信元としてのあなたの信頼性を損なう可能性もある。そのため、Return-Pathには、実際にバウンスメールを受信し、それを適切に処理できる有効なメールボックスを設定するか、サービスプロバイダがバウンスを処理し、レポートを返してくれる仕組みを利用することが不可欠だ。

これらのメール認証設定が正しく機能しているかを確認するには、簡単なテストを行うとよい。あなたが管理しているGmailアドレスにテストメールを送信し、そのメールの「オリジナル」を表示する機能を使うのだ。Gmailでは、受信したメールの詳細なヘッダー情報を確認できる。特に「Authentication-Results」というセクションに注目してほしい。ここでSPFとDKIMの両方が「pass」と表示され、さらに、その認証に使われたドメインが、あなたがFromヘッダーに設定したドメインと一致していることを確認する。もしここでDMARCが「fail」となっている場合は、設定に何らかの問題がある可能性が高い。

このように、メール送信の背後には、ユーザーが見る表面的な情報だけでなく、その信頼性と到達性を保証するための複雑な認証の仕組みが働いている。システムエンジニアとしてメールシステムに関わる際には、これらのエンベロープセンダー、Fromヘッダー、そしてSPF、DKIM、DMARCといった認証技術の役割と相互関係を深く理解することが、メールの確実な配信とスパム対策にとって非常に重要となる。これらを適切に設定・管理することで、メールが意図した通りに受信者に届き、ビジネスコミュニケーションが円滑に進む基盤を築くことができる。