TwoFive メールセキュリティ Blog 第15回「RUA の宛先を増やすと DMARCレポートが受け取れない?!? ~ DMARCレコードの RUAタグに入れられる宛先数の制限について調べてみた」 | ScanNetSecurity
2024.07.24(水)

TwoFive メールセキュリティ Blog 第15回「RUA の宛先を増やすと DMARCレポートが受け取れない?!? ~ DMARCレコードの RUAタグに入れられる宛先数の制限について調べてみた」

 実際に制限をしているところがあるのかを調べてみました。弊社で DMARCレポートの分析サービスを行っている中で上位にくるレポータを 5 つピックアップしてみました。

特集 コラム
(イメージ画像)
(イメージ画像) 全 3 枚 拡大写真

 DMARCレポートの分析サービスを行っていて気になることがありました。それはあるお客様だけが一定期間 DMARCレポートが受け取れていない事象があったのです。

 そのお客様に確認したところ、RUAレポートを受け取るレポートの宛先を増やしたとのことでした。記述の内容に問題はなく、宛先を 5 つに増やしていました。弊社のお客様の場合、多くても 3 宛先だった為、タイミングと設定数から考えて、もしかしたらそれが原因なのではないかと推測しました。

[事象]
・宛先を増やす前は届いており、増やしたタイミングで特定のレポータから全ての宛先に DMARCレポートが届かなくなった

・事象が発生したのは特定のレポータからそのお客様宛のレポートのみ

・他のお客様ではそのレポータからのレポートが問題なく届いていた

[解決]
・DNSレコード(DMARCレコード)の変更を行うことなく(5宛先のままで)、時間の経過のみで解決した

 この様な状況の為、レポートが届かなくなった原因が宛先の数を増やしたことが問題だったかどうかの判断はつかない結果となりました。そこで、これをきっかけに RUAレポート送信先の数に制限があるのかについて調べてみようと思いました。

 まず RFC7489 を読んでみます。

7.2.1. Transport
The Mail Receiver, after preparing a report, MUST evaluate the provided reporting URIs in the order given. Any reporting URI that includes a size limitation exceeded by the generated report (after compression and after any encoding required by the particular transport mechanism) MUST NOT be used. An attempt MUST be made to deliver an aggregate report to every remaining URI, up to the Receiver's limits on supported URIs.
(RFC7489から引用。太字は筆者によるもの https://datatracker.ietf.org/doc/html/rfc7489) 

 この記載を読むと、「受信者側(レポータ側)のリミットに達するまで」と記載があり、リミットを設けることは許容されていると解釈することが出来ます。理論上、RUAアドレスの制限を設けることができるということです。

 実際に制限をしているところがあるのかを調べてみました。弊社で DMARCレポートの分析サービスを行っている中で上位にくるレポータを 5 つピックアップしてみました。

 その内 1 社はメールアドレスが用意できなかった為、4 つのレポータ(メールサービス)を選択して(以下A~D)、RUAアドレスの数を変えて DMARCレコードを書き換えながら送信を行って試験をしてみました。送信元に使用したドメインは検証用のドメインですが、登録したのは 10 年以上前で新規取得ドメインではありません。また約 50 の RBL に SPAM発信元として登録されていないことを確認済みです。

 その結果が以下です。
(✔:レポート受信 / ─:レポート受信不可)

(1)レポート受信先が複数ドメイン

(2)レポート受信先が単一ドメイン

単一ドメインの場合には複数アカウントが用意しやすかったので、最大 6 まで試しました

 結果としては、A ~ C の 3 つのレポータはいずれも RUA のアドレス数に関係なくレポートを受信することができました。ただし、レポータD(某携帯会社)はレポートを受信することが出来ませんでした。レポータD 自体は RUAレポートの送信には対応している会社さんです。そもそもテスト送信したメールが相手のメールボックスに殆ど届いていなかった為、何らかの理由でテストメールが SPAM判定されていた可能性があります。

 メールアドレスの長さ等によっても動作は異なる可能性はありますし、またそれぞれのレポータの動作が今後変更される可能性もありますが、現時点では大手のメールサービス(レポータ)は RUAレポートの数が 5 以内であれば問題なく全ての宛先にレポート送信してくれるようです。

 今回調査したのは 5 宛先(単一ドメインは 6 宛先)だけですが、弊社のお客様ではレポートの受信先として 4 以上設定されているお客様は殆どいらっしゃいませんので、これくらいが現実的なのではないかと考えます。

 また、もしレポートに設定するアドレス数の多さに不安がある場合はメーリングリストアドレスや配布リストを設定することも仕様上問題はないので、そういった対応をすることでシンプルに設定を行うことは可能です。

 また、余談ですが複数設定する際に忘れがちなのが mailto: です。設定する際には漏れのないようお気を付けください。
以下は、レポート送信先として、dmarc@example.comsysadmin@example.com の 2 つに設定する DMARCレコードの例ですが、それぞれのアドレスの前に mailto: が必要です。

正しい例

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com,mailto:sysadmin@example.com; ruf=mailto:dmarc@example.com

mailto:が抜けている例(誤設定)

v=DMARC1; p=quarantine; rua=mailto: dmarc@example.com,sysadmin@example.com; ruf=mailto: dmarc@example.com

[著者]
株式会社TwoFive 高橋 尚也(たかはし なおや)
 海外メールベンダー製品のプリセールスとしてスパムフィルタの国内展開・導入サポートに従事後、2014年からは、株式会社TwoFiveにてメールシステムのプリセールスやコンサルティング、サポート等を担当

《株式会社TwoFive 高橋 尚也》

この記事の写真

/

特集

関連記事

PageTop

アクセスランキング

  1. ランサムウェア集団が謝罪

    ランサムウェア集団が謝罪

  2. 富士通の複数の業務パソコンに高度な手法で攻撃を行うマルウェア、複製指示のコマンドを実行し拡大

    富士通の複数の業務パソコンに高度な手法で攻撃を行うマルウェア、複製指示のコマンドを実行し拡大

  3. 東京海上日動火災保険 提携先の税理士法人にランサムウェア攻撃

    東京海上日動火災保険 提携先の税理士法人にランサムウェア攻撃

  4. 国際手配のランサム犯 逮捕されずに世界中を旅行

    国際手配のランサム犯 逮捕されずに世界中を旅行

  5. マイクロソフト、CrowdStrikeに起因する障害への支援について発表

    マイクロソフト、CrowdStrikeに起因する障害への支援について発表

ランキングをもっと見る
PageTop