STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

DMARC の取り組み

こんにちは。セキュリティ本部の yokoyama です。

セキュリティ本部では、「STORES プラットフォームに内在するセキュリティリスクを適切にコントロールする」をミッションに、日々さまざまな活動に取り組んでいます。

少し時間が経ってしまいましたが、2025年6月に全サービスドメインの DMARC ポリシーを quarantine に移行しました。 今回は、DMARC の取り組みについてご紹介します。

DMARC について

DMARC(Domain-based Message Authentication, Reporting and Conformance)は、SPF や DKIM の認証に失敗したメールの扱いを受信側でどう扱うかを送信側が DMARC ポリシーで宣言する仕組みです。DMARC ポリシーの種類は以下の通りです。

  • none
    • DMARC 認証に失敗したメールに対して何もアクションを取らず、レポートを収集するモードです。
  • quarantine
    • DMARC 認証に失敗したメールを隔離(通常は迷惑メールフォルダに配置)するよう受信側に指示します。
  • reject
    • DMARC 認証に失敗したメールを拒否し、受信者に配信されないよう受信側に指示します。

STORES での DMARC の取り組みについて

STORES ネットショップ では商品購入時の通知メール、STORES 予約 では予約時の通知メールなど、各種メール通知を行なっており、メールは当社サービスに欠かせない仕組みです。

各サービスドメインの送信元を適切に認証し、なりすましメールによるフィッシング詐欺やブランド毀損などのリスクを軽減するため、DMARC の導入と段階的なポリシー強化に取り組んできました。

目標設定

以下の目標を掲げ、DMARC 導入プロジェクトを立ち上げました。

  • 全サービスドメインの DMARC ポリシーを quarantine まで移行する
  • 正規のメール配信に影響を与えない
  • 段階的なポリシー強化による安全な移行を実現する

取り組み概要

DMARC ポリシー none の設定と現状把握

各サービスドメインに DMARC ポリシーを none で設定し、モニタリングを開始しました。

  • 全サービスドメインの DNS レコードに DMARC ポリシーを none で設定
  • DMARC RUAレポートを収集および、分析ツールの製品選定、分析方法、運用設計を確立
  • 正規の送信元とそれ以外の送信元を洗い出し

SPF と DKIM の整備

DMARC RUA レポートを分析し、認証に失敗している正規の送信元を特定しました。その結果をもとに、SPF(Sender Policy Framework)と DKIM(DomainKeys Identified Mail)の設定を見直しました。

  • 全サービスドメインで認証に失敗している正規の送信元を特定
  • SPF と DKIM の設定を見直し
  • DMARC の認証状況を確認

none から quarantine への移行

SPF と DKIM の整備が完了し、正規の送信元からのメールが DMARC 認証を通過することを確認した後、DMARC ポリシーを none から quarantine に移行しました。

  • メール流通量の少ないサービスドメインから移行
  • 移行後の DMARC RUA レポート監視

継続的なモニタリング

フィッシングメールなどの流通状況を把握するため、DMARC 認証失敗が一定数を超えた時に Slack で通知する仕組みを導入し、監視しています。

DMARC 認証失敗が一定数を超えた際の Slack 通知例

DMARC の取り組みで感じたこと

送信元の把握の難しさ

最も苦労したのは、全サービスドメインのメール送信元を正確に把握することでした。

STORES は複数のスタートアップが経営統合されてできた会社です。 サービスごとにメール配信サービスやマーケティングツールが異なるため、全社的な棚卸しが必要でした。

DMARC RUA レポートは Google や Microsoft などから ZIP ファイル形式(中身は XML ファイル)で指定した宛先に毎日届きますが、XMLファイルは以下のような内容です。

  <record>
    <row>
      <source_ip>***.***.***.****</source_ip>
      <count>100084</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>stores.jp</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>stores.jp</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>em.stores.jp</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

XML ファイルのままでは解析困難です。そこで、DMARC 分析ツールを利用して以下の対応を行いました。

DMARC 分析ツールでは、DMARC RUA レポートの source_ip から、Google WorkSpace、SendGrid など送信グループごとに DMARC、DKIM、SPF の統計情報を CSV 出力できるため、この CSV ファイルを活用しました。

各部門に利用状況の棚卸しを依頼する際に利用したスプレットシート例

統計情報のみでは正規メール、メール転送、フィッシングの疑いなどを判断できないため、source_ip ごとの DMARC、DKIM、SPF の結果を確認して判断した上で、各部門に利用状況の棚卸しを依頼し、送信元の全体像を把握してきました。

source_ip ごとに正規メール、メール転送、フィッシングの疑いの可能性などを判断で利用したスプレットシート例

関係部署との調整

メール配信への影響が出ないようセキュリティ本部だけでなく、開発、マーケティング、カスタマーサポートなど、メール配信する全部門と調整を行いました。社内やオーナー様への事前周知と十分な準備期間を確保した上で、移行を進めました。

まとめ

全サービスドメインの DMARC ポリシーを quarantine に移行したことで、当社ドメインを詐称したなりすましメールの一定数はメールボックスに届かなくなりました。

今後も、DMARC RUA レポートの継続的な監視を行い reject への移行や、BIMI(Brand Indicators for Message Identification)の導入による、さらなるメールセキュリティの向上を目指しています。

おわりに

今回は、セキュリティ本部で実施している DMARC の取り組みの一部をご紹介しました。

STORES では、「Just for Fun」というミッションの実現のため、一緒に働く仲間を大募集しています。

セキュリティに高い関心をお持ちの方、 ぜひ採用サイトにも遊びに来てください!

jobs.st.inc