メールヘッダーとは?内容の読み方と確認すべき理由を徹底解説

知らないメールアドレスからスパムやフィッシングメールを受け取ったことはありませんか?無料旅行への招待、個人的な写真との引き換えにビットコインを送るよう求めるメッセージ、あるいは単なる迷惑なマーケティングメールなど、その手のメールはさまざまな形で届きます。

そうしたメールが一体どこから来たのか、疑問に思ったことはありませんか?自分のメールアドレスをスパム業者に偽装(スプーフィング)され、「どうやってそんなことが可能なのだろう」と不思議に思った経験はありませんか?

メールスプーフィング、つまりメールが実際の送信元とは別のアドレスから送られてきたように見せる手法(例えばwhitehouse.govから届いたように見えて、実際は詐欺師からのもの)は、驚くほど簡単に行えてしまいます。

その理由は、中核となるメールプロトコルには認証の仕組みが一切存在しないためです。「From」アドレスは、いわば自由記入欄のようなものなのです。

普段見えているのはヘッダーの一部だけ

通常、メールを受信すると、次のような情報が表示されます。

From: Name <name@gmail.com>
Date: Tuesday, July 16, 2019 at 10:02 AM
To: Me <Me@freecodecamp.com>

この下に件名と本文が続きます。しかし、そのメールが本当にどこから来たのか、どうやって確認すればよいのでしょうか?分析に使える追加データはないのでしょうか?

鍵となるのが「完全なメールヘッダー」です。上記で見えている情報はヘッダーの一部にすぎません。完全なヘッダーには、メールがどこから送られ、どのような経路で受信箱に届いたのかを示す追加情報が含まれています。

自分のメールヘッダーを確認したい場合は、OutlookやGmailで以下の手順でアクセスできます。

• Gmailの場合: メールを開き、右上の「⋮」(その他)メニューから「メッセージのソースを表示」を選択
• Outlookの場合: メールをダブルクリックで開き、「ファイル」→「プロパティ」→「インターネットヘッダー」を確認

ほとんどのメールソフトでも同様の操作で確認でき、それ以外のメールサービスについては、簡単な検索でヘッダーの表示方法を見つけられます。

この記事では、実際のヘッダーを読み解いていきます(ホスト名、タイムスタンプ、IPアドレスは匿名化しています)。ヘッダーは上から下へ読み進めますが、新しいサーバーは自身のヘッダーをメールの最上部に追加していく点に注意してください。つまり、最終的なメッセージ転送エージェント(MTA)から読み始め、メッセージを最初に受け取ったMTAへと下っていくことになります。

内部転送の確認

Received: from REDACTED.outlook.com (IPv6 Address) by REDACTED.outlook.com with HTTPS via REDACTED.OUTLOOK.COM; Fri, 25 Oct 2019 20:16:39 +0000

最初のホップに「HTTPS」という記述があります。これは、サーバーが標準のSMTP経由ではなく、Webアプリケーションで受け取った入力からメッセージを作成したことを意味します。

Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1358.20; Fri, 25 Oct 2019 20:16:38 +0000

Received: from REDACTED.outlook.com (IPv6Address) by REDACTED.outlook.office365.com (IPv6Address) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2385.20 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000 Authentication-Results: spf=softfail (sender IP is REDACTEDIP)smtp.mailfrom=gmail.com; privatedomain.com; dkim=pass (signature was verified)header.d=gmail.com;privatedomain.com; dmarc=pass action=noneheader.from=gmail.com;compauth=pass reason=100Received-SPF: SoftFail (REDACTED.outlook.com: domain of transitioning gmail.com discourages use of IPAddress as permitted sender)

これらは最初の2つのヘッダーブロックで、内部のメール転送を示しています。Office365サーバー(outlook.com)で受信され、正しい受信者へ内部でルーティングされたことがわかります。

また、メッセージが暗号化されたSMTP経由で送信されていることも読み取れます。「with Microsoft SMTP Server」の記述に続き、使用されているTLSのバージョンと具体的な暗号スイート(cipher)が指定されているためです。

3番目のヘッダーブロックは、ローカルメールサーバーからメールフィルタリングサービスへの移行を示しています。「via Frontend Transport」とあるのは、Microsoft Exchange固有のプロトコルであるためです(厳密にはSMTPではありません)。

このブロックには、複数のメール認証チェックの結果も含まれています。Outlook.comのヘッダーにはSPF/DKIM/DMARCの判定結果が記載されています。SPF softfailは、このIPアドレスがgmail.comに代わってメールを送信する権限を持っていないことを意味します。

dkim=passは、メールが名乗る送信者のものであり、転送中に改ざんされていない可能性が高いことを示します。

DMARCは、メールサーバーに対してSPFとDKIMの結果をどのように解釈すべきかを指示するルールセットです。passであれば、メールはそのまま配送先へ進むことになります。

SPF、DKIM、DMARCの詳細については、関連記事をご参照ください。

内部から外部への移行ポイント

Received: from Redacted.localdomain.com (IP address) byredacted.outlook.com (IP address) with Microsoft SMTPServer (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id15.20.2305.15 via Frontend Transport; Fri, 25 Oct 2019 20:16:37 +0000

Received-SPF: None (Redacted.localdomain.com: no senderauthenticity information available from domain ofsender@gmail.com) identity=xxx; client-ip=IPaddress;receiver=Redacted.localdomain.com;envelope-from="sender@gmail.com";x-sender="sender@gmail.com"; x-conformance=sidf_compatible

Received-SPF: Pass (Redacted.localdomain.com: domain ofsender@gmail.com designates sending IP as permittedsender) identity=mailfrom; client-ip=IPaddress2;receiver=Redacted.localdomain.com;envelope-from="sender@gmail.com";x-sender="sender@gmail.com"; x-conformance=sidf_compatible;x-record-type="v=spf1"; x-record-text="v=spf1ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

これはGoogleのSPFレコードです。gmail.comから来ると主張するメールが、Googleが承認したサーバーから実際に送信されていることを、受信側サーバーに伝えています。

Received-SPF: None (redacted.localdomain.com: no senderauthenticity information available from domain ofpostmaster@redatedgoogle.com) identity=helo;client-ip=IPaddress; receiver=Redacted.localdomain.com;envelope-from="sender@gmail.com";x-sender="postmaster@.google.com";x-conformance=sidf_compatibleAuthentication-Results-Original: Redacted@localdomain.com; spf=Nonesmtp.pra=sender@gmail.com; spf=Pass smtp.mailfrom=sender@gmail.com;spf=None smtp.helo=postmaster@redacted.google.com; dkim=pass (signatureverified) header.i=@gmail.com; dmarc=pass (p=none dis=none) d=gmail.comIronPort-SDR: IronPort-PHdr: =X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: =X-IronPort-AV: ;d="scan"X-Amp-Result: SKIPPED(no attachment in message)X-Amp-File-Uploaded: False

ここには追加のSPF/DKIM/DMARCチェックの結果とともに、IronPortによるスキャン結果が記録されています。

IronPortは、多くの企業がスパム、ウイルス、その他の悪意あるメールを検出するために導入している代表的なメールフィルターです。メール内のリンクや添付ファイルをスキャンし、そのメールが「悪意のあるもの(破棄すべき)」「正当なものである可能性が高い(配信すべき)」「疑わしいもの(ユーザーへの警告ヘッダーを付与)」のいずれに該当するかを判定します。

送信元から受信先までの経路

Received: from redacted.google.com ([IPAddress])by Redacted.localdomain.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; Fri, 25 Oct 2019 16:16:36 -0400

Received: by redacted.google.com with SMTP idfor recipient@localdomain.com; Fri, 25 Oct 2019 13:16:35 -0700 (PDT)

X-Received: by IPv6:: with SMTP id; Fri, 25 Oct 2019 13:16:35 -0700 (PDT) Return-Path: sender@gmail.com

Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted])by smtp.gmail.com with ESMTPSA id redacted IP(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);Fri, 25 Oct 2019 13:16:34 -0700 (PDT)

Received: from senderssmacbook.fios-router.home (pool-.nycmny.fios.verizon.net. [IP address redacted])by smtp.gmail.com with ESMTPSA id redacted IP(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);Fri, 25 Oct 2019 13:16:34 -0700 (PDT)

このセクションには、送信者の初期デバイスからGmailのルーティングシステムを経由し、受信者のOutlook環境に至るまでの内部ホップが記録されています。ここから、最初の送信者がニューヨークのVerizon Fios回線を使用する家庭用ルーター経由で接続したMacbookユーザーだったことが読み取れます。

これで、送信者から受信者までのメールの経路を示すホップ情報は終わりです。これ以降はメールの本文(および通常目にする「From:」「To:」などのヘッダー)が続き、メディアタイプやメールクライアントに応じた書式情報(MIMEバージョン、コンテンツタイプ、boundaryなど)が含まれる場合があります。また、メッセージを送信したデバイスの種類に関する詳細を示すユーザーエージェント情報が含まれることもあります。

この事例では、Appleの命名規則から送信デバイスがMacbookであったことはすでに判明していますが、ヘッダーにはCPUの種類やOSのバージョン、さらにはデバイスにインストールされていたブラウザとそのバージョンまで記録されていることがあります。

ケースによっては(常にではありませんが)、送信デバイスのIPアドレスが含まれることもあります。ただし、多くのプロバイダーは法的な要請(召喚状など)がない限り、この情報を開示しないようにしています。

メールヘッダーから何がわかるのか?

メールヘッダーは、メールが名乗る送信者以外から実際に送信されていないかを特定する手がかりになります。送信者に関する一定の情報を得られますが、通常は真の送信者を特定するには不十分です。

法執行機関であれば、このデータをもとに適切なISPへ情報開示を求めることができますが、一般のユーザーにとっては、主にフィッシング調査などの参考情報として活用するのが現実的です。

ただし、この調査プロセスには落とし穴があります。ヘッダーは悪意のあるサーバーやハッカーによって偽造される可能性があるためです。各サーバーの所有者に問い合わせ、メール内のヘッダーがSMTPログと一致することを一つひとつ確認しない限り(これは非常に骨の折れる時間のかかる作業です)、ヘッダーが正確であると断言することはできません。自分のメールサーバーが付与したヘッダーを除いては、です。

DKIM、DMARC、SPFといった認証技術はこの検証プロセスを助けてくれますが、完璧ではありません。そして、これらが使われていない場合は、検証手段がまったく存在しないことになります。

自分でヘッダーを分析するのが面倒な場合は、ヘッダーを自動解析してくれるオンラインツールを利用するのも一つの手です。