メールヘッダー（Email Header）

2025/05/02

概要
SPF・DKIM・DMARC(認証技術)
メールヘッダーの表示方法
メールヘッダーの解析
SPF認証の結果
DKIMの正しい評価法
DKIM未署名メールに対する対応
WHOIS情報の確認方法
AbuseIPDB
感想

概要

*以前のメールヘッダー記事をこちらにまとめました。

最近、特に金融関係のフェイクメールが多くなった。パスワードが盗まれて証券会社のネット口座が悪用されているらしい。

　先日来たメール :

　"【ご注意ください】野村證券を装ったフィッシング詐欺による不正取引が多発しています。
　これに伴い、野村證券では、さらなるセキュリティ強化策を講じることとなりました。
　2025年5月1日（木）以降、すべての口座に対し、事前認証手続きを義務付けます。
　本手続きが未完了の場合、ログイン・取引・出金を含む一切のサービスが即時停止されます。
　速やかに以下のリンクから手続きを行ってください。
　.................................."

野村証券と取引はなく、メールヘッダーを解析してもフェイクメールと解るが、実際に口座を持っている人のなかには、リンクを開いてパスワード入力をしてしまうかもしれない。

2段階認証していても突破される例として、

ユーザーが偽メールにある偽サイトのリンクからID/パスワードを入力してログイン
その先ではハッカーが別画面で本物のサイトに同じID/パスワードでログイン
登録してあるスマホに認証コードが送られてくる
ユーザーは偽サイトで認証コードを入力
ハッカーも本物のサイトにその認証コードを入力して本物のサイトにログインする。

証券会社の口座と入出金する銀行口座は登録制だから大丈夫と思っていても、次のような被害が報告されている。不正にログインされた口座内の株式を全て売却し、その売却代金で低価格で売買の少ない株(中国株)を大量購入し株価が吊り上がった時点で別口座から売ってしまう。結果、口座には低価格の株が残る。

決して、メールにあるリンクは開かずに、心配ならブックマークしてあるサイトのURLからログインする。まともな会社であれば緊急に必要なアクションはログインしてすぐに重要メッセージとして表示されるはず。常日頃から特に金融関係のサイトはブックマークしておくことが肝要。

フェイクメールの多くは、件名を検索するだけで正体が割れる。怪しいタイトルはネット上で多数報告されている。だが、件名だけでは判断しきれないケースもある。

そんなときに役立つのが、メールヘッダーに含まれる技術的な情報。送信元サーバー、経由サーバー、認証結果などが詳細に記録されており、見慣れれば不正の兆候が読み取れるようになる。

今回はこのメールヘッダーの中身を、ChatGPTとの対話を通じて解析し、フェイクメールを見抜く具体的な方法を紹介する。迷惑メールに慣れてしまい、つい見過ごしがちな一通にも、リスクは潜んでいる。被害を防ぐためには、メールの中身よりもまず出どころを疑え。メールヘッダーはその最前線の手がかりとなる。

🔰 ドメイン , IPアドレス , DNS とは (click)

📧 メールアドレス「xxxx@yyyy.jp」から学ぶ：ドメインとIPアドレスのしくみ（初心者向け）私たちが使っているメールアドレス「xxxx@yyyy.jp」は、2つの大事な要素でできています： xxxx：これはメールアカウント名（ユーザー名）です。 yyyy.jp：これはドメイン名と呼ばれます。 ■ ドメイン名とは？ドメインはインターネット上の名前付きの住所です。ここでの「yyyy.jp」は、メールを管理している組織（会社や学校など）のドメイン名です。「jp」は「日本」を表すトップレベルドメイン（TLD）です。「yyyy」は、その下にある会社名や団体名などを表します。たとえば： @gmail.com → ドメイン名は「gmail.com」 @docomo.ne.jp → ドメイン名は「docomo.ne.jp」 @yyyy.jp → ドメイン名は「yyyy.jp」つまり、ドメイン名は「@」を含まず、メールアドレスの後ろ半分のうち、組織やサービスを表す部分だけを指します。 ■ IPアドレスとは？インターネットの世界では、実際の通信はIPアドレスという数字で行われます。例： 203.0.113.5 というような数字がIPアドレスです。 IPアドレスは、インターネット上の正確な住所です。ただし、数字だけでは覚えにくいので、私たちは「yyyy.jp」のようなドメイン名を使って通信しています。 ■ ドメインとIPアドレスの関係ドメイン名（例：yyyy.jp）は、実際にはDNSという仕組みを使ってIPアドレスに変換されてから通信に使われます。 📬 メールが届く流れ（簡略版）：「xxxx@yyyy.jp」にメールを送信。インターネットが「yyyy.jp」のIPアドレスをDNSで調べる。正しいメールサーバーにメールが届けられる。 ■ まとめ項目説明ユーザー名（xxxx）メールを使う人の名前。ドメイン名（yyyy.jp）メールの所属組織を示す名前（@は含まない）。 IPアドレスインターネット上の正確な住所。 DNS ドメイン名をIPアドレスに変換する仕組み。

SPF・DKIM・DMARC(認証技術)

まずは予備知識 : メールには、送受信時に必要な情報や配送経路を記録した「メールヘッダー」が含まれている。メールヘッダーには、宛先、送信元、件名といった基本情報に加え、メールがどのサーバーを経由して送られたか、送信日時、IPアドレス、認証情報などの詳細情報も記録される。また、メール認証技術としてSPF、DKIM、DMARCが利用される。

🔍 用語解説

用語	意味
SPF（Sender Policy Framework）	メール送信が許可されたIPアドレスをDNSで宣言する仕組み。受信側は、送信元IPが許可リストにあるか確認する。
DKIM（DomainKeys Identified Mail）	メールに電子署名をつけて送信し、改ざんされていないか＆正規の送信元かを検証。署名の検証にはDNSにある公開鍵を使う。
DMARC（Domain-based Message Authentication, Reporting & Conformance）	SPFやDKIMの検証結果に基づき、受信側がどう処理するかをドメイン所有者が指定できる仕組み。また、検証結果レポートを送信させることも可能。
DNS（Domain Name System）	ドメインに関する情報（SPFレコード、DKIM公開鍵、DMARCポリシーなど）を記録しているシステム。
検疫（quarantine）	スパム扱いなどにして受信者の迷惑メールフォルダなどに振り分けること
拒否（reject）	メールを受け取らない（配送エラーとして拒否）という処理。

🧭 補足ポイント 1. SPFとDKIMは技術的認証の手段 * SPFは「誰が送ったか（IPの正当性）」を確認。 * DKIMは「何が送られたか（内容が改ざんされていないか）」を確認。 2. DMARCは判断ルールと報告機能 * SPFやDKIMのどちらか（あるいは両方）にパスしなかった場合、どう処理するかはDMARCが決める。 * また、DMARCの設定により、メールの受信結果がドメイン管理者に定期レポート（XML形式）で送られる。 3. DNSにすべての宣言情報がある * SPF・DKIM・DMARCすべて、送信ドメインのDNSに情報を登録する。 * これにより、受信サーバーは正しいかどうかをチェックできる。 🧩 まとめ：図の一言解説 > 送信側のドメインは、DNSで「どのIPが送信OK」「署名の鍵」「どう処理すべきか」を宣言し、受信側はSPF・DKIMを検証した上でDMARCポリシーに従ってメールを処理する。そして結果をレポートでフィードバックする。

参考)
xxxx@yyyy.jpのメールアドレスの場合、windowsのコマンドプロンプトで次のコマンドでDMARCのポリシーが表示される
  C:\Users\abc>nslookup -type=TXT _dmarc.yyyy.jp　
  C:\Users\abc>_dmarc.yyyy.jp  text ="v=DMARC1; p=none; rua=mailto:dmarc_report@yyyy.jp"
  説明: 
    v=DMARC1 : バージョン
    p=none : 何もしない、
    ( p=quarantine	 : 怪しいメールは迷惑メールフォルダに入れるなどの措置を推奨
      p=reject : 認証に失敗したメールは拒否する（最も厳格）)
    rua=mailto:dmarc_report@yyyy.jp : メールの送信先

メールヘッダーの表示方法

メールヘッダーの見方について。

メーラー	操作
Outlook(office)	メールを2度クリック > ファイル > プロパティ > インターネットヘッダー
Outlook.com	メールの右上 [...] > 表示 > メッセージのソースを表示
Gmail	メールの右上 [︙] > 原文を表示
yahoo!メール	メールの右上 [詳細ヘッダー]
Thunderbird	メールの上[表示] > メッセージのソース
Macメール	メールの [表示 ] > メッセージ > ソース

フェイクメールのサンプル

先日送られてきた GMOクリック証券を騙るフェイクメール。GMOクリック証券から注意記事が出ている。*メールのソースに中国語のコメントがあった。

【GMOクリック証券】ご利用設定に関するご確認のお願い

GMOクリック証券 <mail.monex-mldnnfql@service.●●●●.cn> 宛先　bluebee@zarc.cars.ne.jp 重要なお知らせ 平素よりGMOクリック証券オンラインサービスをご利用賜り、誠にありがとうございます。昨今の情報通信環境の変化および外部リスクの高まりを受け、当社ではセキュリティ対策の一環として、2025年4月末を目途に「接続環境の最適化機能」の導入を予定しております。本機能では、IPアドレスや端末情報等の技術情報を活用し、異常なアクセス経路の検出や操作支援の自動化を図ります。取得する情報は、継続的かつ安全にサービスをご利用いただくためにのみ使用され、本人確認や認証等の目的には使用いたしません。【ご対応内容】 1. ご利用中の環境（IP・地域・ブラウザ等）の確認 2. 内容をご確認のうえ、登録を完了 3. 登録済み環境からのご利用時には、一部確認が省略されます

本人確認を行う→

安全で快適なお取引環境のため、ご理解・ご協力をよろしくお願い申し上げます。【お客様へのお願い】・本メールはお客様個人宛ての重要なお知らせです。他者への転送、複製は禁止いたします。・誤受信の場合は速やかに送信元にご一報の上、削除をお願いいたします。・メールにて個別のお取引や残高についてのご質問には対応できません。＜お問い合わせ先のご案内＞お問い合わせ内容別に専用窓口がございます。詳しくは以下URLからご確認ください。　　　　　　　　　　　　　　　　　© GMOクリック証券 CO., LTD. All rights reserved.

メールヘッダーの解析

次のメールヘッダーを詳細に説明してください: 実際のメールの例。セキュリティ上ipアドレス､ドメイン名は変更してある。

①　Return-Path: <mail.monex-mldnnfql@service.●●●●.cn>

➁　Received: from imtb1234.zarc.eot.ne.jp by ibmta0007-jc.im.ntti.ne.jp
          with ESMTP
          id <20250429095153803.RJCI.31027.imtb1234.zarc.eot.ne.jp@imtb1234.zarc.eot.ne.jp>
          for <bluebee@zarc.cars.ne.jp>; Tue, 29 Apr 2025 18:51:53 +0900
　　Received: from service.●●●●.cn([107.△△△.△△△.86])   
          by ifmta0007-jc.im.xxx.ne.jp with ESMTP
          id <20250429095153565.CGYW.27850.service.●●●●.cn@imtb1234.zarc.eot.ne.jp>
          for <bluebee@zarc.cars.ne.jp>; Tue, 29 Apr 2025 18:51:53 +0900
　　Received: from mail.nbptt.zj.cn (165.△△△.△△△.78) by service.●●●●.cn id h22gji0001gh for <bluebee@zarc.cars.ne.jp>; Tue, 29 Apr 2025 05:41:50 -0400 (envelope-from <mail.monex-mldnnfql@service.●●●●.cn>)

➂　DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mykey; d=●●●●.●●●●.cn;
 　　h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type;
　　 bh=4K8NDp9wkeVO7AHn7TKjykEmIgg=;
 　　b=i9hh2D3UphZn+zLnXLtlaRXm+DLX2tt0/dykk9OCe1WFXuQfjt4mMT0NDFkuhsmqPDjn27cfTvfE
   CK7Q0BHsSKp5dQKlBgSXe66+XlSTOQERp3JkYIsm8mqklwakXO/Vc157YxDfm5qCbRNb0y/q997j
   UpvdSJ571Q2APe3ZdcI=

Date: Tue, 29 Apr 2025 18:41:39 +0900
⑤　From: =?utf-8?B?R01P44Kv44Oq44OD44Kv6Ki85Yi4?= <mail.monex-mldnnfql@service.●●●●.cn>
To: <bluebee@zarc.cars.ne.jp>
⑥　Subject: =?utf-8?B?44CQR01P44Kv44Oq44OD44Kv6Ki85Yi444CR44GU5Yip55So6Kit5a6a44Gr6Zai44GZ44KL?=
	=?utf-8?B?44GU56K66KqN44Gu44GK6aGY44GE?=
Message-ID: <20250429184149623263@service.●●●●.cn>
⑦　X-mailer: Foxmail 6, 13, 102, 15 [cn]
Mime-Version: 1.0
⑧　Content-Type: multipart/alternative;
	boundary="=====003_Dragon561118115488_====="

④　Authentication-Results: mx.zarc.eot.ne.jp; spf=pass
	 smtp.mailfrom=mail.monex-mldnnfql@service.●●●●.cn; sender-id=pass
	 header.From=mail.monex-mldnnfql@service.●●●●.cn
X-VC-DATE: Tue, 29 Apr 2025 18:51:53 +0900

このメールヘッダーは、メールがどのサーバーを経由して送られてきたか、送信元が正当かどうか、どんなツールで作成されたかなどを知るための情報です。順に詳細に解説します：　 ① Return-Path: Return-Path: <mail.monex-mldnnfql@service.●●●●.cn> - 意味：エラーが発生した際に返信されるメールアドレス（envelope from）。 - 特徴：`monex` を装っていますが、実際のドメインは `.cn`（中国）。これは非常に怪しく、フィッシングの可能性が高いです。 ② Received（メール配送ルート）: これらは「どのサーバーを経由したか」を示します。下から上に読みます。 a. 一番下のReceived: Received: from mail.service.●●.cn (165.△△△.△△△.78) by service.●●●●.cn id h22gji0001gh for ; Tue, 29 Apr 2025 05:41:50 -0400 - `165.△△△.△△△.78` というIPから、`service.●●●●.cn` というサーバーがメールを受け取った。 - 明らかに中国のISP/サーバーで構成されており、信頼性に欠けます。 b. 中間のReceived: Received: from service.●●●●.cn([107.△△△.△△△.86]) by ifmta0007-jc.im.xxx.ne.jp with ESMTP - `service.●●●●.cn` から、日本のメールゲートウェイに転送されています。 - `107.△△△.△△△.86` はアメリカのVPSホスティング（たとえばVultr等）で使われがちなIPで、スパム送信に利用されることも多いです。 c. 最上位のReceived: Received: from imtb1234.zarc.eot.ne.jp by ibmta0007-jc.im.xxx.ne.jp ここは正規のプロバイダ処理です。 ③ DKIM-Signature: d=service.●●●●.cn; - ドメイン `service.●●●●.cn` によってDKIM署名されています。 - 技術的には有効ですが、信頼できないドメインによる署名であるため、信頼性はなし。 ④ Authentication-Results: spf=pass sender-id=pass - SPFとSender-IDは通過していますが、これは詐欺送信でもよく使われるテクニックで、正当性を保証しません。 - メールヘッダーを偽装していても、SPFを通すことは可能です。 ⑤ From: =?utf-8?B?R01P44Kv44Oq44OD44Kv6Ki85Yi4?= *GMOグループ株式会社 (筆者注) <mail.monex-mldnnfql@service.●●●●.cn> - 表示名は「GM○（たぶんGMO）」を装っていますが、実際のドメインは "service.●●●●.cn"で完全に無関係。 - 偽装された差出人です。 ⑥ Subject（件名）: =?utf-8?B?...?= - 日本語がBase64でエンコードされており、内容はGMOや金融サービスっぽいキーワードを含む可能性が高い。 - フィッシングでよく見られる形式です。 ⑦ X-mailer: Foxmail 6, 13, 102, 15 [cn] - 中国製のメールソフト「Foxmail」で送信。一般的な企業メールで使われることはまずありません。攻撃者が好んで使うツール。 ⑧ Content-Type: multipart/alternative; boundary="=====003_Dragon561118115488_=====" - HTMLメールとテキストメールの両方を含む構成ですが、不審な境界文字列が特徴的で、マルウェア埋め込みがある場合も。 🔍 結論（このメールの評価） - ✅ SPF/Sender-ID/DKIMは形式上は通っている - ❌ 送信元IPは怪しい（VPSや中国サーバー経由） - ❌ 差出人ドメインがGMOではなく中国の不審ドメイン - ❌ メールソフトがFoxmailで典型的なスパム送信に使用される - ❌ 件名・内容・表示名は偽装されている 🔒 このメールは： > 高確率でフィッシングメール（詐欺メール）です。絶対にリンクをクリックしたり返信しないでください。

SPF認証の結果

フィールド名	例	説明
spf=	spf=pass / spf=softfail / spf=fail	SPF認証の結果。 pass: SPF認証成功 softfail: 許可されていないが完全拒否ではない fail: SPF認証失敗（詐称の可能性高）
smtp.mailfrom=	smtp.mailfrom=user@example.com	エンベロープFrom（Return-Path）。 SPFチェックに使われる実際の送信元アドレス。
header.From=	header.From=info@shop.com	メール本文のFromヘッダー。表示名に使われる差出人。詐称されやすい部分。
sender-id=	sender-id=softfail	Sender IDの結果（Microsoft独自）。 SPFと似た技術で、`From:`ヘッダーを対象に認証。
policy=	policy=neutral / none	DMARCポリシーの適用状況（SPFと連携して使われる）。*省略される場合も。

DKIMの正しい評価法

DKIMの正しい評価法を解説して : より詳しく。

　*DKIMの構造(筆者):

DKIM-Signature: v=1; ← バージョン a=rsa-sha1; ← アルゴリズム（署名にSHA-1を使用：古く危険） c=relaxed/relaxed; ← ヘッダーとボディの整形方法 s=mykey; ← セレクタ（DNS上の公開鍵を探すキー） d=service.●●●●.cn; ← 署名ドメイン h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; ← 署名対象ヘッダー bh=4K8NDp9wkeVO7AHn7TKjykEmIgg=; ← 本文のハッシュ（base64） b=（長い署名値） ← この署名全体をDKIM秘密鍵で暗号化したもの

DKIM（DomainKeys Identified Mail）の正しい評価方法は、単に「DKIM署名が検証に成功したか（=pass）」を見るだけでは不十分です。ドメインの信頼性、署名の整合性、DMARCとの組み合わせなど、以下の要素を包括的に評価する必要があります。 ✅ DKIMの正しい評価ポイント一覧 ① 署名が技術的に検証成功しているか（pass） - 最初の条件。メールヘッダーの `Authentication-Results:` に `dkim=pass` とあるか確認。 - 署名が壊れている（途中で改ざんされた、経路で変更された）と `fail` になる。例: Authentication-Results: spf=pass dkim=pass dmarc=pass ② `d=` で示される署名ドメインがFromのドメインと一致しているか - `From:` のアドレスと、`DKIM-Signature:` の `d=example.com` が同じかどうか。 - ✅ 一致：信頼性あり（例: `From: user@example.com` かつ `d=example.com`） ⚠️ 不一致：第三者による署名（中継者や悪用の可能性）例: From: alerts@bank.example.com DKIM-Signature: d=bank.example.com; ← 一致 → OK From: alerts@bank.example.com DKIM-Signature: d=suspicious-domain.cn; ← 不一致 → 注意 ③ 署名ドメイン（`d=`）が信頼できるか？ - 信頼性のある企業や団体のドメインであるか。 - 以下のようなケースは信頼性がないと判断される： - 無意味なランダムドメイン（例: `kxrmqz.cn`） - ドメインにアクセスしても企業情報がない - Whois情報が匿名登録 - ブラックリストに登録されている - SNSや企業サイトに登場しないドメイン ④ 署名対象のヘッダー項目が正しく網羅されているか - DKIMは署名に含めるヘッダー項目を `h=` で指定しています。 - 重要なヘッダー（例：`From`, `Subject`, `Date`, `To`）が署名対象に含まれているか確認。 - 改ざん防止の観点からも、最低限 `From` は必須。例: h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; ⑤ 公開鍵がDNSに適切に登録されているか - `d=`（署名ドメイン）と `s=`（セレクタ）を元に、`s._domainkey.d` の形式でDNSから公開鍵を取得し検証します。 - この公開鍵が改ざんされていないか、正しく構成されているかも大事ですが、通常はメールサーバー側が処理します。 ⑥ DMARCと連携した整合性チェック（Fromとの整合性） - DMARCでは、「DKIMまたはSPFがpassし、かつFromのドメインと一致している必要がある」と定義されています。 - DKIM評価の信頼性は、DMARCが"pass"になって初めて確定的な意味を持つ。 🧠 総合評価の観点

チェック項目	説明	良い例	危険な例
DKIM署名 pass	署名の技術的整合性	`dkim=pass`	`dkim=fail`
Fromとの一致	`From:` と `d=` が一致	両方 example.com	From=gmo.jp, d=●●●●.cn
ドメイン信頼性	実在企業ドメイン	gmo.jp, google.com	無意味な文字列.cn
DMARC整合性	DMARCがpassしている	dmarc=pass	dmarc=fail

📌 結論：DKIM評価で大切なこと > ✅ "DKIM=pass" だけでは安全とは言えない。 > 本当に大切なのは、「誰が署名したか」「署名ドメインが信頼できるか」「Fromと一致しているか」の3点。

DKIM未署名メールに対する対応

では、主要なメールサービス（Gmail・Outlook・Yahoo!メール）のDKIM未署名メールに対する対応の違いを比較表でご紹介します。 ✅ DKIM未署名メールへの対応比較表（2025年時点）

項目 / サービス	Gmail	Outlook.com（旧Hotmail）	Yahoo!メール
DKIMがないだけで即ブロック？	❌ 原則ブロックしない（※1）	❌ 原則ブロックしない	❌ 原則ブロックしない
迷惑メールに入る可能性	高（他要素と総合判断）	高	高
SPFまたはDMARCが有効なら？	通常は通過	通過する傾向あり	通過する可能性あり
FromドメインとReturn-Pathの不一致	非常に厳しく評価される	緩めだが評価対象	緩め
DMARC `p=reject` の場合	拒否または迷惑メール行き	一部拒否／一部迷惑メール扱い	通常は迷惑メールへ
送信元IPの評判が悪い場合	拒否またはスパム扱い	同上	同上
警告表示（なりすましの可能性など）	✅ 強い警告（赤文字バナー）	⚠️ ラベル表示のみ	⚠️ ラベル表示

🔍 備考 - ※1 Gmailでは、「DKIMなし・SPF失敗・DMARCなし・内容が怪しい」メールは高確率で迷惑メールフォルダ行きです。 - Outlook.comは、比較的「内容や送信元の評判」による判定が強く、SPFと送信元の整合性が重要視されます。 - Yahoo!メールは、警告表示はあるものの、迷惑メール振り分けがやや甘いという声もあります。 📌 管理者向けヒント（メールが届かない場合） - 自ドメインの送信メールが受信者側でブロックされている／迷惑メールになる場合は： 1. SPFレコードの設定 2. DKIM署名の追加 3. DMARCレコードの導入（p=noneから始める） 4. 送信元IPアドレスのクリーンな評判維持が効果的です。

WHOIS情報の確認方法

WHOIS（フーイズ）とは、ドメイン名やIPアドレスの登録情報を確認できるインターネット上の公開データベース。

ドメイン名	対象のドメイン（例：example.com）
登録者（Registrant）	ドメインの所有者（法人名や個人名）※現在は匿名化されることが多い
登録年月日	ドメインの登録日
有効期限	録の有効期限（期限切れで失効する可能性あり）
ネームサーバー情報	DNSサーバーのアドレス（どのサーバーで管理されているか）
レジストラ	ドメインを管理・販売している事業者（例：お名前.com、GoDaddyなど）
技術連絡先・管理連絡先	技術的・運用上の連絡先（最近は匿名化が多い）

DomainTools :ドメイン情報の収集と分析に特化したアメリカ・シアトルの企業。これまでに蓄積された120億を超えるドメイン情報と日々新たに登録されるドメインをリアルタイムに収集。

DomainToolsで署名ドメイン"●●●●.cn"を調査

Whois Record for ●●●●.cn How does this work? Domain Profile Registrar 大连市●●●●科技有限公司 IANA ID: — URL: — Whois Server: — Registrar Status Dates 316 days old Created on 2024-06-18 Expires on 2025-06-18 Name Servers DAX.NS.CLOUDFLARE.COM (has 29,842,109 domains) LUCIANA.NS.CLOUDFLARE.COM (has 29,842,109 domains) IP History 13 changes on 13 unique IP addresses over 1 years Hosting History 4 changes on 5 unique name servers over 1 year Whois Record ( last updated on 20250430 ) Domain Name: ●●●●.cn ROID: 20240618s10001s58549699-cn Domain Status: ok Registrant: 陈●● Registrant Contact Email: Sponsoring Registrar: 大连市●●●●科技有限公司 Name Server: ●●●●.ns.cloudflare.com Name Server: ●●●●.ns.cloudflare.com Registration Time: 2024-06-18 09:29:37 Expiration Time: 2025-06-18 09:29:37 DNSSEC: unsigned

この WHOIS 情報から読み取れる内容と、それに基づくセキュリティ評価を以下に整理して説明します。 ✅ 基本情報の読み取り

項目	内容	解説
ドメイン名	`●●●●.cn`	評価対象のドメイン
登録日	2024-06-18	非常に新しい（約10ヶ月前）＝信頼性低い可能性
有効期限	2025-06-18	登録期間1年だけ＝短期使い捨ての可能性あり
登録者（Registrant）	陈●●（Chen ●●）	中国人名。ただし連絡先メールアドレスなし＝不透明
レジストラ	大连市●●●●科技有限公司	小規模レジストラ（悪用されやすい傾向あり）
ネームサーバー	Cloudflare（`dax.ns.cloudflare.com`, `luciana.ns.cloudflare.com`）	CloudflareはCDNとして合法的に使われるが、悪用ドメインの隠蔽にも使われることがある
DNSSEC	未署名（unsigned）	DNS改ざん対策がされていない＝セキュリティレベル低

🚩 危険兆候と評価 ❗ ① 登録が非常に新しい - 登録日が 2024年6月18日 → 現時点で約10ヶ月前。 - フィッシングや詐欺に使われるドメインの多くが取得後1年以内に使い捨てされる傾向があり、該当。 ❗ ② 登録期間が短い（1年だけ） - 正規の企業ドメインは通常 3年以上の長期契約をして維持します。 - 1年登録のみは「捨てアカウント」の可能性が高いです。 ❗ ③ レジストラが小規模・中国国内業者 - `大连市●●●●科技有限公司`（英語では“Dalian ●●●● Technology Co., Ltd.”）は、大手ではなく、スパム・詐欺用ドメインの登録に使われた事例もあります。 ❗ ④ 登録者情報が不完全（メールアドレスなし） - 現在のWHOISには連絡先メールアドレスが記載されていない。 - 本来、正規のドメイン登録には連絡手段が必要。これは「追跡を避ける目的」の匿名化の可能性。 ⚠ ⑤ Cloudflare使用 - Cloudflareの利用自体は悪ではありませんが、**ドメイン所有者のIPやサーバー情報を隠すことが可能**。 - スパム・詐欺サイトはCloudflareを悪用して実態を隠すことがあります。 ✔ 結論 > このドメイン（`●●●●.cn`）は信頼できない用途（詐欺・フィッシング）に使用されるリスクが高いと考えられます。理由： - 登録が新しく、短期間で、匿名性が高い - レジストラが信頼性の高くない中国国内業者 - 本文・ヘッダーともに正規企業を装う内容と組み合わさっているさらに進めて、ドメインに関連するIPのブラックリスト状況を調査することもできますが、進めましょうか?

AbuseIPDB

AbuseIPDB: インターネット上で悪意のあるIPアドレスに関する情報を収集・共有するプラットフォーム。ユーザーからの報告を基に、スパム、ハッキング、サイバー攻撃など、悪意のあるアクティビティに関わるIPアドレスをデータベース化している。

AbuseIPDBサイト

要約 : IP Abuse Reports for 107.△△△.△△△.86: This IP address has been reported a total of 6 times from 3 distinct sources. 107.△△△.△△△.86 was first reported on March 29th 2025, and themost recent report was 5 days ago. Recent Reports: We have received reports of abusive activity from this IP address within the last week. It is potentially still actively engaged in abusive activities

日本語訳 : 107.△△△.△△△.86 の IP 不正使用報告このIPアドレスは、3つの異なるソースから合計6回報告されています。 107.△△△.△△△.86は2025年3月29日に最初に報告され、最新の報告は5日前です。

最近の報告：このIPアドレスから過去1週間以内に不正行為の報告を受けています。このIPアドレスは、現在も不正行為が活発に行われている可能性があります。

感想

今回のメールは、IPアドレスとドメイン調査でブラックリストに載っていたことが判明。

自分で迷惑メールのルールを設定していなくても、メールが「迷惑メールフォルダー」に自動的に振り分けられていることがある。これは、DMARC認証の結果などに基づいて、受信側のメールサービスが迷惑メールと判断した場合に起こることがある。

認証技術の全世界の採用割合(2024年)

認証技術	採用率（世界平均）	備考
SPF	約85～90%	最も広く普及している技術。無料で設定も比較的簡単。
DKIM	約70～80%	SPFより少し導入が難しく、一部中小では未導入
DMARC	約30～50%	設定率がまだ低め。ポリシー設計に知識が必要。

※これらはメールセキュリティ企業（Valimail、Cisco Talosなど）の公開レポートを基にした概算です。

メールサーバーの管理者の立場では、認証技術は難解であり、複雑なケースを考慮すると安易な判断を避けたいと考えるかもしれない。その場合、受信者側も自己責任で判断する必要がある。

補足 : 悪意のあるメールを使う場合に送り手がCloudflareを使うメリットはあるか?

はい、攻撃者が悪意あるメールを送信する際に、Cloudflareを利用することにはいくつかの「技術的なメリット」があります。ただし、Cloudflare自体は正当なセキュリティ・高速化サービスであり、悪用を意図して設計されたものではありません。それでも、攻撃者が間接的にCloudflareを利用するケースは存在します。悪意のあるメールとCloudflareの関係（攻撃者視点の「メリット」） ① フィッシング用の偽サイトのホスティングにCloudflareを利用 Cloudflareを使って偽サイトをホスティングし、次のような利点を得ます：攻撃者のメリット説明 IPアドレスの匿名化 Cloudflareのリバースプロキシにより、本当のホスティングサーバーのIPアドレスが隠れる（Whois調査等で特定困難） HTTPS（SSL）証明書を無料で入手無料SSLにより、見た目は安全そうな「https://」付きのURLにでき、ユーザーを信用させやすい CDNによる高速表示偽サイトでも高速に表示されるため、正規サイトのように見える（ユーザーが不信感を抱きにくい） Bot検出やレート制限などの機能を悪用セキュリティ製品やスキャンツールのアクセスをブロックするよう設定できる（セキュリティ会社からの分析妨害） ② Cloudflare Tunnel（旧Argo Tunnel）を悪用するケース Cloudflare Tunnelを使うと、ポート開放なしにインターネット公開ができます。これを悪用して、内部ネットワークから外部に不正アクセス用のバックドアを作ることも技術的には可能です。 ③ Cloudflareを“正規の信頼マーク”として利用受信者がCloudflareの証明書やURL構造を見て「安心」と思う可能性がある。 Cloudflareのブランドが信頼されているため、偽サイトの信頼性を装う材料になる。 🚫 Cloudflareの対策と制限 Cloudflareも当然このような悪用を防ぐ取り組みをしています：フィッシングやマルウェアサイトは通報があれば速やかに停止されるセーフブラウジングや各種機械学習によりドメインの挙動監視 Abuseレポートポータル（https://abuse.cloudflare.com）による対応 ✅ 結論まとめ Cloudflare自体はセキュリティと高速化を提供する正規のサービスですが、攻撃者はその機能（匿名化・SSL・スピードなど）を悪用して、フィッシングサイトの“信頼性を装う”ために使うことがあります。そのため、メールに記載されたURLがCloudflare経由（例：cdn.cloudflare.comやssl.cf-ip.com）だからといって安全とは限らないのです。

戻る