エンベロープFromとは？ヘッダーFromやエンベロープToとの違いや確認方法を解説

メールを送受信する際には、見えない部分で多くの情報がやり取りされています。その中でも特に重要なのが、エンベロープとヘッダーの情報です。

これらはメールの送信先や送信元を決定する上で欠かせない要素であり、それぞれには「From」と「To」の情報が含まれています。メールを開くと送り主（From）が表示されますが、記載されている内容は送信元と同じとは限りません。メールソフトでメッセージを作成すると自身のアドレスが自動的に差出人として登録されるため、送信元と送り主を同じ意味だと考える方が多いようですが、実は違うのです。

この仕組みを理解するためには、エンベロープとヘッダーの役割について知る必要があります。本記事では、エンベロープとヘッダーが分かれている理由と、そのメリット・デメリットについても触れ、エンベロープの情報がどこで設定されるのか、そして実際にエンベロープFromの確認方法について、GmailやOutlookを例にして紹介します。

メールシステムの裏側に隠された仕組みを理解することは、セキュリティ上の理由からも非常に重要です。不正なメールの送信元を見破る手がかりとなることもありますので、この機会にその仕組みをしっかりと把握しておきましょう。

エンベロープとヘッダー

エンベロープとは、メールの送り主などの情報が記されたものです。ヘッダーにも同じような情報が記載されていますが、異なる点もあります。この、エンベロープとヘッダーに書かれた情報が一致しているとは限らないため、送信元と送り主が異なるケースが発生するのです。

メール送受信の仕組み

エンベロープとヘッダーについて確認する前に、メールの構成について整理しておきましょう。

メールの送受信は、サーバーを経由し、SMTP（Simple Mail Transfer Protocol）というプロトコルを使用してメール通信を行います。

メールを郵便の仕組みに例えてみましょう。メールが手紙、サーバーが郵便局、SMTPが配達員です。手紙（メール）を作成し送信すると、郵便局（サーバー）にて選別され、配達員（SMTP）によって宛先に届く仕組みです。

エンベロープの役割

エンベロープは、メールがインターネットを通じて正確に送受信されるために必要な情報を含みます。物理的な手紙で言うところの「実際の封筒」に相当し、メールの配送に関わる最も基本的な情報、すなわち送信元と送信先のアドレス（SMTPサーバーが使用する）が含まれています。

このエンベロープ情報は、メールサーバー間でのメールの送受信（ルーティング）に使用されますが、通常、最終的な受信者には直接表示されません。

エンベロープの主な役割は以下の通りです。

• メールの配送先と送信元の指定
• メールサーバー間でのメールのルーティング
• スパムフィルタリングやセキュリティポリシー適用の基礎情報提供

ヘッダー

ヘッダーは、メールの内容（本文）よりも前に配置される、メールに関するメタデータを含む部分です。ヘッダーには、送信者（From）、受信者（To）、メールの件名（Subject）、送信日時（Date）など、メールの送受信に関する詳細情報が含まれています。

これらの情報は、最終的な受信者に対してメールのコンテキストを提供するために使用され、Gmail、Outlookなどのメールクライアントによって受信者に表示されます。

ヘッダーの主な役割は以下の通りです。

• メールの内容に関するメタデータの提供
• 受信者がメールの文脈を理解するための情報提供
• メールの追跡や管理に関する情報提供（例：Message-ID）

エンベロープとヘッダーの違い

上述した郵便の例で考えると、エンベロープは手紙の封筒、ヘッダーは封筒の中の便箋に例えられます。

エンベロープに記される情報は、メール送信で使用する宛先と送り主情報です。便箋に住所と送り主名を書くことをイメージするとわかりやすいでしょう。対してヘッダーには、宛先と送り主情報に加えて件名や日付などを含む多様な内容が記載されます。

ここで、実際に手紙を書くシーンをイメージすると分かりやすいです。

• エンベロープ（封筒）に書かれた送信元の情報＝封筒の裏の差出人の情報
• 中身のヘッダー（便箋）に書かれた送り主の情報＝手紙の末尾の「〇〇より」の部分

このふたつの情報が一致していなかったとしても、手紙は届けられます。これはメールでも同様で、これが送信元と送り主が異なるケースがうまれる原因です。

エンベロープとヘッダそれぞれのFromとToの違い

エンベロープは封筒、ヘッダーは封筒の中の便箋と前述しました。さらにエンベロープとヘッダーにはそれぞれFrom（送り主）とTo（宛先）があります。それぞれの役割は以下の通りです。

• エンベロープFrom（封筒の送り主）
• エンベロープTo（封筒の宛先）
• ヘッダーFrom（便箋の送り主）
• ヘッダーTo（便箋の宛先）

 実際に手紙を郵送する場合と同様、エンベロープ（封筒）情報が正しく記載されていないとエラーが発生し、相手には届きません。そのため、エンベロープの情報に記載されている情報が本来のメール送り主・宛先といえるでしょう。

エンベロープの情報は簡単には書き換えができません。しかし、ヘッダーの情報については記載内容の変更が可能です。また、エンベロープ情報とヘッダー情報の内容が異なっている場合でも、メールの送信はできます。郵便物を郵送する時に封筒と便箋に記されている情報が一致しているかは重要ではない（確認しない）ためです。

それぞれの概要を以下で簡単に解説します。

エンベロープFrom（封筒の送り主）

エンベロープFromは、メールが実際に送信された元のアドレスを指します。

これはSMTP（Simple Mail Transfer Protocol）セッション中にメールサーバーに通知される情報であり、メールの実際の配送プロセスにおいて「誰がこのメールを送ったか」を示します。

エンベロープFromは、メールが配送される過程で使用され、通常、最終的な受信者には表示されません。主にメールの配送とルーティングに使用され、スパムフィルタリングや送信者の認証にも重要な役割を果たします。

エンベロープTo（封筒の宛先）

エンベロープToは、メールが実際に送られるべき最終的な受信者のアドレスを指します。

エンベロープFrom同様にSMTPセッションでメールサーバーに伝えられ、メールの配送プロセスにおいて使用されます。エンベロープToによって、メールがどの受信者に届けられるべきかが決定されます。

エンベロープToはメールの正確な配送先を指定し、メールが適切な受信箱に届けられるようにするために使用されます。

ヘッダーFrom（便箋の送り主）

ヘッダーFromは、メールの送信者を示す情報です。

この情報はメールクライアントやウェブインターフェースに表示され、最終的な受信者が「誰からのメールか」を識別できるようにします。ヘッダーFromは、メールの形式や文脈に関連する情報を提供します。

ヘッダーFromは受信者にメールの送信元を明示し、メールの文脈や信頼性を提供するために使用されます。

ヘッダーTo（便箋の宛先）

ヘッダーToは、メールの受信者を示す情報です。

この情報はメールの本文の前にあるヘッダーセクションに含まれ、メールが誰宛てに送られたかを受信者に示します。ヘッダーToは、メールの受信者が自分自身や他の受信者を識別できるようにするために重要です。

ヘッダーToは受信者にメールが誰宛てであるかを明示し、メールの対象となる受信者グループを識別するために使用されます。

エンベロープとヘッダーに分かれているメリット・デメリット

エンベロープとヘッダーを分けることに、どんな意義があるのでしょうか。ここからは、エンベロープとヘッダーに記載する情報が分かれているメリットをご紹介します。また、分かれているために起こるデメリットについても確認しておきましょう。

メリット

メールを送受信するうえで、さまざまなメリットがあることからエンベロープとヘッダー分けています。ここでは、From（送り主）とTO（宛先）それぞれの視点からみていきましょう。

柔軟なメール処理

転送されたメールであっても、正式な送り主からのメールとして送信することが可能です。

メールの転送機能を使用すると、転送操作を行う差出人が、エンベロープFrom（封筒の送り主名）に設定されてしまいます。この時、転送前の送り主情報をヘッダーFrom（便箋の送り主名）に設定しなおすことで、問題を回避できます。

また、大量のメール配信を行うために外部のメール送信サービスを利用する場合にも便利です。この場合、何も対策を行わないと配信を行うサービス会社が送り主になってしまいます。これでは、どこからメールが届いたのかわからず、顧客を混乱させてしまうでしょう。

メール配信時に、顧客に表示したいアドレスをヘッダーFromに設定しなおすだけで誰から送られたものなのかわかりやすく表示できます。

Bcc機能が使用できる

Toが分かれているため、Bcc（Blind Carbon Copy）機能を使用可能です。この機能はヘッダーToの宛先を非表示にし、エンベロープToの情報のみ宛先編集できる機能です。

この機能を使用すると、メール受信者側は、Bccに指定されている他のメールアドレスを見ることはできません。つまり、公表したくないメールアドレスを非表示にした状態で複数の宛先にメールを送信できるのです。

この特性を生かし、多くの顧客に対してビジネスメールを送る時などに利用されます。

セキュリティとプライバシーの向上

エンベロープとヘッダーの分離は、SPFやDKIMなどのセキュリティメカニズムの実装を容易にします。

これらは主にエンベロープFromを使用して送信者を認証し、フィッシングやスパムを防ぎます。

デメリット

エンベロープとヘッダーに分かれているのは上記のようなメリットがあるからです。しかし、知っておくべきデメリットもありますので紹介します。

なりすましメール

エンベロープとヘッダーに分かれていることで起こる代表的な問題が「なりすまし」です。なりすましとは、有名企業などの名称をかたり相手を信用させる詐称行為です。

なりすましメールは、エンベロープFromとヘッダーFromが一致していなくてもメールを送信できる仕組みを悪用しています。ヘッダーFromに偽りの情報を記載し、相手を信用させメールを開封させます。開封したメールから誘導してフィッシング詐欺をはたらいたり、標的型攻撃を企んだりする悪徳業者が存在するのです。

管理の難しさ

エンベロープとヘッダーの情報を正確に保つためには、適切なメールポリシーとセキュリティ対策が必要です。不適切な管理は、送信エラーやスパムフィルタリングシステムによる誤検出を引き起こす可能性があります。そのため、専門知識をもった人材やメール配信関連のサービスを使うなどの対応が必要となります。

エンベロープとヘッダーが分かれていることには、このようなデメリットもあることを理解しなければなりません。被害に遭わないためには、送信ドメイン認証技術の活用など、対策について把握しておく必要があります。

エンベロープの情報はどこで設定される？

メールは、本文に加え、ヘッダーTo（宛先）とヘッダーFrom（送り主）を設定してからメールを送信します。では、エンベロープToとエンベロープFromはどこで設定するのでしょうか。

エンベロープの情報はMTA（Message Transfer Agent）がメールサーバー上で自動的に設定しています。このMTAとは、メールを受信用サーバーから送信用のサーバーへ転送する働きをします。転送作業を行う時に、エンベロープの情報が設定される仕組みです。このMTAとSMTPが連携して、メールを送信します。

通常の場合、メール作成者がエンベロープの情報を編集することはできません。一般的なメールサーバーのプログラムは、ヘッダーの情報をそのままエンベロープ情報として使用します。しかし、使用しているプログラムによってはヘッダーの情報を使用しないケースもあるようです。

エンベロープFromと送信ドメイン認証（SPF・DMARC）の関係

エンベロープFromは、単なる「封筒の送り主情報」ではありません。送信ドメイン認証の技術的な起点となる、メール配信の要です。

2024年2月のGmail送信者ガイドライン強化、2025年5月のOutlook新メール送信要件により、送信ドメイン認証は大量配信者にとって必須要件となりました。エンベロープFromの正しい理解と設定が、到達率を左右する時代です。

SPF認証はエンベロープFromを検証する

SPF（Sender Policy Framework）は、メールの送信元IPアドレスがドメイン所有者から許可されたものかを検証する仕組みです。このとき検証対象となるドメインは、ヘッダーFromではなくエンベロープFromです。

受信サーバーは、エンベロープFromに記載されたドメインのDNSを参照し、SPFレコードに登録されたIPアドレスと実際の送信元IPアドレスを照合します。この照合が一致しない場合、なりすましと判定されてスパムフォルダに振り分けられる可能性が高まります。SPF認証の仕組みを深く知りたい方は、以下の関連記事も参考にしてください。

DMARCアライメントとエンベロープFromの関係

DMARC（Domain-based Message Authentication, Reporting and Conformance）は、SPFとDKIMの認証結果を統合し、なりすまし対策を強化する仕組みです。DMARCの核となる概念が「アライメント」。

DMARCアライメントとは、エンベロープFromのドメインとヘッダーFromのドメインが一致しているかを検証する仕組みです。両者のドメインが一致していれば「DMARCパス」、不一致なら「DMARC失敗」となります。

DMARCが失敗したメールは、送信ドメイン側で設定したポリシー（none/quarantine/reject）に従って処理されます。rejectポリシーの場合、受信者に届かずブロックされる仕組みです。アライメントの詳細やポリシー設定については、以下の記事で体系的に解説しています。

2024年以降のGmail・Outlookガイドラインでの必須化

2024年2月、Googleは1日5,000通以上を送信する送信者に対して、SPF・DKIM・DMARCの設定を必須化しました。これに続き、Microsoftも2025年5月から同等の要件をOutlook/Hotmail向けに適用しています。

両社のガイドラインに共通するのは、エンベロープFromとヘッダーFromのアライメント要件です。両者のドメインが適切に揃っていなければ、大量配信メールは受信者に届かない、もしくは迷惑メールフォルダに振り分けられます。

メルマガ配信やシステム通知メールを運用している企業にとって、エンベロープFromの適切な管理は事業継続のための必須事項です。

エンベロープFromの確認方法

エンベロープの情報を編集することはできません。しかし、エンベロープFromを確かめることは可能です。これは不審なメールが届いた際のチェックにも役立つでしょう。

エンベロープFromはReturn-Pathで確認

エンベロープFromの情報は、メールのヘッダー内の「Return-Path」を通じて確認することができます。

SMTPプロセスを通じてメールが送信されると、エンベロープFromの情報は最終的に受信サーバーによって「Return-Path」として記録されます。これにより、メールがどこから送られてきたのか、そして配送エラーが発生した際にどこへエラーメッセージを返すべきかを示すための重要な手がかりとなります。

確認方法は使用しているメーラーによって異なります。ここでは、GmaiとOutlookの確認方法をご紹介します。 

Gmailの場合

Gmailの確認方法は以下の通りです。

1. エンベロープFromを確認したいメッセージを開く
2. 右上の三点リーダーボタンをクリックし「メッセージのソースを表示」をクリック
3. 右下のクリップボードにコピーをクリック（ソースのコピーが可能）
4. こちらのサイトにアクセス（Google Admin Toolbox Messageheader）
5. 「ここにメールヘッダーを貼り付けます」と記載されている所にソースのコピーを貼り付け
6. 画面下部の「上記のヘッダーを分析」をクリック
7. 分析結果の中のMessageldに表示されているアドレスがエンベロープFrom

Outlookの場合

Outlookの確認方法は以下の通りです。

1. エンベロープFromを確認したいメッセージを開く
2. メール本文表示後、左上のファイルをクリック
3. プロパティをクリック
4. プロパティ下部メールヘッダー枠内のReturn-PathがエンベロープFromとなる

Thunderbirdの場合

ThunderbirdでエンベロープFromを確認する手順は以下の通りです。

1. 確認したいメッセージを開く
2. メニューの「表示」→「メッセージのソース」をクリック（またはCtrl+U）
3. 表示されたソース内で「Return-Path:」の行を探す
4. Return-Pathに記載されたアドレスがエンベロープFrom

ショートカットキー（Ctrl+U）で素早くソース表示できる点がThunderbirdの利点です。

Yahoo!メールの場合

Yahoo!メールでの確認手順は以下の通りです。

1. 確認したいメッセージを開く
2. メール右上の「…」（その他）メニューをクリック
3. 「メールのソース（ヘッダー）を表示」を選択
4. 別ウィンドウで開いたソース内の「Return-Path:」行を確認

Yahoo!メールはWebインターフェースのみの提供のため、ブラウザから直接確認する形になります。

iCloudメールの場合

iCloudメール（iCloud.com）での確認手順は以下の通りです。

1. iCloud.comにログインし、該当メッセージを開く
2. メールヘッダーの「詳細」や「ソースを表示」オプションを選択
3. 表示された全ヘッダー情報内で「Return-Path:」を確認

iCloudメールはmacOSのメールアプリからも確認可能です。この場合は「表示」→「メッセージ」→「すべてのヘッダ」を選択すると、全ヘッダー情報が表示されます。

いずれのメーラーでも、Return-PathがエンベロープFromの確認ポイントである点は共通です。不審なメールを受信した際は、必ずRetrun-Pathの内容をチェックする習慣をつけておきましょう。

エンベロープFromに関するよくあるトラブルと対処法

エンベロープFromの仕組みを理解していても、実務では設定不備によるトラブルが頻発します。ここでは典型的な3つのトラブルと、その対処法を整理します。

エンベロープFromとヘッダーFromの不一致でスパム判定される

最も多いトラブルが、エンベロープFromとヘッダーFromのドメインが一致せず、DMARC失敗によりスパム判定されるケースです。

外部のメール配信サービスを利用する際、設定を間違えるとエンベロープFromに配信サービス側のドメインが設定される一方、ヘッダーFromには自社ドメインが残るという状態になります。この不一致がDMARCアライメント失敗を引き起こす原因です。

対処法は、利用するメール配信サービスで「カスタムドメイン」や「送信ドメイン認証」の設定を行うことです。自社ドメインのDNSにSPFレコードとDKIM署名用のTXTレコードを追加し、エンベロープFromとヘッダーFromを同じドメインに揃えます。

Return-Pathが設定されずバウンスメールが追えない

エンベロープFromの情報は、受信側に「Return-Path」として記録されます。ここに適切なアドレスが設定されていない場合、バウンスメール（配信エラー）の受け取り先が不明となり、配信不能アドレスの管理ができなくなります。

自社サーバーからメール送信している場合、MTA（Postfixやsendmail等）の設定でReturn-Pathを明示することが必要です。外部サービスを利用する場合は、サービス側のバウンス処理機能を活用することで、エンジニア側での個別対応が不要になります。

Return-Pathの仕組みや確認方法の詳細は、以下の関連記事で解説しています。

外部サービス経由送信時のエンベロープFrom設定

SendGrid・Amazon SES・blastengineといった外部メール配信サービスを利用する場合、エンベロープFromの設定方法はサービスごとに異なります。一般的な設定パターンは以下の3つに分かれます。

• サービス指定のドメインをエンベロープFromに使用し、ヘッダーFromのみ自社ドメインにする方法
• 自社ドメインを「委任ドメイン」として登録し、エンベロープFromとヘッダーFromを揃える方法
• 自社サブドメインを切り出し、配信専用ドメインとして運用する方法

いずれの方法でも、DNSレコードの適切な設定が前提です。SPF・DKIM・DMARCの3つが揃って初めて、なりすまし判定の回避と高い到達率を両立できます。メールヘッダーの詳細解析方法については、以下の記事も参考にしてください。

エンベロープFromを正しく設定するならメール配信システムを活用する

エンベロープFromの設定やSPF/DKIM/DMARCといった送信ドメイン認証の実装は、自社メールサーバーで行うには専門知識と継続的な運用工数が必要です。メール配信システムを活用すれば、こうした技術的負担を大幅に軽減しながら、高い到達率を実現できます。

メール配信システムを使うメリット

Gmail送信者ガイドラインやOutlookの新要件に対応した配信基盤を自前で構築・維持するのは、エンジニアにとって大きな負担です。メール配信システムを使えば、以下のメリットが得られます。

• エンベロープFromとヘッダーFromのアライメントが自動的に整う
• SPF・DKIM・DMARC認証に標準対応し、なりすまし判定を回避できる
• 大量配信時のIPレピュテーション管理をベンダー側が担う
• バウンスメール処理やエラー解析を自動化できる

メール配信システムの導入により、エンジニアは本来のコア業務に集中しながら、高い到達率と信頼性を両立できます。

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、お客様のシステムとSMTPリレーやAPIで連携することで、一斉配信やトランザクションメールを簡単に実現できるメール配信サービスです。エンベロープFromの適切な設定と送信ドメイン認証への対応がサービス側で完結するため、エンジニアを面倒なメール運用から解放します。

• SPF/DKIM/DMARC対応: 送信ドメイン認証に標準対応し、なりすまし判定を回避
• API連携・SMTPリレー: 既存システムへの組み込みが容易で、最短当日から利用開始可能
• 99%以上の高いメール到達率: 国内キャリア・ISPへの個別送信ロジックで確実に届ける
• バウンスメール自動対応: エラーメール管理を自動化し、エンジニアの運用負荷を大幅に削減
• IPレピュテーション管理: ベンダー側で運用・管理するため、常に高い送信者評価を維持

エンベロープFromの設定ミスによる配信トラブルや、Gmail・Outlookの最新ガイドライン対応に悩むエンジニアに最適です。メールアドレス入力のみで無料トライアルが可能ですので、まずは気軽にお試しください。

ブラストエンジン公式サイト：https://blastengine.jp/

まとめ

エンベロープとヘッダー情報の違い、分かれている理由などについて解説しました。

エンベロープやヘッダーの仕組みをイメージする際は、封筒に記された情報がエンベロープ情報、便箋に記された情報がヘッダー情報とイメージするとわかりやすいでしょう。

エンベロープとヘッダーのFrom/Toが分かれていることによるメリットや、発生するデメリットについても確認が必要です。なりすまし被害に遭わないためにも、理解を深めておきましょう。