
Envelope-Fromとは?仕組みやHeader-Fromとの違いについて解説
電子メールの設定をおこなう際、あらかじめ理解しておくと良いキーワードがいくつかあります。本記事では、主にエンジニアの方向けにそのようなキーワードの中から「Envelope-From (エンベロープ フロム) 」と「Header From (ヘッダー フロム) 」について説明します。また、関連するメールのセキュリティ設定との関係についても解説します。
目次[非表示]
- 1.実際の手紙と電子メール
- 2.Envelope-From・Header-From・Header-To・Header-Reply-Toの違い
- 2.1.Envelope-Fromとは
- 2.2.Header-Fromとは
- 2.3.Header-Toとは
- 2.4.Header-Reply-Toとは
- 3.EnvelopeとHeaderが分かれているメリットとは
- 3.1.BCC機能が利用できる
- 3.2.柔軟な転送・代理送信が可能
- 4.EnvelopeとHeaderが分かれているデメリットとは
- 5.Envelope-Fromが設定される仕組み
- 5.1.確認方法
- 6.メールのセキュリティ設定
- 7.DKIM(ディーキム:DomainKeys Identified Mail)
- 7.1.DKIMの2つの署名方法
- 7.2.DMARC(ディーマーク:Domain-based Message Authentication Reporting and Conformance)
- 7.3.S/MIME (エスマイム:Secure / Multipurpose Internet Mail Extensions)
- 8.Envelope-FromとHeader-Fromを理解しメール配信を開始しよう
実際の手紙と電子メール
まずは、概念を整理するために、実際の手紙と電子メールを比較してみましょう。
実際の手紙の仕組み
実際に手紙を書く際は、便箋に本文を書き、それを封筒に入れて送ります。便箋には手紙の宛名にあたる送付先の方の名前、本文、そして末尾に手紙の送り主である自分の名前を書きます。また、封筒にも送付先の住所・宛名、差出人の住所と名前を書き、封筒に便箋を入れて郵送します。
これにより、手紙の配達員は、便箋に書かれた宛名や本文を確認することなく、封筒に書かれた情報を頼りに送付先へ手紙を届けることができます。
電子メールの仕組み
電子メールも実際の手紙と同じように、手紙の封筒や便箋に似た仕組みがあります。メール配信処理においても、封筒を開けてメール本文を読み解くことはせず、封筒に書かれている情報を元にメールを配信します。この仕組みは、元々はメールを書いた人が使用しているシステムの代わりに別のシステムがメールを配信することを想定した仕組みです。
例えば、実際の手紙の場合も、手紙を書いた人が自ら送信先の方の自宅まで赴き、郵便受けに手紙を投函することはせず、代わりに郵便局や宅配便が送付先へ手紙を届けてくれます。これと同じようなイメージです。
Envelope-From・Header-From・Header-To・Header-Reply-Toの違い
メールには複数の送信元や宛先を表す情報があり、それぞれ役割が異なります。
ここではEnvelope-From、Header-From、Header-To、Header-Reply-Toの違いと、メール配信や認証との関係を分かりやすく説明します。
Envelope-Fromとは
Envelope-Fromは、メール配送時に使用される差出人情報で、いわば「封筒」に書かれた差出人のようなものです。配送エラーが発生した際、この情報をもとにバウンスメール(エラーメール)が返送されます。多くの場合、メール配信システムによって、自動的に設定されます。
Header-Fromとは
Header-Fromは、メール本文のヘッダーに記載される差出人情報で、受信者がメールを開いたときに表示される「差出人」欄にあたります。これは人が読むための情報であり、実際にメールを配送したサーバ情報とは異なることがあります。メールの転送や代理送信の際も差出人表示を維持できるため、ブランドや送信元を一貫して見せられるメリットがあります。
Header-Toとは
Header-Toは、メールの宛先を示すフィールドで、受信者が閲覧した際に「宛先」欄に表示される情報です。複数の人への一斉送信やCC・BCCの設定もここで管理され、誰宛てのメールなのかを明確にする役割を持ちます。
Header-Reply-Toとは
Header-Reply-Toは、返信先を制御するためのフィールドで、差出人とは異なるアドレスを指定できます。たとえば広報メールを配信する際、返信先をサポート専用アドレスに設定することで、問い合わせを一元管理することが可能です。ユーザー体験を損なわずに、担当部署へ効率的に返信を集約できるため、マーケティングや顧客サポート運用で重要な役割を果たします。
EnvelopeとHeaderが分かれているメリットとは
メールでは、配送に使う情報(Envelope)と、受信者に表示される情報(Header)が分かれています。この仕組みにより、柔軟なメール配信やエラー管理、ユーザー体験の最適化が可能になります。
BCC機能が利用できる
Envelope-ToとHeader-Toが分かれていることで、BCC機能が利用できます。BCC宛先はEnvelope-Toのみに設定し、Header-Toには記載しないため、他の受信者に宛先が表示されず、安全な一斉送信が可能です。プライバシーを守りつつ複数の宛先へメールを配信できる点は、業務メールやメルマガにおいて、欠かせないメリットです。
柔軟な転送・代理送信が可能
Envelope-FromとHeader-Fromを分けて管理することで、外部のメール配信サービスを利用した一斉送信や転送時でも、受信者には企業名やブランド名を表示したまま配信できます。これにより、運用の自由度を確保しつつ、顧客にとって分かりやすい差出人表示ができ、ブランド体験を損なわずに済みます。
EnvelopeとHeaderが分かれているデメリットとは
一方で、EnvelopeとHeaderが分かれている仕組みは悪用される可能性もあります。最大のリスクは「なりすましメール」です。メール配送ではHeader-Fromの情報は配送経路に使われないため、攻撃者が差出人を偽装しても配信できてしまいます。これにより、フィッシング詐欺や標的型攻撃メールが発生し、ユーザーが本物と誤認して開封してしまう危険があります。こうしたリスクに対処するためには、SPF・DKIM・DMARCといった送信ドメイン認証を設定し、正規のメールのみを通す仕組みを構築することが重要です。
Envelope-Fromが設定される仕組み
メール作成時に入力されるのは、通常ヘッダー情報(From/To/Subjectなど)です。実際の送信時には送信サーバ(MSA/MTA)がSMTP通信の中で MAIL FROM: コマンドを発行し、これが Envelope-From として使われます。多くのメール配信システムでは、ここにHeader-Fromではなく、配信エラー処理用の専用アドレス(例:bounce@〜 や個別識別用のVERPアドレス)を自動設定します。メールは配送の過程でMTA同士がEnvelope情報を保持し続け、最終的に受信サーバに到達するとEnvelopeは破棄され、値が Return-Path としてヘッダーに記録されます。これにより、バウンスメールは正しい送信元(配信システム)へ返され、エラー管理や配信リストのメンテナンスに利用されます。
確認方法
Envelope-From を確認するには、受信メールの全ヘッダーを表示し Return-Path をチェックします。
例:Gmailの場合
対象メールを開き、右上メニュー(︙)→「メッセージのソースを表示」を選択し、画面内の「Return-Path:」を探します。Google Admin Toolbox(Messageheader)にヘッダーを貼り付けると、解析結果で送信経路やReturn-Pathを簡単に確認できます。
例:Outlook(Windows)の場合
メールを開き[ファイル]→[プロパティ]→「インターネット ヘッダー」でReturn-Pathを確認します。バウンス通知などではReturn-Pathが空(<>)の場合もあります。
送信側の設定を調べたい場合は、テスト送信して受信側で確認するか、利用中の配信サービスやMTAの仕様で MAIL FROM の付与ルールを確認すると安心です。
メールのセキュリティ設定
一方で、メール本文に記載された差出人と、実際にメールを配信した配信元の情報が異なっていても問題なく送信できます。そのため、本文に事実と異なる差出人名が書かれていても、メール配信システムはその真偽を判別できません。
これが不正なメール配信の一種、いわゆる「なりすまし」の手法です。
この「なりすまし」メールの対抗策として、メールのセキュリティ設定があります。本物の差出人だけが設定できる情報をインターネットに公開し、メール受信側ではその公開情報を元に受信したメールを検証するものです。メールのセキュリティ設定について、それぞれ見ていきましょう。
SPF (エスピーエフ:Sender Policy Framework)
SPFは、Envelope-Fromに指定する配信元のなりすましを検証するためのセキュリティ設定です。Envelope-Fromに指定される配信元が、使用するメールサーバのIPアドレスのリストをインターネットに公開することで、それ以外のサーバから送信されてきたメールは、なりすましの可能性が高いと判断します。
Envelope-Fromは、原則としてはメール配信システムによって指定される配信元情報のため、メール配信システムを管理する組織によって、セキュリティ設定がインターネットに公開されています。
現在のメール配信の仕組みにおいては、設定が不可欠で、SPFが正しく設定されていない場合は不正なメールと判定される可能性が非常に高くなります。
元来SPFは、Envelope-Fromの検証の仕組みであり、基本的にはHeader-Fromの差出人の検証には使用されません(Header-FromとSPFの関係性の評価は後述のDMARCでおこなわれます)。なお、SPFをメール本文の差出人(Header-From)にも適用して評価する通信事業者があるため、メール本文の差出人も配信システムと同様にSPFを設定することがあります。
DKIM(ディーキム:DomainKeys Identified Mail)
DKIMは、Header-Fromに指定する差出人のなりすまし、およびメールの改ざんを検出するためのセキュリティ設定です。メールの差出人がなりすましされていないことや、メール本文などの主要な項目が途中の経路で改ざんされていないことを確認するために、DKIMに対応したシステムがメールを配信する際に電子署名を付与します。メール受信側は、メールに付与されている電子署名を検証し、メールが改ざんされていないことを確認します。
DKIMの2つの署名方法
一つは作成者署名と呼ばれ、Header-Fromで指定したメールアドレスのドメインである差出人の組織が管理する鍵で署名する方法です。もう一つは第三者署名と呼ばれ、作成者署名とは異なり第三者(一般的にはメール配信システムを管理する)組織が管理する鍵で署名する方法です。作成者署名は、メール本文の差出人が属する組織が鍵の管理やインターネットへの公開をおこなうため、運用に手間がかかりますが、セキュリティ的な信用度は第三者署名よりも高く評価されます。
DMARC(ディーマーク:Domain-based Message Authentication Reporting and Conformance)
DMARCは、メール差出人として、仮にSPFやDKIMが成立しなかった場合にメール受信側にそのメールをどう取り扱ってもらうかを宣言するための仕組み、およびSPFとDKIMを組み合わせた評価方法に関するセキュリティ設定です。メール差出人側は、あらかじめSPF・DKIMへ対応する旨をDMARCレコードを通じてインターネットに公開します。この情報には「DMARCポリシー」と呼ばれる情報が含まれており、SPF/DKIMの評価がうまく行かなかった場合にどう取り扱うかを3段階 (何も行わない・スパムとしてフィルタリング・受信を拒否) で表明します。
DMARCに対応しているメール受信側は、受信したメールをSPFとDKIMで評価し、認証に失敗した場合はDMARCポリシーに従って処理します。この際、メール差出人側のシステムのSPF・DKIM設定が不完全な状態で厳しいポリシーを設定すると、正規のメールであっても受信ボックスに到達しないため、設定には注意が必要です。そのため、最初はゆるいポリシーでDMARC運用を始め、SPF/DKIMの設定が間違いなくおこなわれるよう設定を改善し、確認後にポリシーを厳しくしていきます。こうすることで、差出人になりすます不正なメール配信者を締め出します。
このように、DMARCはメール配信側としてのセキュリティ設定に対する姿勢を表す指標と言えます。DMARCが公開されていないメール配信者は、今後メール受信側に信用されなくなっていくことから、SPF・DKIMと合わせて必須の設定項目となっています。
なお、DMARCポリシーはHeader-Fromで指定するメール配信者のドメイン単位で評価がおこなわれます。お手元のメールソフトからメールを配信する場合だけでなく、例えば組織のWebサイトの問い合わせフォーム入力後に送信される通知メールなど、メール送信元システムが組織内で複数ある場合は全てがその評価の対象となりますので、注意が必要です。
S/MIME (エスマイム:Secure / Multipurpose Internet Mail Extensions)
DKIMはメールが途中の経路で改ざんされていない事を証明するための仕組みでしたが、S/MIMEは、DKIMよりも更に高度な、差出人のなりすましおよびメールの改ざん検知に加えてメール本文全体の暗号化が行える仕組みです。
メールが配信される経路の一部ではなく、配信元で暗号化され受信先で復号化される、エンドツーエンドで暗号化されるという特徴があります。鍵の取得に関する経済的なコストや運用の労力がかかりますが、認証局(CA)を通じた公開鍵基盤(PKI)という広く信頼されている機関を利用するため、機密性の高い情報をメールで送信するためには有効な手段です。
S/MIMEに対応するには、メール作成側、メール受信側両方がS/MIMEに対応している必要があり、かつメール配信側は信用がおける第三者による認証を得て電子鍵および証明書を得ておく必要があります。なお、メール受信側がS/MIMEに対応していないとメールを読むことができませんので、注意が必要です。
Envelope-FromとHeader-Fromを理解しメール配信を開始しよう
メール配信の設定にあたって必要な「Envelope-From」と「Header-From」、そして、セキュリティ設定に関してご紹介しました。。
それぞれのワード、設定について理解が深まりましたでしょうか。
セキュリティ対策について、「もう少し確認してからメール配信を試したい!」「相談をしてから実施をしたい」という方は、アララ メッセージへご相談ください。技術面についてはサポートチームが対応いたします。また、実際にメール配信の運用を行う営業やマーケティング担当者さまへはトライアルもご用意しています。一か月から契約可能ですので、ぜひ、お気軽にお問い合わせください。
![]()
著者 |
導入事例はこちら
関連コラム


















