Why｜調べたきっかけ
- セキュリティ・リスク・スコアリングサービスなどを導入していると、利用しているドメインのDMARCポリシーやSPFレコードをチェックする項目で、ポリシーが設定されていないことが通知されたりします
- 上記の通知を受けて、約1年前に社内でDKIM&DMARCの対応を行いました
- 対応に際して、送信ドメイン認証について情報整理したので、その内容を改めて纏めます
How｜情報整理の意図
- この投稿では、送信ドメイン認証に関する用語と概要について纏めます
- 技術的な内容や、DKIM,DMARCの対応記録については、別途投稿できればと考えています
What｜調べた内容
ひとこと説明のまとめ
- SPF（えすぴーえふ）
- 「送信元IPアドレス」をもとに「送信元ドメインがなりすましでないか」を検査する
- DKIM（でぃーきむ）
- 「電子署名」によって「送信元ドメイン」と「内容が改ざんされていないか」を検査する
- DMARC（でぃーまーく）
- SPFやDKIMの認証が失敗した際に「受信側がとる対応」を「ポリシーで定めて」おく
- BIMI（びみ）
- 「認証をPass」した信頼できるメールに「企業のブランドアイコンを表示」する
SPF（Sender Policy Framework）
概要
- 読み方は「えすぴーえふ」
- ひとことで言うと、送信元IPアドレスをもとに認証する仕組み
- 受信メールのIPアドレスと、SPFレコードとして事前に登録されている送信元IPアドレス情報との一致を確認することで、メールの送信元ドメインが詐称されていないかを検査する
検証可能なこと
- 送信元ドメインが「なりすまし」でないかの確認
余談ですが、初見のときは「SPFポーク」を連想しました。
こちらは「Specific（特定の） Pathogen（病原体） Free（無い）」の略で、あらかじめ指定された病原体を持っていないという意味とのことです。
DKIM（DomainKeys Identified Mail）
概要
- 読み方は「でぃーきむ」
- ひとことで言うと、電子署名をもとに認証する仕組み
- 送信側が送信するメールに電子署名を付与し、 受信側はメール受信時にDNSレコードに登録された送信者の公開鍵情報を取得して検証することで、送信元の詐称とメール内容の改ざんを検知する
検証の流れ
- 送信者はドメインの秘密鍵を用いてメッセージを暗号化し、ハッシュを作成
- 受信者のメールサーバーは、送信者の公開鍵を使用して、メッセージから同じ構成要素を暗号化する
- 受信者は暗号化された結果であるハッシュ値を受け取り、復号化された送信者のハッシュと比較する
- 両方の文字列が同じであれば、DKIM認証にパスする
- メッセージ内の文字が1つでも変わっていれば、受信時に公開鍵で暗号化して返されるハッシュは、送信者のメールサーバーから送信されたものと同一にならないため、DKIM認証がフェイルとなる
DKIMの署名方法は2種類
- 作成者署名
- メール送信者のドメインを利用して署名する
- 公開鍵の問い合わせ先は、利用ドメインのDNSサーバ
- メールのヘッダー情報に表示されるFromアドレスと同じドメインで署名するので、受信側から見て信頼性が高い
- 第三者署名
- メール送信者以外のドメインを利用して署名する
- メール配信サービスなどで広く使われている
- 公開鍵の問い合わせ先は、サービス提供企業のDNSサーバ
検証可能なこと
- 送信元ドメインが「なりすまし」でないかの確認
- メール本文が「改ざん」されていないかの確認
DMARC（Domain-based Message Authentication Reporting & Conformance）
概要
- 読み方は「でぃーまーく」
- ひとことで言うと、SPFやDKIMの認証が失敗した際の受信側対応を定めておく仕組み
- SPFやDKIMの認証が失敗した場合に、受信側でどのように対応するかを「DMARCポリシー」としてあらかじめ定義しておく
DMARCポリシー
「ドメイン認証失敗時は、受信側は次のパターンのいずれかで対応してください」という宣言
- [none]
- 何もしない（メールを受け取る）
- [quarantine]（くあらんてぃん）
- 隔離する（迷惑メールフォルダに振り分ける）
- [reject]
- 拒否する（メールを破棄する）
DMARC設定のメリット
- 送信側で認証に失敗したメールの取り扱いを指定できる
- SPFやDKIMでは、認証に失敗したメールを受け取るか破棄するかなどの取り扱いを受信側の判断に委ねている
- DMARCでは、利用しているドメインになりすましたメールが送信されていることが分かった場合に、送信者の判断で「なりすましメールを受信させない」という設定が可能
- メール送信者が受信者から認証の結果通知を受けられる（DMARCレポート）
- メール受信元のプロバイダからSPF・DKIMの認証結果をリアルタイムで受け取れるため、なりすましメールが発生した場合にどこから送られているメールなのかを素早く判別することが可能
- 「第三者署名」を不許可にし、より厳格なDKIM認証とすることができる
- DKIMの「第三者署名」ではFailさせることにより、「作成者署名」による送信元の明確化が可能
ここまでの内容を踏まえて、下記記事の図を確認すると理解しやすいです
BIMI（Brand Indicators for Message Identification）
概要
- 読み方は「びみ」
- ひとことで言うと、認証をPassした信頼できるメールに企業のブランドアイコンを表示する仕組み
BIMI導入までの道のり
- DMARCレコードの設定、ポリシー強化
- ブランドロゴの表示が認められるためには、DMARCの導入と[p=quarantine]以上のDMARCポリシー設定が必要
- ブランドロゴ画像の商標登録
- 認証局による「VMC（verified mark certificate/認証マーク証明書)」が必要（お金がかかる）
- ロゴ情報の公開・BIMIレコードの設定
- ブランドロゴ画像を表⽰させるため、HTTPS サーバ上にロゴ画像データを置き、DNSレコード設定が必要
- メール受信とブランドロゴ表示
- DMARCの認証が成功し、かつDMARCポリシーが[quarantine]あるいは[reject]に設定されている場合に、受信側サーバがBIMIレコードを参照する
- BIMIレコードが見つかればそこから企業のロゴの場所を特定し、その画像を受信トレイ上で表示する