Header Fromとは

Header Fromを読むときの前提

Header From（RFC5322 From）は、メールクライアント上で送信者として表示されるFromヘッダーです。利用者が目にする差出人であり、DMARCが守ろうとする中心のドメインです。

実務では、表示名、Fromドメイン、エンベロープFrom、DKIM d=、SPF評価ドメイン、DMARCアライメント、なりすまし表示、委託送信SaaSのFrom設定を合わせて確認します。

証跡には、元メールヘッダー、Header From、Return-Path、DKIM-Signature、Authentication-Results、利用者画面の表示、確認時刻を残します。

表示名とドメインを分ける

Header Fromには、表示名とメールアドレスのドメインがあります。表示名だけを会社名にしても、ドメインが別物なら利用者には誤解されやすく、DMARCの観点でも確認が必要です。

なりすまし調査では、表示名、実際のFromアドレス、返信先、Return-Path、リンク先を分けて確認します。画面上の差出人表示だけで正規メールと判断しません。

• 表示名とFromドメインを分けて記録する。
• Reply-ToやReturn-Pathとの違いを見る。
• 利用者画面と生ヘッダーを両方保存する。

DMARC alignmentを見る

DMARCでは、Header Fromのドメインと、SPFまたはDKIMで認証されたドメインが揃っているかを見ます。SPFやDKIMが単独でpassしても、Header Fromと関係がなければDMARCは失敗することがあります。

外部配信サービスでは、Header Fromを自社ドメインにしつつ、Return-PathやDKIM d=がサービス側になることがあります。独自ドメイン設定やDKIM署名設定を確認します。

• Header FromとReturn-Pathを突合する。
• DKIM d=がFromドメインと揃うか見る。
• Authentication-ResultsでDMARC結果を確認する。

利用者影響と配送実態を分ける

Header Fromは利用者が見る情報なので、なりすましや誤送信の問い合わせでは最初に注目されます。一方、配送経路やSPF評価は別のヘッダーやSMTP情報で判断します。

ブランド名変更、送信代行、共有メールボックス、メーリングリストでは、利用者に見えるFromと配送上の送信元がずれます。問い合わせ対応では、表示と配送実態を分けて説明します。

• 利用者画面のFrom表示を確認する。
• 配送ログと生ヘッダーを同じメールで見る。
• From変更時の利用者向け説明を残す。

変更証跡と引き継ぎ

Header From変更では、旧From、新From、表示名、送信サービス、DKIM/SPF/DMARC結果、利用者表示、戻し条件を残します。送信代行ではSaaS側のドメイン認証設定も同じ変更範囲に入れます。

引き継ぎでは、メール基盤管理者、広報/ブランド担当、SaaS所有者、関連語としてエンベロープFrom、DMARCアライメント、DKIM、SPFを残すと確認しやすくなります。

• From表示と生ヘッダーをセットで保存する。
• 変更前後のDMARC結果を比較する。
• 送信代行サービスの所有者を記録する。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能