DMARCをなめてました

この記事は、弁護士ドットコム Advent Calendar 2025 の 3 日目の記事です。

クラウドサイン SRE チームの進藤です。

「メール送信者のガイドライン」の改訂を機に「DMARCをなめるな」が公開されてから約 2 年が経過しましたが、ついにクラウドサインがサービスで利用する cloudsign.jp の DMARC ポリシーを quarantine に変更できました。

そこで本記事では、DMARC ポリシーを none から quarantine に変更するまでの流れを説明した後に、その過程での誤算や学びを共有します。 これから DMARC ポリシーを quarantine に変更する方々の参考になれば幸いです。

DMARC ポリシーを none から quarantine に変更するまでの流れ

クラウドサインでは、大まかに次の流れで DMARC ポリシーを quarantine に変更しました。

1. DMARC レポート分析環境の構築
2. DMARC ポリシーの変更による影響の事前調査
3. DMARC ポリシーの変更

DMARC レポート分析環境の構築

DMARC レポートはメール受信側サーバーから送られてくる XML 形式のファイルです¹ã€‚ 実際には基本的に zip もしくは gzip 化されたものがメールに添付されて送られてきます。

クラウドサインの場合は 100 通を超える DMARC レポートが送られてくる日も多く、個別に分析することが現実的ではありません。 そのため、まずは DMARC レポートの分析環境を構築して、DMARC ポリシーの変更による影響を分析できるようにしました。

DMARC レポートの分析環境としては SaaS や OSS も候補に入りますが、クラウドサインの場合は社内データ基盤が存在していたのでそちらを選択しました。 具体的には、XML 形式よりも CSV 形式の方が扱いやすかったためファイル形式を変換するバッチを実装し、CSV 形式の DMARC レポートを社内データ基盤に入力する構成としています。 また社内データ基盤では、ヘッダー From ドメインなどで各種認証結果を絞り込めるようにしたり、各種認証結果の時系列変化を追跡できるようにしています。

DMARC ポリシーの変更による影響の事前調査

クラウドサインは契約書を始めとした書類を介する合意締結を実現するサービスであり、合意締結の過程では書類の送信者と受信者が存在します。 書類の受信者がクラウドサインのアカウントを保有していない場合もあるので、例えば書類が送信されたことはメールで通知しています。

DMARC ポリシーを quarantine に変更すると、DMARC 認証に失敗したメールは基本的に迷惑メールフォルダに振り分けられます。 クラウドサインの場合は、それがクラウドサイン利用者の契約行為を遅延させてしまう可能性があるので事前調査を実施しました。 結果として、1 日あたり 5000 通を超えるメールに影響を与えうるとわかったため、DMARC ポリシーの変更は慎重に進めていくことにしました。

DMARC ポリシーの変更

DMARC ポリシーの変更は、リリース手法にカナリアリリースを採用することで慎重に進めていきました。 DMARC では設定の pct= パラメーターによってポリシーの適用率を指定できます²ã€‚ そのため、適用率を段階的に引き上げていくことで DMARC ポリシーの変更による影響をコントロールすることを意図したわけです。

具体的には、quarantine ポリシーの適用率と適用期間は下表のとおり計画していました。

適用率	適用期間
0%	-
5%	14 日間
10%	14 日間
20%	14 日間
100%	-

しかし実際には、後述する影響も踏まえて下表のとおりとなりました。 適用率 5% の段階では影響がほとんど確認できなかったので、適用期間を縮めつつ適用率 10% の段階をスキップしています。 振り返ってみると、適用率は計画通り 5% から 10% に引き上げる方が良かったかもしれません。

適用率	適用期間
0%	-
5%	5 日間
20%	42 日間
50%	13 日間
100%	-

DMARC レポートの分析をなめてました

DMARC レポートを分析すれば「quarantine ポリシーが適用されたメールの DMARC 認証失敗率を測れるだろう」「転送によって DMARC 認証に失敗している正当なメールを特定できるだろう」と、当初はそう考えていました。 しかし、そう単純ではありませんでした。

以下に示す DMARC レポートの例を踏まえて、その理由を説明します。

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
    <report_metadata>
        <!-- 省略 -->
    </report_metadata>
    <policy_published>
        <!-- 省略 -->
    </policy_published>
    <record>
        <row>
            <policy_evaluated>
                <disposition>quarantine</disposition>
                <dkim>pass</dkim>
                <spf>pass</spf>
            </policy_evaluated>
        </row>
        <identifiers>
            <envelope_from>mail.cloudsign.jp</envelope_from>
            <header_from>cloudsign.jp</header_from>
        </identifiers>
        <auth_results>
            <!-- 省略 -->
        </auth_results>
    </record>
</feedback>

「quarantine ポリシーが適用されたメールの DMARC 認証失敗率を測れるだろう」

DMARC レポートの feedback > record > row > policy_evaluated には DMARC 認証の結果が示されています。 disposition がメールに適用された DMARC ポリシー、dkim が DKIM Alignment の結果、spf が SPF Alignment の結果です。 この仕様から、quarantine ポリシーのカナリアリリース中は、次の条件をすべて満たすものが「DMARC 認証に失敗し、隔離対象となったメール」であると判断できるはずです。

• disposition が quarantine である
• dkim が fail である（DKIM Alignment が Fail である）
• spf が fail である（SPF Alignment が Fail である）

この失敗率を監視することで、カナリアリリースの継続可否を判断できると踏んでいました。

ところが実際にレポートを確認してみると、disposition が quarantine となっているデータがほとんど見当たりません。 このため、quarantine ポリシーが適用されたメールを識別できず、DMARC レポートからカナリアリリースの影響を正確に測ることは断念せざるを得ませんでした。 その代わりに、quarantine ポリシーの適用が原因と思われる問い合わせの件数の変化から影響を概観することにしました。

「転送によって DMARC 認証に失敗している正当なメールを特定できるだろう」

DMARC レポートの feedback > record > identifiers > envelope_from には、メールヘッダーのエンベロープ From ドメインが記載されます。 エンベロープ From ドメインが mail.cloudsign.jp である場合、そのメールの多くは「クラウドサインから送信され、転送されることなく受信者のメールボックスに届いた正当なメール」と考えられます。 一方でエンベロープ From ドメインが mail.cloudsign.jp ではない場合、そのメールは次のどちらかであると考えられます。

• ヘッダー From を詐称してクラウドサインになりすましたメール
• クラウドサインから送信されたが、転送されて受信者のメールボックスに届いた正当なメール

quarantine ポリシーの適用によって、なりすましメールが隔離されるのは期待通りですが、受信者側で転送されたメールが隔離されるのは困ります。 そのため、受信側での転送が原因で隔離されるメールを減らすことができないか検討しました。 具体的には、受信者が顧客である場合に限られますが、次の条件をすべて満たすメールはそういったメールである可能性が高いです。

• DMARC 認証に失敗している
• feedback > record > identifiers > envelope_from が mail.cloudsign.jp ではない
• feedback > record > identifiers > envelope_from が顧客の保有するドメインである

このことから、顧客を特定して個別にサポートできれば、転送が原因で隔離されるメールを減らしていけると考えました。

しかし、実際のデータを見てみると envelope_from が空値であるレコードが 99％を占めており、転送の有無を知ることすら困難でした。 これにより、DMARC レポートの分析に基づいた能動的な顧客サポートができるという目論見も外れることになります。

メールの受信者への影響をなめてました

「DMARC 認証に失敗しても、メールは迷惑メールフォルダに振り分けられるだけだろう」と予測していました。 しかし、実際には少し様子が違いました。

DMARC 認証に失敗した際の挙動はメール受信側サーバーの実装に依存しますが、quarantine ポリシーであれば、基本的には迷惑メールフォルダへの振り分けで済むと思い込んでいました。 そのため、カナリアリリースに際しては「【重要】メールセキュリティ強化にともなうDMARCポリシー変更のお知らせ」で「メールが受信トレイに見当たらない場合は、迷惑メールフォルダをご確認ください」という旨の案内をしていました。 なお、顧客には同内容をメールでも通知しています。

ところがカナリアリリースを開始すると、顧客から「メールが迷惑メールフォルダにすら届いていない」という問い合わせを受けることになりました。 結果としてわかったのは、一部のメールプロバイダーやセキュリティ製品ではメール検疫機能で隔離され、メールがユーザーの目に触れる場所へ届かないケースがあるということでした。

「メールが迷惑メールフォルダにも届いていない」という事象を想定できていなかったことにより、クラウドサイン利用者の契約行為を遅延させてしまった可能性もあります。 幸いなことに、重大な問題に発展したという事実は確認されていないですが、悔いが残りました。

振り返ってみると、顧客から問い合わせを受けてもメール送信側で解決できることがないため、次の案内を通知した方が良かったかもしれません。

• メール受信側サーバーの管理者に対する確認を促す案内
• メール受信側サーバーの管理者向けの案内

社内への影響をなめてました

「DMARC ポリシーの変更は周知できているので、問い合わせが急増することはないだろう」と楽観視していました。 しかし、予想に反して多くの問い合わせを受ける結果となりました。

カナリアリリースに際しては前述のとおり案内の掲載とメール通知をしていましたが、カナリアリリースを契機として、メール関連の問い合わせが通常時と比較して最大 30％ も増加することになりました。 更なる増加は問い合わせに対応するメンバーの稼働を逼迫させてしまう一方で、DMARC ポリシーの変更はなりすましメールを対策する目的であることから切り戻すのも望ましくありません。

そのため、カナリアリリースで quarantine ポリシーの適用率を引き上げる間隔を当初の予定より長く取ることを選択しました。 結果としては問い合わせ数の平準化に繋がったと考えられ、無事に quarantine ポリシーの適用率を 100% まで引き上げることができました。

普段からの多岐にわたる問い合わせに加え、今回の問い合わせにも尽力してくれたメンバーには心から感謝しています。 改めてありがとうございました。

今後の展望

次は DMARC ポリシーを reject に変更していきたいところですが³ 、quarantine に変更できたことで実現可能になったことがあります。 それが、BIMI の導入です。

BIMI とは、メールプロバイダーの受信トレイ上で、送信元の商標登録されたロゴ画像を表示させる技術です。 「DMARC ポリシーが quarantine 以上であること」が導入条件だったのですが、クラウドサインでも導入が可能になりました。

BIMI のサポート状況はメールプロバイダーによって様々ですが⁴、ロゴ画像の表示は正当なメールであることの証明の 1 つにもなり、ユーザーの安心感につながります。 今後はこの導入に向けた取り組みを進めていきたいと考えています。

---

1. 書式の詳細や各要素の意味については仕様を参照してください：RFC7489 Appendix C. DMARC XML Schema↩
2. 例えば DMARC 設定が p=quarantine; pct=10 である場合 10% のメールに quarantine ポリシーが適用されます。↩
3. reject が適用されたメールは、DMARC 認証に失敗するとメール受信側サーバーで受信拒否されることが期待されます。↩
4. BIMI の標準化団体が BIMI のサポート状況を公開しています：MailBox Provider↩