メールヘッダーのフィールド解説：Received、From、Return-Pathなど

要点まとめ

1. ヘッダーの見つけ方。 どのメールアプリにも完全なヘッダーを表示する方法があり、「元のメッセージを表示」「ソースを表示」「メッセージの詳細」などと呼ばれています。
2. 目に見えるフィールド：From、To、Subject、Date。 From、To、Subject、Dateは、メールアプリが表示するフィールドです。
3. Received：経路。 メッセージを処理したサーバーはすべて、先頭にReceived行を追加します。
4. Return-Path、Reply-To、Message-ID。 Return-Pathにはエンベロープ送信者が入っており、バウンスの送り先であり、SPFの検証対象となるアドレスです。
5. Authentication-Results。 受信側サーバーは、SPF、DKIM、DMARCの判定結果を、検証したsmtp.mailfromやheader.dなどの識別子とともにAuthentication-Results行に記録します。
6. DKIM-Signature。 DKIM-Signatureフィールドには、署名ドメインがd=、セレクターがs=、署名アルゴリズムがa=、署名対象フィールドの一覧がh=に入っています。

ヘッダーの見つけ方

どのメールアプリにも完全なヘッダーを表示する方法があり、「元のメッセージを表示」「ソースを表示」「メッセージの詳細」などと呼ばれています。最初の行から最初の空行までをすべてコピーしてください。空行がヘッダーの終わりであり、そこからメッセージ本文が始まります。

コピーしたヘッダーは、当社のメールヘッダー解析ツールに貼り付けると、経路、遅延、認証結果が順に整理されて表示されます。

目に見えるフィールド：From、To、Subject、Date

From、To、Subject、Dateは、メールアプリが表示するフィールドです。これらは送信者が設定するもので、どんな内容にもできるため、それだけではメッセージの出所の証拠にはなりません。表示名に実際とは異なるアドレスを含めることもでき、これはよくある偽装の手口です。

Dateフィールドは、送信者がメッセージを作成した時刻を記録しています。Received行の時刻と比較すると、長い遅延を見つけられます。

Received：経路

メッセージを処理したサーバーはすべて、先頭にReceived行を追加します。各行には、どのサーバーからメッセージを受け取ったか、自身はどのサーバーか、プロトコル、そしてタイムスタンプが記録されます。下から上へ読むと、経路を順にたどることができます。

Received: from mail.example.net (mail.example.net [203.0.113.5])
        by mx.example.org with ESMTPS id abc123
        for <you@example.org>; Tue, 13 Oct 2026 16:14:12 +0000

2つのタイムスタンプの差は、メッセージがそのホップに留まっていた時間です。大きな差は、たいていキュー、グレーリスティング、または再試行を示しています。最初に信頼できるサーバーより下の行は送信者が書いた可能性があるため、慎重に扱ってください。

Return-Path、Reply-To、Message-ID

Return-Pathにはエンベロープ送信者が入っており、バウンスの送り先であり、SPFの検証対象となるアドレスです。受信側サーバーが追加します。Reply-Toは返信の送り先を示しており、Fromと異なる場合は注意して確認する価値があります。Message-IDはメッセージの一意の識別子で、通常は末尾に送信システムのドメインが付きます。

Message-IDのドメインがFromのドメインと異なることは、サービスがお客様に代わって送信する場合によくあり、それだけで不具合というわけではありません。

Authentication-Results

受信側サーバーは、SPF、DKIM、DMARCの判定結果を、検証したsmtp.mailfromやheader.dなどの識別子とともにAuthentication-Results行に記録します。メールが失敗したときに最初に読むべき行ですが、信頼できるのは自社の受信サーバーが書き込んだ場合に限られます。

Authentication-Results: mx.example.org;
 spf=pass smtp.mailfrom=bounce.example.net;
 dkim=pass header.d=example.net header.s=s1;
 dmarc=fail header.from=example.com

通常の値は、pass、fail、softfail、neutral、none、temperror、permerrorです。SPFとDKIMがどちらもpassなのにDMARCがfailになる場合は、ほぼ確実に、passしたドメインがFromとアラインメントしていないことが原因です。

DKIM-Signature

DKIM-Signatureフィールドには、署名ドメインがd=、セレクターがs=、署名アルゴリズムがa=、署名対象フィールドの一覧がh=に入っています。受信側はd=とs=を使ってDNSから公開鍵を探し、署名を検証します。

d=が自社のドメインであること、h=にFromが含まれていることを確認してください。a=rsa-sha1で作成された署名は古く強度が弱く、また、署名する本文の範囲を制限するl=タグを使うと、署名後にテキストを追加できてしまいます。

List-Unsubscribeなどの便利なフィールド

マーケティングメールにはList-Unsubscribeを付けるべきです。ワンクリック配信停止にはList-Unsubscribe-Postが必要で、GmailとYahooは大量送信者にその対応を求めています。受信側によっては、X-Spam-Statusなどのスパムフィルター用フィールドを追加し、メッセージがどのように採点されたかを示します。

ARCフィールドは、転送者やメーリングリストが自分が見た認証結果を記録したことを示しており、転送されたメッセージの最終段階でSPFが失敗する理由を説明してくれます。

参考資料と出典

• RFC 5322: Internet Message Format
• RFC 8601: Message Header Field for Indicating Message Authentication Status
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 5321: Simple Mail Transfer Protocol

MigoSMTPで実践する：ヘルプセンターの記事

• メールヘッダーを読んで認証の問題を調査する
• SMTPバウンスコードの解説
• カスタムReturn-Pathとトラッキングドメイン

関連ガイドとツール

• メールヘッダー解析ツール：ヘッダーを貼り付けると、経路と結果が分かります。
• SPF・DKIM・DMARCチェッカー：公開中のレコードを確認します。
• SPF・DKIM・DMARCの失敗を修正する：エラーの読み方と対処法。
• DMARCポリシーの解説：アラインメントとは何か。