用語辞典・メール

ヘッダーFrom

ヘッダーFromとは

ヘッダーFromは、メール本文とともに表示されるFromヘッダーの差出人で、配送上の差出人とは別に設定できます。RFC 5322では、メッセージの著者、つまり内容を作成した人やシステムのメールボックスを示す欄です。

一つの項目は、任意の表示名とメールアドレスから構成できます。メールアプリは表示名を大きく、アドレスを小さく見せることがありますが、表示名は自由に設定できる文字列です。

ヘッダーFromは受信者が差出人として見る重要な識別子ですが、文字列を書くだけでは本人証明になりません。DKIM署名とDMARC整合、受信経路、内容を合わせて確認します。

メッセージカード上部の著者情報を受信画面へ表示し、外側の配送用封筒にある返送先とは別に扱う表示名の印象ではなく、アドレスのドメインと認証結果を確認する
開いた封筒のメッセージカードに著者の人物印とドメイン紋章が表示され、別の外封筒には異なる返送印があり、受信者が著者側の認証を確認するヘッダーFromのピクトグラム図解
図1表示名に正規の会社名が書かれていても、アドレスの@右側が別ドメインなら同じ送信元とは判断できません。

差出人に関係する六つのフィールドを分ける

画面に見える著者、実際の送信担当、返信先、配送返送先、署名責任を役割ごとに並べる同じアドレスが入ることはあっても、仕様上の役割は同じではない
From内容の著者

受信者へ差出人として表示され、DMARCのAuthor Domainを提供する

Display名前人向けの表示名

任意の文字列で、アドレスや認証済みの本人名そのものではない

Sender実際の送信担当

著者とは別の代理人がメッセージ送信を行った場合に示す

Reply-To著者が希望する返信先

返信操作で優先されることが多く、Fromと異なる宛先を指定できる

Return-Path配送エラーの返送先記録

最終配送側がSMTP逆方向経路から作り、通常の返信には使わない

DKIM d=電子署名の責任ドメイン

Fromと整合するかはDMARCが評価し、単独では著者と同一とは限らない

図2不審メール調査では、Fromだけを切り出さず、Authentication-Results、DKIM-Signature、Return-Path、Receivedも一緒に確認します。

Fromは著者、Senderは送信を実行した主体を表す

Fromはメッセージ内容を作成した著者のメールボックスです。秘書、配信システム、代理サービスなど別の主体が実際の送信を担当した場合、Senderヘッダーでその送信担当メールボックスを示せます。

Fromに複数のメールボックスを置く場合、RFC 5322は単一のSenderを必要とします。共同著者と送信担当を分けるためで、任意の複数差出人を本人確認済みとして表示する機能ではありません。受信システムは不正な複数Fromを曖昧に処理しません。

表示名はアドレスではなく、本人確認にも使えない

表示名は人が読みやすい名称で、同じ名前を誰でも設定できます。攻撃者は表示名へ企業名や正規アドレス風の文字列を入れ、自分の別ドメインのアドレスを目立たなくできます。

受信画面では詳細を開いて@を含むアドレス全体を確認します。Unicodeの似た文字、長いサブドメイン、途中に埋め込まれた正規ドメインに注意し、@より右を末尾まで読みます。

Reply-Toがあれば、返信先はFromと異なり得る

Reply-Toは著者が返信を希望する宛先を示します。問い合わせ受付、チケットシステム、代理送信などで正当に使われます。メールアプリの返信操作は通常Reply-Toを優先し、なければFromを使います。

請求やアカウント確認メールで、Fromと無関係な返信先へ誘導される場合は慎重に確認します。返信画面を開いた後の宛先も見直し、機密情報や認証コードをメールで返しません。

エンベロープFromは、ヘッダーFromと独立して配送される

エンベロープFromはSMTP MAIL FROMの逆方向経路で、配信失敗の返送とSPF評価に使われます。ニュース配信ではヘッダーFromをブランドの窓口、エンベロープFromをバウンス管理専用ドメインにすることがあります。

異なること自体は不正ではありません。DMARCは、SPF通過したエンベロープドメインか、DKIM通過した署名ドメインの少なくとも一方がヘッダーFromと整合することを求めます。

DKIMはFromを署名するが、d=との同一性はDMARCが見る

DKIM署名はFromヘッダーを署名対象に含める必要があります。署名後にFromが変われば検証に失敗するため、転送中の改ざん検出に役立ちます。

ただしDKIM単独ではd=署名ドメインとFromドメインが一致する必要はありません。DMARCのalignmentが、受信者に見えるAuthor Domainと署名責任の関係を確認します。

DMARCはFromのAuthor Domainを保護対象にする

DMARCはRFC5322.FromからAuthor Domainを抽出します。SPFのMAIL FROMやDKIMのd=が認証通過し、そのドメインがAuthor Domainと厳格または緩和で整合すればDMARC通過です。

DMARC通過でも、表示名だけの詐称、似た別ドメイン、正規アカウントの乗っ取り、悪意ある正規ドメインは残ります。Fromドメインの使用許可と、人物・内容の安全性を分けます。

転送時にFromを書き換えるかは、運用上の選択である

単純転送は元のFromを保てますがSPFを壊しやすく、メーリングリストが本文を変えるとDKIMも壊れ得ます。一部システムは配送を保つためFromを書き換え、元の著者をReply-Toなどへ残します。

書き換えは受信者の見え方と返信先を変えます。元の著者、転送主体、認証責任をどのフィールドで示すかを定め、勝手なFrom改変で誤解を生まないようにします。

受信画面と生ヘッダーを使い分ける

通常の確認では表示名、完全なFromアドレス、Reply-To、受信アプリの認証表示を見ます。不審な場合はメッセージソースを開き、Authentication-Results、DKIM-Signature、Return-Path、Receivedを確認します。

Fromアドレスを末尾まで読み、認証結果がどのドメインへ対するものかを対応させ、リンクや返信先が別ドメインなら公式の別経路で確認することが安全です。

著者フィールドと認証の確認資料:RFC 5322「Internet Message Format」、RFC 6376「DKIM」、RFC 9989「DMARC」

関連用語