それぞれの業界には、一般の人にはほとんど知られていないにもかかわらず、その業界関係者だけが「おぉ！」とざわつくニュースがありますよね。
IT 業界ももちろんその例でして、ここ数年で一番の衝撃だったのが SSL 証明書の有効期限短縮化でしたが、同じく地味に衝撃が広がりつつあるのが RFC9989 の制定と、RFC7489 の廃止です。
こんなもったいぶった書き方をしていますが、「RFC9989 って何？」と思った方は正常です。むしろ知っていたら、私と同じように E メールオタクか、RFC 研究家として名乗れます。
まず RFC とは、インターネットをみんなで平和に使えるようにしよう！と考えるインターネットの神様的な人たち（IETF）が取り決めているインターネット技術の標準仕様や運用ルールのことだとお考え下さい。
その中で、この RFC7489 や RFC9989 というのは、“なりすましメール対策” として Google が導入を義務化した「DMARC」の仕様書にあたります。DMARC については何度か本コラムや JECCICA のセミナーでご紹介したことがあるのでご記憶の方もいらっしゃるのでは。
「DMARC の仕様を示す RFC が新たに制定されました」いうニュースを聞いたとしても、ほとんどの方は「ふーん」で終わってしまうと思いますが、このニュースは DMARC という技術が「さなぎから蝶になった」というような節目ともいえるような出来事なのです。
実は今まで DMARC は「試作品」だった？
DMARC が初めて標準化されたのは 2015 年の RFC7489 で、約 10 年前。世の中でなりすましメールによる詐欺行為が話題になり始めたころです。
当時、メール業界では SPF や DKIM という認証については普及し始めていたものの、「でも認証に失敗したメールを受信側はどう扱えばいいの？」という次の課題が発現してきていました。そこで登場したのが DMARC です。
改めて DMARC の持つ効力を簡単にまとめてみると、ドメイン保持者が自分のドメインのメールアドレスのメールを受信した人に対し、「認証に失敗した時には（ 受信拒否 / 迷惑フォルダに隔離 / 気にせず受信 ）してください」のどの方法で対応してほしいかを依頼できる画期的な仕組みです。
ところがこの RFC7489 はこの 10 年間、正式な RFC としてのルールではなく、Informational として存在しているだけだったのです。
簡単に言えば「こういうやり方もアリです」といった参考資料であり、インターネット標準としての規定されたルールではない、というレベルだったのです。
料理で例えるなら、「このレシピ、おいしかったからやってみて」くらいの参考レシピの意味らしいのですが、公開してみたらそのレシピが世界中で大ヒットし、Google のようなＥメール最大手をはじめ、Microsoft も Apple も Yahoo!も DMARC を採用し、最終的には世界中すべてのＥメール送信者に対して「このレシピを使わない人を認めません」と DMARC を義務化していきました。つまり RFC が標準化として制定する前にこの「参考レシピ」が世界標準になっていたわけです。
10 年間の現場経験が詰め込まれた RFC9989
この 2015 年に作られた RFC7489 は机上の想定から作られたレシピであり、実際に導入してみると思った効果をもたらさない部分もいくつか出てきていることがわかってきました。
そこで新たに作られたのが RFC9989 というものですが、これは単なる改訂版ではなく、RFC7489 により DMARC が約 10 年間にわたり世界中のメールサーバーで運用された経験が反映された「実践編」という次のステージのルールであり、先に記載したような「さなぎが蝶に変わった」という感じです。
例えば RFC7489 では曖昧だった部分が数多く整理されており、「結局はどう対応すればいいの？」という悩みに答える内容になっています。
・ ドメイン整合性（アライメント）の解釈
・ レポート送信の考え方
・ 受信側が迷いやすかった記述
・ 実際には受信側の対応が間に合っていない部分の廃止 などなど
例えるなら、当初の参考レシピでは「適量入れて」「お好みで」などと書かれていたものを、「砂糖は小さじ 1 杯です」と書き直したような感じでしょうか。
多分今後もブラッシュアップされていくと思いますが、それは、曖昧だった部分が明確化されることで、蝶として羽ばたきやすく発展しやすくなったとも言い換えられると思います。
仕様は変わった。でもしばらくは焦らないでも大丈夫。
RFC9989 が公開されたと聞いて、DMARC レコードをまた書き換えないと！と思った管理者もいるかもしれませんが、一旦はご安心を。
そもそも E メールのルールは、各メールサービス（特に主導権は Gmail）がいつから対応するかを宣言しない限り、はっきりいって導入は進まないという性質があります。
とくに国内の多くの企業の場合、ギミックに富んだ DMARC は入れていないと思いますので、急な変更は不要と考えています。
例えば、今の DMARC レコードが以下のような構成の場合、変更は不要です。
v=DMARC1; p=reject; rua=mailto:rua-mail@sample.jp
この記載でメールサーバーが突然動かなくなることもないですし、自分のメールが届かなくなることもありません。DMARC レポートも昨日までと同じように届きます。
変更が必要になる可能性があるのは、細かな技術的設定値を入れている場合です。
便利なのに実はあまり使われていなかった！？さようなら「pct」
今回、RFC9989 の制定で私たちが一番衝撃だったのは、DMARC 運用に不可欠な「pct」タグの廃止です。
DMARC を導入したことがある方なら、
v=DMARC1; p=reject; pct=10; rua=mailto:rua-mail@sample.jp
といった「pct=」という記載を見たことがあるかもしれません。
この pct は、「DMARC ポリシーを何％のメールに適用するか」を指定するタグです。
例えば pct=10 なら、「10％だけ拒否を適用、残り 90％は隔離を適用してね」という段階的な導入を想定するためのとても便利な機能で、私が DMARC の導入・運用を補佐する案件では、必ずこのタグを利用して DMARC の強度の上下を図りつつ運用しています。
なぜこの pct を利用するかというと、BtoC の場合、個人のお客様ではショップからのメールを携帯などの別のアドレスに転送しているケースが多く、そういった場合、DMARC の強度を「reject」にすると正規のお客様が受信できなくなってしまうリスクがあるのです。
その対策として、まずは全体の 10％だけ reject にしてどれだけ影響があるか様子見し、問題がなければ 20％、50％、100％へと引き上げていく――そんな運用を期待し、利用しています。
ところがインターネットの神様たちの調べでは、「実際は想定したような運用をされていなかった」という結果がでているそうで、それにより、この「pct」という便利な機能が廃止されてしました。
（勝手な想像ですが）単に受信側の開発が追い付いていないだけで、こんなに便利なものを廃止するのは拙速ではないかと個人的には思っています・・・
とてもよい仕組みだと考えられていたこの「pct」ですが、RFC9989 では historic（過去の遺産というような扱いでしょうか）と評されることになってしまいました。
※ちなみに、「pct」の代替機能として「t」というタグが生まれています。
しかしながらこれは「今すぐ削除しなさい」という意味ではないのでご安心ください。
「pct」が広まり切らなかったことと同じく、逆に受信側で既に「pct」 の仕組みを導入している場合、これを外すような開発はすぐにはできないはずです。
そのため、いま皆さんのドメインの DMARC レコードにこの pct が書かれていても、多くの受信サーバーは変わらず動作するとみています。
しかし、新しく DMARC を設計するのであれば pct に頼った運用は推奨されなくなったことは確かですので、また別の方法を考えたほうがいいとも思います。
EC 業界にも無関係ではありません
EC 事業者にとって DMARC は決して他人事ではないことを改めてお伝えします。
近年はフィッシングメールの大半が、流通関連を装って送信されていると思いませんか？
「お荷物のお届け」
「ポイント失効のお知らせ」
「お支払い情報を更新してください」
どれも見慣れた文面で、うっかり開封してしまったという方も多いと思いますし、なんならショップドメインで変なメールが送られてきた、というお客様からの問い合わせを経験した方も珍しくないのでは。
皆様のショップに対する信頼度が高いお客様であればあるほど、第三者のなりすましメールを開封して、メール文面内の URL をクリックしてしまうかもしれません。
もし皆さんのドメインが DMARC を適切に設定してあれば、多くのなりすましメールはお客様のメールボックスに行く前に排除できる可能性が高まります。
もちろん DMARC だけですべての攻撃を防げるわけではないという悲しい事実はあるものの、「本物のドメイン保持者しか本物のメールを送れない世界」に一歩近づける技術であることは間違いないですので、まだ導入していない、もしくは導入はしたがずっと放置しているという方は、是非うまく活用してみてください。
地味だけれど、とても大きな一歩
以上のとおり、今回発表された RFC9989 は、新しい機能をたくさん追加した仕様書ではなく、この 10 年間にわたる世界中のメール事業者が積み重ねてきた運用実績と知見が詰まった涙と汗の結晶のような感じになっています。
「pct」も現在はなくなったこと自体に衝撃を感じていますが、将来「昔こんな機能もあったのう」とインターネットあるある老人会で懐かしく語られるようになるのでしょう。
普段は誰にも注目されない RFC の更新ですが、現場を混乱に陥れたいという思惑はなく、あくまで世界中で毎日送受信される数千億通ものメールを安全なものにしたいということであるのは確かです。
しかしながら現場の人間は対応に追われ、なんで勝手に変えるんだよ・・・と愚痴りたいところですが、「DMARC もようやく蝶として羽ばたき始めたんだな」と考えて、少しでもＥメールによる犯罪が減ることを祈り、うまく活用できる方法を考えていきたいと思います。
