2026年「還付金確定通知書を格納いたしました」は詐欺メール?国税庁(e-Tax)をかたるフィッシングの見分け方

この記事は、スパムアサシンやメーラーでのスパム判定をすり抜けた怪しいメールを取り扱います。その内容の判定や設定方法の改善策について取り扱います。巧妙化する攻撃に対応について記載します


結論から言うと、このメールは国税庁を装ったフィッシング詐欺です。リンクは開かず、メールは削除してください。

2026年10月11日(日)、筆者のもとに「【重要なお知らせ】還付金確定通知書を格納いたしました」という件名のメールが届きました。差出人は「e-Tax」で、国税庁のドメインから送られたように見えます。

迷惑メール判定は受けておらず、一見すると本物のように見えます。この記事では、同じメールを受け取って「本物かどうか」を調べている方のために、偽物と判断した根拠と、開いてしまった場合の対処法をまとめます。

届いたメールの内容

件名と本文の要点は次のとおりです(リンクは無効化しています)。

  • 件名:【重要なお知らせ】還付金確定通知書を格納いたしました
  • 内容:令和8年分の所得税確定申告の還付金が確定し、通知書をe-Taxのメッセージボックスに格納した。確認期限は令和8年10月1日。
  • 誘導:Android版e-Taxアプリをインストールしていない場合は、ボタンからダウンロードするよう案内。
  • リンク先:hxxps://ojzvvq[.]cn/?ywtxqcrw

同じ文面が届いた方は、以下の見分けポイントと照らし合わせてみてください。

偽物と判断できる7つの理由

1. 存在しない通知である(日付の矛盾)

本文は「令和8年分(令和8年1月1日〜12月31日)の確定申告の還付金が確定した」と述べています。しかし令和8年分は、メールが届いた2026年10月11日時点でまだ年が終わっていません。申告は令和9年(2027年)の2月〜3月ごろに行うもので、還付金が確定しているはずがありません。

さらに、確認期限が「令和8年10月1日」で、メールが送られた時点で10日も過ぎています。期限切れの日付を書いている時点で、おかしな通知です。

2. リンク先が国税庁のサイトではない

ボタンのリンク先は ojzvvq[.]cn というランダムな文字列のドメインで、国税庁のドメイン(nta.go.jp)とは無関係です。末尾の ?ywtxqcrw は、受信者や配信ロットを識別するためのものと考えられます。

.go.jp は日本の政府機関しか取得できないドメインです。リンク先が .go.jp で終わっているかどうかは、見分ける際の基本ポイントです。

3. 本文の内容が矛盾している

  • 「通知はアプリ内のメッセージボックスでのみ確認できる」と説明しながら、外部サイトのボタンへ誘導している
  • 「Android版」のインストールだけを強調している

偽サイトで情報を入力させる、またはAndroid用の不正なアプリ(マルウェア)をインストールさせるのが目的と考えられます。ただし、筆者は偽サイトにアクセスしていないため、実際の動作は確認していません。

4. 本物の文章とリンクを混ぜて信頼させようとしている

後半には、マイナンバーカード方式の説明や個人情報保護方針が長々と書かれています。公式サイトの文章を流用したものと思われ、e-tax.nta.go.jp、digital.go.jp など本物のリンクも混ざっています。国税庁の所在地や法人番号も記載されていますが、これらは公開情報です。本物のリンクや情報が含まれていても、本物の証拠にはなりません。

5. 不自然な日本語がある

  • 「e-Taxボームページ」「ホームベージ」(正しくは「ホームページ」)
  • 「ー部サービス」(漢数字の「一」ではなく長音記号)
  • 文頭の不自然な中黒「·」

公式文書をコピーして加工した形跡とみられます。

6. 「お金」と「期限」で焦らせる

還付金という「得をする話」と、確認期限という「急がせる要素」の組み合わせは、フィッシングの典型的な手口です。冷静に考える時間を与えないための工夫です。

7. メールヘッダが「国税庁からではない」ことを示している

メールの送信元情報(ヘッダ)を調べると、差出人の詐称がはっきり分かりました。

調べた項目結果分かること
送信元の認証(SPF)失敗国税庁ドメインの送信元として許可されていないIPアドレスから送られた
電子署名(DKIM)なし正規のメールに付く署名がない
DMARC失敗送信元の詐称を見抜くための仕組みの判定も不合格
送信元IPアドレス59.59.212[.]137(逆引きできず)国税庁のサーバーとは対応しない。日本のIPアドレス管理機関(JPNIC)の検索では該当データなし
送信ソフトFoxmail(中国語圏向けのメールソフト)国税庁が使うとは考えにくい
送信日時のタイムゾーン+0800(中国標準時)日本の機関なら通常+0900(日本標準時)
URLの検査本文中のURLがフィッシング用のブロックリストに該当すでに危険なURLとして知られている

差出人、Return-Path、Message-IDのすべてが e-tax.nta.go.jp になっており、送信ドメインそのものを詐称していました。

なぜ迷惑メール判定をすり抜けたのか

認証に失敗しているのに配信された理由の1つは、国税庁ドメインのDMARCポリシーです。筆者がDNSで確認したところ、_dmarc.e-tax.nta.go.jp の設定は次のとおり、p=none(認証に失敗しても拒否・隔離を求めない) でした(2026年10月11日時点)。

v=DMARC1; p=none

p=none は「監視のみ」の設定で、認証に失敗したメールも受信側でそのまま配信される可能性があります。そのため、受信側の設定によっては、この種のメールが受信箱に届いてしまいます。迷惑メールフォルダに入っていないことは、安全の証明にはなりません。

対策:送信認証の失敗を条件にしたフィルタを作る

政府機関のように送信認証を整えているはずのドメインを名乗り、かつ認証に失敗しているメールは、ほぼ偽物とみなせます。この条件でメールを自動で振り分けると効果的です。

筆者が使っているThunderbirdでは、次の設定でできます(Authentication-Results は受信サーバーが付けるヘッダです)。

  1. メニューから「ツール」→「メッセージフィルタ」を開く
  2. 「新規」を選び、条件の項目で「カスタマイズ」から Authentication-Results を追加する
  3. 「次の文字列を含む」で spf=fail と dmarc=fail の両方を条件にする(「すべての条件に一致」)
  4. 動作は「削除」ではなく「ゴミ箱へ移動」または専用フォルダへの移動にする

筆者の環境では、この設定により、今回のメールは迷惑メール判定がなくても自動でゴミ箱に入っていました。

ゴミ箱・隔離フォルダは定期的に確認する

送信認証の失敗は、偽メール以外でも起こることがあります。たとえば、メールを別のアドレスへ転送している場合や、一部のメーリングリストを経由した場合です。正規のメールを見逃さないために、振り分けたフォルダは次のように確認しましょう。

  • 週に1回程度、ゴミ箱と隔離フォルダの差出人と件名を確認する
  • 見覚えのある差出人や、自分が関わった手続きのメールが入っていたら、元のフォルダに戻す
  • 判断に迷うメールは、本文内のリンクを開かず、公式サイトや公式アプリから直接確認する
  • 確認して問題がなければ、メールを完全に削除する

メールヘッダの見方

  • Thunderbird:メールを開き、「表示」→「ヘッダ」→「すべて」。またはCtrl+Uでソースを表示
  • Gmail:メール右上の「︙」→「メッセージのソースを表示」
  • Outlook:メールのプロパティから「インターネットヘッダー」を確認

Authentication-Results の行に spf=fail や dmarc=fail があれば要注意です。

もしリンクを開いてしまったら

状況別の対処は次のとおりです。

リンクを開いただけで何も入力していない場合
慌てる必要はありません。ブラウザを閉じ、念のためブラウザの履歴とキャッシュを削除してください。

偽サイトにIDやパスワードを入力した場合

  • 入力したIDとパスワードを、公式サイトから直ちに変更する
  • 同じパスワードを使い回しているサービスもすべて変更する
  • マイナンバーカードの暗証番号を入力した場合は、カードの一時利用停止も検討する(マイナンバー総合フリーダイヤル 0120-95-0178)
  • クレジットカード情報を入力した場合は、カード会社にすぐ連絡する

アプリをインストールしてしまった場合

  • 機内モードにしてネットワークを遮断する
  • 該当アプリをアンインストールし、ウイルス対策アプリでスキャンする
  • 銀行・証券・クレジットカードなどのパスワードを変更する
  • 不審な動作が続く場合は、端末の初期化も検討する

相談先

  • 警察の相談窓口:#9110
  • 消費者ホットライン:188
  • 最寄りの税務署

通報先

  • フィッシング対策協議会
  • 迷惑メール相談センター

今後も見破るための3つのルール

  1. メール内のリンクは開かない。 公式アプリやブックマークから直接アクセスする
  2. 「還付」「期限」「重要」で急かされたら、まず疑う。 本物の税務手続きは、メールのボタンだけで完結しない
  3. 差出人の表示名やドメインは信用しない。 差出人は簡単に詐称できる

よくある質問

Q. 「還付金確定通知書を格納いたしました」というメールは本物ですか?
A. 今回のメールは偽物です。令和8年分の還付金が現時点で確定することはなく、リンク先も国税庁のドメインではありません。

Q. すでにリンクをクリックしてしまいました。
A. 何も入力せず、アプリもインストールしていなければ、大きな被害の可能性は低いです。「もしリンクを開いてしまったら」の対処を確認してください。

Q. 本物のe-Taxからの連絡かどうか、どう確認すればいいですか?
A. メールのリンクではなく、公式サイトやブックマーク、公式アプリから自分でe-Taxにログインして、メッセージボックスを確認してください。

Q. 迷惑メールフォルダに入っていないのはなぜですか?
A. 送信元の詐称を見抜く仕組み(DMARC)が「監視のみ」の設定で、認証に失敗したメールも受信側でそのまま配信されることがあるためです。受信側のフィルタで、送信認証の失敗を条件に振り分けると効果的です。

まとめ

  • 「還付金確定通知書を格納いたしました」は、国税庁を装うフィッシングメールです
  • 日付の矛盾、国税庁ではないリンク先、本文の矛盾、不自然な日本語、ヘッダの認証失敗から、偽物と判断できます
  • 迷惑メール判定をすり抜けることがあるので、「判定されていない=安全」とは考えないでください
  • 送信認証の失敗を条件にしたフィルタが有効です。ただし、振り分け先のフォルダは定期的に確認してください

この記事は2026年10月11日時点の情報です。手口は変化するため、最新の注意喚起は国税庁やフィッシング対策協議会の公式サイトでご確認ください。



過去(2024年以前)実施の迷惑メール対策方法、設定

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意いたしま。コメントとをお願いします。

2026年夏、IFTTTを解約して無料プランに戻した理由|使い続けた理由と、今切った理由

IFTTTを有料のまま使い続けた理由と、無料プランに戻した理由。製品連携は生きていた。必要機能が約30個から2個に減り、外部サービスとの接点だけ残して解約した。


IFTTTを今も使っている人に向けて書く。これから使おうとしている人にも向けて書く。

知りたいのは、解約ボタンの場所ではない。なぜ今まで払い続けていたのか。なぜ、このタイミングでそれを止めたのか。その二つである。

先に結論を書く。

連携製品がIFTTT非対応になったから切ったのではない。製品は対応したままだった。動いてもいた。切ったのは、残したい機能の数が、無料枠の2個まで減ったからである。

よくある解約理由と、そうではなかった理由

すでにIFTTTを辞めた人の話を聞くと、理由は似ている。使っていた製品がIFTTT連携をやめた。アプレットが死んだ。だから去った。

自分の場合は逆だった。連携したい製品は複数あり、それらは有効に機能していた。だから使い続けた。

スマート製品は日々変わる。仕様も変わる。よくなることもあるし、デグレードすることもある。一時的な不具合なら待てばよい。待っても戻らない変更だけが、本当に効いてくる。

その意味で大きかったのが、Google Assistant V2だった。

仕様としてのデグレード

Google Assistant V2で一番失ったのは、カスタム発話と、変数つきの命令である。「アクティベート」を挟まないと動かないことも、使う気を削った。

これは不具合ではなかった。仕様としてのデグレードだった。待っても修正されない。音声を入口にしていた自動化は、ここで一気に薄くなる。

もともとの塊は、おおよそこうだった。

  • 音声の入口:約20個
  • 機器のオンオフ:約10個
  • 通知:約3個
  • 外部サービス連携:約5個

音声の約20個は、V2の時点でほとんど消した。残したのは3個ほどである。それでも、機器操作や通知、外部連携を含めて、残したいアプレットは約30個あった。無料の2個では足りない。だから有料を続けた。

続けた理由は、IFTTTが好きだったからではない。有効な機能が、まだそこにあったからである。

今もIFTTTを使っている人の継続理由も、だいたいこれだと思う。満足しているというより、代替がまだ来ていない。一度組んだものが、裏で動いている。月額は、切る判断を発生させない大きさである。

このタイミングで切った理由

切った直接のきっかけは、hoscmのHSA v0.12がテストリリースされたことである。HSAはAndroid向けの音声エージェントで、スマートホーム環境hsBoxと組み合わせて使う。

自分はIFTTTとhsBox、HSAの利用者である。開発側そのものではない。ただし開発側とはコラボの関係にあり、その立場で継続の見通しを確認できた。

HSA v0.12とhsBox 1.4の組み合わせで、IFTTTに置いていた機能のかなりの部分をカバーできるようになった。音声の入口は、ここで実質20個分が戻る。機器操作や通知の側も、本体側へ移せるものが増えた。

「どうしてもIFTTTで使いたい機能」が、約30個から2個になった。無料枠で足りる、という状態である。

テストリリースの段階で有料を止めてよいか。今使っている人は、そこを見ると思う。完成を待たずに切ったのではない。テスト版でも、継続提供は確定し、さらに強化していく方向だと分かっていた。代替が「今たまたま動いている」のではなく、「消えにくい」と判断した。その見通しが、このタイミングである。

残した2個の意味

無料で残す2個は、保険ではない。hsBoxと外部サービスの、入出力ゲートウェイである。

  • LINEへのメッセージ発信
  • YouTubeで検出したイベントの配信

どちらも、hsBoxから外へ出す、外から受け取る、その接点に使っている。本体の自動化はこちらへ移し、IFTTTには外との継ぎ目だけ残す。

これが、今の使い方である。IFTTTを家の中枢に置かない。外のサービスと内部をつなぐ2本の線として残す。

今使っている人向けに言うと、棚卸しの単位はアプレット数ではない。塊である。音声の入口、機器のオンオフ、通知、外部連携。どれが本体で、どれが継ぎ目か。本体が他へ移せるなら、有料である必要はない。継ぎ目が2本以内なら、無料で足りる。

これから使おうとしている人向けに言うと、最初から30個をIFTTTに置かない方がいい。置いた瞬間に、有料前提の家になる。最初から置くなら、他では出せない外部サービスとの接点だけに限った方がいい。自分の場合、それがLINEとYouTubeだった。

連携は生きていた。残したい機能が30個から2個になったタイミングで、有料を止めた。

続けていたものと、切ったもの

整理すると、こうなる。

使い続けていた理由は、連携が生きていたこと。複数の製品が、実際に機能していたこと。Google Assistant V2で音声入口は大きく死んだが、残った機能がまだ仕事をしていたこと。

このタイミングで切った理由は、その残務の大半を引き取る側が来たこと。必要数が無料枠まで減ったこと。代替が一時しのぎではなく、継続する前提だったこと。

IFTTTが不要になったわけではない。役割が変わった。中枢から、ゲートウェイへ移った。

自動化サービスは、作り始めた時より、辞め時の方が分かりにくい。不満が出た日が辞め時ではない。継続理由が死んだ日が、辞め時である。自分の場合、継続理由は「他に置き場がなかったこと」で、それが死んだのが今だった。

解約そのものは付録である

有料から無料へ戻す操作は、サブスクリプションの解約である。押した瞬間に無料になるのではない。今の課金期間が終わるまで有料機能は残り、期限後に自動でFreeになる。アプリを消しても止まらない。

契約した場所で、止める場所が違う。

  • 公式サイトのクレジットカード決済なら ifttt.com/billing の Cancel
  • iPhoneのアプリ内課金なら、設定 → 自分の名前 → サブスクリプション → IFTTT
  • Androidなら、Playストア → アカウント → お支払いと定期購入 → 定期購入 → IFTTT

Freeは有効アプレット2個までである。All に残っているものは制限に入る。残さないものは Archive か Delete した方がいい。自分で作ったものは Archive、他人の公開アプレットは Delete になる。

画面や料金は変わる。最新は公式のプランページを見てほしい。


関連記事

Claude 詐欺メールを解剖する|認証が通っても偽物だった

ある日、「Claude Max トライアルの準備ができました」という件名のメールが届く。これは典型的なClaude 詐欺メールです。差出人の欄には「Claude」と表示され、本文には自分のメールアドレス、文末には Anthropic 社の住所まで載っている。だから本物の案内に見えてしまう。本記事では、この Claude 詐欺メールを実物のヘッダごと解剖し、見破り方とスパム判定の強化策まで整理します。

厄介なのは、この Claude 詐欺メールが SPF・DKIM・DMARC というメール認証をすべて「合格(pass)」して受信箱に届いていた点です。当サイトでは過去に何度も、認証技術によるなりすまし対策を取り上げてきました。今回はその強化してきたはずの判定をすり抜けた一通が題材です。なぜ通り抜けられたのか、何を見れば見破れるのか、最後にスパムとして弾く方法までを、一般の方とエンジニアの双方に向けて述べます。

届いた Claude 詐欺メールの中身

まず実物を見ます。本文は英語でした。受信者のメールアドレスは伏せています。

claude • max

Your Claude Max trial is ready
Hello,

You have been granted 1-month trial access to Claude Max.
(あなたに Claude Max の1か月トライアルアクセスが付与されました)

ACCOUNT
xxxxx@****(受信者本人のアドレス)

Get Started → https://claudetrial.com/?session=3355555667

Note: This invitation is unique to xxxxx@**** and will expire in 24 hours.
(この招待はあなた専用で、24時間で失効します)

Anthropic PBC, 530 Divisadero St, San Francisco, CA 94117, USA

一見、ただの「無料トライアル案内」です。自分のアドレス宛てに「あなた専用」と書かれている。Anthropic の正しい住所まで載っている。普段 Claude を使う人ほど、正規のお知らせと受け取りやすい。そこを突くのが、この Claude 詐欺メールの狙いです。

本文だけで分かる Claude 詐欺メールの兆候

落ち着いて読めば、本文だけでも危険信号が見つかります。

1. リンク先が Anthropic のものではない。「Get Started」の先は https://claudetrial.com/?session=335555667 です。Claude の正規サービスは claude.ai や anthropic.com で提供されます。claudetrial.com は無関係の別ドメインです。末尾の ?session=… は、クリックした人を追跡する仕掛けの可能性があります。このURLは絶対に開かないでください。

2. 「24時間で失効」と急かす。「あなた専用」「24時間以内」は、考える時間を与えず即クリックさせる古典的な手口です。正規の案内がここまで急かすことはまずありません。

3. 身に覚えのない「手続き完了」通知。申し込んでいないのに「ご要望に応じてお送りしました」とある。これもフィッシングの常套句です。

同種のキャンペーンは国内外で確認されています。セキュリティ企業 MailGuard は、Anthropic を騙る支払い失敗型のフィッシングを報告。日本でも2026年3月、「Claude 日本語無料版」を名乗る偽サイトがITmedia に報じられました。偽の Claude サイトがマルウェアを仕込んだ事例もMalwarebytes が解析しています。Claude の利用者が増えるほど、その名前を悪用する攻撃も増えています。

ヘッダで見抜く Claude 詐欺メールの正体

メールのヘッダ(送信元や経路の記録)を見ると、正体がさらにはっきりします。重要な部分を抜き出します。

From: Claude <accounts1@dallasmbs.com>
Reply-To: accounts1@dallasmbs.com
Return-Path: <accounts1@dallasmbs.com>

Received: from static195-40.de.dm.aliyun.com (47.245.195.40)
Received: from dallasmbs.com by smtp.aliyun-inc.com
Feedback-ID: default:accounts1@dallasmbs.com:alibabak_SmtpBatch

X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"

表示名は「Claude」でも、実際の差出人は accounts1@dallasmbs.com。これが核心です。メールの「表示名」は、送る側が自由に決められます。「Claude」とも「Anthropic」とも、誰でも名乗れる。一方で実アドレスは dallasmbs.com。Anthropic とは縁もゆかりもないドメインです。返信先も戻り先も、すべて同じ無関係ドメインでした。

配信経路は中国系クラウドの一斉配信基盤です。経路をたどると Alibaba Cloud の aliyun.com 系サーバを経由しています。Feedback-ID の alibabak_SmtpBatch は、バルク配信サービスの痕跡です。世界規模の Anthropic が、正規案内をこの種の基盤から送るとは考えにくい。

ヘッダ自体も壊れています。受信側が BAD HEADER SECTION の警告を出しました。「MIME-Version」が二重に書かれているという意味です。雑な送信ツールの典型的な痕跡で、正規の大規模配信ではまず起きません。送信時刻のタイムゾーンも経路ごとにバラバラでした。

なぜ認証は「全部 pass」したのか

ここが今回いちばんの要点です。この Claude 詐欺メールのヘッダには、こう記録されていました。

dkim=pass  header.d=dallasmbs.com
spf=pass   smtp.mailfrom=accounts1@dallasmbs.com
dmarc=pass (policy=none) header.from=dallasmbs.com

SPF・DKIM・DMARC が、いずれも pass。当サイトが「なりすまし対策」として紹介してきた三つの認証が、すべて通っています。「認証が通った=本物では?」と感じた方こそ、ここが落とし穴です。

カラクリはこうです。これらの認証が見るのは、「dallasmbs.com が dallasmbs.com として正しく送ったか」だけ。攻撃者は自分で取得した dallasmbs.com から送っています。だから検査は当然パスします。

つまりこの Claude 詐欺メールは、Anthropic を認証レベルで詐称してはいません。ドメインを偽装したのではなく、認証が一切見ない場所——「表示名」に「Claude」と書いただけです。

当サイトのDMARC 解説やなりすまし対策で強化したのは、主に「正規ドメインを騙るドメイン詐称の検知」でした。今回はドメインを詐称していないため、その網にかからず素通りした。これが「すり抜け」の正体です。SpamAssassin のスコアも score=1.6 required=30.0 と低く、ほぼ素通りでした。

逆のケースも知ると理解が深まります。あるセキュリティ製品の開発者は、本物の Anthropic メールを誤って詐欺判定した経験を公開しました。本文の印象だけでは本物すら怪しく見え、偽物が本物らしく見える。最終的に本物と確証できたのは、認証結果が header.from=claude.com で揃っていたから。「どのドメインとして認証が通ったか」を見たからです。

見るべきは「表示名」ではなく「実アドレス」

ここまでをひとことでまとめます。

認証が「合格」でも、それは「そのドメインとして正しく送られた」ことの証明にすぎない。「あなたが思う相手(Anthropic)から来た」ことの証明ではない。

だから見るべきは、派手な表示名(”Claude”)ではありません。実際の差出人アドレス(@dallasmbs.com)です。表示名が「Claude」でも、実アドレスのドメインが claude.ai や anthropic.com でなければ、正規の案内ではないと判断できます。

そして、ここが最も強調したい警告です。メーラーの中には、この実アドレスを隠し、表示名しか見せないものがあります。スマホのメールアプリでは特に、差出人欄に「Claude」とだけ出て、タップして初めて accounts1@dallasmbs.com が現れることがあります。設定によっては最後まで見えないものすらある。

確認すべき情報を隠すメーラーは、それ自体が危険です。普段使う環境で「実際の差出人アドレスが常に確認できるか」を、一度点検しておくことをおすすめします。なお、ツールや連携の挙動を過信しない姿勢は、当サイトの技術検証記事でも繰り返し触れてきた通りです。

Claude 詐欺メールをスパム判定するには(一般の方へ)

今回のメールは、メーラーもサーバも迷惑メールと判定できませんでした。認証が揃い、スコアが低かったためです。まずは技術設定なしでできる、一般の方向けの習慣から。

第一に、表示名でなく実際の差出人アドレスを必ず確認します。@より後ろのドメインが正規のものと一致するかを見るだけです。第二に、メール内のリンクは踏みません。必要ならブックマークや検索から公式サイトへ自分で行きます。

第三に、「24時間以内」「今すぐ」と急かすメールほど、いったん止まります。急かしは考えさせないための演出です。判断に迷えば AI に画像ごと相談するのも手ですが、AI も誤ります。最後はドメインの一致で確かめてください。

Claude 詐欺メールを弾くルール設計(エンジニアへ)

この Claude 詐欺メールが素通りした根本は、「ドメイン認証は正しいが、ブランド名を表示名で騙っている」点にあります。対策の方向は DMARC の先——認証では捕まらない『ブランド詐称』の検知です。

SpamAssassin なら、「From の表示名に著名ブランド名を含むのに、送信ドメインが正規でない」場合に加点するメタルールが書けます。考え方を示す擬似ルールが以下です。実運用では正規表現とドメインリストの精査が要ります。

# 表示名に "Claude"/"Anthropic" を含む
header  L_BRAND_NAME  From:name =~ /\b(claude|anthropic)\b/i

# 送信ドメインが正規ドメインでない(例:claude.ai / anthropic.com 以外)
header  L_NOT_OFFICIAL  From:addr !~ /\@(claude\.ai|anthropic\.com)$/i

# 両方に当てはまれば「ブランド詐称の疑い」として加点
meta    L_BRAND_SPOOF  (L_BRAND_NAME && L_NOT_OFFICIAL)
score   L_BRAND_SPOOF  4.0
describe L_BRAND_SPOOF  Display name claims a known brand but sender domain does not match

あわせて、実務では次の重み付けが効きます。新規・低評価ドメインへの加点です。dallasmbs.com や claudetrial.com のような、登録が新しく評価の低いドメインに点を上乗せします。今回ヒットした URIBL 系のフィードを増やすのも有効です。

次に一斉配信インフラのヒューリスティックです。海外バルク基盤+日本宛て+英語本文+著名ブランド名という組合せに加点します。今回 X_NONJAPANESE_SUBJECT が既にヒットしているので、足がかりにできます。さらに BAD HEADER SECTION などのヘッダ構文異常もスコアに織り込みます。

最後に、組織としては正規連絡元ドメインのホワイトリスト化が最も確実です。「Anthropic からの案内は claude.ai / anthropic.com 由来のみ」と運用ルールを明文化します。これらは SPF/DKIM/DMARC を置き換えるものではなく、その「外側」を補う層です。認証は「ドメインの正しさ」は保証しますが、「ブランドの正しさ」は見ていないからです。

まとめ:Claude 詐欺メールの教訓

今回の Claude 詐欺メールは、SPF・DKIM・DMARC をすべて pass しながら、受信者に「本物が来た」と誤認させる、よくできた一通でした。すり抜けの理由は、ドメイン偽装ではなく、認証が見ない「表示名」にブランド名を書いただけ。だから受信者は表示名でなく実アドレスのドメインを見るべきで、それを隠すメーラーは危険です。

弾く側は、認証の外側で「表示名とドメインの乖離」を検知する層を足すことが次の一手です。身に覚えのない「無料トライアル」「支払い失敗」「アカウント停止」が届いたら、まず止まって差出人の実アドレスを確かめる。それだけで、多くの被害は防げます。

関連記事

※本記事で扱ったメール・ドメイン・URL は、注意喚起のための実例です。記載のリンク先(claudetrial.com 等)には絶対にアクセスしないでください。

Ubuntu26 / PHP8.5 移行で発生したトラブルと対処方法|Failed to get boot ID・ProcSubset=pid

Ubuntu 26 と PHP 8.5 への移行作業中に、従来環境では発生しなかった問題をいくつか確認した。本記事では hash 仕様変更や systemctl status 実行時の「Failed to get boot ID」など、実際に遭遇したトラブルと対処方法をまとめる。

Ubuntu 26 と PHP 8.5 への移行作業中に、従来環境では発生しなかった問題をいくつか確認した。本記事では hash 仕様変更や systemctl status 実行時の「Failed to get boot ID」など、実際に遭遇したトラブルと対処方法をまとめる。
※移行はまだ完了していないので、随時追加更新していきます。

Ubuntu26・PHP8.5移行で発生した問題

PHP 8.5のhash仕様変更で発生した問題 hashのデフォルト動作変更、php内の内部処理、仕様の変更

軽く受け流せば、すぐに解決出る問題かもしれないが、対処の過程でGPTの修正案がセキュリティ脆弱性を引き起こすものだったので、参考のために書いておく。
GPTは安易に、セキュリティ対策実装をもっともらしい理由をつけて消す。それで、何とか動くケースだったらもしかしたら見逃していたかもしれないが、その修正では動かなかった。じっくりコードを見直したところ、除去してはいけないセキュリティ対策実装であったというものだ。 別な対処方法で解決できた。
 直接原因は、hash値に使用される文字の種類が拡張されたことです。詳細についてはセキュリティにまつわる話なので非公開とします。このようにセキュリティ関係の情報は非公開であることが多いのか、GPTも弱いようです。脆弱性の検出に使うのはよいとしても、セキュリティ確保には十分ではないというか、セキュリティ周りの実装は丸投げするのは危険だろう。

ブラウザ経由の PHP exec() → 「Failed to get boot ID」が出る systemctl statusでFailed to get boot IDが発生

実装修正で、比較的簡単に回避はできたが、これが発生する原因特定には時間を要している。

# systemctl cat apache2.service
# /usr/lib/systemd/system/apache2.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=https://httpd.apache.org/docs/2.4/

[Service]
Type=notify
Environment=APACHE_STARTED_BY_SYSTEMD=true
ExecStart=/usr/sbin/apachectl start
ExecStop=/usr/sbin/apachectl graceful-stop
ExecReload=/usr/sbin/apachectl graceful
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
PrivateTmp=true
Restart=on-abnormal
OOMPolicy=continue
RemoveIPC=yes

DevicePolicy=closed
KeyringMode=private
LockPersonality=yes
MemoryDenyWriteExecute=yes
PrivateDevices=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=read-only
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes


# systemctl show apache2.service | grep -E 'ProtectProc|ProcSubset|ProtectKernelTunables|ProtectKernelModules|RestrictNamespaces|ProtectSystem|ProtectHome|ReadOnlyPaths|InaccessiblePaths|PrivateTmp|RestrictAddressFamilies'
InaccessiblePaths=/boot /root -/etc/sudoers -/etc/sudoers.d -/etc/ssh -/etc/apt -/etc/.git -/etc/.svn
PrivateTmp=no
PrivateTmpEx=no
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectHome=read-only
ProtectSystem=full
RestrictNamespaces=yes
ProtectProc=invisible
ProcSubset=pid

ProcSubset=pid これが設定されていると、プロセスから見える /proc が自分のPID関連だけに絞られ、/proc/sys/ 配下がまるごと見えなくなります。systemctl status は内部で /proc/sys/kernel/random/boot_id を読もうとするので、Apache配下のPHPから実行したときだけ「Failed to get boot ID: No such file or directory」が出ていた、というわけです。

⇒対処方法
いろいろな対処方法がありますが、
statusのかわりに showを使うように見直しました。
具体的には次のよう感じです

修正前
$command = "systemctl status NetworkManager.service 2>&1";

変更後
$command = "systemctl show NetworkManager.service -p ActiveState,SubState,ActiveEnterTimestamp 2>&1";

PHP 8 の「数値文字列と非数値文字列の比較ルール変更

if ( $m === 0 ) { //部分一致する文字列がなければ 数値化してみる

★PHP7では数値文字列を数値に自動変換していたが、PHP8では変換しない

Ubuntu 22 と 26 で変わったこと

whoコマンドの挙動変化

挙動変化に伴いログイン状態のチェックができなくなっています

# 旧
who | grep tty2

# 新
pgrep -t tty2 2>/dev/null | xargs -r -I{} ps -p {} -o comm= 2>/dev/null | grep -v "^agetty$" | grep -v "^$" | wc -l
# 旧
who

# 新
loginctl list-users
# または
loginctl list-sessions

ImageMagick

Ubuntu 26 移行に伴うビルド側のパッケージ構成変更(GraphicsMagick の IM 互換コマンドを失った)

★ちょっと想定外なdmarcの過剰fail 2025年内に終了するので放置なのか?

DMARC設定で、過剰にfailしているのを発見しました。 ちょっとだけ想定外でした。。。 対象のメールは、ちょっと前に書いたソーラーフロンティアのメールです。


ARC-Authentication-Results: i=1;
***.xserver.jp;
dkim=pass header.d=hke.dkim.mpse.jp header.s=mpse.201103 header.b=Stua66Jg;
spf=pass (***.xserver.jp: domain of z-hke-xhp3nn-0-de-005miuramic.or.jp@bma.mpse.jp designates 106.185.96.14 as permitted sender) smtp.mailfrom=z-hke-xhp3nn-0-de-005miuramic.or.jp@bma.mpse.jp;
dmarc=fail reason="SPF not aligned (strict), DKIM not aligned (strict)" header.from=solar-frontier.com (policy=none)

ちょっと対策が必要そうです。

関連記事

https://www.nri-secure.co.jp/blog/dmarc-report

詐欺メール 、新たなストーリーベース詐欺の前振り? 2005年ころからおなじみのストーリー調スパムの最新版か spam-mail

この記事は、スパムアサシンやメーラーでのスパム判定をすり抜けた怪しいメールを取り扱います。その内容の判定や設定方法の改善策について取り扱います。

このメールはdmarcポリシーのチェックを”pass”しています。 このパターンはドメイン自体を自動的にbanする(ブラックリスト登録する)のが良いかもしれませんが、様子見です。 スパマーによるハニーポット探索が目的なのかもしれません。  

★対象のメールのコピー

Apple Store 20,000円ギフトカードを今すぐ受け取る

Apple Store 5,000円 gift card 贈呈中 @media only screen and (max-width:600px){ .container{width:100% !important;} .btn{display:block !important; width:100% !important;} } 【Apple Store】20,000円 gift card 贈呈中 特定アカウント限定/24時間以内に受け取り

いつもAppleをご利用いただきありがとうございます。現在、特定のアカウントを対象に20,000円分のApple gift cardを贈呈しております。

本gift cardは24時間以内に 受け取り いただいた場合のみ有効です。期限内に受け取りが完了しない場合、権利は自動的に失効いたします。

20,000円を受け取る ▼

ご利用条件対象:本メールを受信した特定アカウントに限ります。 受け取り期限:本メール受信から24時間以内。 利用範囲:Apple Storeおよびオンラインストア内の特定商品に限りご利用いただけます。 他の割引・クーポンとの併用はできない場合があります。
本メールは送信専用です。ご返信いただいても対応いたしかねます。
誤送信と思われる場合は、このメールの破棄をお願いいたします。
© 2025 Apple. All rights reserved.
spam22
spam
過去(2024年以前)実施の迷惑メール対策方法、設定

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意いたしま。コメントとをお願いします。

スパムメール/詐欺メール DMARC設定で激減、2025年以降この設定は必須!?

この記事は、スパムメールや詐欺メールに関する情報を扱います。過去に何度かスパム対策を行ってきましたが、徐々に増えてきているので対策を見直しました。Eメールはいろいろなセキュリティレベルの相手と通信する仕掛けなので完璧な対策はないと言ってもよいかもしれません。 そうはいっても明らかにスパムと判断できるものも保留してスパムかどうかを判断していくのは面倒である。 明確にスパムと判断できるものは受け取らないようにしたのでよいだろう。 というのも、最近、送信元が自分であるスパムメールが増えていた。明らかに自分が送信していないのでスパムであることは明白なので、なぜこのような送り方をするのか疑問だが、チェックルールをかいくぐる手として使っているのだろう。

このようなメールは完全に受け入れなければよい。 これを実現するのがDMARCである。DMARCは、「自分のドメインを使ったなりすましメールを見つけ、受信側で拒否・隔離できるようにする」仕組みである。そこで、DMARCポリシーを「メールを配送しない」に設定した。

この設定により、最近増えていた下のような送信元が”自分”だと詐称されたメールを撲滅できた。 素晴らしい!   激減とはいうものの、 スパムメールの全体の一部であることには変わりない。引き続きスパムとの闘いは続く。

DMARC 設定で拒否できるようになったスパムメール例(サンプル)

★対象のメールのコピー

[SPAM] 新作登場!今だけの特別オファーをご覧ください


[SPAM] 【期間限定セール】LOUIS VUITTON 人気商品が最大70%OFF! ***


 本日新商品アップしました、全商品80% OFF,送料無料,代引きで支払う,代金引換。
是非、宜しくお願い致します。

[ONLY 1]LOUIS VUITTON モンスリ PM Ref:M45410 <https://superfluity.qpon/357>

[ONLY 1]LOUIS VUITTON モンスリ PM Ref:M45410 <https://superfluity.qpon/357>
17,000 JPY 359,700 JPY


【Louis Vuitton】クロスボディ ショルダー バックパック M82769 <https://
superfluity.qpon/358>

【Louis Vuitton】クロスボディ ショルダー バックパック M82769 <https://
superfluity.qpon/358>
30,000 JPY 178,000 JPY


Louis Vuitton ルイヴィトン ボディバッグ ウェストバッグ 長財布 2点セット お得
<https://superfluity.qpon/359>

Louis Vuitton ルイヴィトン ボディバッグ ウェストバッグ 長財布 2点セット お得
<https://superfluity.qpon/359>
30,000 JPY 168,000 JPY

【存在感抜群☆国内発】LV ディスカバリー・バックパック PM M46802 <https://
superfluity.qpon/360>

【存在感抜群☆国内発】LV ディスカバリー・バックパック PM M46802 <https://
superfluity.qpon/360>
24,000 JPY 168,000 JPY


【ルイヴィトン】NEW!シャドーブラック☆スリムバッグDANUBE <https://
superfluity.qpon/361>

【ルイヴィトン】NEW!シャドーブラック☆スリムバッグDANUBE <https://
superfluity.qpon/361>
23,000 JPY
*dmarcで破棄できた例



【信用金庫】ポイント加算の確認をお願い申し上げます


お客様へ

平素より全国信用金庫協会をご利用いただき、誠にありがとうございます。


■ ポイント加算のお知らせ

2025年10月1日〜2025年10月31日までのご利用分について、下記内容で全国信用金庫協会
ポイントが加算されましたのでお知らせ申し上げます。

*■ 加算内容*

* *対象期間:*2025年10月1日〜2025年10月31日
* *加算ポイント数:*5130ポイント(5130円相当)
* *加算日:*2025年11月18日
* *加算対象取引:*給与の受け取り、公共料金の自動引落し、キャッシュレス決済の利用


■ 受取期限について

加算されたポイントの受取期限は **2025年11月17日** までです。期限を過ぎると、ポイ
ントは失効いたしますので、**お早めにご確認いただき、手続きをお願いいたします**。


■ ポイント受け取り手続き

下記リンクより、ポイント受け取り手続きを速やかに行っていただけます。

▶ ポイントを受け取る <https://yagwg.com/shinkin/s/selectState>

--------------------------------------------------------------------------------

*【ご注意】*
インターネットバンキングは毎週日曜日23:56〜月曜日6:00にメンテナンスが行われま
す。この時間帯はサービスをご利用いただけませんので、予めご了承くださいますようお
願い申し上げます。

--------------------------------------------------------------------------------

【お問い合わせ】
全国信用金庫協会 カスタマーサポート
電話:0120-579-835(携帯・IP電話:03-6387-3213)
受付時間:平日 9:00〜16:00

全国信用金庫協会株式会社
〒103-0028 東京都中央区八重洲1丁目3番7号
© 全国信用金庫協会 All Rights Reserved.

==============================================
■判定結果

ARC-Authentication-Results: i=1;
***.xserver.jp;
dkim=fail ("body hash did not verify") header.d=mail20.funcwei.com header.s=mail20 header.b="T2j/oEP0";
spf=pass (sv8645.xserver.jp: domain of info@mail20.funcwei.com designates 35.185.141.217 as permitted sender) smtp.mailfrom=info@mail20.funcwei.com;
dmarc=fail reason="SPF not aligned (relaxed)" header.from=hama-sushi.co.jp (policy=none)

■最初の数件 Spamフィルタに引っ掛からなかったものもdmarchafail
dmarc=fail reason="No valid SPF, No valid DKIM" header.from=uccard.co.jp (policy=none)


4:19---------------------v対象メール
【重要なお知らせ】UCカードご利用確認のお願い

最近行われましたプライバシ-ボリシ-の改定に伴いまして、こ確認のお手続きは、一回限りで、数分で終了致します。
お客様によるご確認行為は必須となっており、お客様のアカウント情報のご確認が行われなかった場合は、アカウントが停止される可能性がごさいます。
この確認は義務付けられており、確認していただけない埸合は、アカウントが停止される場合もあります。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
ご利用確認はこちら
※この確認は義務付けられており、確認してい ただけない埸合は、アカウントが停止される場合もあります。つきましては、以下ヘアクセスの上、カードのご利用確認にご協力をお願い致します。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
※24時間以内にご確認がない場合、誠に申し訳ございません、お客様の安全の為、アカウントの利用制限をさせていただきますので、予めご了承ください。
=======================
アットユーネット利用規約
第1条(利用規約)
1.本規約は、ユーシーカード株式会社(以下「UC社」と称します。)またはUC社と業務提携するカード会社(以下これらをあわせて「当社」と称します。)にユーシーカードホームページ上で提供するインターネットサービス「アットユーネット」(以下「本サービス」と称します。)のユーザー登録申請を行い、当社が承認した方(以下「アットユーネット会員」と称します。)に適用されます。
2.アットユーネット会員は、本規約のほか、第2条第1項に定めるカードの「会員規約」及び本サービスにおける各「サービス規約」、「ご案内」、「ご利用上の注意」その他の注記事項(以下「本規約等」と称します。)を遵守するものとします。
https://atunet.uccard.co.jp/UCPc/pages/images/person/PC/terms/index.html
第2条(ユーザ登録)
1.本サービスのユーザ登録を申請できる方は、当社が発行するUCブランドのクレジットカードのうち当社が認めたクレジットカード個人会員及びコーポレートカードのカード使用者とします。(以下これらのクレジットカードを総称して、「カード」とします。)
2.ユーザ登録を希望する方(以下「申込者」と称します。)は、当社所定の方法により申請するものとします。
https://www2.uccard.co.jp/cs/services/#entertainment
3.当社は、申込者のうちユーザ登録を承認した方に対し、アットユーネット会員を特定する番号(以下「ID」と称します。)を付与し、登録されたEメールアドレスに通知します。
https://www2.uccard.co.jp/cs/card/lineup/mileageplus.html
4.UC社と業務提携するカード会社の申込者は、申込者の所属するカード会社(以下「所属カード会社」と称します。)がUC社にユーザ登録に関する受付のほか、本サービスに関する事務等について、業務委託することに同意するものとします。
https://www2.uccard.co.jp/cs/privacy/member.html
第3条(登録の拒絶及び承認の取消)
当社は、申込者が以下の何れかの項目に該当する場合、当該申込者の本サービスの利用を拒絶し、あるいは、承認後であってもその取り消しができるものとします。
1.ユーザ登録をした方が、カードの会員資格又はコーポレートカードのカード使用者資格を有していない場合
2.ユーザ登録をした時点で、カードご利用状況、お支払状況等が不適当な場合
3.ユーザ登録の際の申告事項に、虚偽の記載、誤記、又は記入漏れがあった場合
4.当社に予め登録されている情報について改めて確認が必要な場合
5.カード不正使用による被害発生時や、申込者が当社に届け出た氏名、勤務先、住所、お支払口座等に変更があり、直ちに当社所定の届出用紙により手続きを行わなかった場合など正確な本サービスの提供が困難と予測される場合
6.その他、会員規約違反などがあり、当社がアットユーネット会員として不適当と判断した場合
https://www2.uccard.co.jp/maintenance/index.html
第4条(再登録)
アットユーネット会員は、次のいずれかに該当する場合、当社所定の届出を行うものとします。
なお、届出がないことによりアットユーネット会員ならびに第三者に不利益や損害が発生した場合には当社はその責任を負わないものとします。
(1)カード番号切替等申請した登録内容に変更があった場合
(2)自己のID及びパスワードが第三者に無断使用されている、又はそのおそれがあることが判明した場合
https://www2.uccard.co.jp/uc/uccard/corporatecard/
第5条(本人認証)
1.当社は、入力されたID及びパスワードの一致を確認することによって、アットユーネット会員による本サービスの利用とみなします。なお、当社は、本サービスの提供において、本人認証のためにその他の手続きを求める場合があります。
2.アットユーネット会員は、本人認証手続きに対応したオンライン加盟店においては、パスワードまたは当社が発行するワンタイムパスワードを入力する方法により、ショッピングサービスを利用できるものとします。
https://www2.uccard.co.jp/uc/services/seikyu/
業務委託先 株式会社クレディセゾン
Copyright © UC CARD CO., LTD. All Rights Reserved.

関連記事

https://www.nri-secure.co.jp/blog/dmarc-report

https://mic.or.jp/info/2025/11/16/mail-2


過去(2024年以前)実施の迷惑メール対策方法、設定

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意いたします。コメントとをお願いします。

ソーラーフロンティア ホームエネルギーモニタリングサービス終了! 2025年12月solar発電データ監視がストップ?の代替で継続を検討

ソーラーフロンティア ホームエネルギーモニタリングサービスが2025年12月に終了!hsboxでsolar発電データ監視を代替を検討

過去の関連記事

はじめに

次のようにフロンティアモニターのシステム終了のアナウンスがきています。
hsBoxを使って代替機能を実装していきましょう。

**** 様

日頃より【フロンティアモニター】ホームエネルギーモニタリングサービスをご利用いただき、誠にありがとうございます。

【システム終了のお知らせ】
2025年12月22日(月)をもって本計測装置のサービスを終了いたします。
なお、システムの都合により、一部サービス終了のタイミングについては前後する可能性がございますので、ご承知おきください。
詳しくはお客様ご利用サイトのお知らせ欄をご覧ください。

本メール発信は、メールシステムメンテナンスにより、1日遅延する場合があります。メンテナンスの日程は、お客様ログイン画面の「お知らせ」欄に随時記載いたします。
メンテナンス時はご不便をおかけしますが、何卒ご承知おきくださいますようお願いいたします。

下記の通り、2025年11月07日の発電量をお知らせいたします。

発電量:37.44kWh


今後ともフロンティアモニターをよろしくお願いいたします。
★なお、お心当たりのない方は、お手数ではございますが、下記メールアドレスまでご連絡頂きますようお願いいたします。
★このメールは送信専用メールアドレスから配信しています。このまま返信いただいてもお答えできませんのでご了承ください。
-----------------------------------------------
ソーラーフロンティア株式会社
【フロンティアモニター】お客様サービスセンター
電話:0570-053115(受付時間:9:00-17:00)※日曜、祝祭日、メーデー、年末年始を除く
メール:information@solar-frontier.com
-----------------------------------------------

順次、実装を進めていきます。 参考してみてください。 コメントなどあればお願いします。

まずは、次の情報を集めます

●パワーコンディショナー(メーカーと型番)
●フロンティアモニターの接続方式

次の図ような方式で、データ収集できそうな目途が立ちました。
※最初PROXY方式で検討しましたが、途中で直接採取する方式に変更してデータ取得できるようになりました。

順番に構築・検証していきます。以下に一部公開済みです。

・hsBoxにproxyを構築 [公開済み]
・hsBoxのproxyでデータ収集を検証[公開済み]
・proxyで実データ収集に調整 pruxy方式は放棄、諦めて別方式へ[公開済み]
・hsBoxで、直接発電電力データの取得に成功!![公開済み]
・hsBoxで収集してデータを蓄積[公開済み、取得と同時にNASへ蓄積]
・hsBoxで取得したデータの妥当性を比較検証[公開済み]
・集積したデータでグラフを書かせてみた[公開済み]
・発電量通知メールを置き換え LINEで通知[公開済み]
・異常検知を検知して、メール、LINEで通知 [公開済み]

この後の作業予定です。[近日追加公開予定]
・蓄積したデータのhsBoxでTVやスマートディスプレイに表示

関連記事

最近怪しい郵便物が多い。 正式であるなら、正式と判定されるように公式な発信をしてほしい。

Grok4とGPT4に判定してもらいました。 結果は下の通り

GPT4: 確認できない → 判定不能
Grok4: 詐欺の疑いが強いと考えられます。

プロンプトは次

公益財団法人日本財団 口座記号番号 00150-5-293429 は 詐欺じゃないでしょうか?


Grok4の回答

ユーザーのご懸念、よくわかります。公益財団法人日本財団は実在の信頼できる組織ですが、寄付を装った詐欺が社会的に問題になっています。指定された口座記号番号「00150-5-293429」について、公式情報を基に検証した結果をお伝えします。

検証結果

  • この口座番号は日本財団の公式寄付口座として確認できませんでした。日本財団の公式ウェブサイト(nippon-foundation.or.jp)では、銀行振込やゆうちょ銀行振込の口座情報は寄付申し込み後にメール(kifu@ps.nippon-foundation.or.jp)で個別に案内される形式を取っており、公開された一覧に「00150-5-293429」は記載されていません。 また、ゆうちょ銀行対応は一部の基金(特定のプロジェクト)のみで、過去の公開例(例: 2019年の台風19号緊急支援)では異なる口座番号「00160-0-00266041」が使用されています。
  • ウェブ検索やX(旧Twitter)での調査でも、この具体的な口座番号を日本財団の公式寄付として言及した信頼できる情報は見つかりませんでした。一方、X上では日本財団の寄付活動自体を「詐欺的」と疑う投稿が散見されますが、これらは主に休眠口座の活用や政治的陰謀論に関するもので、この口座番号に直接結びつくものはありません。

詐欺の可能性

  • 詐欺の疑いが強いと考えられます。寄付を募る詐欺では、信頼できる団体の名前を騙り、偽の口座情報を提供するケースが急増しています。日本財団の名前を使った類似事例も報告されており、急な寄付依頼や不明瞭な口座情報は要注意です。 特にゆうちょ銀行の口座記号番号形式(例: 001XX-X-XXXXXX)は偽造しやすく、詐欺師が悪用しやすい点に注意してください。

正しい寄付方法のすすめ

日本財団への寄付は、以下の公式ルートをおすすめします。絶対に不明な口座に振り込まないでください。

  • 公式ウェブサイト: https://www.nippon-foundation.or.jp/donation でオンライン寄付や申し込み。クレジットカード、コンビニ払い、口座振替などが可能です。
  • 銀行振込の場合: 寄付申し込み後、公式メールで案内される口座を使用。
  • お問い合わせ: 寄付総合窓口(電話: 0120-533-236、平日9:00~17:00)またはメール(kifu@ps.nippon-foundation.or.jp)で直接確認を。 疑わしい情報があれば、すぐに相談してください。

もしこの口座情報をどこで入手したか(メール、SNSなど)詳細を教えていただければ、さらに深掘りして調べられます。安全第一でご判断ください!


GPT4の回答

私の調査では、公益財団法人日本財団が 口座記号番号「00150-5-293429」 を公式に案内しているという信頼できる情報は確認できませんでした。

一般的な安全確認のポイントとしては:

  • 灯籠口座(ゆうちょ銀行の「記号-番号」形式)を使った寄付の場合、その事務所/団体の公式ウェブサイトや公的な案内冊子に「ゆうちょ銀行記号番号:00150-5-293429」などと明記されているか確認する。
  • 団体の公式ウェブサイトで「この口座は正規です」と明記されているか。
  • 寄付を求める連絡が、公式のメールアドレス・電話番号からかどうか。 突然SNSや電話で「至急寄付を」と連絡が来た場合は注意が必要。
  • 団体に直接問い合わせて「この口座に振込しても良いか」確認する。

もしご希望であれば、日本財団の公式の寄付口座を探して、一緒に照合するお手伝いもできますが、どうしますか?


どう見ても詐欺メール、どう自動破棄処理するのが良い? spam

スパムフィルタを使っていると正当なメールをスパムメールと、誤判定してしまうケースがあるが、これらのメールは自動処理してしまってもよいだろう。グレーケースとあきらかな詐欺メールは分類して処理するのが良いかもしれない。

以下、明らかな、詐欺メールのサンプル


組織犯罪対策部:あなたはマネーロンダリングの疑いがあります。保釈金として150万を下記の口座にお振り込みください。捜査終了後、保釈金は返金されます。2025年10月31日までに送金しない場合は資産は凍結され、あなたは逮捕されます。

三菱UFJ銀行 (金融機関コード0005)
恵比寿支店(支店コード136)
普通 2041699
名義 TS 合同会社
ティーエスゴウドウガイシャ

〒100-8974 東京都千代田区霞が関2丁目1番2号
電話番号 03-3581-0141(代表)


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <iwashita_manami@e-nepia.com>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on **.xserver.jp
X-Spam-Flag: YES
X-Spam-Level: **************************************************
X-Spam-Status: Yes, score=52.2 required=30.0 tests=CMCL_1,FSL_HELO_NON_FQDN_1,
HELO_NO_DOMAIN,RDNS_NONE,SPF_SOFTFAIL,TVD_SPACE_RATIO_MINFP autolearn=no
autolearn_force=no version=3.4.0
X-Spam-Report:
* 0.0 FSL_HELO_NON_FQDN_1 No description available.
* 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
* 50 CMCL_1 Cloudmark Authority detected spam
* 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
* 0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
* 0.0 TVD_SPACE_RATIO_MINFP Space ratio (vertical text obfuscation?)
X-Spam-CMAuthority: v=2.4 cv=UZQDS7SN c=1 sm=1 tr=0 ts=69025ac7
p=feqnlMpVuKP_xuHrwg4A:9 a=0FI5FzLfUpbmheKzllYW6Q==:17 a=IkcTkHD0fZMA:10
a=x6icFKpwvdMA:10 a=5KLPUuaC_9wA:10 a=M51BFTxLslgA:10 a=QEXdDO2ut3YA:10
a=Mfv3uX3kbRkA:10
Delivered-To: ***@***.or.jp
X-Virus-Status: scanned (With Secure/Atlant/virusgw12107.xserver.jp/)
Received: from qjbgdilxanftbstfbmypojfne (unknown [116.208.97.48])
by ***.xserver.jp (Postfix) with ESMTPS id 08D85280D824FF
for <**@**.or.jp>; Thu, 30 Oct 2025 03:19:47 +0900 (JST)
Authentication-Results: ****.xserver.jp;
dkim=none;
spf=softfail (****.xserver.jp: 116.208.97.48 is neither permitted nor denied by domain of iwashita_manami@e-nepia.com) smtp.mailfrom=iwashita_manami@e-nepia.com;
dmarc=fail reason="No valid SPF, No valid DKIM" header.from=e-nepia.com (policy=none)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=***.or.jp;
s=default; t=1761761990;
h=from:from:sender:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:mime-version:mime-version:
content-type:content-type:
content-transfer-encoding:content-transfer-encoding:in-reply-to:
references; bh=nTl06k+7cmfY6AQy1kTdVmH5deI5cl/IWBO0FE/8tIQ=;
b=Pi5TvKEgEfIRkjKLRatfN1kP2V2M9Ms3PoWWJR1c7us+sedef+I2DW7chT6mpT1j70MyCf
2o0rm8LslrqWEiIh4SPYRxnGRmQGCBroCZGDrfcuKFVD/NgzY4VfP3tanz8+b51aqliKZj
k9pIZTAabz38tBmH3epRH3FeBIWSwCBZf0bZT5bobJTvbDOCJvQmoz/6xLn6udxZslvssz
ox3rVC6lm1Bqd866eLHO2xjvJlcMpO1xbPjljbfODOYD/hk05PW77VMd6XdvzMonlIoAtG
moZuB7iFmlAkYUUs8aRSkMGZFU7dLwXQQlEzO0vtY0hWJIG4DaxAe1ghSYnX7Q==
ARC-Authentication-Results: i=1;
****.xserver.jp;
dkim=none;
spf=softfail (***.xserver.jp: 116.208.97.48 is neither permitted nor denied by domain of iwashita_manami@e-nepia.com) smtp.mailfrom=iwashita_manami@e-nepia.com;
dmarc=fail reason="No valid SPF, No valid DKIM" header.from=e-nepia.com (policy=none)
ARC-Seal: i=1; s=default; d=***.or.jp; t=1761761990; a=rsa-sha256;
cv=none;
b=kalrckxcno2eldITQxlaTxFC6yejHUAK+XC67U4VQbiG3lW4PVTcwhFm8z8s2FCeY62OQl
kYLJ5PTfGn2Z4fSQ+e3qbffTS0kQeC/SeaodSy2Ux29l3VALyDV/hLDtyPbZTtP5eDihGU
sYAUuKppEhdOc2W9EeinimPhS9h/OVclQlPSHB9VQo8jzwbzwuMSU5KfoyA1uO0wrq2SYM
a6Zu2XwgsBjozu9qbVknRsYNBpl5hPykoPBG+SxPAUZ3levk6JBHHeDRhgmxQDPTC5P+Pk
+0yoBkcZ3uu02XGhAEHu4NSUu3Jokw5X922s7f0ufukr+18u16go8BgQSdVsEg==
Message-ID: <lrrhz5s26p.s54pk7.5710.8frl-545754632@qjbgdilxanftbstfbmypojfne>
From: =?utf-8?B?6K2m5a+f5Y6F?= <iwashita_manami@e-nepia.com>
To: =?utf-8?B?U2FtIEVsaXNhYmV0?= <***@**.or.jp>
Subject: [SPAM] =?utf-8?B?6YeN6KaB44Gq44GK55+l44KJ44Gb?=
Date: Wed, 29 Oct 2025 19:19:42 +0100
X-Priority: 3
X-Mailer: LTPGGSAOIBADJ WTSQNJGDOCNBQPA 880.24276.55564
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
XSRV-Filter: ***@**.or.jp
X-Spam-Prev-Subject: =?utf-8?B?6YeN6KaB44Gq44GK55+l44KJ44Gb?=
XSRV-Filter: .Junk

57WE57mU54qv572q5a++562W6YOo77ya44GC44Gq44Gf44Gv44Oe44ON44O844Ot44Oz44OA44Oq
44Oz44Kw44Gu55aR44GE44GM44GC44KK44G+44GZ44CC5L+d6YeI6YeR44Go44GX44GmMTUw5LiH
44KS5LiL6KiY44Gu5Y+j5bqn44Gr44GK5oyv44KK6L6844G/44GP44Gg44GV44GE44CC5o2c5p+7
57WC5LqG5b6M44CB5L+d6YeI6YeR44Gv6L+U6YeR44GV44KM44G+44GZ44CCMjAyNeW5tDEw5pyI
MzHml6Xjgb7jgafjgavpgIHph5HjgZfjgarjgYTloLTlkIjjga/os4fnlKPjga/lh43ntZDjgZXj
gozjgIHjgYLjgarjgZ/jga/pgK7mjZXjgZXjgozjgb7jgZnjgIINCg0K5LiJ6I+xVUZK6YqA6KGM
IO+8iOmHkeiejeapn+mWouOCs+ODvOODiTAwMDUpDQrmgbXmr5Tlr7/mlK/lupco5pSv5bqX44Kz
44O844OJMTM2KQ0K5pmu6YCaIDIwNDE2OTkNCuWQjee+qSAgVFMg5ZCI5ZCM5Lya56S+DQogIOOD
huOCo+ODvOOCqOOCueOCtOOCpuODieOCpuOCrOOCpOOCt+ODow0KDQrjgJIxMDAtODk3NCDmnbHk
uqzpg73ljYPku6PnlLDljLrpnJ7jgYzplqIy5LiB55uuMeeVqjLlj7cNCumbu+ipseeVquWPt+OA
gDAzLTM1ODEtMDE0Me+8iOS7o+ihqO+8iQ==


マイナポイント再手続きのご案内





*** 様


マイナポイント第2弾の登録情報に不備があったため、ポイント付与が行えませんでした。
以下より内容を確認し、再手続きをお願いいたします。


期限:2025年11月01日(土)



手続きに進む



総務省

関連記事