佐川急便スマートクラブの個人情報漏えいを起点に、佐川・ヤマト・日本郵便のメール設定を公開DNSから検証。前半は一般利用者向けに「偽の配達通知にどう備えるか」を、後半は技術者向けにSPF・DKIM・DMARC・BIMIの読み方と設定手順（RFC 9989対応）を解説する。
2026年7月18日、佐川急便が会員サービス「スマートクラブ」で個人情報が漏えいしたと公表した。
配達予定を知らせるメールに、別の会員の氏名、メールアドレス、配送状況確認番号、いわゆる追跡番号が記載されていた。対象は約7万人とされている。
発表を読んで、最初に知りたかったのは原因ではなかった。
対象になった利用者は、これから何をすればよいのか。
漏れたとされる情報に、住所や電話番号、クレジットカード情報、パスワードは含まれていない。少なくとも、パスワードを急いで変える種類の事故ではなさそうだ。
では、何に気をつければいいのか。それを知りたくて、佐川急便のサイトにある「迷惑メールにご注意ください」という案内を開いた。
そこにあったのは、想像をはるかに超える量だった。
佐川急便を装った偽メールやショートメールの実例が、2012年から2025年まで並んでいる。数えると51件。それぞれに件名、差出人名、本文、確認された時期が記録され、偽サイトの画面まで掲載されている。
読み進めると、手口の変化が見えてくる。
初期には、現金の受け取りを求めるなど、文面に不自然さが残るものも多かった。ところが最近は、住所確認、再配達、関税や手数料の支払いなど、実際に荷物を待っている人なら反応しかねない内容へ変わっている。
さらに、本物らしさを高めるため、偽メールの本文中に佐川急便の正規URLや正規のメールアドレスを混ぜる例もある。差出人名も「佐川急便」だけではなく、「サガワ急便」「佐川便」など、少しずつ表記を変えてくる。
十数年にわたり、これだけの事例を記録して公開している。その姿勢は率直に立派だと思う。ここまで過去の手口を公開している会社は多くない。
しかし、51件を読み終えたとき、別の疑問が残った。
利用者はこれをすべて読み、覚え、次に届いたメールが本物かどうかを、自分で見分けなければならないのか。
この一覧は完成した教科書ではない。攻撃者は文面も、差出人名も、リンク先も変えられる。注意喚起が一つ増えれば、また別の形が作られる。
この追いかけっこに終わりはない。
では、利用者が一通ずつ見分ける前に、受信箱へ届かないよう機械で止められる範囲はないのだろうか。
佐川急便、ヤマト運輸、日本郵便の公開されているメール設定を、同じ方法で比べてみた。
調べたのは、ひとことで言えば「その会社の正規ドメインを装った偽メールを、受信箱へ届きにくくする設定が、どこまでされているか」である。この設定は、類似ドメインや表示名だけの詐称までは防げないが、正規ドメインそのものを装う攻撃には効く。
同じ宅配大手でも、進み具合は三社で違っていた。
佐川急便のDMARCは、なりすましの発生状況を把握するためのレポートを受け取る設定になっていた。一方、認証に失敗したメールを隔離・拒否するよう受信側へ求める設定にはなっていない。
利用者には十数年分の事例を示して注意を促しているが、メール認証については、機械的な隔離・拒否ではなく監視を中心とした構成だった。
ヤマト運輸は、監視から隔離へ進めた構成だった。
自社になりすまし、認証に失敗したメールを、受信側で迷惑メールとして自動的に隔離するよう求めている。さらに、対応するメールサービスでは、認証を通過したメールに公式ロゴを表示し、本物を識別するための補助的な目印を提供している。
もちろん、これですべての偽メールが消えるわけではない。攻撃者がヤマトとは別の、よく似た名前のドメインを新しく取って送ってくれば、ヤマト自身の設定では止められない。
それでも、少なくとも本物と同じFromドメインを装う攻撃については、人の目だけに頼らず、受信側へ機械的な隔離を求めている。注意喚起を増やすのではなく、利用者が自分で見分けなければならない範囲そのものを、減らしにいっている。
日本郵便は、少し込み入っていた。
会社の看板にあたる代表ドメイン（japanpost.jp）は、「ここからはメールを送りません」と宣言し、なりすましを拒否する強い設定になっている。これだけを見れば、しっかり守られている。
ところが、実際に会員へメールを送っているのは、別のドメインだった。そちらを確認すると、設定は監視を中心とした段階にとどまっていた。
つまり、代表ドメインと、実際に利用者へメールを送るドメインとで、設定方針が異なっていた。
ここに大事な教訓がある。企業のメール対策を確認するときは、代表ドメインだけでなく、実際に利用者へメールを送るドメインを見る必要がある。
三社とも、偽メールへの注意喚起を行っている。しかし、注意喚起と技術的な防御の組み合わせ方は異なっていた。
佐川急便は、十数年分の事例を詳しく公開している。ヤマト運輸は、注意喚起に加えて、正規ドメインの詐称メールを隔離する設定と、公式ロゴによる識別手段を導入している。日本郵便は、代表ドメインと実際のメール送信ドメインで設定方針が異なっていた。
DMARCを厳しくしても、類似ドメイン、SMS、偽サイトまで防げるわけではない。注意喚起は引き続き必要である。
しかし、設定で防げる正規ドメインの詐称まで、利用者に見分けさせる必要はない。
まず機械で防げるものを防ぐ。そのうえで、機械では防ぎきれない攻撃を利用者へ知らせる。
三社の違いから見えたのは、注意喚起の量だけでなく、この二つをどう組み合わせるかという設計の違いだった。
最後に、いちばん知りたかったことに戻る。
今回漏れたとされる情報に、パスワードやクレジットカード番号は含まれていない。だから、この発表だけを理由に、あわててパスワードを変える必要は低い。
本当に警戒すべきなのは、漏れた氏名・メールアドレス・実在する追跡番号を使った、偽の配達通知である。
ここが今回のいちばん大事な点だ。**追跡番号が本物でも、メール全体が本物とは限らない。**今回のように氏名、メールアドレス、実在する追跡番号が別の相手へ送られると、それらが悪用された場合、偽の配達通知を本物らしく見せる材料になりうる。
だから、メールでもショートメールでもLINEでも、配達の通知が届いたら、その本文にあるリンクからは荷物を確認しない。
かわりに、佐川急便の公式アプリを開く。あるいは、自分で登録しておいたブックマークから公式サイトに入る。検索から入るときも、広告や、よく似た偽のアドレスにだけは気をつける。追跡番号は、メールのリンク先ではなく、自分で開いた正規のサイトに入力する。
問い合わせをするときも、届いたメールに書かれた電話番号や窓口ではなく、公式サイトに載っている連絡先を使う。おわびや補償、本人確認、再配達などを口実にした二次的なメールにも、同じ警戒を向けたい。
要点は、たった一つにまとめられる。
届いた通知を入口にしない。自分から、公式の入口を開く。
今回、利用者が取るべき行動は、パスワードの変更よりも、こちらである。
前半で「機械で止める設定」と呼んだものの正体は、送信ドメイン認証である。SPF・DKIM・DMARCの三つ、そして認証済みメールにブランドロゴを表示するBIMIを、三社の実際のレコードを教材に読み解いていく。
2026年7月19日時点で、公開DNSから確認した主な構成は次のとおりだった。
| 項目 | 佐川急便 | ヤマト運輸 | 日本郵便（会員向け送信ドメイン） |
|---|---|---|---|
| SPF | -all | -all | ~all |
| DMARC | p=none | p=quarantine | p=none |
| BIMI | 確認できず | あり | 確認できず |
| DMARCの状態 | 監視 | 隔離を要求 | 監視 |
以下、各技術が何を検証し、三社のレコードがそれぞれ何を意味するかを解説する。
-allと~allでは何が変わるのかSPFは、そのドメインのメールを送信してよいサーバーを、DNSのTXTレコードで宣言する仕組みである。
レコードの末尾には、一覧に含まれていない送信元をどう評価するかが書かれる。今回の三社で確認できたのは、主に次の二つだった。
-all：一覧外の送信元をFailと判定する~all：一覧外の送信元をSoftFailと判定する-allは、「記載されていないサーバーから送られたメールは、当ドメインが許可したものではない」という明確な宣言である。
一方の~allは、「正規の送信元ではない可能性が高いが、直ちに完全な失敗とは扱わない」という移行的な宣言である。メールシステムの移行中や、すべての送信元をまだ把握できていない環境で使われることがある。
ただし、ここで注意が必要だ。
-allは、受信側にメールの拒否を命令する設定ではない。
-allに該当すればSPFの結果はFailになるが、そのメールを拒否するか、迷惑メールへ入れるか、そのまま受け取るかは、受信側の判断やDMARCポリシーに依存する。
ただし、受信システムによっては、SPFのFailをSMTPセッションの早い段階で拒否する場合がある。この場合、DKIMを含むDMARC評価が行われる前に処理が終了し、DMARC集計レポートにも記録されない可能性がある。したがって、-allは単なる表示上の強弱ではなく、正規の送信元を十分に把握したうえで設定する必要がある。
同様に、~allは「受け取ってよい」という意味でもない。結果はSoftFailとなり、SPF認証に成功したことにはならない。
三社の設定では、佐川急便とヤマト運輸が-all、日本郵便の確認対象となった会員向け送信ドメインが~allだった。
これは、一覧外の送信元に対するSPF上の宣言が異なることを示す。しかし、正規ドメインを表示上のFromに使ったなりすましを実際に隔離・拒否できるかは、SPFだけでは決まらない。
なぜなら、SPFが検証するのは主にSMTPのエンベロープFromであり、利用者がメール画面で目にするヘッダーFromとは別だからだ。
攻撃者は、エンベロープFromには自分が管理するドメインを使ってSPFを通し、表示上のFromだけを宅配会社のドメインに偽装できる。
この二つのドメインが整合しているかを確認し、失敗したメールをどう扱うかを決めるのがDMARCである。
なお、ヤマトのSPFレコードには、SPFの参照回数（DNSルックアップ10回）の上限を超えないよう、レコードを平坦化する外部サービスの記述が含まれていた。送信元が多い組織で-allを維持するための実務的な工夫であり、SPFを厳格に保つ運用の一例として参考になる。
DKIMは、送信メールに電子署名を付け、受信側がDNS上の公開鍵で検証する仕組みである。改ざんの有無と、署名したドメインを確認できる。
注意すべきは、DKIMがPassしただけでは、表示上のFromドメインが正しいとは限らない点だ。署名したドメインと、利用者に表示されるFromドメインが一致・整合していて初めて意味を持つ。この整合性（Alignment）を判定するのが、やはりDMARCである。
DKIMの検証にはセレクタ名が必要で、これは実際の送信メールのヘッダーにあるDKIM-Signatureのs=を見ないと分からない。DNSのTXTだけでは網羅確認できないため、本稿の三社比較はSPF・DMARC・BIMIを対象にしている。
DMARCは、SPFとDKIMの認証結果を利用し、少なくとも一方が成功して、表示上のFromドメインと整合しているかを評価する。いずれの方法でも認証と整合が成立しなかった場合に、メールをどう扱うかを送信ドメインの所有者が受信側へ示す。方針は三段階。
p=none：処理は変えず、主にレポートを収集する（監視）p=quarantine：迷惑メールなどへの隔離を求めるp=reject：受信拒否を求めるポリシーはあくまで受信側への「要求」であり、最終処理は受信事業者の実装にも依存する。したがって「p=rejectなら世界中で必ず拒否される」と断定はできない。とはいえ、主要なメールサービスを使う限り、p=noneとp=quarantine／p=rejectの差は大きい。p=noneは、レポートを集めても、認証失敗メールを止める明示的な要求を出していないからだ。
三社のDMARCはこう読める。
佐川急便はp=none。表示上のFromを佐川のドメインに偽装し、SPF・DKIMのAlignmentに失敗したメールが送られても、佐川自身のDMARCは隔離も拒否も要求しない。レポート送信先は設定されているため、観測と分析は行っていると考えられる。
ヤマト運輸はp=quarantine。認証とAlignmentに失敗したメールを、受信側で隔離するよう求める。加えてBIMIを導入している。BIMIを安定運用するにはDMARCが強制モードである必要があり、ヤマトはDMARCによる振り分けと、ロゴによる視覚的な識別を組み合わせている。
日本郵便は、ドメインを分けて見る必要がある。代表ドメインjapanpost.jpはSPFに送信元を列挙せず-all、DMARCもp=reject。これは「このドメインからメールを送らない」前提で、第三者の詐称を防ぐ有効な設定だ。一方、実際に会員へメールを送る運用ドメインを確認すると、SPFは~all、DMARCはp=noneだった。代表ドメインの設定だけを見て全体を評価すると、実際のメール経路を見落とすことになる。
BIMIは、受信箱の一覧に企業の公式ロゴを表示する仕組みである。ロゴが出るには、DMARCが強制モード（quarantine以上）で運用されていることなど、複数の条件がある。
このため、ロゴの表示は、認証済みメールを識別する補助材料になる。ただし、表示条件はメール事業者や証明書の要件にも依存するため、ロゴが表示されないことだけで偽物とは判断できない。
三社のうち、確認できたのはヤマトのみで、商標の所有を認証局が検証した証明書（VMC）を伴う構成だった。佐川と日本郵便の確認対象ドメインでは、BIMIレコードを確認できなかった。また、両ドメインのDMARCはp=noneであり、BIMI表示に必要な強制ポリシーの条件を満たしていない。
日本郵便の例が示すのは、調査対象を代表ドメインに限ってはいけない、ということだ。攻撃者にとって価値が高いのは、必ずしも会社の代表的な名前ではなく、利用者が日常的に目にし、信頼している送信ドメインである。DMARCの棚卸しでは、次のような経路をすべて洗い出す必要がある。
会員サービス、メールマガジン、配達通知、問い合わせシステム、マーケティング配信、請求・決済通知、外部委託サービス、グループ会社や地域会社。これらは代表ドメインと別のドメインやサブドメインで運用されていることが多く、そこがp=noneのままだと、正規ドメインの詐称に対して、DMARCによる隔離・拒否を明示的に要求できない。
p=noneは、それ自体が誤りというわけではない。DMARC導入初期には、正規の送信元を把握するために必要な段階である。p=noneを移行段階として使う場合は、レポート収集の目的、強制モードへの移行条件、移行の予定を明確にしておく必要がある。実務上は、次の順で進める。
送信元を棚卸しする。 DMARC集計レポートで、対象ドメインを名乗っている送信元を洗い出す。自社サーバーだけでなく、SaaS、メール配信サービス、問い合わせ・採用・請求などの各種システムも対象になる。
SPFとDKIMを整合させる。 各送信サービスについて、SPFまたはDKIMがFromドメインとAlignmentするよう設定する。可能ならSPF依存を避け、DKIM署名を有効にする。メール転送でSPFが失敗しても、DKIMが維持されればDMARCを通せる可能性があるためだ。
不明な送信元を整理する。 レポート上の送信元を、正規・廃止済み・なりすましに分類する。使っていない正規サービスが残っていれば、DNSやサービス側の設定を削除する。
段階的に強制する。 十分に整合したら、まずp=quarantineへ移行し、正規メールの到達性とDMARC集計レポートを確認する。旧仕様には適用率を指定するpctタグがあったが、2026年のRFC 9989で廃止された。段階移行が必要な場合は、送信ドメインやサブドメイン、送信経路を分けて実施する。
用途に応じてrejectを検討する。 正規メールの到達性に問題がないことを確認したうえで、送信ドメインの用途に応じてp=rejectへの移行を検討する。
企業システムから通知を送る専用ドメインや、メールを送信しないドメインでは、正規の送信経路を管理できていればp=rejectが選択肢になる。
一方、そのドメインに所属する利用者が日常的にメールを送り、外部のメーリングリストへ投稿する可能性がある場合、RFC 9989はp=rejectによる相互運用上の問題に注意を求めている。このようなドメインでは、p=noneとp=quarantineで十分な期間レポートを確認し、間接的なメール経路への影響を評価する必要がある。
また、RFC 9989は受信側に対し、公開されたp=rejectだけを唯一の根拠としてメールを拒否せず、他の知識や分析も含めて処理を判断するよう求めている。
いずれのポリシーを選ぶ場合も、移行後のDMARCレポート監視は継続する。新しいSaaSやメール送信サービスが無断で追加されれば、正規メールがDMARCに失敗するためだ。
保有ドメインには、Webには使うがメール送信には使わないものもある。その場合、送信しないことを明示する設定が有効だ。SPFは送信元を許可せず-all、DMARCはp=rejectを指定する。加えて、メールを受信しないドメインでは、必要に応じてNull MX（MX 0 .）を設定し、メールを受け付けないことも明示する。ただしNull MXは受信停止の宣言であり、送信元詐称を防ぐSPF・DMARCとは役割が異なる。日本郵便の代表ドメインは、この「送らないドメインを閉じる」型の設定にあたる。
攻撃者は、日常的に使われるドメインだけでなく、グループ会社、旧ブランド、キャンペーン、採用サイトなど、利用者が見覚えのあるドメインを狙う。メールを送らないドメインを放置しないことも、なりすまし対策の一部である。
DMARCは万能ではない。類似ドメイン、フリーメール、SMS、メッセージアプリ、検索広告、偽サイトまでは止められない。だから注意喚起は必要だ。
しかし、DMARCで防げる正規ドメインの詐称まで、利用者に見分けさせる必要はない。今回の三社の設定の違いが示していたのは、技術の有無ではなく運用の進み具合だった。レポートを集める段階にとどめるのか、隔離まで進めるのか、拒否まで進めるのか。代表ドメインだけを閉じるのか、実際に顧客へメールを送るドメインまで整えるのか。
注意喚起を増やす前に、設定で減らせるリスクが残っていないかを確認する。それが、利用者へ「もっと注意してください」と求める前に、送信する企業側にできることである。
Aikido Community Japan
公開日: 2026/7/19
最終更新: 2026/7/18
セキュリティの最新情報をお届けします。