← RFC Reference

メールヘッダーの構造

メール メッセージ内のすべての重要なヘッダー フィールドについて説明します。その意味、設定者、重要な理由についても説明します。完全に注釈を付けた実際の例を含みます。

完全な例

受信者のメールボックスに表示される実際のメール ヘッダーは上から下までです。各ヘッダーについて詳しく説明します。

それでは各ヘッダーを見ていきましょう。

ID ヘッダー

From

RFC 5322 で定義されたメッセージの作成者。これは受信者がメール クライアントで表示するもの。オプションの表示名 (Alice) とメールボックス アドレス (alice@example.com) で構成されます。DMARC アラインメント チェックはこのヘッダーのドメインに対して実行されます。

From はエンベロープ送信者と同じではありません。エンベロープ送信者 (SMTP の MAIL FROM) はまったく異なる場合があります。From: ヘッダーはメッセージ作成者によって設定されます。エンベロープ送信者は送信システムによって設定されます。

To、Cc、Bcc

To: と Cc: は表示ヘッダーです。意図した受信者を示しますが、配信は制御しません。実際の受信者は SMTP RCPT TO コマンドで決定されます。これにはヘッダーにリストされていない Bcc 受信者が含まれる場合があります。メッセージには RCPT TO に含まれていないアドレスをリストする To: ヘッダーがある場合があり、その逆もあります (これが Bcc の仕組みです)。

Reply-To

この例には示されていませんが、一般的です。From: と異なる場合に返信を送信するべき場所を指定します。メッセージが no-reply アドレスから送信されているが、返信がサポート アドレスに送信される場合によく使用されます。

Sender

作成者と異なる送信責任者がいる場合に使用されます。アリスのアシスタントがアリスの代わりにメッセージを送信する場合、ヘッダーは From: Alice と Sender: Assistant と表示される場合があります。ほとんどのメッセージはこのヘッダーを省略します。

メッセージ識別

Message-ID

このメッセージのグローバルに一意の識別子で、送信者によって生成されます。形式は <unique-part@domain> です。これはスレッド化、重複排除、バウンス相関に不可欠です。すべてのメッセージにはこれが必要です。送信システムが設定しない場合、最初の MTA が生成します。ただしその場合、送信されたメッセージとバウンスを相関させる能力が失われます。

In-Reply-To および References

スレッド化に使用されます。In-Reply-To には返信されるメッセージの Message-ID が含まれます。References にはスレッド内の Message-ID 値の完全なチェーンが含まれます。メール クライアントはこれを使用して会話をグループ化します。

日付と件名

Date

メッセージが作成された日時で、送信者によって設定されます。形式は RFC 5322 で指定されています。これは配信時刻ではありません。メッセージは配信前に数時間から数日間キューで停滞する場合があります。常にタイム ゾーン オフセットを含めてください。

Subject

メッセージを要約する自由形式のテキスト。仕様に長さ制限はありませんが、メール クライアントは様々な長さで切り詰めます。一貫した表示を見やすくするために 60 文字以下に保ってください。非 ASCII 文字は RFC 2047 エンコーディング (例: =?UTF-8?Q?...?=) を使用してエンコードする必要がありますが、ほとんどの最新メール システムは透過的に処理します。

Received チェーン

メッセージを処理する各サーバーは Received: ヘッダーを先頭に追加します。下から上へ 読まれます。最も古いホップが下部にあり、最新のホップが上部にあります。各ヘッダーは以下を記録します。

• from — メッセージを送信したサーバー (ホスト名と IP)
• by — メッセージを受け取ったサーバー
• with — 使用されたプロトコル (ESMTP、TLS 用の ESMTPS、ローカル配信用の LMTP)
• id — 受信サーバーのキュー ID
• for — 受信者 (複数の受信者の場合はプライバシーのため省略される場合があります)
• タイムスタンプ — このホップがメッセージを受け取った時刻

Received チェーンは配信遅延のデバッグに非常に役立ちます。ホップ間のタイムスタンプを比較して、時間が失われた場所を見つけます。注意: 送信者側からの Received: ヘッダーは偽造できます。自分のインフラストラクチャによって追加されたヘッダーだけを信頼してください。

Return-Path

最終配信 MTA によって設定され、SMTP エンベロープ送信者 (MAIL FROM) を記録します。これはバウンスが送信される場所です。この例では VERP エンコーディングが使用されています。元の受信者 (alice@example.com) がバウンス アドレスのローカル部分にエンコードされています。

Return-Path はメッセージ作成者によって設定されません。SMTP セッションから抽出され、配信サーバーによって追加されます。配信されたメッセージには正確に 1 つの Return-Path ヘッダーが必要です。

認証ヘッダー

DKIM-Signature

送信サーバーによって追加されます。d= フィールドは署名ドメイン (DMARC アラインメント用に使用) を識別します。s= フィールドは DNS で公開鍵を検索するために使用されるセレクターです。h= フィールドは署名されたヘッダーをリストします。完全な検証プロセスについては、メール認証について説明 を参照してください。

Authentication-Results

受信サーバー (RFC 8601) によって追加されます。これはこのホップでこのメッセージの認証チェックの権限ある記録です。authserv-id (mx1.example.net) はチェックを実行したサーバーを識別します。SPF、DKIM、DMARC の結果を記録します。チェックされた識別子を含みます。

セキュリティに関する注意: 外部ソースからの偽造 Authentication-Results ヘッダーは境界 MTA によってストリップされるべきです。自分のインフラストラクチャによって追加された場合のみ、このヘッダーを信頼してください。

MIME ヘッダー

MIME-Version

メッセージが MIME (RFC 2045) を使用することを示します。これは常に 1.0 であり、すべてのメッセージに存在する必要があります。なければメッセージはプレーン US-ASCII テキストとして解釈されます。

Content-Type

メッセージ本文のメディア タイプについて説明します。一般的な値:

• text/plain — プレーン テキスト
• text/html — HTML コンテンツ
• multipart/alternative — 同じコンテンツの複数のバージョン (通常はテキストと HTML)。メール クライアントが最適なものを選択します。
• multipart/mixed — 添付ファイル付きメッセージ
• multipart/related — インライン画像付き HTML

boundary パラメータは MIME パート間の区切り文字を定義します。詳細は RFC 2046 を参照してください。

Content-Transfer-Encoding

本文が安全な転送のためにどのようにエンコードされるか。一般的な値: 7bit、quoted-printable、base64。添付ファイルは base64 を使用します。HTML メール本文は通常 quoted-printable を使用して、非 ASCII 文字を処理しながらほぼ読める状態に保ちます。

リスト管理ヘッダー

RFC 2369 は List-Unsubscribe を定義します。これはアンサブスクリプション用の URL および/またはメール アドレスを提供します。RFC 8058 は List-Unsubscribe-Post を追加します。メール クライアントの UI からワンクリック アンサブスクリプション機能を有効にします。ブラウザを開く必要はありません。Gmail および他の主要なプロバイダーは一括およびマーケティング メールの両方のヘッダーを必要とします。

表示されるべきではないヘッダー (表示される場合もあります)

X-Mailer / User-Agent

メール クライアントまたは送信ソフトウェアを識別します。スパム フィルターのシグナルとして使用されることもあります。最新の送信システムは、フィンガープリント表面を削減するためにこれを省略することがよくあります。

X-Priority / Importance

メッセージ優先度を設定しようとする非標準ヘッダー。ほとんどのメール クライアントはこれらを無視します。一部のスパム フィルターは優先度の高いマーキングを負のシグナルとして処理します。

X-Spam-Status / X-Spam-Score

スパム フィルター システム (SpamAssassin など) によって追加されます。標準化されていませんが、広く内部で使用されています。これらは発信メールに存在しません。受信インフラストラクチャによって追加されます。

問題が発生する可能性がある事項

Message-ID の欠落

Message-ID を設定しない場合、最初の MTA が設定します。ただし、送信されたメッセージとバウンスおよび配信通知を相関させる能力が失われます。送信前に常に自分の Message-ID を生成してください。

From とエンベロープ送信者の混乱

配信品質の問題の一般的な原因。From: ヘッダーは alice@example.com を表示していますが、エンベロープ送信者は bounce@esp.com です。SPF は ESP ドメインではなくあなたのドメインを検証します。DKIM 署名が d=esp.com も使用する場合、DMARC アラインメント両方のメカニズムに失敗します。修正: d=example.com で署名して DKIM をアラインさせてください。

重複または矛盾するヘッダー

RFC 5322 は、From:、Date:、Message-ID: などの一部のヘッダーがちょうど 1 回現れる必要があることを指定しています。重複はオブザーバー不可能な動作を引き起こす可能性があります。異なるメール クライアントが異なる値を選択する場合があります。一部のスパム フィルターは重複した From: ヘッダーを疑わしいものとして処理します。

Date ヘッダーの欠落

Date: ヘッダーがない場合、受信 MTA またはメール クライアントは独自のタイムスタンプに置き換えます。これは大幅に異なる場合があります。一部のスパム フィルターは Date ヘッダーのないメッセージにペナルティを与えます。

Received チェーン偽造

誰でも送信前にメッセージに偽造 Received: ヘッダーを追加できます。受信 MTA は自分で追加したヘッダーのみを信頼できます。デバッグするときは、上部 (最新) から開始して下へ進み、自分のインフラストラクチャと外部世界との間の境界に達したら信頼を停止してください。

重要なポイント

• ヘッダーはメッセージについてのメタデータです。エンベロープ (MAIL FROM / RCPT TO) が配信を制御します。ヘッダーは表示と処理用です。
• From: は受信者が表示するもの。Return-Path: はバウンスの送信先。しばしば異なります。
• Received: ヘッダーはメッセージのパスを示す下から上へのチェーンを形成します。自分のインフラストラクチャからのヘッダーのみを信頼してください。
• Authentication-Results: は SPF、DKIM、DMARC に対する受信サーバーの判定です。
• 常に Message-ID、Date、From、MIME-Version、Content-Type を設定してください。
• 一括/マーケティング メール用に、List-Unsubscribe と List-Unsubscribe-Post を含めてください。

参考資料

Related RFCs