BIMIをはじめようとしたらDMARCではまった話

はじめに

情報システム部の植野です。

2022年11月、アジアクエストではコーポレートドメイン（asia-quest.jp）でBIMIを有効化しました。

BIMI有効化を考えていた当初、「メール送信者のアイコンに会社のロゴが表示されるとカッコいいよね！！」という軽いノリで取り掛かった自分に反省文を求めたい気持ちです。想像以上に大変でした。なぜ大変だったのか？それはアジアクエストの事業内容と、これまでの会社の成長過程が大きく関係していたのでした。

BIMIとは

BIMIはBrand Indicators for Message Identificationの略で、適切に認証されたメッセージの横にブランド固定のインジケーターを表示するための規格です。ここに書かれている「適切に認証されたメッセージ」というのが重要なキーワードなのです。

この記事では、メッセージを「適切に認証するための仕組み」について書きます。

BIMIとDMARCの関係

BIMIを有効にするためには以下の手順が必要です。

1. BIMIの設定準備を行う
2. ブランドロゴを作成してアップロードする
3. VMC（Verified Mark Certificate）を取得する
4. ドメインのBIMI TXTレコードを追加する

（引用：BIMI について）

リンク先の手順１「BIMIの設定準備を行う」の中に、「ドメインの SPF、DKIM、DMARC レコードを設定する」という項目があります。

そうです。BIMIを設定するためにはSPFとDKIMとDMARCを適切に設定しなければならないのです。「適切に」というのがポイントですね。

結論として、「SPFとDKIMとDMARCが適切に設定されたメッセージ」とは、「送信者メールアドレスがSPFまたはDKIMによって正しく認証され、DMARCポリシーが隔離（quarantine）または拒否（reject）になっているメッセージ」を指します。

この状態が実現できれば、あとは手順に従ってロゴの作成やVMCの取得を行いましょう。

VMCの取得もなかなか面倒な作業で、費用もそこそこかかりますが、今回の記事では割愛します。

いにしえのプロトコル

SPF、DKIM、DMARCを理解するためには、メール配送プロトコルであるSMTP（Simple Mail Transfer Protocol）の仕組みを理解する必要があります。

SMTPのポイントは２つあります。

1. SMTPでは送信者のメールアドレスを非常に簡単に詐称できる
2. 送信者のメールアドレスには、「Envelope From」と「Header From」の２種類がある

SMTPはインターネットの黎明期から存在しており、1982年に発行されたRFC821で標準化されました。その後、SMTPにはいくつかの拡張が行われていますが、基本的な動作は当時のものとほとんど変わりません。

当時のインターネットは限られた人だけが利用しており、現在のような迷惑メールは存在しませんでした。もちろん、送信者認証の必要性もありませんでした。しかし、現在のように多くの人がインターネットを利用し、その中に悪意を持つ者が増えると、SMTPの仕組みは問題になってきました。ここでの問題は大きく２つあります。ひとつは受信者が望まないメールを送りつけられる迷惑メール（spamメール）で、もうひとつはフィッシングメールのように送信者を詐称するメールです。

メールサービスプロバイダは、このような悪意のあるメールを排除するため、様々な対策を実施してきました。そのひとつが送信者認証です。

送信者認証の「送信者」とは、「Envelope From」と「Header From」の２種類を対象にしています。

Envelope Fromは、SMTPの送信手順の中に含まれる送信元メールアドレスです。多くの場合、受信したメールヘッダの “Return-Path” や “Sender” などに記録されます。ここに記録されたメールアドレスを、利用者が直接意識する機会はありません。配送エラーが発生したときに、メールサーバがエラーメールの送信先として利用するくらいです。

Header Fromは、メールヘッダの “From” に記述された送信元メールアドレスです。利用者が認識する送信者とはHeader Fromのことです。Envelope Fromと異なり、標準のSMTPの手順においてメールサーバがHeader Fromを意識することはありません。

Envelope Fromはメールサーバのためのもの、Header Fromは利用者のためのもの、と考えるとすっきり整理できます。

送信者認証～SPFとDKIM～

送信者認証の仕組みとして主流になっているのはSPFとDKIMです。

SPF

SPFはSender Policy Frameworkの略で、Envelope Fromに記述されたドメインが詐称されていないかを検証するための仕組みです。SPFでは、DNSを利用してEnvelope Fromに記述されたドメインの送信元サーバの情報を検証します。このとき、DNSサーバに登録されているレコードをSPFレコードと呼びます。

 SPFレコードには、そのドメインの送信元となるサーバの情報が記述されています。とても簡単に表現すると、「接続してきているメールサーバのIPアドレスが、SPFレコードの中に記述されているか」が判断基準です。記述されていれば合格（PASS）とし、記述されていなければ失敗（FAIL）と判断されます。

DKIM

DKIM はDomainKeys Identified Mailの略で、電子署名によってメッセージが改変されていないかを検証する仕組みです。DKIMの電子署名を検証するための公開鍵は、DNSを利用して公開されます。

メッセージを受信したメールサーバは、メールヘッダに含まれる情報（”DKIM-Signature”の”d”パラメータ）を参照してDNS検索を行い、取得した公開鍵を利用してメッセージの改変を検証します。メッセージが改変されていなければDKIMは合格（PASS）し、改変されていることが検出されれば失敗（FAIL）になります。

このDKIMの重要なポイントは、「メッセージの署名は誰が行ってもよい」ということと「必ずしもHeader Fromのドメインによって署名されるとは限らない」ということです。例えば、メールサービスプロバイダを利用している場合、その事業者が所有する秘密鍵によって署名され、その公開鍵は事業者が所有するドメインのDNSサーバに登録されます。必ずしもHeader Fromのドメインでなくてもよいのです。

ただし、ひとつのメールの中に複数のDKIM署名を記述できます。これを利用すると、メールサービスプロバイダのドメインによる署名と、Header Fromのドメインによる署名の両方を共存させることができます。

そしてDMARCへ…

いよいよ本丸のDMARCです。

DMARCはDomain-based Message Authentication, Reporting, and Conformanceの略で、送信者認証に失敗したメールを、どのように取り扱うかというポリシーを受信者に提供するものです。ここでの重要なポイントは、「DMARCの検証対象となるドメインは、Header Fromに記述されたものである」という点です。このポイントをおさえておくと、SPF・DKIMとDMARCの関係を理解しやすいと思います。

「ウチから送信されたメールは、すでにSPFもPASSしているし、DKIMもPASSになっているよ。だからDMARCのポリシーを”reject”に変更してもOKだよね。」というのは大きな誤解なのです。私もDMARCを正しく理解するまではこの誤解をしていました。ここから先は、この誤解を解いていきます。

DMARC検証においては、以下のいずれかの条件を満たすと合格（PASS）と判断されます。

1. SPFレコードを利用したDMARC検証（ここでは「DMARC-SPF」と呼びます）にPASSする
2. Header FromドメインによるDKIM署名の検証（ここでは「DMARC-DKIM」と呼びます）にPASSする

※ここに書いた「DMARC-SPF」と「DMARC-DKIM」は、RFCなどに記載されている標準用語ではありません。この記事の中で説明のしやすさのためにつけた便宜上の名前です。

本来のSPFは、Envelope Fromを検証する仕組みでした。このため、Envelope FromとHeader Fromが異なるケースでは、本来のSPF検証がPASSになったとしても、DMARC-SPF検証はFAILになることがあるのです。具体的には、大量のメール配信を行うために、Amazon SESのような外部のメール配信サービスを利用するケースです。例えば、アジアクエストがAmazon SESを利用してメールマガジンを送信すると、Header Fromのドメインは”asia-quest.jp”になりますが、Envelope Fromのドメインは”amazonses.com”になります。

しかし、このようなシステムを利用したメールを除き、一般のメールクライアントを利用したメールではEnvelope FromとHeader Fromは一致します。この場合、本来のSPFにPASSすると、DMARC-SPFもPASSになります。

次にDMARCにおけるDKIM検証についてです。

本来のDKIMは、メールヘッダに記述された署名が正しいものであるかを検証する仕組みでした。このため、DKIM署名に利用したドメインがHeader Fromと異なるドメインであるケースでは、本来のDKIM検証がPASSになったとしても、DMARC-DKIMはFAILになることがあるのです。具体的には、Gmailのようなメールサービスプロバイダを、標準の設定で利用しているようなケースです。DMARC-DKIMをPASSさせるためには、Header FromのドメインのDNSサーバに公開鍵を登録しなければなりません。

ここまで書いたDMARC-SPFとDMARC-DKIMのいずれかにPASSするようになれば、あとはDMARCのポリシーを隔離（quarantine）または拒否（reject）に設定して、BIMIの利用手続きに進みます。

私たちがはまったポイント

多くの企業では、コーポレートドメインによるメール送信は、メールクライアントを利用した社内外とのメールで利用されます。しかし、アジアクエストのドメインは、メールクライアントを利用したメール以外でも利用されていました。具体的には、社内の業務システムで利用していたSaaSからのメールや、私たちの主要事業である開発・運用で利用している監視サーバからの通知メールなどです。

これらのシステムから送信されるメールは、DMARCポリシーが「何もしない（none）」になっていたことで、「なんとなく」受信できている状態でした。今回のBIMI有効化にあたってDMARCポリシーを”reject” に変更すると、これらのメールが受信できなくなるという問題が明らかになりました。また、これらのメールを放置することでアジアクエストのドメインレピュテーションが低下し、正規のメールが配送エラーに発展することも懸念しました。

このため、DMARCポリシーを変更するにあたり、社内での利用状況を調査して必要に応じてメールアドレスを変更する作業が必要になり、想像以上に時間と手間がかかってしまいました。

ドメインは重要なブランドです。BIMIを有効化するかどうかにかかわらず、DMARCポリシーは “reject” にするべきだと考えています。

2022年11月のtwofive社の調査によると、日経225企業のなかでDMARCポリシーが「quarantine」もしくは「reject」になっているドメインは、5,047ドメインのうち285ドメイン（約5.6%）とのことです。

これから新しいドメインを運用しようとする場合、そのブランドの価値を維持するためにも、さらにEmotetに代表されるウイルスメールの被害を減らすためにも、ドメインの用途や運用ポリシーを事前にきっちりと決めておくことをおすすめします。