ドコモメール 公式マーク付きの詐欺メール｜PASSでも届くDKIM リプレイと入力の悪用、送信側の対策と確認手順

正規の仕組みを踏み台にして信頼を借りる攻撃は、配布物に入り込むサプライチェーン攻撃と考え方が近い構図です。全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。本記事はドコモメール 公式マークの事案を起点に、メールを送る側が何を確かめるかに絞ります。

ドコモメール 公式マーク付き詐欺メールの時系列（タイムライン）

ドコモメール 公式アカウントは送信ドメイン認証を通った登録事業者のメールにマークを出す仕組みです。案内には「弊社がメールの内容を保証するものではありません」とあります。

何が起きたか：正規の署名のまま偽の文面が届く2つの経路

公式に分かっているのは「一部企業の送信ドメイン認証の設定に脆弱性があった」までです。どの設定だったのかは公表されていません。ここでは、同じ形の事象を起こすと公表・報道された2つの経路を説明します。

経路1：DKIM リプレイ（署名済みのメールの再送）

DKIM は、送信ドメインがヘッダーの一部（h= に並べたもの）と本文に署名する仕組みです。SMTP のエンベロープ、つまり実際の配送先には署名しません。署名済みのメールを1通手に入れれば、別の宛先へ送り直しても署名は壊れず、DMARC も From のドメインと署名のドメインが一致して通ります。

Google の例では、攻撃者は自分のドメインに me@ で始まる Google アカウントを作り、OAuth アプリを登録して、その「アプリ名」欄にフィッシングの文面を丸ごと入れました。アクセスを許可すると、Google が自分の DKIM 署名つきでセキュリティ通知を me@ に送ります。攻撃者はそれを被害者へ送り直し、[email protected] からの正規の通知に見せかけました。Google は当初、想定どおりの動作だとしましたが、のちに OAuth の問題に対処すると伝えてきたと Johnson は投稿しています。修正が済んだかは公表されていません。

経路2：入力のエコー（入力欄の値がそのまま通知に載る）

問い合わせフォームの自動返信は入力された連絡先に、入力された名前や本文を載せて送ります。攻撃者が連絡先に被害者のアドレスを、本文欄に誘導文や URL を入れれば、自社のサーバーから自社の署名で、被害者に偽の文面が届きます。エックスサーバー・さくらインターネット・ロリポップ! は以前から、この悪用への注意を呼びかけてきました。

Robinhood の例では、攻撃者がアカウント登録時に「デバイス名」へ HTML を入れました。ログイン通知のテンプレートがそれを無害化せずに描画したため、正規の noreply アドレスから「見覚えのないデバイス」の警告と、偽サイトへのボタンが届きました。メールは SPF と DKIM を通っています。Robinhood はシステムの侵害ではないと説明し、問題に対処したと報じられています。

2つの経路は組み合わさります。Google の例では、署名された中身に攻撃者の文面（アプリ名）が入っていたので、送り直すだけで偽の文面が届きました。

楽天カード名義の件で分かっていること

利用者の報告では、SPF の評価対象は楽天と無関係に見える .com のドメインでした。送り直されたメールなら、エンベロープの送信元は送り直した側のドメインになり、DMARC は DKIM の一致で通ります。報告とは矛盾しませんが、これで経路が決まるわけではありません。MailData は「正規の送信基盤から送られ、DKIM で署名されたメールは、SPF・DKIM・DMARC を pass し、BIMI のロゴも表示されます」と書き、この件を2つの経路の悪用として解説しています。ドコモと楽天カードは、どちらの経路かを公表していません。

ドコモメール 公式マーク・BIMI ロゴ・PASS が保証する範囲

どの表示も、文面を誰が書いたかは見ていません。自社の送信基盤が外の人の書いた文面に署名して送れば、表示はすべて「本物」になります。

受け取る側はマークの有無で判断せず、本文のリンクを使わないことが基本です。To が自分のアドレスでないのは再送の手がかりになりますが、署名の範囲によっては書き換えられるので、それだけでは判断できません。リンクを踏ませる手口と、それを防ぐ認証の選び方はパスキーと多要素認証｜SMSやTOTPでも中継されるフィッシングの穴と、WebAuthnが塞ぐ理由を実測で扱いました。

対策：自動返信と通知メールを踏み台にしない（送信側）

MailData は自動返信に入力を載せるなら「通知用とは別のサブドメインから送り、BIMI を設定せず、HTML はエスケープする」ことを条件に挙げています。DKIM 側の緩和策は Red Sift・Proton などが挙げています。どれが何を防ぐかは次のとおりです。

再送そのものは送信側の設定では止められません。MailData も「設定が仕様どおりでも、DKIM の署名範囲が狭い場合や、入力内容を自動返信に載せている場合は防げません」と書いています。効くのは、署名する中身に外の人の文面を入れないことです。

役割が分かれている組織では、確認の相手も分かれます。自動返信の文面を作るのが Web 担当、DKIM・DMARC・BIMI を設定するのが情報システム担当なら、両者で「自動返信に何を載せ、どのドメインから送っているか」を一度突き合わせます。

BIMI のドラフトは、サブドメインがロゴの表示を辞退する記録（v=BIMI1; l=; a=;）を定めています。辞退の記録が無いと組織ドメインの記録がサブドメインにも使われることがあるので、自動返信のサブドメインにはこれを置きます。辞退したサブドメインでも DMARC は強制（p=quarantine か reject）にしておきます。強制していないと、そのドメインを詐称される余地が残ります。

自システムの確認コマンド：自動返信が入力を載せていないか

DNS の記録と、自社のフォームから自分宛てに届いた自動返信を見ます。コードのリポジトリを調べる手順ではないので、git の操作はありません。example.com は自社のドメイン、form.example.com は自動返信を送るサブドメインに置き換えます。

1. 自動返信を送るドメインの DMARC と BIMI

dig +short TXT _dmarc.example.com
dig +short TXT _dmarc.form.example.com
dig +short TXT default._bimi.example.com
dig +short TXT default._bimi.form.example.com

2行目が空なら、サブドメインには組織ドメインの DMARC（sp= があればその値）が使われます。3行目にロゴの URL（l=https://…）があり、4行目が空なら、自動返信にもロゴが付く可能性があります。4行目が "v=BIMI1; l=; a=;" なら辞退済みです。BIMI のセレクタを default 以外にしているなら、その名前で引きます。ドコモの公式アカウントは BIMI とは別の登録なので、どのドメインが対象かはドコモに登録した内容で確かめます。

2. 自動返信の DKIM 署名の範囲

フォームから自分宛てに送らせた自動返信を、メールソフトの「ソースを表示」などで .eml に保存し、autoreply.eml という名前にします。

awk '{sub(/\r$/, "")} /^$/{exit} /^[ \t]/{h = h $0; next} {if (h != "") print h; h = $0} END{if (h != "") print h}' autoreply.eml | grep -i '^DKIM-Signature:' | tr -d ' \t' | tr ';' '\n' | grep -E '^(d|s|l|x)='
awk '{sub(/\r$/, "")} /^$/{exit} /^[ \t]/{h = h $0; next} {if (h != "") print h; h = $0} END{if (h != "") print h}' autoreply.eml | grep -i '^DKIM-Signature:' | tr -d ' \t' | tr ';' '\n' | grep '^h=' | cut -c3- | tr 'A-Z:' 'a-z\n' | sort | uniq -c

1つ目は署名したドメイン（d=）・セレクタ（s=）と、l=・x= の有無を出します。l= が出たら本文の長さを限った署名です。2つ目は署名したヘッダーの一覧で、数字が2以上なら重ねて署名しています。subject・to・date が無ければ、そこは署名の外です。ヘッダー部分だけを読むので、本文に DKIM-Signature: という文字列があっても拾いません。

3. 入力がそのまま載るか

フォームの名前の欄に <b>ECHO7f3a</b>、本文の欄に https://example.com/ECHO7f3a と入れ、連絡先を自分のアドレスにして送ります。届いた自動返信を autoreply.eml に保存して実行します。

python3 - autoreply.eml ECHO7f3a <<'PY'
import sys, email
from email import policy
msg = email.message_from_binary_file(open(sys.argv[1], 'rb'), policy=policy.default)
mark = sys.argv[2]
print('Subject', 'echo=yes' if mark in str(msg['subject']) else 'echo=no')
for part in msg.walk():
    if part.get_content_maintype() != 'text':
        continue
    text = part.get_content()
    html = part.get_content_subtype() == 'html'
    print(part.get_content_type(),
          'echo=yes' if mark in text else 'echo=no',
          'tag=raw' if html and '<b>' + mark in text else 'tag=-',
          'link=yes' if html and 'href="https://example.com/' + mark in text else 'link=-')
PY

件名と本文のパートごとに、目印が載ったか（echo）、HTML のタグが無害化されずに残ったか（tag=raw）、URL がリンクになったか（link=yes）を出します。本文が base64 で符号化されていると grep では見落とすので、デコードしてから探しています。Contact Form 7 なら、自動返信（メール (2)）の既定の件名に [your-subject]、本文に [your-message] が入っています（6.2.2 のソースで確認）。

結果の読み方と、このコマンドの限界

ダミーのメールと、ローカルに立てた DNS サーバーで、掲載したままのコマンドを走らせました。

実在のドメインに対する dig は未検証です（出力の形はローカルの DNS で確かめた）。読むときの注意は2つです。

・何も出なくても安全とは限らない：確かめたのは1つのフォームの1つの欄。ほかのフォーム、会員登録・パスワード再設定の通知、管理画面に入力できる表示名なども同じ経路になりうる
・echo=yes でも悪用されるとは限らない：エスケープしたテキストで送っていれば、偽のボタンやリンクは作れない。ただし文字の誘導文は届くので、載せる欄を減らすのが先

影響範囲：誰が何を確かめるか

送信基盤そのものを乗っ取られる場合は、また別の対策が要ります。クラウドのメール送信サービスの認証情報を奪われた例はAmazon SES悪用フィッシング・BEC攻撃急増2026｜SPF/DKIM突破の手口とIAM最小権限防御で、ISP のメールのパスワードが漏れた件はKDDI情報漏洩とは｜ISPメールのパスワード761万人分が平文、対象の見分け方・原因と利用者がやることで扱っています。

参照ソース

・公式アカウントについて（NTTドコモ） — 公式アカウントマークの表示条件と、内容を保証しないという記載
・入力のエコーを使ったなりすましの解説（MailData） — 楽天カード名義の事例の分析、自動返信に入力を載せるときの条件
・Google Sites と DKIM リプレイを使ったフィッシング（The Hacker News） — Google の通知を使った DKIM リプレイ
・Robinhood のアカウント作成の悪用によるフィッシング（BleepingComputer） — デバイス名の欄を使った入力のエコー
・DKIM リプレイ攻撃の解説（Red Sift） — 重ね署名・l= を使わない・x= などの緩和策
・DKIM リプレイ攻撃の仕組み（Proton） — 再送の仕組みと緩和策の限界
・RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — 署名の対象（h=・l=・x=）とエンベロープを扱わない点
・メールフォームの悪用への注意（エックスサーバーのマニュアル） — 問い合わせフォームの自動返信を使った迷惑メールと、自動返信の無効化