メールヘッダ読み方

【Authentication-Resultsフィールド】

A. SPF (Sender Policy Framework)

メール送信元のIPアドレスが、送信ドメインの公開ポリシー（SPFレコード）で許可されているかを検証します。

項目名	説明	例
spf	SPF認証の結果。pass、fail、softfail、neutral、none、temperror、permerror などがあります。	spf=pass
smtp.mailfrom	SPFの検証対象となるエンベロープFromアドレス（MAIL FROM:コマンドで指定されるアドレス）のドメイン。	smtp.mailfrom=sender.com

B. DKIM (DomainKeys Identified Mail)

メールに付加された電子署名を検証し、送信中に内容が改ざんされていないか、正規のサーバーから送られたものかを検証します。

項目名	説明	例
dkim	DKIM認証の結果。pass、fail、none、temperror、permerror などがあります。	dkim=pass
header.d	署名に利用されたDKIMドメイン。署名を作成した組織のドメインを示します。	header.d=signedby.com
header.s	セレクタ(DKIM-Signatureのs=)	header.s=selector1
header.b	署名値の先頭部分	header.i=@example.com
header.i	DKIM署名の識別子。通常はエンベロープFromアドレスまたはFromヘッダーアドレスと整合性があることを示します。	header.i=@signedby.com

C. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

SPFとDKIMの結果を基に、Fromヘッダーのアドレスのドメインとのアライメント（整合性）を確認し、メールの処理ポリシー（隔離、拒否など）を指示します。

項目名	説明	例
dmarc	DMARC認証の結果。pass、fail、none、temperror、permerror などがあります。	dmarc=pass
header.from	Fromヘッダーアドレスのドメイン。DMARCの検証対象となるドメインです。	header.from=example.org
policy	受信サーバーが適用したDMARCポリシー。	p=quarantine

【Receivedフィールド】

Received行は、メールが送信元から受信者まで経由したすべてのメールサーバーの記録を示す重要なヘッダ情報です。メールが配送される過程で、各メールサーバーがこの行を追加していきます。

1. 追加の仕組み

• メールが通過するメールサーバー(MTA: Mail Transfer Agent)ごとに、先頭に新しいReceived行が追加されます
• 最も上にあるReceived行が最後に経由したサーバー(受信者に最も近いサーバー)
• 最も下にあるReceived行が最初に経由したサーバー(送信者に最も近いサーバー)

2. 記載される情報

典型的なReceived行には以下の情報が含まれます:

Received: from mail.example.com (mail.example.com [192.0.2.1])
    by mx.recipient.com (Postfix) with ESMTP id ABC123
    for <[e-mail]>; Mon, 1 Feb 2026 10:30:45 +0000 (UTC)

• from: 送信元のホスト名/IPアドレス
• by: 受信したサーバーのホスト名
• with: 使用された通信プロトコル(SMTP, ESMTP, HTTPなど)
• id: メッセージID(サーバー内での識別子)
• for: 宛先メールアドレス
• 日時: そのサーバーでメールを受信した日時

【Return-Pathフィールド】

Return-Pathは、メールの配送に失敗した場合に、エラー通知(バウンスメール)を送り返すべき宛先を示すヘッダフィールドです。別名「エンベロープFrom」や「バウンスアドレス」とも呼ばれます。

基本的な特徴

1. 自動生成の仕組み

Return-Pathは送信者が直接設定できません。以下のプロセスで生成されます:

① SMTPセッション開始
   送信MTA → 受信MTA: MAIL FROM:<[e-mail]>
   
② メール本体送信
   ヘッダ(From, To, Subject等)と本文を転送
   
③ 最終配送時
   受信MTAがメールボックスに配送する際に
   「MAIL FROM」の値を使ってReturn-Pathを追加

SMTPセッションの詳細

2. 追加されるタイミング

重要: Return-Pathは最終配送サーバー(メールボックスに配送するサーバー)でのみ追加されます。

3. 形式

Return-Path: <[e-mail]>

• 必ず山括弧< >で囲まれたメールアドレス形式
• 空の場合は <> と表記されます

中継サーバーがある場合の動作

📨 配送経路の例

送信者MTA → 中継1 → 中継2 → 受信者MTA → メールボックス
              ↓       ↓        ↓           ↓
           Received Received Received  Return-Path追加
           追加のみ  追加のみ  追加のみ   + Received追加

各段階での処理

送信者のMTA

• SMTPで MAIL FROM: <[e-mail]> を送信
• この情報をエンベロープ情報として次のサーバーへ

中継サーバー1, 2, ...

• ✅ Receivedヘッダを追加
• ❌ Return-Pathは追加しない
• ✅ エンベロープ情報(MAIL FROM)はそのまま次へ転送

受信者のMTA(最終配送サーバー)

• ✅ Receivedヘッダを追加
• ✅ Return-Pathを追加(エンベロープ情報を使用)
• ✅ メールボックスに配送完了

実際のヘッダ例

Return-Path: <[e-mail]>
Delivered-To: [e-mail]
Received: from mx.recipient.com (mx.recipient.com [203.0.113.5])
    by mailbox.recipient.com (Postfix) with ESMTP id XYZ789
    for <[e-mail]>; Mon, 1 Feb 2026 10:35:00 +0000
Received: from relay2.net (relay2.net [198.51.100.20])
    by mx.recipient.com (Postfix) with ESMTP id ABC456
    Mon, 1 Feb 2026 10:34:50 +0000
Received: from relay1.net (relay1.net [198.51.100.10])
    by relay2.net (Postfix) with ESMTP id DEF123
    Mon, 1 Feb 2026 10:34:40 +0000
Received: from mail.sender.com (mail.sender.com [192.0.2.1])
    by relay1.net (Postfix) with ESMTP id GHI890
    Mon, 1 Feb 2026 10:34:30 +0000
From: User Name <[e-mail]>
To: [e-mail]
Subject: Test Mail
Date: Mon, 1 Feb 2026 19:34:25 +0900

ポイント:

• Return-Path: 1つだけ(最上部、最終配送サーバーが追加)
• Received: 4つ(各サーバーが追加)
• Return-Pathのアドレスは最初の「MAIL FROM」が維持される

FromヘッダとReturn-Pathの違い

これは非常に重要な概念です:

項目	Return-Path	Fromヘッダ
レイヤー	SMTPプロトコル層(エンベロープ)	メッセージ層(ヘッダ)
用途	配送エラー通知の送信先	メール本文上の送信者表示
設定者	受信側MTAが自動追加	送信者が自由に設定可能
偽装難易度	困難(SMTPレベルで記録)	容易(単なるテキスト)
表示	メーラーでは通常非表示	メーラーで送信者として表示
認証対象	SPFで検証される	DMARCで検証される

📧 具体例: メルマガ配信

Return-Path: <[e-mail]>
From: カスタマーサポート <[e-mail]>
Reply-To: [e-mail]

• From: 受信者に見せたい送信者名(企業の公式アドレス)
• Return-Path: バウンス処理用の専用アドレス(配信システムが管理)
• Reply-To: 返信先アドレス

この設定により:

• ユーザーには「[e-mail]」から届いたように見える
• 配送失敗は「[e-mail]」に届く
• ユーザーが返信すると「[e-mail]」に届く

主な用途

🔄 1. バウンス処理

配送失敗時の通知先として機能します:

配送失敗の流れ:
送信者MTA → 受信者MTA (配送失敗)
              ↓
         バウンスメール生成
              ↓
         Return-Pathのアドレスへ送信
              ↓
         送信者が配送失敗を認識

バウンスメールの特徴:

Return-Path: <>  ← 空(バウンスのバウンスを防ぐ)
From: Mail Delivery System <[e-mail]>
To: [e-mail]  ← 元のReturn-Pathの値
Subject: Undelivered Mail Returned to Sender

🛡️ 2. SPF認証

SPFとは

特殊なケースと例外

🔄 1. メーリングリスト

メーリングリストサーバーは新しいメールとして再送信します:

元のメール:
Return-Path: <[e-mail]>
From: [e-mail]
To: [e-mail]

↓ メーリングリストサーバー処理

配信されるメール:
Return-Path: <[e-mail]>
From: [e-mail]
Reply-To: [e-mail]

なぜ書き換えるのか?

• メーリングリスト経由の配送失敗を管理者が把握するため
• 元の送信者に大量のバウンスが届くのを防ぐため

🔄 2. メール転送(Forward)

転送の種類によって動作が異なります:

パターンA: エンベロープ維持型

[e-mail] → [e-mail] (転送設定)

結果:
Return-Path: <[e-mail]>

• 元の送信者が維持される
• バウンスは元の送信者に届く
• ⚠️ SPF認証が失敗する可能性あり

パターンB: SRS(Sender Rewriting Scheme)使用

[e-mail] → [e-mail] (転送設定)

結果:
Return-Path: <SRS0=HHH=TT=company.com=[e-mail]>

• SPF問題を回避するため書き換え
• バウンスは転送元サーバー経由で元の送信者に届く

📭 3. 空のReturn-Path

Return-Path: <>

使用される場面:

• バウンスメール自体
• システム通知メール
• 返信不要の自動送信メール

目的: バウンスのバウンス(二重バウンス)を防ぐ

もしバウンスメールに通常のReturn-Pathがあると:

元のメール配送失敗 → バウンス送信 → バウンスも配送失敗
→ バウンスのバウンス送信 → 無限ループ ❌

空のReturn-Pathにすることで、このメール自体がバウンスしても通知されません。

🏢 4. 大規模メール配信システム

VERP(Variable Envelope Return Path)という手法:

Return-Path: <[e-mail]>
Return-Path: <[e-mail]>
Return-Path: <[e-mail]>

利点:

• 各受信者ごとに固有のReturn-Path
• バウンスメールを解析しなくても、アドレスだけで誰への配送が失敗したか判別可能
• 自動処理が容易

実務での活用ポイント

🔧 メールサーバー管理者として

1. 設定確認

# Postfixの場合
# MAIL FROMのデフォルト設定
/etc/postfix/main.cf:
  myhostname = mail.example.com
  myorigin = $mydomain

2. バウンス処理の設定

# バウンス通知の設定
/etc/postfix/main.cf:
  notify_classes = bounce, delay, policy, protocol, resource, software
  bounce_notice_recipient = [e-mail]

3. ログでの追跡

# Postfixログでエンベロープ情報を確認
tail -f /var/log/maillog | grep "MAIL FROM"

# 出力例:
Feb  1 10:34:30 mail postfix/smtp[12345]: MAIL FROM:<[e-mail]>
Feb  1 10:34:31 mail postfix/smtp[12345]: RCPT TO:<[e-mail]>
Feb  1 10:34:32 mail postfix/smtp[12345]: 250 2.1.0 Ok