Zenn
レバテック開発部
🌟

俺はDMARC認証の対策をしたと思ったら、いつの間にか他社のDMARCレポートに引っかかっていた

smmr
2024/04/24に公開
#
メール
#
DMARC
#
arc
tech

あ…ありのまま今起こったことを話すぜ！

はじめに

どうも、レバテックでCREをやっている住村です。
去年から飼い始めた犬が先日1歳の誕生日を迎えて、「もう1歳か」と「まだそれくらいしか経ってないのか」という矛盾した感覚を覚えます。
世のお父さんお母さんたちもこういう感覚なんでしょうか？

先日、Gmailの送信ガイドラインの変更で各社でもList-Unsubscribeヘッダの対応に追われたり、自社ドメインのDMARC認証状況を確認するためにDMARCレポートを見るようになったりで様々な対応を迫られていると思います。

関連して、今回は自社のメーリングリストが他社のDMARCレポートで認証失敗として検知されたので、その対応で得た知見を書こうと思います。

概要

  • メーリングリストなどによるメールの転送時、DMARC認証に失敗することがある
    • メール転送時にエンベロープFromが書き換わり、ヘッダFromとの差異が発生するため
  • メール転送時の認証失敗の対策としてARC認証が存在する
    • Gmail送信ガイドラインでは、メール転送時はARC認証の設定を推奨される
    • DMARC認証に失敗した場合も、受信メールサーバの設定次第でARC認証に成功していれば受信できる
      • DMARCレポート上ではアライメントの失敗が表示されるが、ARC認証の成功は確認できる

DMARCとメール転送

まず今回のメイン、メーリングリストによるメール転送でDMARC認証に失敗していた件から説明します。

DMARC

DMARCはメール送信元の正当性を担保するための仕組みです。

今回の事象に関わる部分は、DMARCの認証に失敗した場合の挙動とSPF/DKIMで認証されたドメインのアライメントの検証です。
DMARCの認証に失敗した場合も、受信メールサーバ側の設定次第で受信できます。
また、後述するDMARCレポートの送信先メールアドレスもDMARCの設定で指定します。

アライメントの検証では、ヘッダFromとSPF/DKIMで認証したドメインが一致するかをチェックします。

メーリングリストなどのメール転送で失敗する理由

メーリングリストの仕組み上、メーリングリストが受信したメールを参加者へ送信するため、ヘッダFromはそのままでエンベロープFromがメーリングリストに切り替わります。
これによってヘッダFromとエンベロープFromでドメインが異なるのでアライメントの検証に失敗するので、メーリングリストなどのエンベロープFromを書き換えて転送されるメールはDMARC認証に失敗してしまいます。

この状況を図化すると、下図の流れでDMARC認証が失敗します。

メール転送により、DMARCの認証に失敗する場合
メール転送により、DMARCの認証に失敗する場合

ARC

（2024年4月現在、RFC上だとARCはStandardではなくExperimentalの扱いです）

前述のメール転送時の認証失敗に対応するための仕組みが、ARCです。
ARCはメールを転送する際に送信元の認証情報を再署名してARCヘッダとして付与し、連鎖的に送信元の正当性を検証できます。

メール転送時、ARCが設定されている場合
メール転送時、ARCが設定されている場合

DMARC認証に失敗した場合も、受信メールサーバ側の設定次第でARCの認証に成功すればメールが受信できます。
冒頭で触れたGmai送信ガイドラインでは、メーリングリストなどを利用したメール転送時に発生する認証の失敗への対応にARCの設定が推奨されています。

DMARCレポート

DMARCレポートはメール受信サーバから定期的にドメイン所有者に送信されるDMARC認証の集計レポートで、DMARCレコードのruaタグで指定されたレポート送信先のメールアドレス宛に送信されます。
ヘッダFromのドメインからの送信でDMARC認証に失敗しているメールがあれば、ここで検知できます。
メーリングリスト経由でのメール送信によるDMARC認証の失敗もこのレポートに含まれます。

DMARC認証に失敗し、受信メールサーバの設定でDMARCポリシーを上書いてメールを受信した場合、その旨がレポートのreasonセクションに記載されます。

ARC認証の成功で受信した時の表示

DMARCレポートのRFC上では、DMARCの認証に失敗したメールを受信サーバの設定で受信した場合はレポートのreasonセクションに記載するのみが定義されており、ARCに対して個別の言及は存在しません。
そのため、現状はARCで通った場合も他の上書き理由と同様に汎用的な上書き理由のセクションへ丸められます。

ARC認証に成功した場合のDMARCレポート例
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
        <reason>
          <type>local_policy</type>
          <comment>arc=pass</comment>
        </reason>
      </policy_evaluated>

DMARCレポート解析ツール上での確認方法

これはツールが上書き理由（reasonセクション）の表示に対応しているかどうかに依存します。
対応しているツールの例としては下記です。

ツールが対応していない場合は前述のDMARCレポート上で直接確認する必要があります。

感想

今回はDMARCレポート上でメーリングリストなどで転送した場合のケースについて記載しました。

最初に問い合わせを受けた際は「自社からの送信メールでDMARC認証に対応していないものがある」という問い合わせかと勘違いし、そこから話を伺ったら「自社からFrom偽装して送信している可能性がある」という疑惑になったので、かなり焦りました。
（問い合わせ元から添付されたレポート表示ツールの画像にはreasonが表示されていなかったこともあり）

そこから「GmailAPI使って変な送信やってるとこがあるんじゃないか？」「ウィルス感染か？」「本当にウチからの送信か？」などかなり混乱しましたが、会社のメンバーからメーリングリスト宛に送信しているメール情報の提供などがあり、原因が分かりました。

DMARCレポートの見方に関するナレッジもそこまで豊富な状況でもないので、今回のGmailガイドライン変更に伴ってナレッジが蓄積されると混乱は少なくなるんじゃないかと思います。
あと、RFC上だとDMARCレポートにARC認証時の記載に関する明記がないので、早いとこARCがExperimentalからStandardになってレポート上で明記されるようになることを心から祈ります。

最後に、今回の対応にあたって関連情報や知見を共有してくれた社内の仲間に最大限の感謝を！
（本記事の9割は社内からの情報提供で構成されています）

レバテック開発部
レバテック開発部

レバテック開発部の公式テックブログです！

Discussion