SPF・DKIM・DMARCが全部PASSした詐欺メール。ならばこちらも罠を仕掛けてみようか

2026年10月8日 2026年10月8日

sentsuko

XServerを名乗るフィッシングメールが大量に届いた。私は仕事でホームページやサーバーの管理もしているので、こういうメールは他人事ではない。とはいえ、毎回律儀に相手をするほど暇でもない。

ところが今回は、少し調べたら気になるものが出てきた。SPF、DKIM、DMARC。全部PASS。

え、そこは通るんかい。そこからDNSを調べ、企業ドメインの管理について考え、最後には「だったら受信する側にも、ちょっと仕掛けを作れないか」という話になった。

先に断っておくと、この記事は調査先の企業を告発する話ではない。関与を示す証拠はなく、第三者に悪用された被害者の可能性もある。企業名やドメイン、IPアドレスなどは伏せ、私が見たことと、そこから考えたことを分けて書いていく。

XServerを名乗るメールが、やたらと届く

サーバー会社を装ったメールは、管理する側としては紛らわしくて困る。本物の連絡まで見落としたら、それはそれで仕事に響く。

今回届いたのも、XServerを名乗るフィッシングメールだった。もちろん、XServerが送ったという意味ではない。サービス名を勝手に使っているメールだ。

普通なら迷惑メールに振り分けて終わり。でも、これだけ届くと少し気になる。どこから、どういう仕組みで送っているのか。仕事を片付ければいいのに、こういうところを調べたくなるのが悪い癖だ。

Thunderbirdで、メールの裏側をのぞく

Thunderbirdでメールヘッダーを確認した。普段画面に出ている差出人名や件名の裏に、配送経路や認証結果などの情報が並んでいる。

差出人の表示名は、それだけでは本人確認にならない。そこで認証結果や送信元の情報を見ていく。ヘッダーを読む際には、受信側の信頼できるメールサーバーが付けた情報と、送信側が自由に書ける部分を区別する必要もある。

そして目に入ったのが、三つ並んだPASSだった。

SPF・DKIM・DMARC、まさかの全部PASS

私が今回確認したメールでは、SPF、DKIM、DMARCがすべてPASSしていた。名前だけ見ると、三重の検査を通過した優良メールに見える。実際には、それぞれが確認している範囲が違う。

SPF：主に配送用の差出人ドメインについて、その送信元IPからの送信が許可されているかを確認する。画面上の差出人アドレスを直接保証するものではない。
DKIM：ドメインの電子署名を検証し、署名された範囲の内容が署名後に改変されていないかを確認する。署名したドメインが、本文の主張を正しいものにしてくれるわけではない。
DMARC：画面上のFromドメインと、SPFまたはDKIMで認証されたドメインとの整合性を確認する。不合格時の取扱方針やレポート要求も公開できる。SPFとDKIMの両方の成功が必須というわけではない。

もう少し正確にいうと、DMARCはSPFが成功してその認証ドメインがFromドメインと整合するか、DKIMが成功して署名ドメインがFromドメインと整合すればPASSになる。整合性の判定には、厳密な一致を求める設定と、組織ドメイン単位で認める設定がある。

つまり、認証が通ったことと、メールが安全であることは別の判定なのだ。攻撃者が自分で管理するドメインに正しく認証を設定することもできるし、正規の送信環境が悪用される場合もある。

今回のPASSだけで、どのケースなのかは決められない。認証の仕組みを「突破」したと断定する話でもない。認証は成立していても、本文が人をだます内容であることはあり得る。ここが今回、私が引っかかったところだ。

送信元IPを調べると、海外のホスティング網

次に送信元IPを調べると、海外のホスティングネットワークに関連する情報が出てきた。

ただし、これで犯人の居場所が分かるわけではない。IPアドレスの割り当て先やネットワークの情報と、送信を操作した人物の所在地は同じものではない。クラウドや中継の仕組みもある。

ここで分かったのは、調べたIPがどのようなネットワークに関連していたかまで。国名だけで話を完成させると、調査というより想像大会になってしまう。

Google Admin Toolbox DigでDNSを確認

続いて、Google Admin ToolboxのDigで送信元に関係するドメインのDNSを調べた。

DNSには、名前をIPアドレスへ結び付けるAレコードや、メール送信を許可する範囲を示すSPFの設定などが公開されている。SPFは通常、TXTレコードに記述される。

難しそうな文字列が並ぶが、今回見たかったのは単純だ。このドメインが示すIPは何か。そして、どこからメールを送ってよいという設定になっているのか。

AレコードとSPFの設定が、送信元につながった

私が調べた時点では、Aレコードで確認したIPと、SPFで許可されている送信元が、メールの送信元IPと一致していた。

この状況なら、SPFがPASSしていたこと自体は不思議ではない。ただし、Aレコードが一致するだけでSPFが成功するわけではなく、実際のSPF設定に従って判定される。

そして、この一致はその企業が詐欺メールを送った証拠にも、サーバーが侵害された確証にもならない。管理者が誰なのか、送信権限がどう使われたのか、設定がいつ変更されたのか。そうしたことは、公開DNSと受信メールだけでは分からない。

DNSは調査時点の情報なので、過去の設定まで保証してくれるものでもない。つながりは見えても、事情までは見えないのだ。

送信元ドメインの先に、実在企業の情報があった

さらにドメインを調べていくと、実在する企業に関連する情報が見つかった。ここで話が急に生々しくなる。

ただ、公開情報上の関連が見えたことと、その企業が今回の送信に関わったことは別だ。調べた範囲では、不正行為への関与を裏付ける材料はない。むしろ、何かを悪用されている側かもしれない。

だからこの記事には、企業名も、調査したドメイン名も載せない。担当者名、住所、電話番号、実際のヘッダーも掲載しない。この先の話に、それらを公開する必要はないからだ。

.co.jp、.jp、.com。同じような名前が並ぶ

調査の途中で、同じような名前の.co.jp、.jp、.comという複数のドメインも見つかった。

企業が用途ごとに複数のドメインを持つことはある。ただし、名前が似ているというだけで、所有者も管理者も同じとは限らない。現在使っているものなのか、過去のものなのか、誰が管理しているのか。そこまで一気に決め付けることはできない。

それでも、自分が管理する側だと考えると気になる。会社のドメイン、全部把握できていますか。昔ホームページを作ったときのものまで含めて。これは私自身にも向けた話だ。

.co.jpの信頼と、管理を続ける責任

.co.jpは、日本国内で登記している会社など、登録資格を満たす組織が登録できる属性型JPドメインだ。原則として、1組織につき一つという制約もある。

その登録条件には意味がある。でも、登録資格の確認は、その後のメールやサイトの内容すべてを審査し続ける仕組みではない。.co.jpだから本文も安全、とはいかない。

なお、JPドメイン名の登録管理を担うレジストリはJPRS。JPドメイン名の登録管理業務は、2002年にJPNICからJPRSへ移管されている。JPNICは移管後もJPドメインの公共性などに関わるが、現在の登録管理組織とは区別して考えたい。

私はドメインを、会社自身が管理すべき財産だと思っている。信用が積み重なる一方で、管理が途切れたときの影響も積み重なる。更新料金を払っていれば、それで全部終わりというわけにはいかない。

Gmailの迷惑メール対策にも、認証以外の仕事がある

ここまで調べて、メール認証に何でも期待していたら困るなと思った。Gmailでも認証は重要な判断材料だが、それだけで受信トレイ行きが決まるわけではない。迷惑メールやフィッシングの検知、利用者からの報告なども使われる。

Google自身も、迷惑メールを送る側がメールを認証する場合があると案内している。PASSは万能の通行証ではないのだ。

受け取る側としては、メール内のリンクをそのまま踏む前に、普段使っているブックマークや公式アプリから管理画面を開いて確認する。怪しいものは迷惑メール・フィッシングとして報告する。地味だが、こういう行動も大事になる。

公開用と管理用のメールアドレスを分ける

そこで今後の対策として考えたのが、メールアドレスの役割分担だ。

ホームページに載せる問い合わせ先と、ドメインやサーバーの契約・管理に使うアドレスを分ける。管理用はむやみに公開しない。公開アドレス宛てに届いた「管理者様へ」というメールを、少し距離を置いて見られるようになる。

もちろん、非公開なら絶対に知られないわけではない。アドレスを分けても不正ログインを防げるわけではないので、使い回さないパスワードや二段階認証、復旧手段の管理も必要だ。

そして、もう一段細かく分けたらどうだろう、と考えた。

カナリア方式。こちらにも小さな仕掛けを置いてみる

サービスごとに、推測しにくい専用アドレスを作る

ここからは、今回の経験をきっかけに考えた今後の対策案だ。まだ実装した仕組みではない。

XServerに登録するアドレス、お名前.comに登録するアドレス、Adobeに登録するアドレスを、それぞれ別にする。しかも、アドレス自体にはサービス名を入れず、推測しにくいランダムな文字列を使う。

XServer専用：ランダムなアドレスA
お名前.com専用：ランダムなアドレスB
Adobe専用：ランダムなアドレスC

例えば形式としては「r8m4q7v2@example.com」のようなもの。これは説明用の架空例で、実際には自分で管理するドメインや、利用できるエイリアスサービスで発行する。短い連番など、次のアドレスが簡単に当てられるものにはしない。

受信はまとめて、登録先との対応は残す

別々の受信箱を毎日巡回したいわけではない。メールエイリアスや転送機能を使い、受信は一つのメールボックスへ集約する。どの専用アドレスに届いたかを確認できる状態にして、アドレスと登録先の対応表を安全に管理する。

使うサービスによって機能は違うので、元の宛先が分かるか、必要な通知が届くかは導入時にテストする。転送はSPFなどの認証判定に影響する場合もあるから、単に転送できれば完成、という話ではない。

重要な契約更新やアカウント復旧に使うなら、転送先だけでなく、エイリアスや独自ドメイン自体の維持も必要だ。罠を作ったつもりで、自分が更新通知を受け取れなくなったら笑えない。

鳴ったら調べる。鳴っただけで犯人を決めない

あるサービスにしか登録していないアドレスへ、無関係なメールが届いたらどうか。そのアドレスが想定外の経路で知られた可能性を調べる手がかりになる。

これは、触られたことを知らせるカナリアトークンやハニートークンの考え方を、メールの宛先管理に応用しようというものだ。ただし、この専用アドレスは正規の通知も受け取る。知らない差出人が現れたら即発報、即犯人確定、という単純な仕組みにはできない。

登録先が正規に利用する配信代行会社、委託先、転送経路、こちら側の端末やメール環境、偶然の推測など、考えられる経路は複数ある。そのサービスから情報が漏洩したと断定できるわけではない。差出人の表示名だけで判断せず、登録履歴や通知内容も含めて確認する必要がある。逆に、怪しいメールが来ないから情報が外へ出ていない、とも言い切れない。

題名には「罠」と書いたが、相手を攻撃したり、個人を突き止めたりする仕掛けではない。自分の情報がどこで想定外に使われたか、気付くための小さな目印だ。

被害を防ぐ対策と、異変に気付く対策。二段階認証などの基本を押さえたうえで、後者も少し工夫できないか。今回、私が面白いと思ったのはここだった。