要約

  • Internet Society Pulseが9月1日に紹介したPalisadeの調査では、観測した99,300ドメインの58.1%に有効なDMARCレコードがあった。
  • DMARCを公開したドメインの20.7%には集計レポートの送付先がなかった。ただし、この結果だけでは監視の有無も、事業者に委託された業務の範囲も分からない。

メールの移行が終わっても、送信元は増えていく。請求書の配信サービスや顧客対応システムが同じドメインを使い始めれば、認証の確認と方針の見直しが必要になる。その担当まで移行契約で決まっているとは限らない。

Internet Society Pulseの9月1日の寄稿は、この問題を考える材料になる。執筆者のSamuel ChenardはPalisadeのCEO兼共同創業者で、紹介しているのは同社の調査だ。Internet Societyは寄稿者の見解が必ずしも組織の見解ではないと明記している。新たな制度や義務の発表ではない。

調査で分かる範囲

対応するPalisadeのベンチマークは、8月14日の8分間に99,300ドメインを観測した。有効なDMARCレコードは57,732件で、全体の58.1%。その公開者のうち36,938件、64%が隔離または拒否を要求し、11,959件、20.7%には集計レポートの送付先がなかった。

後の二つの割合は、全標本ではなくDMARC公開者を分母にしている。数値は調査者が公表した集計であり、本稿がスキャンを再現したものではない。対象も上位にランクされたウェブドメインで、業務用メール全体の悉皆調査ではない。

さらに、MXから見えるのは受信用の設備である。前段のゲートウェイによって、背後のメールボックス基盤が見えない場合がある。サイトの順位帯を調整した比較でも、特定の事業者を選んだことが設定を生んだという因果関係は証明できない。調達先の順位表として読むには限界がある。

委託できる仕事を、曖昧に残さない

現行仕様のRFC 9989は、ドメイン方針と認証の整合、フィードバックの確認、正当な送信の不具合修正を結び付けている。Domain Ownerの定義には顧客のために行動するサービス提供者も含まれる。業務を外部に任せることはできるし、委託できない法的義務をこの仕様が定めているわけでもない。

ただし、メールボックスの運営、DNSの操作、レポートの分析、方針変更の承認は同じ担当とは限らない。マネージドサービスが一括して引き受けるなら、それは具体的な価値になる。サービス名だけで担当を推定するのではなく、その範囲を確認する必要がある。

監視段階のp=noneも、直ちに放置を意味しない。RFC 9989は、見落としていた正当な送信元を把握し、認証を直してから厳しい処理を求めるための出発点として推奨する。送信頻度によって必要な観察期間は変わる。

送付先のないドメインがすべて無監視とも言えない。逆に、アドレスの公開だけでレポートの到着や分析は確認できない。RFC 9990には外部宛先の承認や配信に関する条件がある。DNSの記録と、現場の仕事の実態は区別すべきだ。

共通仕様は契約範囲を決めない

Lu Hengが論じる最小限の共通仕様と現場での意思決定は、この分担を理解する手掛かりになる。本稿の編集上の解釈であり、IETFの追加要件ではない。共通仕様は協調を可能にするが、誰が毎日の業務を担うかまでは決めない。

必要なのは一律の内製化ではない。送信元一覧、報告の確認、DNS変更、承認のそれぞれが、契約に含まれるのか、社内に残るのか、別途委託されるのかを明確にすることだ。外注の効果は、継続する仕事の引き受け方によって変わる。

出典