朝から昼寝

整理しておきたいIT関連の小ネタ

送信ドメイン認証のDNSレコード検索方法(SPF、DKIM、DMARC、ARC)(+BIMI)

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、動作確認等のために、各送信ドメイン認証のDNSレコードを検索する方法をまとめたものです。
SPFDKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

本記事の目的

  • 各送信ドメイン認証技術のDNSレコード検索方法を理解する。


目次

サマリ

以下のTXTレコードです。

届いたメールをもとに検索

今回、InstagramからGmailに届いたメールを例にします。

Instagramから届いたメール
Instagramから届いたメール

Instagramのロゴが表示されているのでBIMI対応済みです。

ARヘッダ
ARヘッダ

Authentication-Results(AR)ヘッダには、"dkim=pass"、"spf=pass"、"dmarc=pass"が記載されています。 DMARCのポリシーは"p=REJECT sp=REJECT"です。

このメールの送信元ドメインは以下の通りです。

本記事では、このメールを例に、各DNSレコードを検索する例を記載します。

SFPレコード

SPFレコードを検索する場合、エンベロープFromのドメインを用いてDNS検索する必要性があります。
エンベロープFromのドメインが分からない場合、SPFレコードを検索することはできません。

届いたメールをメーラやWebMailで開く時点では、エンベロープFromドメインを正確には特定できません。100%正確な方法ではありませんが、便宜上以下のようにエンベロープFromドメインを特定しています。

今回は、Return-PathヘッダやAR(Authentication-Results)ヘッダのspfタグより、エンベロープFromドメインはmail.instagram.comであると推測しました。spfタグについては、spf=passの後のコメント部分(reasonspec)に、"smtp.mailfrom=xxxx@mail.instagram.com"というエンベロープFromアドレスと思われる記載があります。

このエンベロープFromドメインをもとにSPFレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。
"v=spf1 include:facebookmail.com -all"

"include"があるので、include先も検索してみます。

  • digコマンドの場合
    dig -t TXT facebookmail.com
  • nslookupコマンドの場合
    nslookup -q=TXT facebookmail.com

上記問合せにより得られるレコードのうち、SPF用のものは以下です(2022年9月時点)。
"v=spf1 ip4:66.220.144.128/25 ip4:66.220.155.0/24 ip4:66.220.157.0/25 ip4:69.63.178.128/25 ip4:69.63.181.0/24 ip4:69.63.184.0/25" " ip4:69.171.232.0/24 ip4:69.171.244.0/23 -all"

DKIMレコード

DKIM-Signatureヘッダは以下です。セレクタ名とドメイン名を確認できます。

DKIM-Signatureヘッダ
DKIM-Signatureヘッダ

上記の内容に従い、DKIMレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT s1024-2013-q3._domainkey.mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT s1024-2013-q3._domainkey.mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。

"k=rsa; t=s; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7twdVo+BW8Pv2poU5129KYmE6npHdxUU8fktUKTE9TNovCvLy5LVjYc3TQcUFjOH" "VaZ89ZCjmpAcrA2QnTEKZ/2QWV56gn6bWdFW4SFxnQdHjguBZQykfKe5KTxy2a/OxuA0x2dHfdnYfw7RVzr4uednpKcWJy4Rl3gM6XB1zDwIDAQAB"

pタグの部分が公開鍵です。
TXTレコードの255文字の制限があるので、複数の"xxxx"に分割されています。

DMARCレコード

ヘッダFromドメインに従い、DMARCレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT _dmarc.mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT _dmarc.mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。
"v=DMARC1; p=reject; rua=a@dmarc.facebookmail.com; ruf=fb-dmarc@datafeeds.phishlabs.com; pct=100"

p=rejectです。
DMARCレポートのうち、RUFの方は別ドメインの解析ツール?を利用しているかもしれません。

ARC用のDKIMレコード

今回のメールでは、mail.instagram.comドメインから送信される時点ではARC署名は追加されていません。
Gmailで受信した際に最初のARC署名(i=1)が追加されていますので、このARC署名に対応するDKIMレコードを検索してみます。

ARC用のDKIM(とほぼ同等の)署名が格納されるARC-Message-Signatureヘッダは以下です。セレクタ名とドメイン名を確認できます。

ARC-Message-Signatureヘッダ
ARC-Message-Signatureヘッダ

上記の内容に従い、ARC用のDKIMレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT arc-20160816._domainkey.google.com
  • nslookupコマンドの場合
    nslookup -q=TXT arc-20160816._domainkey.google.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。

"k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Lztpxs7yUxQEsbDFhjMc9kZVZu5P/COYEUIX4B39IL4SXAbv4viIlT9E6F6iZmTh1go7+9WQLywwgwjXMJx/Dz0RgMoPeyp5NRy4l320DPYibNqVMWa5" "iQ2WiImQC0en1O9uhLLvzaSZJ03fvGmCo9jMo0GwKzLNe14xMgn/px2L5N/3IKlKX4bqUAJTUt8L993ZlWzvgMnSFSt8B+euSKSrtAiopdy4r1yO4eN5goBASrGW0eLQc1lYouNvCrcTQpos4/GEAqiGzpqueJLmBfOO4clNvVvpPkvQs2BHw9I9LmIjaMxTNGxkGBRaP3utDiKXXqu1K+LRzl0HCNSdQIDAQAB"

BIMIレコード

BIMI-Selectorヘッダは以下です。セレクタ名を確認できます。
(BIMI-SelectorヘッダがDKIM署名に含まれていませんが)

BIMI-Selectorヘッダ
BIMI-Selectorヘッダ

上記の内容に従い、BIMIレコードを検索するコマンドは以下です。

  • digコマンドの場合
    dig -t TXT fb2021q2v1._bimi.mail.instagram.com
  • nslookupコマンドの場合
    nslookup -q=TXT fb2021q2v1._bimi.mail.instagram.com

上記問合せにより得られるレコードは以下です(2022年9月時点)。

"v=BIMI1; l=https://instagram.com/images/bimi/ig-logo.svg; a=https://instagram.com/bimi-vmc.pem;"

上記のSVGやPEM(VMC)については、別の記事で触れています。

BIMIレコード(余談)

当初twitter.comから届いたメールを例にしようとレコード確認していたのですが、BIMIレコードを検索できなかったので見送りました。
twitter.comからのメールはGmail上でロゴ表示されているので、BIMI対応はしていると思います。BIMI-Selectorヘッダが無いのでデフォルトのセレクタ名(default)を用いてdefault._bimi.twitter.comで検索したところ、レコードが存在しませんでした。

Instagramからのメールの例より、Gmailは既存のBIMI-SelectorヘッダがDKIM署名対象外であってもヘッダ削除しないようなので、twitter.comからのメールにも最初からBIMI-Selectorヘッダは存在していなかったと推測されます。あるいは、Gmail側のBIMI動作として個別にtwitter.comを信頼する設定というのも考えにくいです。よく分かりませんでした。

BIMIの整理しておきたいポイント(2022年10月更新版)

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、送信ドメイン認証の関連技術であるBIMI(Brand Indicators for Message Identification)についてまとめたものです。
SPFDKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

本記事では、BIMIが扱う画像(Brand Indicators)のことを簡単に"ロゴ"と記載しています。

本記事の目的

  • BIMIの概要を理解する。
  • BIMI対応の際してのポイントを把握する。

※本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。

また、本記事は、BIMI認証についてまとめてありますが、以下については含んでいません。適宜IETFの文書等を参照願います。
- BIMI Reportingの詳細
- ロゴ画像(SVG)の詳細
- 認証マーク証明書(VMC)の詳細


目次

基本

BIMIは、既存のDMARCポリシーを活用し、電子メールの認証を普及を促進することを目的とした技術です。

BIMIの動作例

例として、楽天グループから届いたメールをWebブラウザ版のGmailで表示した際に、BIMIのロゴが表示されている画像を掲載します(楽天推しという訳ではありません)。

BIMIによるロゴ表示
BIMIによるロゴ表示

送信元ドメインがBIMI対応していない場合、イニシャル("RG")等が表示されますが、BIMI対応している場合には、その送信元ドメインに応じたロゴが表示されます。この仕組みがBIMIです。
メールを読む人に対し、そのメールが詐称されていないことの安心感や、ロゴのビジュアル自体によるブランドイメージのアピールができます。

ロゴ表示するためには、メールの送信元と、メールを受信するシステムやメールクライアント(WebMailやメーラ)の両方でBIMI対応している必要性があります。

楽天グループの詐称メール対策に関する説明ページに、「Gmail」におけるブランドシンボル(ロゴ画像)の表示にはBIMIが使用されている旨の説明があります。大手EC企業ですので、このような詐称メール対策に関する情報発信は大事かと思います。

BIMIの認証対象と認証成否

  • メールのヘッダFromドメインの管理元により指定されたロゴ(画像)を認証します。
  • BIMI自体は、送信者ドメイン認証の関連技術です。SPFDKIM、DMARC、ARCといった既存の送信者ドメイン認証技術に依存し、BIMI自体の認証方法が定められていますが、それ自体が新たな送信ドメイン認証のプロトコルという訳ではありません。
  • ヘッダFromドメインDNSに登録されたBIMIレコードに基づいてロゴを検証する等、BIMI認証に必要な一連の処理を行い、正しいものであると判断できれば認証成功です。
  • DNSレコードを保有するドメインの管理元により、「そのロゴをメールに表示することを認められている」という点が担保されます。

認証時の動作

  • メールを受信する側が、上記の認証を行います。
  • BIMI認証の際には多くの検証処理が行われます。詳細は後述します。

BIMI対応に必要な設定(メールを送信するドメイン側)

  • メール送信元ドメインとしてBIMI対応に必要な設定等は、基本的にロゴ画像の準備とDNSレコードの登録なのですが、そのために多くの準備が必要です。商標登録済みのロゴ画像や、ロゴ画像を配置するWebサーバ、さらにロゴ画像が正当なものであることを証明するためのVMC(証明書)の購入等です。
  • また、BIMI対応の前提として、DMARCを正式運用できている必要性があります。
  • DMARC対応が前提になるということは、SPFもしくはDKIM、あるいはその両方に対応している必要性があります。環境によってはARC対応も考えられます。
  • 詳細は後述します。

BIMI対応に必要な設定(メールを受信する側)

  • メールを受信する側としてBIMI対応に必要な設定等は、MTAとMUAの環境設定です。
  • 分かりやすい例だと、GmailのWebMailやアプリは、既にBIMI対応済みです。
  • 詳細は後述します。

認証結果

  • BIMIの認証結果は、以下のいずれかです(IETF文書より)。
    • pass
    • none
    • fail
    • temperror
    • declined
    • skipped
  • この認証結果は、以下に記載されます。
    • Authentication-Resultsヘッダ内のbimiの値
    • 以下のようにコメントを追記しても良いです。
      • bimi=fail (Invalid SVG)
      • bimi=skipped (sender not trusted)
      • bimi=skipped (message failed DMARC)
  • 送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダの詳細は別記事にまとめる予定です。

詳細

BIMIの仕様策定や普及の状況

参考情報として、BIMIの仕様策定や普及の状況について記載します。

  • BIMIの仕様を定めたRFCはまだ存在せず、2022年11月現在、IETFにおいて"Internet-Draft"の扱いです。
    • BIMI GroupのWebサイトに、一連の文書へのリンクがあります。
    • これらの"Internet-Draft"は2023年4月12日に期限切れになります。次の文書が公開されると思われます。
  • 普及状況としては、以下のページが参考になります。
    • Where Is My BIMI Logo Displayed?
      • 受信したメールに対するBIMIのロゴ表示に関するページです。
      • BIMIは、一般的なメーラよりもMBPが提供する専用アプリあるいはWebMailの方が実装が早いようです。
        例えばGmailなど、MTAとMUA(WebMail)が同じMBPの管理下にある場合には、MTAのBIMI認証結果をMUAが信頼できるよう構成しやすいため、その結果BIMI対応をスムーズに進められるようになると推察されます。
    • BIMI GroupのWebサイト(bimigroup.org)
      BIMIのサポート状況が記載されています。基本的にMBPやMUAの製品やサービスの提供元のサポート状況は、受信したメールのBIMI認証の対応状況を指しているはずです。
      以下、2022年11月時点の状況を控えておきます。
    • 一方で、メールを送信する側のBIMI対応は、送信元のドメインおよびメールシステムの管理元が推進するものです。詐称メール対策やブランディングに積極的な組織では、対応が早いと思われます。
  • その他のメール関連システムにおけるBIMI機能の実装は、SPFDKIM、DMARC、ARCほどは進んでいないようです。今後、BIMI対応するシステムは増えると思われます。
  • オンプレミスのWebメールソフトウェアでは、BIMIのロゴ画像表示に対応したものは見当たりませんでした(2022年8月時点)。

導入ステップや運用ポリシーに応じた調整のポイント

BIMIは、メールを送信するドメイン側、メールを受信する側の両方で対応が必要です。

メールを送信するドメイン

  • BIMI自体には、SPFにおける修飾子やDMARCにおけるポリシー(p=)のような、検証基準を調整するパラメタはありません。
    ただし、送信する全てのメールをBIMI対応させる本番運用開始の前に、テスト用に個別のセレクタを用意し、テスト用に送信するメールにのみ、そのセレクタ名を指定することで、試験的な段階を設けることはできそうです。
  • なお、BIMI対応の前提として、DMARCを正式運用できている必要性があります(DMARC Enforcement)。
    BIMI対応を進める上で、このDMARCポリシーに対する要件は、メールシステムの技術面、運用面で課題になりやすいでしょう。
  • その他、商標登録済みのロゴ画像や、ロゴ画像を配置するWebサーバ、さらにロゴ画像が正当なものであることを証明するためのVMC(認証マーク証明書)の購入等、直接的なシステム設定以外の手順が多い点には注意が必要です。
  • ドメインの管理元がBIMI対応するきっかけとして、以下のようなものが考えられます。
    • ロゴ表示による自組織のブランド価値向上
      2022年11月時点で、Gmailの受信トレイを開いてみると、大手のECやSNS関連企業から届いたメールにはロゴ表示されているものが多いです。それらは既にBIMI対応済みということです。
      将来的にBIMIの普及が進めば、BIMI対応していないことにより、その組織のブランド価値が低く見られてしまう場面は少なからず生じそうです。
      BIMIのInternet-Draft文書にも、ロゴを表示できることが、送信ドメイン認証を普及させるための動機付け(インセンティブ)になる旨が記載されています(As an additional benefit, mail-originating organizations are incentivized to authenticate their email as doing so will enable them to influence how email and Indicators from the organization are displayed.)。
    • 送信ドメイン認証に対する投資成果の可視化
      既に多くのコストや時間をかけてSPFDKIM、DMARC、ARC等の送信ドメイン認証に対応してきたとしても、それらのセキュリティにおける価値を分かりやすく可視化、表現するのは難しいものです。
      BIMIは、馴染みのあるロゴの表示という誰にでも分かりやすいアプローチで、それらのセキュリティ価値をアピールできます。
    • ユーザエクスペリエンスの変化
      これは私の主観ですが、BIMIのロゴ表示によりメール読者に対してポジティブな印象を与えられるようになると考えられます。
      従来型のスパム対策は透過的に動作するものが多く、メール読者に対して基本的に何もアピールしません。強いて言うなら、メールがスパム対策を通過して読者の受信トレイに届いたということが「これは不正なメールではありません」という検査結果のようなものの代わりになります。
      対して、BIMIのロゴ表示は「これは本物のブランドロゴ付きのメールです」というポジティブなアピールを含みます。これは読者に対してそのままポジティブな印象として伝わるでしょう。
      ユーザは無意識にその体験を蓄積していくので、メールを信頼するかどうかの判断をする際の基準(嗜好)が徐々に変化し、このBIMIのようにキャッチーな技術が"当たり前"なものになっていくと思います。
  • なお、あるメールのBIMI認証が何らかの理由で失敗した際、その失敗が理由でメール配送を拒否するようなポリシー運用の受信者はいないはずです。影響は、メールを開いたユーザに対してロゴが表示されないだけでしょう。
    メール自体が届かない、読めないといったトラブルの心配まではせずにBIMI対応を進められます。

メールを受信する側

  • 使用しているメールシステムの環境により、BIMI対応のためのステップは異なります。
    • Gmail等のクラウドサービスを利用している場合には、メールを受信する側としてのBIMI対応はできています。GmailのWebMailや専用アプリを使用すれば、BIMIによりロゴ画像を表示できます。追加の設定等は不要です。
      逆に、GmailMUA(WebMailや専用アプリ)において、BIMIを無効化(ロゴ画像を表示しないように)する設定は見当たりません。
    • 自組織でメールシステムを運用している場合は、そのメールシステムをBIMI対応させる必要性があります。
      • MTAは、受信したメールに応じBIMIレコードを検索し、ロゴ画像を取得、検証できるよう設定します。さらに、その検証結果に基いてMUAに伝達すべきBIMI関連情報をメールヘッダに反映するための設定も必要です。
      • MUAは、受信したメールの内容に応じ、ロゴ画像をユーザインタフェースに表示できる実装が必要です。また表示するかどうかを決定するための判断処理の実装も必要です。
      • なお、2022年8月現在、一般に配布や販売されているオンプレミス向けメールシステムでは、BIMIを実装できそうな仕組みは見つかりません。
  • 注意すべき点は、MUAにとって、MTAによるBIMI認証結果が信用できるシステム構成であるべきということです。
    • 送信ドメイン認証を外部サービスに委託している構成の場合、BIMI認証を含む送信ドメイン認証の基準が信頼できるものかの確認が重要です。また自組織のセキュリティ運用に従い、その基準を調整できる権限があることも重要です。
    • 言い換えると、MUAとMTAが同じ信頼境界の中に存在しているべきという観点です。

(小ネタ)あるドメインからのメールがBIMI対応済みかどうかの確認方法

小ネタです。BIMIの動作を理解する上での参考情報として記載します。
例えば、受信したメールのBIMI対応有無や、メールは受信していなくても任意のドメインに対するBIMI対応有無を確認する方法です。

  • Gmail等のBIMI対応のMUA環境でメールを表示する
    そのメールにロゴ画像が表示されれば、当然そのメールの送信元ドメイン(ヘッダFromドメイン)はBIMI対応済みです。またそのメールもBIMI対応したものであると言えます。

    BIMIによるロゴ表示
    BIMIによるロゴ表示

  • DNSレコードを確認する
    Instagramからのメールにロゴが表示されていましたので、試しにそのロゴ表示に使用されたBIMIレコードを検索してみます。

    BIMIによるロゴ表示
    BIMIによるロゴ表示

    検索方法は、以下のTXTレコードを検索するというものです。
    (セレクタ名)._bimi.(ヘッダFromドメイン名)
    セレクタ名は、BIMI-Selectorヘッダで指定されている値です。BIMI-Selectorヘッダが無い場合、'default'がデフォルトのセレクタ名です。
    ヘッダFromドメインでBIMIレコードが得られない場合、次に組織ドメインで検索することになっています。ヘッダFromドメインがaaa.bbb.domain.comであれば、domain.comが組織ドメインです。

    以下は、InstagramからのメールのBIMI-Selectorヘッダで指定されたセレクタ名(fb2021q2v1)のBIMIレコードをWindows上で検索する際のコマンド例です。
    > nslookup -type=TXT fb2021q2v1._bimi.mail.instagram.com
    検索の結果、得られたBIMIレコードは以下です。
    "v=BIMI1; l=https://instagram.com/images/bimi/ig-logo.svg; a=https://instagram.com/bimi-vmc.pem;"

    参考までに、セレクタ名defaultのBIMIレコードは存在しませんでした。
    >nslookup -q=TXT default._bimi.mail.instagram.com
    *** UnKnown が default._bimi.mail.instagram.com を見つけられません: Non-existent domain

    次に、取得したBIMIレコードのlタグとaタグの内容を確認してみます。

    • lタグで示されたURIからは、SVG形式のロゴ画像を取得できます。
      l=https://instagram.com/images/bimi/ig-logo.svg
      メールに表示されたロゴと同じ画像です。
    • aタグで示されたURIからは、VMC(認証マーク証明書)を取得できます。
      a=https://instagram.com/bimi-vmc.pem
      取得したVMCの拡張子を.crt等に変更してWindows上で開いてみると、証明書の内容を確認できます。
      VMCの中身
      VMCの中身
      拡張キー使用法が"不明なキー使用法 (1.3.6.1.5.5.7.3.31)"と表示されますが、このOIDはBIMI用(id-kp-BrandIndicatorforMessageIdentification)のようです。WebサイトのHTTPS対応に使用されるサーバ証明書では"サーバー認証 (1.3.6.1.5.5.7.3.1)"となっている箇所ですので、異なる用途の証明書であることが分かります。
  • 受信したメールのヘッダを確認する
    MUAで開いたメールのヘッダから、送信元ドメインのBIMI対応状況を正確に判断することはできませんが、手がかりになる情報を含む場合があります。
    これらの情報を確認する際の前提として、該当メールヘッダが改ざんされたものでないこと、BIMIの規約に準拠し動作するメールシステムを経由して配送されたメールであること、が挙げられます。
    以下は各ヘッダの簡単な確認方法です。各ヘッダのもう少し詳細な説明を含む項目は後述します。

    • BIMI-Selectorヘッダ
      メールヘッダ中にBIMI-Selectorヘッダが存在する場合、メール送信者が意図的にロゴ表示のためBIMIレコード検索用のセレクタ名を指定した上でメールを送信したと考えらます。
      省略した場合はセレクタ名defaultが使用されます。
    • BIMI-Locationヘッダ、BIMI-Indicatorヘッダ
      メールヘッダにBIMI-LocationヘッダやBIMI-Indicatorヘッダが存在する場合、メールを受信したMTAが、MUAにロゴを表示させるためにこれらのヘッダを追加したと考えられます。
      これらのヘッダは、MTAでBIMIの検証が行われた結果、認証成功した場合に追加されることがあるものです。
    • Authentication-Resultsヘッダ
      MTAによるBIMIの認証結果(bimi=)が記載されている場合があります。
      なお、ARCはDMARC認証の必須要素ではありませんが、ARC-Authentication-ResultsヘッダにBIMIの認証結果(bimi=)が記載される場合もあります。
    • DKIM-Signatureヘッダ
      DKIM署名の範囲(h=)にBIMI-Selectorを含めることにより、BIMI-Selectorヘッダの改ざんを検知できるようになります。よって、DKIM署名者(基本的にはメール送信者)の署名時点におけるBIMI-Selectorヘッダの内容が改ざんされていないことを確認できます。
      なお、ARCはDMARC認証の必須要素ではありませんが、ARC-Message-Signatureヘッダ内のDKIMと同等の署名範囲にBIMI-Selectorが含まれる場合もあります。
    • 例として、InstagramからのメールをGmailで受信した際のBIMI関連ヘッダを記載します。このメールはBIMIのロゴが表示されています。
      • BIMI-Selectorヘッダ
        BIMI-Selector: v=BIMI1; s=fb2021q2v1;
      • Authentication-Resultsヘッダ
        dkim=pass …
        spf=pass …
        dmarc=pass …
        Gmail側で受信した際の認証結果が記載されていますが、bimi=passの記載はありませんでした(ARヘッダへのBIMI認証結果の記載はMUSTでなくSHOULDなので必須ではありません)。
        BIMI認証成功の前提となるDMARCの認証結果は"pass"です。
      • DKIM-Signatureヘッダ
        DKIM-Signature: … d=mail.instagram.com … h=Date:To:Subject:From:MIME-Version:Content-Type; Instagramドメインによる署名ですが、署名範囲にBIMI-Selectorヘッダが含まれていません。含まれていた方が良いと思います。
      • ARC-Message-Signature
        ARC-Message-Signature: i=1; … d=google.com; …h=…:bimi-selector:…;
        Gmail側のメールシステムによりメール受信した際に追加されたARC署名です。
        署名範囲にBIMI-Selectorヘッダが含まれています。ただ、Instagramドメイン側のDKIM署名(あるいはARC署名)の範囲にBIMI-Selectorヘッダが含まれていないので、Gmail側に届く前までの改ざんを検知する効果はありません。
        また、Gmail側の動作として、他のメールも確認したところ、BIMI-Selectorヘッダが存在しないメールの場合、ARC署名範囲にBIMI-Selectorヘッダを含めないようでした(そのヘッダが無かったことも分かるようにするという意味では、含めた方が良いと思います)。

BIMI全般

ここでは、BIMI全般について記載します。
主に、Brand Indicators for Message Identification (BIMI) draft-brand-indicators-for-message-identification-02に関する内容です。
後で文書が改版された際にチェックしやすいよう、カッコ()の中はこの文書の見出しを示しています。

  • 概要(1. Introduction)
    • BIMIは、既存のDMARCポリシーを活用し、電子メールの認証の普及を促進することを目的としています。DMARCは、SPFDKIM、ARCをサポートしています。

メールを送信するドメイン側のBIMI対応

(2. Overview)

BIMI対応のために、メールの送信元ドメインにおいて必要な項目を記載します。

送信元ドメインの管理元

送信元ドメインの管理元においては、以下の対応が必要です。

  • DMARC正式運用(DMARC Enforcement)
    DMARC対応において、以下の全てを満たす必要性あります。
    • p=none以外(reject or quarantine)のDMARCポリシー(MUST)
      • p=quarantine、かつ、pctタグがある場合は、pct=100
      • p=rejectの場合、pctの値は任意
    • サブドメインポリシー(spタグ)がある場合、sp=none以外(reject or quarantine)のDMARCポリシー(MUST NOT be "none")
    • 組織ドメインおよびその全てのサブドメインに対してDMARCポリシーを公開
    • SPFDKIMで使用される識別子(認証対象となるドメイン)の一致(alignment)
  • BIMIレコードを通じロゴの公開
    • BIMIレコードの内容については後述します。
    • (以下は、6. Domain Owner Actionsより)
      • BIMIレコード公開に際し、ロゴ画像を決定します。(6.1. Determine and Publish Indicator(s) for Use)
      • BIMIレコードを公開します。(6.2. Publish Assertion Records)
      • 複数のドメイン(同じ信頼境界内)に同じロゴを使用し、かつ、そのロゴを1つのDNSドメインで管理したい場合、CNAMEの使用が推奨されます(RECOMMENDED)。SPFのredirect修飾子と似た用法です。
        BIMIでは、lタグが送信元ドメインと一致していなくても良いので、CNAMEが良い方法です。(6.3. Manage multiple uses of the same Indicator(s) within a trust boundary)
      • (6.4. Set the headers on outgoing email as appropriateについては後述)
  • エビデンス(VMC)の準備も必要です。

メールの送信者

メールの送信者(作成者)においては、以下の対応が必要です。

  • メールが適切に認証され、DMARCポリシーを満たすこと
    なお、" has a sufficiently strict DMARC [RFC7489] policy"とありますが、これはDMARCのアラインメントモードがstrictであることを要求している訳ではないように思われます。

メールを受信する側のBIMI対応(後述)

内容が多く、また別文書の内容とまとめるため後述します。

用語と定義

(3. Terminology and Definitions)

  • BIMI Assertion

    • Protocol Clientが、BIMIレコードを取得し、またロゴ画像を取得するためのURIを構成する仕組み
  • Indicator

    • ロゴ画像
  • Mark Verifying Authority (MVA)

    • エビデンスを提供することができる主体
    • 例えばVMCを発行するCA
    • MVAはロゴを審査する(サイズ、商標等)
  • BIMI Evidence Document

    • MVAにより発行されたドキュメント
    • 例えばVMC
    • 単に"Evidence"と呼ぶことも
  • Verified Mark Certificate

    • ロゴ用の証明書(VMCガイドラインに沿ったCAにより発行)
    • VMCはBIMI Evidence Documentの一種
  • Protocol Client

    • ロゴを取得するためにレコードを取得、解釈する主体
    • 基本的にメールを受信する側のMTA
  • Verifying Protocol Client

    • Protocol Clientのうち、エビデンスを検証する機能をもつもの

以下、追加で整理しておきたい用語を追加で記載します。

  • MBP(Mail Box Providers)

    • 基本的にはメールストアの役割を含むメールシステムを指すことが多そう
    • 文脈によるが、メールを受信する側のMTAとMUAの役割を含むメールシステム全体を提供するサービスプロバイダのことを、MBPと表現することも
  • reciever

    • ドメイン以外からのメールを受け取るMTAやメールシステム全体を指すことが多そう
    • メールの宛先やメール読者はrecieverでなく"recipient"
    • 本記事ではとりあえず"受信者"や"受信する側"、あるいは"MTA"と記載

DNS上のBIMIレコード

(4. BIMI DNS Records)

BIMI対応のために、メールの送信元ドメインが公開する必要性のあるDNSレコードについて記載します。

  • このDNSレコードは、BIMI Assertion Recordsと呼ばれます。本記事ではBIMIレコードと記載します。
  • ドメインの管理元は、BIMIレコードの公開により、MUAに表示させたいロゴの認証や取得に必要な設定情報(policy)を提示します。この設定情報は、Protocol Client(主にメールを受信する側のMTA)により解釈、適用されます。
  • BIMIの設定情報は以下の意図により、DNS経由でのみ発行されます。メールヘッダは使用されません。
    • MTAの振る舞いをシンプルにできる
      • MTAは特定のDNSレコードを確認するだけ
    • 不正なヘッダを攻撃に使われないようにできる
      • そのためにはロゴは事前に取得&キャッシュすべき(SHOULD)

BIMIレコードの形式と各タグ

(4.2. Assertion Record Definition)

BIMIレコードは、以下の問合せにより取得可能なTXTレコードです。
(セレクタ名)._bimi.(ヘッダFromドメイン)

TXTレコードの内容は、以下です。
"v=BIMI1[; l=(ロゴのURI)][; a=(VMCのURI)]

例えば、"example.com"ドメインの所有者が、"default._bimi.example.com"というBIMIレコードを公開したとします。BIMI対応済みのメール受信者は、ヘッダFromが"example.com"ドメインのメールを受け取ると、BIMI認証のため"default._bimi.example.com"のTXTレコードを検索します。そのレコードの情報を用いて一連の認証処理を行った後、MUAでロゴを表示できるようになります。

  • DKIM(RFC 6376)で定義されたタグ構文を使用可能です。
  • メール受信者は、BIMIレコードの構文や大文字小文字のエラーを修正してはいけません(MUST NOT)。BIMIレコードは正確に定義されるものであるためです。
  • BIMIレコードで使用可能なタグは以下の通りです。
    • vタグ(必須)
      • バージョン情報です。
      • 本記事作成時点で選択可能な値は"BIMI1"のみです。
    • lタグ(必須)
      • ロゴのファイルを取得するためのURIです。
      • 空の値は、ロゴの公開拒否を示します。
      • URIは、HTTPS必須です。
    • aタグ(任意)
      • BIMIエビデンスドキュメント(VMC)を取得するためのURIです。
      • 指定する場合は、空の値、もしくは単一のURIを指定します(MUST)。
      • 空の値は、ドメインの管理元がエビデンスを開示したくない、もしくはエビデンスが無いことを示します。
      • aタグが無い場合、空の場合と同じであるとみなされます。
      • URIは、HTTPS必須です。
      • aタグは任意ですが、適切なBIMI運用のためにはエビデンス公開は必須と思われます。エビデンスが無い場合、メール受信者自身が信頼する送信元ドメインを個別に定義するようなポリシーの場合にのみロゴ表示されることになります。
  • vタグ以外の順序は任意です。
  • BIMI対応しないこと(辞退)を明示的に示す場合、以下のBIMIレコードを公開します。(4.2.1. Declination to Publish)
    v=BIMI1; l=; a=;
    • lタグ、aタグの両方が空なので、そのレコードが公開されたドメインおよびセレクタはBIMI対応しないことを示しています。
    • 例えば、組織ドメインがBIMI対応しているものの、そのサブドメインの方はBIMI対応しないことを明示しておきたい場合に有効です。
    • また、辞退用のレコードを公開するためのBIMIセレクタを用意しておき、そのセレクタ名を指定(BIMI-Selectorヘッダ)して送信されたメッセージは、ロゴ表示されません。他のセレクタではロゴ表示できるようになっていても、セレクタで使い分けることができます。

ロゴ画像の形式

(4.2.2. Supported Image Formats for l= tag)

BIMIで使用できるロゴ画像の形式について記載します。

  • 2022年8月時点で、SVGとその圧縮形のSVGZが許可されています。
  • RFC6170 section 5.2に定義されたSVG、SVGZファイルをlタグに使用可能です。
    その他の制限として、SVG Tiny Portable/Secure(SVG Tiny PS)の要件が適用されます(参考:BIMIの準備:ロゴの準備(digicert))。
  • メール受信時の検証の際、lタグで指定されたURI中のファイル拡張子が異なっていたり、受信したファイルが別形式の場合、BIMI認証はエラーとなります(MUST)。

セレクタ

(4.3. Selectors)

  • メール送信者は、BIMI-Selectorヘッダにより、そのメッセージのBIMI認証に適用すべきセレクタを指定できます。指定が無い場合は"default"というデフォルトのセレクタ名が使用されます。DKIMセレクタと同様のものです。
  • これは、1つのFromヘッダドメインが、複数のBIMIの設定情報を使い分けることができるということです。シーズンやイベントごとのブランディング方針に応じ、複数のロゴを使い分けることができます。
  • セレクタ名は、それ自体をピリオド(.)でサブドメインのように分割可能できます。セレクタをカテゴリ分け等する際に有用です。
    例:name.category._bimi.example.com
  • 定義可能なセレクタの数は無制限です。

BIMI-*メールヘッダ

(5. BIMI Header Fields)

DNSでBIMIレコード(ポリシー)の公開の他に、ドメインの管理元はBIMI関連メールヘッダを通じて追加情報を提供できます。
BIMI関連ヘッダは大文字小文字は区別しません。必須タグが無い場合、BIMI認証はエラーになります。

  • BIMI-Selectorヘッダ(5.1. BIMI-Selector Header)
    • default以外のセレクタ名以外を使用したい場合に、メール送信者が指定します。
    • 以下の書式です。
      • vタグ(必須)
        • バージョン情報です。
        • 本記事作成時点で選択可能な値は"BIMI1"のみです。
      • sタグ(必須)
  • BIMI-Locationヘッダ(5.2. BIMI-Location Header)
    • メール受信者(BIMI認証を行ったMTA等)が、MUAにどこからロゴを取得するかを示すために追加されるヘッダです。
    • 以下の書式です。
      • vタグ(必須)
        • バージョン情報です。
        • 本記事作成時点で選択可能な値は"BIMI1"のみです。
      • lタグ(aタグがある場合は任意、それ以外の場合は必須)
        • ロゴを取得するためのURIです。
        • 基本的にBIMIレコードに含まれるlタグもしくはaタグのURIと同じ内容です(詳細は"7.9. Construct BIMI-Location URI")。
        • MTAによって必要なチェックとBIMIレコード取得後に追加されます。
        • URIHTTPS必須です。
      • aタグ(エビデンスが検証成功した場合は必須)
        • エビデンス(VMC)を取得するためのURIです。
        • 基本的にBIMIレコードに含まれるaタグのURIと同じ内容です。
        • MTAによって必要なチェックとBIMIレコード取得後に追加されます。
        • URIHTTPS必須です。
    • BIMI-Locationヘッダはメール送信者によって追加されてはいけません(MUST NOT)。(6.4. Set the headers on outgoing email as appropriate)
  • BIMI-Indicatorヘッダ(5.3. BIMI-Indicator Header)
    • メール受信者(BIMI認証を行ったMTA等)が、MUAにロゴを渡すために追加されるヘッダです。
    • BASE64エンコードされたSVGファイルが格納されます。
    • BIMI-Locationで取得する画像と一致している必要性があります(MUST)。
    • SVGZの場合、解凍後にBASE64化する必要性があります(MUST)。
  • ヘッダ署名(5.4. Header Signing)
    • BIMI-Selectorヘッダが存在する場合、それがDKIM署名対象範囲に含まれるべきです(SHOULD)。ここで言及されているDKIM署名は、ヘッダFromドメインを認証対象としたDKIM(DMARC aligned DKIM)のことです。
      BIMI-SelectorヘッダがDKIM署名対象範囲に含まれない場合、そのヘッダ(BIMI-Selector)は無視されるべきです(SHOULD)。
    • 受信者はBIMI-Selectorの検証方法を追加することができます(MAY)。例えばARC認証です。ARC認証成功した場合に、BIMI-Selectorが署名対象であるメッセージと同等の扱いをしても良いです(MAY)。
    • BIMI-Locationヘッダ、BIMI-IndicatorヘッダはDKIM署名対象に含まれてはいけません(MUST NOT)。これらのヘッダは、MTAによりDKIM検証された後、MTAとそのMUA間でのみ使用されるものであるためです。よって、これらのヘッダを署名対象に含めるのは無意味です。

メールを受信する側のBIMI対応

ここでは、メールを受信する側のBIMI対応について記載します。
参照しているIETF文書は、主に以下の2つです。

draft-brotman-ietf-bimi-guidance-06の内容

メールを受信する側のBIMI対応に関し、システム構成上、整理しておきたいポイントのみ抜粋します。

MUA、MTAの役割

(3.3. MUA Authors、3.4. MTA Authors) ロゴを最終的に表示する(かどうかを決める)のはMUAです。
一方で、受信したメッセージを検証するのは受信者やMBPです。
また、MBPがBIMIレコード中のURLやエビデンスから直接取得せずプロキシを使用するよう構成することが理想的です。

BIMIの前提

(5.2.1. BIMI processing requirements)
BIMIはDMARC認証成功を前提としていますが(MUST)、さらに追加の要件をローカルポリシーとして設定してよいことになっています。
そのローカルポリシーの基準が厳しいほど、誤ってMUAに対しロゴ表示を許可することが少ないです。
例えば、以下のようなポリシーが例示されています。

  • DKIMSPFの両方がヘッダFromアドレスの組織ドメインで検証済みであること DMARCでは、DKIMSPFのどちらか一方がヘッダFromと一致することが必須要件になっています。
  • SPFにおいて、"-all"を必須とすること
    "?all"や、大きなアドレス空間に対する許可設定を拒否する設定です。

BIMI対応済みの受信者は、既に存在しているBIMI-Selector以外のBIMI-*ヘッダを削除もしくはリネームすべきです。それらのヘッダが攻撃者によって追加されたものかもしれないためです。"BIMI-Selector以外"というのは、BIMI-SelectorがDKIM署名に含まれている場合の話です。そうでない場合はBIMI-Selectorも削除もしくはリネーム、あるいは無視されるべきです。
BIMI対応していない受信者も、これらのヘッダを削除すべきです。MUAが適切に認証されていないメールにロゴを表示することを避けるためです。MUAは、BIMI関連ヘッダーを使用すべきでなく、メールストアの設定に依存すべきですが、MUA単独でヘッダを使用してしまう動作は可能です。
メールをいったん受信後、そのサイトの外に出ていくメールについても、同様にBIMI-*ヘッダーを削除すべきです(再配送などのケースと思われます)。

MTAからMUAへのBIMI認証結果の伝達

(5.3. Communicating BIMI results between the MTA and the MUA)
メール受信するシステム(MTA)は、MUAに画像表示すべきことを知らせるために、以下を行います。

  • MTAはBIMI認証しなければいけません。認証成功した場合、表示すべきロゴを含むヘッダを追加します。
  • MUAはロゴを読み込む前に、BIMI認証成功したかをチェックしないといけません。
  • MTAによって追加されたヘッダは、それらが信頼できるものによって追加されたヘッダであることの追加チェック無しで、MUAから依存(信頼)されるべきではありません。例えば、MTAがメール受信時に既存のBIMI-*ヘッダを削除しているかどうかの確認や、信頼のおけるARヘッダからbimi=passを確認を行うことです。

MUAによるロゴの取得

(5.4. Image Retrieval)
BIMIの仕様において、MUAによるロゴの取得方法は重要です。以下の方法があります。

  • MUAが、BIMI-Locationヘッダ内のURIから直接ダウンロード
    最も基本的な方法です。
  • MTAがメールヘッダに追加したロゴ画像データをMUAが取得
    推奨される方法です。
    MTAがメールヘッダにBASE64エンコードしたロゴ画像データを追加し、MUAがそのヘッダからロゴを取得するものです。MUAにとっては、既にMTAが取得および認証したロゴを取得できるので推奨されています。
    この方法は、メールのサイズに関して注意が必要です。1~30KBのSVGファイルをBASE64エンコードすると35%程度大きくなります。そのエンコード後のサイズ分、増加することになります。
  • キャッシュされたロゴをMUAが取得
    ローカル領域にロゴをキャッシュし、その領域をメールヘッダにロゴ取得用のアドレスとして示す使用する方法です。プロキシのような運用方法です。
    具体的なローカル領域の場所について言及が無いので、推測となりますが、原理的には受信者側の裁量で任意の場所を指定可能と思われます。
    • 受信者サイト内のどこか(MTA、MBP、その他)にキャッシュ
    • MUA内にキャッシュ

    キャッシュの具体的な仕組みはMBP全体の実装によると思われます。

    • 例えば(GmailのBIMI動作を見て思ったことですが)、キャッシュしたロゴを使用するためにBIMI-SelectorヘッダやBIMI-Locationヘッダを必ずしも使用しなくても動作は可能と推察されます。
      MUA(WebMailや専用アプリ)とMBPがBIMI対応のため独自に連携できている場合、MUAへのロゴ情報伝達としてのこれらのヘッダ使用を省略し、MBP主導で適切にキャッシュ画像表示を処理する方が効率や安全性が高い実装になるだろうという意味です。
    • ちなみに、(キャッシュでなく)ロゴのおおもとの配布元についても、送信元ドメインとは別ドメインURIでもよいことになっています(7. Brands)。

HTTPリダイレクトの制限

(5.5. Limited use of HTTP Redirects)

  • メールを受信する側は、ロゴやエビデンス(VMC)を取得するためのURIへのアクセス時にHTTPリダイレクト応答となった場合、そのリダイレクトに従わない、もしくは限られた回数までのリダイレクトにのみ従うといった動作を選択可能です。
  • そういった制限をしている受信者によりロゴが受信されなくなる事態を避けるため、送信者はHTTPリダイレクトを排除、もしくはその回数を制限すべきです。

キャッシュした画像のTTL

(5.6. TTL of cached images)
メールを受信する側の設定として、MUAがロゴを再取得しない期間(TTL)の話です。

  • TTLが短すぎるとMUAによる画像参照が多くなりすぎます。
  • TTLを以下のように設定することも可能です。
    • 数時間
    • 1日
    • ロゴ画像を含むエビデンス(VMC)の有効期限と同じ
  • キャッシュ実装の欠点は、キャッシュの仕組みにおいて証明書失効チェックや再取得が必要となる点です。

プライバシーに関する考慮

(6. MUA Authors -> 6.3. Privacy Concerns)
メールを受信する側において、プライバシー漏えいに関する以下の考慮が必要です。

  • 例えば、送信者は宛先メールアドレスごとに異なるセレクタを用意したり、ロゴ取得用のURIに追跡のための文字列を追加することができます。
    これにより、宛先メールアドレスごとにロゴ画像取得タイミングから行動を追跡される可能性があります。
  • メールを受信する側は、ある組織ドメインが使用しても良いセレクタの数を定義し、その数を超えた場合に処理を拒否することができます。
  • MTAは、追跡を制限するため、BIMIレコード、エビデンス(VMC)、ロゴをキャッシュした方が良いです。
  • MUAは、ロゴを直接取得するよりBIMI-Indicatorヘッダから取得した方がよいです。これはMUAがロゴを取得していることが分かるのはMTAのみ(ここはMTA以外に、BIMI-Indicatorヘッダで指定された、信頼されているであろうロゴ取得先やキャッシュ先も含む意味かと推察しています)となるように制限できるからです。
  • BIMIは、SVGプロファイルで外部からSVGを読み込むことを禁止することを認めています。これはMUAがロゴを表示する際の追跡に関するリスクを取り除くことができます。

ロゴの配置等

(7. Brands)

  • ロゴを配置するホストは、メールの送信元ドメインと別ドメインのホストでも問題ありません。全てのメール送信元ドメインに対応するWebサーバが存在するとは限らないためです。(7.1. Logo Hosting Considerations)
  • BIMIのロゴ取得の処理は通常のブラウザと異なる動作となるため、CDNから要求されるチャレンジ応答不可となり、ロゴを取得できない場合があります。
    そのため、CDN側の対応としては、誰からでもアクセスできるよう構成すべきです(チャレンジ要求無しで)。(7.2. CDN Considerations)
  • エビデンス(VMC)は、1つ以上のドメイン名を提供します。SAN(別名)を定義することも可能です。
    これらのドメイン名は、ヘッダFromドメイン名と一致している必要性はありませんが、BIMIレコードで使用されているドメインと一致している必要性があります(そのレコード自体のドメインのことかと思われます)。
    例えば、VMCに組織ドメインを定義してある場合、3rdレベルドメインもこのVMCを使用できることになります。
    (7.3. Domains listed in your evidence document)

基本的なフロー

(9. Basic flow example)
後述の別文書の方が詳しい記述なので、そちらにまとめます。

draft-brand-indicators-for-message-identification-02の内容

メールを受信する側のBIMI対応に関し、システム構成上、整理しておきたいポイントのみ抜粋します。

メール受信時のBIMI認証フロー

BIMI認証の前提

(7.1. Authentication Requirements)

  • 1. ヘッダFromが複数ある場合、BIMI処理は実行されていないけません(MUST NOT)。
  • 2. ヘッダFromのDNSドメインをAuthor Domainと定義します。
  • 3. Author Domainの組織ドメインを決定します。これをAuthor Organizational Domainと定義します。Author Domainが組織ドメインであれば、そのまま組織ドメインはAuthor Domainとなります。
  • 4. Author Domainに対するDMARC結果を評価します。この結果は、BIMI DMARC Resultと定義します。
  • 5. BIMI DMARC Resultがpassでない場合、受信者は追加の認証メソッドを適用しても良いです。例えばARC評価や、ローカルポリシー適用です。
    受信者はこの場合、BIMI DMARC Resultがpassの場合と同様なものとして扱っても良いです(MAY)。
  • 6. DMARC結果がpass以外、かつ追加の認証メソッドも成功しない場合、BIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)
  • 7. Author Domain or Author Organizational DomainのDMARCポリシーがp=noneの場合もBIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)。
  • 8. Author Domain、もしくはAuthor Organizational DomainのDMARCのサブドメインポリシーがあり、sp=noneの場合、BIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)。
  • 9. Author Domain、もしくはAuthor Organizational DomainのDMARCポリシーがp=quarantineで、かつpctタグがある場合には、pct=100でないと、BIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)。
BIMIレコードの検索

(7.2. Assertion Record Discovery)

  • BIMIレコードの検索は、DMARCレコードの検索と似ています。
  • メールを受信する側のポリシーに基づく認証が失敗したメールに対しては、BIMIレコード検索を試みてはいけません(MUST NOT)。
  • 以下の相反する要件とのバランスを取る必要があります。
    • ワイルドカードサポート
    • サブドメインポリシーオーバーライドの許可
    • DNSクエリ負荷の制限 そのために、Protocol Clientは以下の検索方法でBIMIレコードを検索しなければいけません(MUST)。
  • 1. ヘッダFromのDNSドメインをAuthor Domainと定義します。
  • 2. セレクタ名を決定します。BIMI Selectorヘッダあればそれ、無ければ"default"をセレクタ名とします。
  • 3. DNS検索します(MUST)。レコードが無い場合もあります。
  • 4. 取得したBIMIレコードがvタグから始まらない場合、無視します(MUST)。
  • 5. レコードが無い場合、組織ドメインで再問合せします(MUST)。レコードが無い場合もあります。
  • 6. 取得したBIMIレコードがvタグから始まらない場合、無視します(MUST)。
  • 7. レコードが複数ある場合、あるいはレコードが無い場合、BIMIレコード検索は終了し、そのメッセージに対してBIMI認証は実行されてはいけません(MUST NOT)。
  • 8. レコードが1つのみであれば、そのレコードをBIMI認証に使えます。
ロゴの検索

(7.3. Indicator Discovery.)

  • 1. BIMIレコードにlタグが無い場合、ロゴの検索は失敗します。ロゴは表示されてはいけません(MUST NOT)。
  • 2. a=タグがあり、かつ受信者がBIMIのエビデンス検証に対応している場合、後述のIndicator Discovery With Evidenceに進みます。
  • 3. 受信者がBIMIのエビデンス検証に対応していない場合、もしくはa=タグが無い場合、後述のIndicator Discovery Without Evidenceに進みます。
エビデンスがある場合のロゴの検索

(7.4. Indicator Discovery With Evidence)

  • BIMI Evidence Documentの種類ごとに、追加の検索や検証の方法を指定できます(MAY)。詳細は別ドキュメントです。
  • 以下、draft-brotman-ietf-bimi-guidance-06より、エビデンスとしてVMCを使用する場合のフローです。
    • VMCの検証
      • 受信者はBIMIレコードで指定された場所からVMCを受信します。
      • VMCが信頼できるroot CAを使用しているか検証します。
      • 検証成功したら次へ進みます。
    • VMCから画像の取得
      • 受信者はVMC内の画像を取得します。
      • 取得したSVG画像を検証します(後述の"ロゴの検証(7.6. Indicator Validation)")。
エビデンスを使用しない場合のロゴの検索

(7.5. Indicator Discovery Without Evidence)

  • 取得したBIMIレコードのlタグ、aタグの値が空の場合、そのドメインはBIMI対応しないことを明示的に示しています。この場合、MTAはAuthentication-Resultsヘッダに"bimi=declined"を追加すべきです(SHOULD)。
  • 取得したBIMIレコードの、aタグの値が空、もしくはaタグのURIからエビデンス取得できない場合、以下の手順によりlタグで指定されたURIからロゴが取得されなければいけません(MUST)。
    • 1. lタグのURIからSVGを取得します。
    • 2. HTTPSTLS証明書の検証に失敗したらロゴの検証は失敗となり、ロゴは表示させてはいけません(MUST NOT)。
    • 3. 後述のIndicator Validationステップに進みます。
  • なお、IETF文書のこの章に記載は無いですが、エビデンスが無い場合のBIMI認証成否は、メール受信者側でエビデンスが無い場合のBIMI認証を行うポリシーかどうか、またその送信元ドメインを個別に信頼しているかどうかによると思われます。
ロゴの検証

(7.6. Indicator Validation)

  • 1. 取得したロゴのファイルサイズを、推奨の最大サイズに照らしチェックします。受信者独自のサイズ制限を設定しても良いです(MAY)。
    推奨の最大サイズは、おそらく SVG Tiny Portable/Secure draft-svg-tiny-ps-abrotman-04にある記載のことで、SVG(SVG Tiny PS)はできるだけ小さくすべきであり、非圧縮時の32KB以内であるべきとのことです(SHOULD)。
    受信者は、ドキュメント全体を取得してからサイズをチェックするのではなく、受信制限としてサイズ制限を実装しても良いです(MAY)。
  • 2. SVGファイルが存在しないか、有効でないSVGファイルやSVGZファイルである場合、ロゴの検証は失敗となり、表示してはいけません(MUST NOT)。
  • 3. SVG validation stepsへ進みます。これは、このドキュメントと、別のSVGに関する文書に記載の内容です(詳細は未確認です)。
  • 4. ロゴの検証が成功し、またそのロゴが信頼されたソースから取得されたものであれば、受信者側のポリシーに沿ってロゴを表示して良いです(MAY)。BIMI認証成功です。
    • 以下、draft-brotman-ietf-bimi-guidance-06より、補足です。
      • メールスキャン
        • BIMI認証の成否に関わらず、マルウェア対策やスパム対策等のコンテンツに対するスキャンは必要です。
      • MUAによるロゴ表示
        • メールを受信したMUAはBIMI-*ヘッダをチェックします。
        • BIMI-Indicatorヘッダ(あれば)から画像を取得します。
        • ロゴを表示します。
        • BIMI認証成否に関わらず、メールスキャンによりフィッシングやマルウェアと判断されたメールは、MUAはロゴ表示すべきではありません(SHOULD NOT)。スパムであると判断されたメールの場合は、受信者はロゴを表示しなくても良いです(MAY)。
      • BIMI認証が失敗した場合
        • MTAはMUAに対してロゴ表示するよう指示してはいけません。
        • MUAは、イニシャルの画像や、不明な送信者用のデフォルト画像を表示しても良いです(MAY)。
ARヘッダに追加されるBIMI認証結果

(7.7. Affix BIMI Status to Authentication Results Header Field)

  • 上記のBIMI認証後、MTAはAuthentication-Resultsに認証結果を追記します(SHOULD)。
    内容は以下の通りです。
    • bimiキー(必須)
      • BIMIの認証結果です。
      • 記載可能な値は 前述の通りです。
    • header.dキー(bimi=passの場合、必須)
      • 検証対象となったBIMIレコードのドメイン名です。
      • この値は、基本的にヘッダFromドメインです。BIMIレコード検索時、フォールバックしていたら組織ドメインとなります。
    • header.selectorキー(bimi=passの場合、必須):
      • 検証対象となったBIMIレコードのセレクタ名です。
    • policy.authorityキー(BIMI Evidence Documentがチェックされた場合、必須)
      • エビデンスの検証結果です。
      • エビデンスが提示され、かつチェックされ有効だった場合、"pass"を設定しないといけません(MUST)。検証に失敗したら"fail"に設定しないといけません(MUST)。
      • エビデンスが無い、もしくはMTAがチェックしなかった場合はnoneを設定すべきです(SHOULD)。
    • policy.authority-uriキー(任意)
      • チェックされたエビデンスURIです。
      • BIMIレコードのaタグに設定されていたURIです。
既に存在しているBIMI関連ヘッダの扱い

(7.8. Handle Existing BIMI-Location and BIMI-Indicator Headers)

  • BIMIレコード検索に成否に関わらず、BIMI-Locationヘッダ、またはBIMI-Indicatorヘッダがメールに存在する場合、それらを削除するかヘッダ名を変更しないといけません(MUST)。
    通常、BIMI認証を行うMTAはMDAの直前(あるいはMDAと同じ管理下)にあり、唯一BIMI-Location or BIMI-Indicator を指定してよい存在であるためです(送信元MTAや中継MTAではないということです)。
  • 既に存在していたBIMI-LocationヘッダやBIMI-IndicatorをMUAにそのまま伝達することは、セキュリティリスクとなります。
  • メールがDKIM署名を含んでいた場合でも、BIMI-Locationヘッダを削除しても、DKIM署名は無効にならないはずです。BIMIの仕様に従えばBIMI-LocationヘッダはDKIM署名対象範囲に含まれないからです。またMTAがメールを受け取った際にDKIM検証は済んでいるはずです。
  • 関連情報が、draft-brotman-ietf-bimi-guidance-06の5.2.1. BIMI processing requirementsにもあります(本記事でも前章で言及済み)。
BIMI-Locationヘッダの構成

(7.9. Construct BIMI-Location URI)

  • BIMIの検索や検証が失敗した場合、BIMI-Locationヘッダは追記されてはいけません(MUST NOT)。
  • エビデンスからロゴを取り出した場合、bimi-evidence-location(BIMIレコード中のaタグ)の値になり(SHOULD)、それ以外の場合は、bimi-location(BIMIレコード中のlタグ)の値となります(SHOULD)。
  • なお、aタグとlタグの両方がある場合、それらのロゴが一致することをMTAはチェックしなければいけません(MUST)
BIMI-Indicatorヘッダの構成

(7.10. Construct BIMI-Indicator header)

  • BIMIの検索や検証が失敗した場合、BIMI-Locationヘッダは追記されてはいけません(MUST NOT)。
  • このヘッダの文字数は多くなりますが、1行あたりの文字数の制限以内で折り返さなければいけません(MUST)。1行あたりの制限は、RFC5322の2.1.1. Line Length Limitsにある"CRLFを除いて、各行は998文字を超えてはならならず(MUST)、78文字を超えるべきではない(SHOULD)"のことです(RFC5321にも類似の記載あり)。

BIMIのセキュリティに関する考慮事項

(8. Security Considerations:an incomplete list of considerations)

いくつか備忘用に抜粋して記載します。

  • 再配送(8.1. Indirect Mail Flows)

    • 再配送は、メーリングリストや転送のことです。
    • 再配送されると、再配送先には、既にBIMIヘッダが追加されたメールが届く可能性があります。
    • 再配送先の受信者は、再配送したメールシステムを信頼しているなら既存のBIMIヘッダを使用しても良いです。あるいは、再配送先で再度BIMI認証を行い、BIMI-Locationヘッダを再作成しても良いです。
  • 認証対象ドメインとロゴ配置先の不一致(8.5. Unaligned Indicators and asserting domains)

    • ロゴの管理者が、ドメインの特定の場所(公開Webサーバ)にロゴを配置できるとは限らないので、BIMIの認証対象ドメインに配置することを必須とするのはハードルが高過ぎます。
    • 認証対象ドメインの外にロゴを置くこと望ましいケースがあるかもしれません。
      • 例えば、正当な第三者ドメインDNSやWebサーバにアクセスすることなく、セレクタを管理・設定できるようになります。ドメインの管理元に代わって正当な認証済みメールを送信できる誰かがいるケースです。
  • BIMI-Selectorヘッダが署名対象外の場合(8.6. Unsigned BIMI-Selector Header)

    • 受信者は、BIMI-Locationヘッダを追加するかどうか決定する際に、DKIM署名の有無を考慮に入れることができます。
    • DMARC認証成功が、DKIMでなくSPFの認証成功だけによる者である場合、BIMI-Selectorが改ざんされていないことを署名により担保できないためです(ARCも考慮するなら、ARCによる署名もあります)。
  • ロゴ中のCGIスクリプト(8.7. CGI scripts in Indicator payload)

    • MTAとMVAは、インジケーターが適切ものであるかを積極的にチェックすべきです。
    • また、MTAは適切なインジケーターをキャッシュし、それらをMUAに直接提供する場合があります。これにより、MTAではなくエンドユーザーに実行されるよう意図された悪意のある動的データを回避できます。

BIMI仕様の背景

備忘用に、An Overview of the Design of BIMI draft-bkl-bimi-overview-00の内容を一部記載しておきます。

  • 4.2. S/MIME signatures
    • 原則として、インジケータはS/MIMEによりアサートできる。実装や普及が難しいため基本的に使われない方法。
  • 6. Validator options
    • 検証者には色々な検証の選択肢がある。第三者による検証など。
  • 7.1. Issues
    • MUAがBIMI-LocationヘッダのURIを用いてロゴ取得すると、Web bug問題が生じる。
    • MTAによるBIMI-Locationヘッダ追加で、この問題は回避できる。MTAはロゴをキャッシュしローカルURIをヘッダ(おそらくBIMI-Locationヘッダ)に挿入することもできる。MTAによるロゴ取得により、送信者にメールがそのドメイン(BIMI認証を行うシステム)に届いたことは分かるが、最終的な受信者は直接ロゴ取得しないので最終的な受信者の行動は把握されずに済む。
  • 9.4. IMAP flags
    • MDA(LMTPサーバ等)がメールに対し、そのBIMI-Locationヘッダが本物であることをマークするためのIMAPフラグを付与できる。
    • 他のアプローチとして、MDADKIM署名を追加する方法。そのDKIM署名には、受信者ドメインのdタグを含み、新しいBIMI-Locationヘッダを署名範囲に含む。これはMUADKIM署名を検証するということ。なりすましに注意が必要。
    • (個人メモ)メールストアとMUAが一体となったMBPでなく、クライアント端末上で動作するメーラの場合、既存のIMAPプロトコル内で実装できるBIMI認証結果等の伝達方法があると有用。POPも。

参考URL等

IETF文書の版数ごとの差分

本記事の作成にあたり参照している以下のIETFのI-D文書については、2022年10月に版数アップした際の差分は特に無いようです。日付の修正と、エンコードされた文字のデコード?の修正のみかと思います。

  • draft-brand-indicators-for-message-identification-02 → 03
  • draft-brotman-ietf-bimi-guidance-05 → 06
  • draft-brand-indicators-for-message-identification-01 → 02
  • draft-svg-tiny-ps-abrotman-02 → 03

ARC認証の整理しておきたいポイント

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、ARC(Authenticated Received Chain)認証についてまとめたものです。
SPFDKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

本記事の目的

  • ARC認証の概要を理解する。
  • ARC対応の際してのポイントを把握する。

※本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。


目次

基本

ARCの認証対象と認証成否

  • メールヘッダ(ARC-*ヘッダ)にある電子署名を認証します。
    このARC-*ヘッダは、メールを中継するシステム(ARC対応のMTA等)によって追加されるたびに増えます。
  • 電子署名の中で指定されたドメインDNSに登録されたレコード(DKIMと同様)に基づいてその署名を検証する等、ARC認証に必要な一連の処理を行い、正しいものであると判断できれば認証成功です。
  • ARC認証の成功により、最初から最新までの全てのARC署名(i=1~N)が有効なChainを構成していることを確認できます("chain of custody":認証/管理の連鎖のようなイメージ)。
    DKIM単体の場合、メールの再配送時に認証情報が無効になってしまうことがありますが、ARCの場合はChainとして保持できます(再配送とは、indirect mail flow:メーリングリストに投稿されたり、別ドメインのメールアドレス宛に転送されること)。これがARCの特徴であり、SPFDKIM、DMARCにおける、再配送時に認証不可になってしまうという課題を緩和できます。
    ARCは、(語弊はありますが)DKIMを再配送に対応させたもののようなイメージです。
  • DNSレコードを保有するドメインの管理元により、「メールに署名することを認められたメールシステムにより、最初から最新までのARC署名(i=1~N)がそれぞれ追加され、また署名の改ざんもされていない」という点を担保します。詳細は長くなるので後述します。

認証時の動作

  • メールを受信する側が、上記の認証を行います。
  • ARC認証の際には多くの検証処理が行われます。
    詳細は、RFC 8617の"5.2. Validator Actions"に記載があります。またARCの検証時にはDNS問合せが多く発生します("11.3.3. DNS Overhead")。
    以下は備忘用です。
    • AMSヘッダの検証は、最新(そのメールヘッダ内で最も大きな値のi=N)のものに対して行われます。
      任意で、全てのAMSヘッダの検証を行い"最初にpassしたARC署名のiの値"を調べることもできます。
    • ASヘッダの検証は、最新から最初までの全てのものに対して行われます。
    • この検証結果は、ARヘッダに記載される必要があります(SHOULD)。

ARC対応に必要な設定

  • ARC対応に必要な設定は、DNSレコード登録の他、ARC署名追加機能の実装が必要です(鍵の準備を含む)。DNSレコードや鍵は、DKIMで使用するものと兼ねることができます。
  • SPFDKIM、DMARCに対応していないドメインであっても、ARC対応することはできます。
    各送信ドメイン認証技術の普及の仕方によると思いますが、基本的にSPFDKIM、DMARCに対応した上で、必要に応じARC対応もすることになるでしょう。
  • 設定に際しての補足事項は別記事にまとめる予定です。

認証結果

  • ARCの認証結果は、"none","fail","pass"のいずれかです。
    • RFC 8617の"4.4. Chain Validation Status"、"10.1. Update to Email Authentication Result Names Registry"に記載されています。
    • この認証結果は、以下で使用されます。
      • Arc-Sealヘッダ内のcvの値
        i=1の場合はnone
        i=2以降の場合はfailもしくはpass
      • ARC-Authentication-Resultsヘッダ内のarcの値
      • Authentication-Resultsヘッダ内のarcの値
  • 送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダの詳細は別記事にまとめる予定です。

詳細

導入ステップや運用ポリシーに応じた調整のポイント

  • まず参考として、ARCの仕様策定や普及の状況についてです。
    • ARCの仕様を定めたRFC 8617は、2019年7月に公開されたもので、Experimentalの扱いです。比較的新しい仕様ということです。
    • 普及状況としては、Gmailは2017年5月にARC対応済み、またmicrosoft.com(Exchange Online)からのメールもARC対応済みであり、その他のメール関連システムにおけるARC機能の実装も進んでいます。今後、ARCを利用するシステムが増えるでしょう。
  • ARC自体には、SPFにおける修飾子やDMARCにおけるポリシー(p=)のような、検証基準を調整するパラメタはありません。
    よって、ARC単独では、(送信元ドメイン側としては)試験的な段階を設けることは難しいでしょう。
  • ARCにより、SPFDKIM、DMARCにおける再配送の課題を緩和するという意味では、以下のようなアプローチが考えられます。
    • 仕組みについては後述します。
    • 送信元ドメイン側でできることは少ないので、主にメールを受信する側のポリシー調整の観点について説明します(受信するメールには検証成功するARC署名が含まれている前提です)。
    • 例えば再配送されたメールを受信する側において、SPFDKIM、DMARCの認証が再配送の影響で失敗しても、ARCの認証が成功すればそのメールを拒否せず受信者に配送する、といった運用が可能です。
      この例の場合、ARCは再配送の課題に対する緩和策になります。もちろんメールを受信する側がDMARCよりARCの認証結果を優先するという運用判断をできること、また使用するシステムがそのような設定に対応できるものであることが前提になります。
    • また、上記のようにARCの認証結果がDMARCの認証結果(結果的にそのメールを拒否したかどうか)に影響を与えた場合、それをDMARCレポートに含めることができます(例は後述)。
      送信元ドメイン側としても、そのDMARCレポートを受け取ることでARCが意図どおりに機能しているか状況分析が可能になります。
  • ドメインの管理元がARC対応するきっかけとして、以下のような利用者目線の課題が考えられます(もちろんシステム管理者側が技術動向を踏まえ先手を打ってARC対応できている場合もあると思います)。
    • 送信元ドメイン側としてARC対応するきっかけ
      メールの送信者が、送ったはずのメールに対して受信者から反応がなくて困っている場合(例えば、実は再配送の課題によりDMARC認証が失敗し受信者に届かなかったり、隔離されたりした)
    • メールを受信する側としてARC対応するきっかけ(ARC認証結果を最終的なメール受信可否の判断材料にするかどうかの検討)
      メールの受信者が、届くはずのメールが届かなくて困っている場合(同上)
    • メールを再配送する側(メーリングリストや転送の機能を持つシステム)としてARC対応するきっかけ
      上記のようにメールの送信者や受信者が困っているから解決して欲しい旨の要望等があった場合
  • メールの送信や中継を行うドメインが新たにARC署名するようになることで、メールが届かなくなるといった悪影響は生じにくいはずです。
    影響が生じるとしたら、それはメールを受信する側のポリシー変更があった場合や、配送経路上のARC対応した他システムが側で行われるARCの検証や署名に不備がある場合が考えられます。

再配送の課題をARCにより緩和する仕組み

  • 例えば、あるメールがメーリングリスト(ML)システムによりSubject変更されたもののDKIM署名の方は修正(署名削除や再署名等)されないまま再配送された場合、その後のDKIM認証は"fail"になります(これにより、DMARC認証も"fail"になることがあります)。しかし、MLシステムの再配送時にARC署名しておくことでARC認証として"arc=pass"となるように対処できます。
    あとはメールを受信する側が、このARC認証の結果に基づいてメールを拒否しないよう判断してくれれば無事配送されます。
  • MLサーバソフトウェア(Mailman、Sympa)はARCの使用を推奨しています。これらのソフトウェアはARC署名が可能です。

なお、MLサーバソフトウェアが、ARC対応以外に、DKIMやDMARCの認証失敗に対してどのような対処を行う機能を持っているかについては、別記事にまとめる予定です。

DMARCレポートへのARC認証情報の記載例

  • 受信する側のローカルポリシーにより、ARCの認証成功時にメールを拒否せず受け入れる判断とした場合のDMARCレポートの記載例です。
    (RFC 8617の"7.2.1. DMARC Local Policy Overrides"、"7.2.2. DMARC Reporting"より)
   <policy_evaluated>
     <disposition>none</disposition>
     <dkim>fail</dkim>
     <spf>fail</spf>
     <reason>
      <type>local_policy</type>
      <comment>arc=pass as[2].d=d2.example as[2].s=s2
        as[1].d=d1.example as[1].s=s3
        remote-ip[1]=2001:DB8::1A</comment>
     </reason>
   </policy_evaluated>
  • 上記のDMARCレポートは、DKIMSPFが認証失敗(fail)しているにもかかわらず、そのメールの処理結果としては<disposition>none</disposition>(何もしない)であり、メールを受信する側がこのメールを拒否せず受け入れたことを示しています。
    その理由として、<type>local_policy</type>に、認証成功(pass)したARCのChainに関する情報が記載されています。
    これは、メールを受信する側がDMARC検証時、そのローカルポリシーによりARCの認証結果に基づいて判断を上書きした例("DMARC Local Policy Overrides")です。

ARCにおける認証情報の保持

  • ARCが認証情報を保持する仕組みは、メールの配送経路において、ARC対応したメールの送信者、中継者を通過するたびに、ARC署名の検証および追加が順に行われることで実現されます。
    ARC署名が追加されるたびにARC-*ヘッダの中のiの値は、i=1、i=2…i=Nのように増えていきます。
  • ARC署名を追加する時点のAutentication-Results:ヘッダの内容がARC関連ヘッダに保持されるので、これを辿ることでそのメールの送信ドメイン認証結果の履歴を確認できます。 ARC関連ヘッダは自身に対する電子署名を含むので(ASヘッダ)、改ざんされた場合、ARC認証が失敗します。
  • 1通のメールにつき、保持できるARC(Chain)は1つだけです。
    何らかの理由でChainが壊れた場合、管理("chain of custody")が無効になります。再確立については今後仕様が議論されるかもしれません(ARC-USAGE)。
  • ARC署名時に追加されるヘッダは以下の3つです。
    RFC 8617の"4.1. ARC Header Fields"に記載があります。
    ARC-Seal(AS): i=x; … cv=(ARCのChainの有効性); d=(ドメイン); b=(電子署名)
    ARC-Message-Signature(AMS): i=x; … d=(ARC内のDKIM認証対象ドメイン)… b=(電子署名)
    ARC-Authentication-Results(AAR): i=x; host.domain.com(このARC署名を追加したホストのFQDN)
    • ARC署名が追加される際、AS、AMS、AARの3ヘッダにおけるiの値は同じ数が記載されます。
      iの値が同じこれら3つのARC-*ヘッダを、"ARCセット"と呼ぶことがあります。
    • ARC-Seal(AS)ヘッダ(封緘)
      • Chainが改ざんされないよう署名を保持する重要なヘッダです。ARC署名追加時点でChainが有効かどうかの認証結果(cvタグ)と、電子署名を含みます。b=の部分が署名です。
      • 署名(bタグ)は、ARC 関連ヘッダを連結したデータから生成されます。署名の内容は、DKIM署名の簡易版です。
      • 署名の作成方法は、RFC 8617の"5.1.1. Header Fields to Include in ARC-Seal Signatures"に記載があります。
        おおまかには、ARC-*ヘッダ(ARCセットヘッダ)の値を正規化したものに対する署名です。
        i=1のARC-*ヘッダから最新のARC-*ヘッダ(いま追加しようとしている分)までの値を全て連結したデータに対して署名されます。つまり、iの値が2以上の場合(2回目以降の署名)は、それまでのARC-*ヘッダが全て対象となります。
        ARC-*ヘッダが署名作成のためのハッシュ関数に渡される順番は、ARC-Authentication-Results、ARC-Message-Signature、 ARC-Sealです。
      • DKIM署名との違いは以下のような点です。
        • DKIMのiタグ(アドレス)でなく、i=1のようなinstance tag
        • メールのBodyを対象とした署名ではないのでbhタグ無し
        • Bodyの正規化無し
        • Relaxed正規化のみ(RFC6376, Section 3.4.2)
        • サポートされるタグは、i,a,b,d,s,t,cv
      • dタグは、AMSヘッダと同じドメイン名になるはずですが、RFC 8617では特にドメインの指定に対する要件は無いようです。
        ("ARC places no requirements on the selectors and/or domains used for the AMS header field signatures."、"ARC places no requirements on the selectors and/or domains used for the AS header field signatures.")
    • ARC-Message-Signature(AMS)ヘッダ
      • ASヘッダとは別の署名です。DKIM署名とほぼ同じ形式です。
        • DKIM-Signatureヘッダとの違いは、ヘッダ名が違う点、vタグが未定義である点、iタグの使い方が違う点、の3つです。
      • DKIMで管理されるDKIM-Signatureの内容とは関係なく、ARC単独で管理されます。
        DKIM署名と同じ鍵が使われるケースはあると思いますが、ARC認証とDKIM認証の仕組み自体は相互に影響しません。
    • ARC-Authentication-Results(AAR)ヘッダ
      • ARC署名時に存在しているメールのAuthentication-Results(AR)ヘッダの内容を、このヘッダにコピーするものです。
      • ARC署名のたびにコピーすることで、メール配送中にARヘッダが削除、改ざんされた場合にも、AARヘッダを参照することで正しい履歴を確認できます。
      • Authentication-Resultsヘッダが複数ある場合、それら全ての情報をAARに含めることになっています(MUST)。
        (参考:RFC 8617 "4.1.1. ARC-Authentication-Results (AAR)"より、"AAR MUST contain the combined authres-payload with all of the authentication results from within the participating ADMD")
        ただ、複数のARヘッダが存在する場合(i=2以降で、authserv-idの異なるARヘッダが存在する場合等)、どのようにAARヘッダに集約されるべきなのか不明でした。RFC 8617の"within the participating ADMD"という表現は、AARにコピーすべきARヘッダはARC署名ドメインと一致するauthserv-idのものだけに絞るという意図のようにも思います。またコピー対象とするARヘッダは直前のARC署名ドメイン分だけで十分かと思います。
  • ARC署名が追加されるべきタイミング
    • まず、理解しやすい極端なケースとして、メール送信元ドメインから外部にメール配送する最初のメールシステム(MTA,MSA)が最初のARC署名(i=1)を追加し、その後も最終的な受信者のメールボックスに配送されるまでの間、MTA等に中継されるごとに必ずARC署名を追加する方法が挙げられます。
      この方法は、ARC単独で配送経路上の全ての送信者や中継者を認証できます。最初のARC署名が追加されたところから、ARCの管理("chain of custody")が始まるので、送信時点からのARC署名により、送信元ドメインから受信側ドメインに届くまでのChainのつながりを検証できます。
      ARCの仕様上も問題はありません(ARC署名が増えると検証処理は重たくなりますが)。(参考:RFC 8617 "5.1.5. Sealing Is Always Safe")
    • ただ、ARCが各ドメインに広く普及しない限り、送信時点ではARC署名が追加されないケースの方が多いでしょう。
      実際、メール送信元がARC署名を追加しなくても、再配送の課題の緩和策としては機能します。再配送処理時に最初のARC署名が追加され、そこからのChainを検証できば良いという考え方です。
      (参考:RFC 8617 "4.4. Chain Validation Status"の"none"の箇所)
      • AARヘッダには、SPFDKIM、DMARCの検証結果(ARヘッダの内容)を記録できるので、最初のARC署名者(メールシステム)が、それまでの送信ドメイン認証の結果をきちんとAARヘッダに記録していれば、配送経路の途中からARCが始まったとしても、送信ドメイン認証全体としては問題ないことになります(なお、最初のARC署名者は必要に応じて、それまでの送信ドメイン認証の検証を自ら行い、ARヘッダを追加するという意味も含みます)。
      • 最初のARC署名者を信頼できるかどうかについては、メールを受信する側の判断になります。
    • ARCを有効に活用するという意味では、"信頼境界をまたぐ配送時にはARC署名を追加する"といった方針が考えられます。RFC 8617では、"Trust Boundaries(信頼境界)をまたいで認証結果を伝達する"という表現があります。
      (参考:RFC 8617 "5.1.4. Broad Ability to Seal"、"5.1.5. Sealing Is Always Safe"、"7.1. Communicate Authentication Assessment across Trust Boundaries")
    • 上記より、ARC署名が追加され得るタイミングは以下です。信頼境界をまたぐ配送時も含みます。
      • メールの送信時
        • メールを送信する時点でARC署名を追加する
        • 例:gmail.com(Gmail)やmicrosoft.com(Exchange Online)から送信されるメールはARC署名あり(2022年8月)
      • メーリングリスト(ML)のメンバへの配送時
        • MLシステムが受け取ったメールが、そのMLメンバに再配送される際に、ARC署名を追加する(DKIMの認証情報が無効となる場合があるため)
      • メール転送による転送先への配送時
        • メール転送機能が有効なメールシステムが、受け取ったメールを、転送先に再配送する際に、ARC署名を追加する(SPFの認証情報が無効となる場合があるため)
      • メールスキャンサービスの通過時
        • スパム対策システム等、メールスキャンサービスがスキャンを終えて宛先に配送する際に、ARC署名を追加する(スキャン時に加えられる変更やスキャン後の中継により、DKIMSPFの認証情報が無効となる場合があるため)
      • 多層のMTA間の配送時
        • 例えば、大規模構成におけるIPベースフィルタ層からコンテンツフィルタ層への配送の際に、ARC署名を追加する(DKIMSPFの認証情報が無効となる場合があるため)
      • あるドメイン管理元(ADMD)から別のドメイン管理元への配送時
        • "よそ"のドメインへのメール配送の際に、ARC署名を追加する(ARC署名があればメール受信者や次の中継者がChainを検証しやすい)

ARC認証により担保されること

ARCは以下の点を担保します。
DKIMの特徴に加え、ARCの特徴である認証情報が保持される仕組みが活かされます。
なおRFC 8617上の表現については、後述の"ARCにより提供できる証拠"に記載しておきます。

  • ARCは、そのChainを構成する各シーリングドメイン(各署名に対応するDNSレコードを保有するドメインの管理元)により以下の点を担保
    • 「そのメールに含まれる個々のARCセットは、それぞれのドメインの管理元から署名することを認められたシステムによって追加されたものである」(※)
    • 「それらのARCセットは、i=1~i=Nの順に追加されたものである」
    • 最新のARC署名がi=Nのとき、「それ以前のARC署名(i=1~N-1)は、ARC署名者(i=N)がメールを受信した時点で存在しており、また改ざんされていない」
  • 個々のAMSヘッダの署名(i=1~N)は、DKIMと同様に、対応するDNSレコードを保有する各ドメインの管理元により以下の点を担保
    • 「メールに署名することを認められたメール送信システム、あるいはメール中継システムが、そのメールの配送経路上に存在した」(※)
    • 最新のAMSヘッダの署名に関し、「そのメールにおいて、電子署名の範囲(hタグで指定したヘッダ、および、本文の全部もしくはlタグで指定した一部)については、署名した時点から改ざんされていない」

(※)”署名することを認められた"という表現は、検証に成功する署名を作成できるのは、DNSレコード上の公開鍵とペアになる秘密鍵を持つシステムのみであるという意味

ARC認証により担保されないこと

ARCでは担保されない範囲については、別記事にまとめるか、本記事を更新予定です。

概要としては、以下です。

  • ARCは、そのメールの配送経路上にARC署名しない送信者や中継者がいた場合、メールがそれらを経由したことを認証することはできません。ARC署名された分のみを認証可能です。
  • ARCは、メール送信時点からのメール内容(署名対象範囲)の改ざん検知を担保するものではありません。最新のARC署名分からの改ざん検知は可能です。

ARCのセキュリティに関する考慮事項

備忘用です。

(RFC 8617の"9. Security Considerations"より)

  • ARCにより提供できる証拠(A received message with a validated ARC Chain provides evidence (at instance N) that:)
    1. the sealing domain (ARC-Seal[N] d=) emitted the message with this body, (ARC検証が成功すれば最新(i=N)の署名時点から本文(※)は改ざんされていない)
    2. the authentication assessment reported in the ARC-Authentication-Results was determined upon receipt of the corresponding message at the sealing domain, and (i=N時点でのAARヘッダ内の認証結果は、そのARC署名者により決定された)
    3. the preceding ARC Chain (1..N-1) (with the validation status as reported in the cv field) existed on the message that was received and assessed.
      (以前のARC署名(i=1~N-1)は、ARC署名者が受信した時点で存在していた)
      (※) 1. については、"body"はDKIM署名の対象範囲にメール本文が含まれていることを指していると思われるが、本文すべてがDKIM署名対象となっていない場合もある(lタグ)。なお、ASヘッダとしてはbodyは対象外("4.1.3. ARC-Seal (AS)"より、"the signature of the AS header field does not cover the body of the message")
  • その他
    • ("9.3. Message Content Suspicion"より)
      ARC authenticates the identity of some email-handling actors. It does not make any assessment of their trustworthiness.(ARCは、メールを中継してきたシステム(MTA)を認証するが、それらの信頼性の評価は行わない)
      Even if all ARC-enabled ADMDs are trusted, ADMDs may have become compromised, may miss unsafe content, or may not properly authenticate messages.
    • ("9.4. Message Sealer Suspicion"より) but whether or not that Sealer is a malicious actor is out of scope of the authentication mechanism.
    • ("9.5. Replay Attacks")

用語等

ARCを定義したRFC 8617の用語についてメモしておきます。

  • ARC-participating ADMD:
    ARC対応しているADMD(管理されたAdministrative Management Domain)のこと。ドメイン管理元。
  • ARC対応のMTA(Mail Handler):
    通常、ARC検証者(Validator)、ARCシーラー(Sealer)の両方として機能する。
  • 署名と封緘: RFC 8617の"3.5. Signing vs. Sealing"を参照。
  • シーリングドメイン:  あるARCセットを追加したドメイン(ADMD)

参考URL等

ARC対応した製品やサービスに関する情報(http://arc-spec.org/)

DMARC認証の整理しておきたいポイント

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、DMARC認証についてまとめたものです。
SPFDKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

本記事の目的

  • DMARC認証の概要を理解する。
  • DMARC対応の際してのポイントを把握する。

※本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。


目次

基本

DMARCの認証対象と認証成否

  • メールのFromヘッダのドメインを認証します。
  • ヘッダFromのドメインDNSに登録されたDMARCレコードに基づいてSPFDKIMの認証結果を検証し、いずれかが成功であれば認証成功です。
    具体的には、以下のいずれかの認証が成功("Pass")すれば、DMARCとして認証成功ということです。
    • "ヘッダFromのドメインと一致するドメイン"に対するSPF認証
    • "ヘッダFromのドメインと一致するドメイン"に対するDKIM認証
      ※成功していない方が認証失敗("Pass"以外、つまり"Fail"等)であったとしても、DMARCとしては認証成功となります。DMARC自体の仕様としては、SPFDKIMの両方が成功した場合にのみDMARCとして認証成功にすることはできません。
  • DMARCレコードを保有するDNSドメインの管理元により、そのメールのヘッダFromに対して、以下のいずれか、あるいは両方を担保するものです。
    • SPF認証が成功した場合
      「そのIPアドレスが、該当ドメインエンベロープFromドメインとして使用することを許可されている」という点、および「そのエンベロープFromドメインはヘッダFromのドメインと一致している」という点
      ※DMARCではalignmentによりFromドメインエンベロープFromドメイン(RFC5321.MailFromのドメイン)と一致するSFPのみを扱う。詳細は後述のalignment modeに補足あり
    • DKIM認証が成功した場合
      「メールに署名することを認められたメール送信システム、あるいはメール中継システムが、そのメールの配送経路上に存在した」という点、および「その電子署名の中で指定されたドメインはヘッダFromのドメインと一致している」という点
      ※DMARCではalignmentにより作成者署名のDKIMのみを扱う。詳細は後述のalignment modeに補足あり
      ※”署名することを認められた"という表現は、検証に成功する署名を作成できるのは、DNSレコード上の公開鍵とペアになる秘密鍵を持つシステムのみであるという意味

認証時の動作

  • メールを受信する側が、上記の認証を行います。
  • "ヘッダFromのドメインと一致するドメイン"に対するSPFまたはDKIMの認証結果を検証することを、DMARCのalignmentと呼びます。一致するドメインのみを対象とすることで、SPF単体やDKIM単体では実現できなかったヘッダFromと紐づく認証を実現できます。
  • メールを受信する側が、ヘッダFromのドメインに対するDMARCレコードをDNS問合せた際、レコードが見つからなかった場合、そのドメインの組織ドメイン(Organizational Domain)に対するDMARCレコードをDNS問合せし直します。
    例えば、ヘッダFromが"@a.b.c.d.example.com"のメールを受信した際、"a.b.c.d.example.com"に対するDMARCレコードが見つからなかった場合、"example.com"のDMARCレコードを検索する動作になります。
    この仕様の詳細は、RFC 7489の"6.6.3. Policy Discovery"、"3.2. Organizational Domain"に記載があります。
    ちなみに、これはドメインのレベルを1つずつ減らしながら繰り返し問い合わせるDNSデボルブ(DNS devolution)とは異なる動作です。

DMARC対応に必要な設定

  • DMARC対応に必要な設定は、基本的にDNSレコード登録のみです。
  • DMARCレポートを受け取る場合にはレポートを受信するための管理者用のメールアドレスが必要です。
  • なお、DMARCはSFPとDKIMを前提としますが、実際にはどちらかを導入済みであれば、DMARCレコードの登録によりDMARC対応できます。
    基本的に、SPFDKIMの両方に対応済みであることが望ましいです。
  • 設定に際しての補足事項は別記事にまとめる予定です。

認証結果

  • DKIMの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。種類は以下の通りです。

    • DKIM(RFC 6376)では、以下が定義されています。
  • 認証結果

    • DMARCの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。全ての種類は以下の通りです。
      • DMARC(RFC 7489)では、以下が定義されています。 "SUCCESS"、"PERMFAIL"、"TEMPFAIL"が定義されています。
        • pass
        • fail
        • temperror
        • permerror
  • 認証結果は、送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダに記録されます。ARヘッダの詳細は別記事にまとめる予定です。

詳細

導入ステップや運用ポリシーに応じた調整のポイント

  • 本格的にDMARC対応するかどうかに関わらず、まず試験的にポリシー"p=none"にてDMARCレコードを公開すると良いです。"p=none"であれば、自ドメインからのメールがDMARCにより拒否されることは基本的にありません。
    DMARCレコードを公開することで、DMARCレポートを受信できるようになるので、自ドメインから送信されるメールの配送状況(送信ドメイン認証失敗の状況)を分析できます。DMARCレポートを受信するには、ruaタグ、rufタグの指定が必要です。
  • DMARC対応は、最終的にp=none以外(reject,quarantine)のポリシーで運用することで正式なものとなります。p=none以外の設定を、DMARC Enforcementと呼ぶことがあります。
  • 補足
    • DMARCは、送信ドメイン認証自体の他、ポリシー定義(p=)やレポートの機能が特徴的です。また、アラインメントモード(alignment mode)を調整することもできます。
    • ポリシー定義は、自ドメインからのメールを受信する側においてDMARC認証が失敗した際、そのメールをどのように扱って欲しいかを示すことができます。 DMARCレコード中のpタグにて指定します。
      指定可能な値は、"none"(何もせず受信)、"quarantine"(隔離)、"reject"(拒否)です。
      以下にいくつか大手メールサービスのDMARCレコードの例を記載します(2022年8月時点)。Gmailはp=none、米Yahooはp=reject、日本のYahoo(yahoo.co.jp)はp=noneです。
      • _dmarc.gmail.com. 600 IN TXT "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
      • _dmarc.yahoo.com. 1800 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"
      • _dmarc.yahoo.co.jp. 900 IN TXT "v=DMARC1; p=none; rua=mailto:ymail_dmarc_report@yahoo.co.jp"
    • DMARCレポートは、以下の2種類があります。
      • aggregate feedback
        ruaタグで指定したアドレスに送信される集約レポートであり、1日1回など、ある期間の認証結果をまとめたもの
      • message-specific failure information
        rufタグで指定したアドレスに送信される認証失敗レポート、認証失敗が発生するたびに送信される
    • アラインメントモード(alignment mode)は、DMARCレコード中のadkimタグ、aspfタグによりalignmentの厳密さを指定します。adkimタグはDKIM用のアラインメントモード、aspfタグはSPF用のアラインメントモードをそれぞれ指定します。 指定可能な値はr(relaxed mode)、s(strict mode、デフォルト)です。
      • strict mode:
        DMARCの認証対象であるヘッダFromのドメインと、SPF(もしくはDKIM)の認証対象ドメインが一致していない場合に、DMARCとしてはそのSPF(もしくはDKIM)の認証結果をもとに認証できません。完全一致している場合にのみ認証できます。
        例えば、SPF(もしくはDKIM)の認証対象ドメインが"news.example.com"、ヘッダFromのドメインが"example.com"であった場合、SPF(もしくはDKIM)が認証成功していたとしても、DMARCとしてはその認証結果をもとに認証成功になることはありません。
        SPFの認証対象ドメインエンベロープFrom(SMTPのMAIL FROMコマンド)のドメインDKIMの認証対象ドメインDKIM署名のdタグで指定されたドメインです。
      • relaxed mode:
        strict modeよりも緩和された条件です。DMARCの認証対象であるヘッダFromのドメインが、SPF(もしくはDKIM)の認証対象ドメインサブドメインであれば、DMARCとしてはそのSPF(もしくはDKIM)の認証結果をもとに認証できます。よって、完全一致していなくても認証成功する場合があります。

DKIM認証の整理しておきたいポイント

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、DKIM認証についてまとめたものです。
SPFDKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

DKIMの設定例として、別記事にPostfixとOpenDKIMの設定(図解)をまとめてあります。

本記事の目的

  • DKIM認証の概要を理解する。
  • DKIM対応の際してのポイントを把握する。

※本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。


目次

基本

DKIMの認証対象と認証成否

  • メールヘッダ(DKIM-Signatureヘッダ)にある電子署名を認証します。
  • 電子署名の中で指定されたドメインDNSに登録されたDKIMレコードに基づいてその署名を検証し、正しいものであると判断できれば認証成功です。
  • DKIMレコードを保有するDNSドメインの管理元により、「メールに署名することを認められたメール送信システム、あるいはメール中継システムが、そのメールの配送経路上に存在した」という点が担保されます。
    (”署名することを認められた"という表現は、検証に成功する署名を作成できるのは、DNSレコード上の公開鍵とペアになる秘密鍵を持つシステムのみであるという意味)
    ※なお、DKIMは、必ずしもFromドメインと一致するドメインに対する署名を検証するとは限らないので、DKIMが担保できる範囲を簡潔に表現するのは難しいように思います。RFC 6376の中では、"to claim some responsibility for a message(そのメールにいくぶんか責任を持つ/主張する)"といった表現が使われています(これは私の備忘用ですが"claim responsibility"は犯行声明を出す意味でも使われる表現)。
  • また、別の観点では、「そのメールにおいて、電子署名の範囲(hタグで指定したヘッダ、および、本文の全部もしくはlタグで指定した一部)については(署名された時点から)改ざんされていない」という点も担保されます。

認証時の動作

  • メールを受信する側が、上記の認証を行います。
  • DKIM署名の検証は、DKIM-Signatureヘッダで指定されているドメイン(dタグ)に対してDNS問合せを行い公開鍵を取得することで可能となります。
    その際のDNSクエリは、DKIM-Signatureヘッダ内のdタグ、sタグの値をもとに生成されます。
    一般的に、以下のTXTレコードをDNSに問い合わせます。
    (selector:sタグの値)._domainkey.(domain:dタグの値)
  • DKIM署名には種類が2つあります。
    基本的に作成者署名が望ましいです。なお、第三者署名によるDKIMはDMARC対応不可です。
  • 署名に使用する鍵は定期的に更新が必要です。IIJの資料によると、3か月~1年程度と記載がありますが、基本的に鍵の強度(鍵長)によると思われます。

DKIM対応に必要な設定

  • DNSレコード登録と、DKIM署名追加機能の実装が必要です(鍵の準備を含む)。設定に際しての補足事項は別記事にまとめる予定です。

認証結果

  • DKIMの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。種類は以下の通りです。
    • DKIM(RFC 6376)では、以下が定義されています。
      • SUCCESS
      • PERMFAIL
      • TEMPFAIL
    • ただし、メール配送時の認証結果を把握する上で実用的なものとしては、Authentication-Resultsヘッダ(RFC 8601)におけるDKIM認証結果("dkim=")の値として、以下が定義されています。
      • none
      • pass
      • fail
      • policy
      • neutral
      • temperror
      • permerror
  • 認証結果は、送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダに記録されます。ARヘッダの詳細は別記事にまとめる予定です。

詳細

導入ステップや運用ポリシーに応じた調整のポイント

  • DKIM自体には、SPFにおける修飾子やDMARCにおけるポリシー(p=)のような、検証基準を調整するパラメタはありません。
    よって、DKIM単独では、(送信元ドメイン側としては)試験的な段階を設けることは難しいでしょう。
  • DKIM単独でなく、SPF、DMARCも併用することで、メールを受信する側でDKIM認証が何らか失敗した場合にも、SPFやDMARCの認証結果、DMARCのポリシー(p=)と合わせて判断することが可能です。
    また、自ドメイン側としても、その際のDMARCレポートを受け取ることで状況分析が可能になります。
  • ちなみに、DKIM ADSP(RFC 5617)というものがありますが、既にIETFによって"Historic"の扱いに変更されています。今後新規に対応する必要性は無いと思われます。
    ADSPは、あるメールのDKIM署名検証が失敗した際、メールを受信した側がそのメールを実際に拒否/破棄すべきかどうかの判断を補助する情報を示す仕組みです。

SPF認証の整理しておきたいポイント

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、SPF認証についてまとめたものです。
SPFDKIM、DMARC、ARC、BIMIといった送信ドメイン認証を俯瞰的にまとめた記事はこちらです。

本記事の目的

  • SPF認証の概要を理解する。
  • SPF対応の際してのポイントを把握する。

※本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。


目次

基本

SPFの認証対象と認証成否

認証時の動作

  • メールを受信する側が、上記の認証を行います。
  • なお、エンベロープFromが<>(アドレス無し)のときは、EHLOコマンド、EHLOコマンドで指定されたドメインDNS検索に使用されます。

SPF対応に必要な設定

  • DNSレコード登録のみです。

認証結果

  • SPFの認証結果は、大きく"Pass"か、"Pass以外"("Fail"等)に分類できます。種類は以下の通りです。
    • None
    • Neutral
    • Pass
    • Fail
    • Softfail
    • TempError
    • PermError
  • 認証結果は、送信ドメイン認証において共通的に使用されるAuthentication-Results(AR)ヘッダに記録されます。ARヘッダの詳細は別記事にまとめる予定です。

詳細

導入ステップや運用ポリシーに応じた調整のポイント

  • allの修飾子(qualifier)
    • デフォルトの認証結果(all)に対する修飾子の指定において、自ドメインからのメールを受信する側のSPF認証時、明示されていないホスト(IPアドレス)からメールが送信された場合に、どの程度厳しく判定して欲しいかを示すことができます。
      修飾子は、"+"(Pass)、"-"(Fail)、"~"(Softfail)、"?"(Neutral)を使用できます。
    • 例えば、以下のようなSPFレコードがあるとします。
      v=spf1 +ip4:xxx.xxx.xxx.xxx +ip4:yyy.yyy.yyy.yyy –all
      • ドメインからのメールを送信を許可するホストのIPアドレスとして"xxx.xxx.xxx.xxx"と"yyy.yyy.yyy.yyy"が明示されています。これらに該当しないIPアドレスから送信されたメールは"–all"にマッチし、修飾子"-"によりSPF認証失敗となります。
        "–"は、メール受信者に"Fail"判定して欲しいことを示しており、"all"の扱いとして最も厳しいものです。
        その代わり、自ドメインからのメールを送信を許可すべきホストの洗い出しに漏れがあった際には、正規のメールがSPF認証失敗により届かなくなる可能性があります。
    • よって、SPF対応の初期段階等で様子を見たい場合には、"-all"でなく、"?all"や"~all"を指定する方法が考えられます。
      "?all"(Neutral)は"all"省略時のデフォルトです。送信元ドメインとして、"all"がメール送信を許可しているかどうかを表明していない、ということを示す設定ですので、"all"に該当するホストがSPF認証により受信拒否されることはありません(もちろんSPF認証以外の理由で拒否されることはあり得ます)。
    • 合わせて、DMARCレポートを受け取る設定にしておくと、自ドメインから送信されたメールに対するSPF認証結果を含む集計情報を得られるので、SPFの"all"に対する修飾子の指定をより厳しいものに変更できるかどうかを検討しやすくなります。
    • なお、修飾子の指定を省略した場合はデフォルト"+"として扱われます。

送信ドメイン認証まとめ(SPF、DKIM、DMARC、ARC)(+BIMI)

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。
本記事は、各送信ドメイン認証の俯瞰的なまとめや、導入ステップの例を記載するものです。SPFDKIM、DMARC、ARCが対象です。参考までに関連技術としてBIMIも記載します。

本記事の目的

  • 送信ドメイン認証技術を俯瞰的に理解する。
  • 各送信ドメイン認証技術の導入ステップを検討する。

関連記事


目次

基本

背景

送信ドメイン認証は、重要なインフラの1つである電子メールを安心して使う上で必須の技術です。
メールの受信者にとっては"スパム対策"のような役割ですが、メールの送信元ドメインの所有者にとっては"第三者が自分のドメインを詐称してメールを送信できないようにするもの(※)"です。つまり、"自ドメインを守る"ことにつながります。
これは、自ドメイン所有者(=自組織)の信頼性の確保にもつながります。逆に、詐称メールを簡単に送られてしまうようなドメインの所有者は社会的信頼を失いかねません。
(※)ここで"送信できないようにする"というのは、送信できたとしても中継者側や受信者側が不正なメールだと気付くことができるという意味も含みます。

各送信ドメイン認証の一覧

本記事とその関連記事で説明する送信ドメイン認証技術を表にまとめます。

(2022年8月時点)

SPF     DKIM DMARC  ARC  (参考)
BIMI
RFC等      RFC 7208 RFC 6376 RFC 7489 RFC 8617
(Experimental)
Internet Draft
認証対象 メール送信元ホストのIPアドレス メールヘッダ(DKIM-Signature)中の電子署名 ヘッダFromドメインに対するSPF/DKIM結果 メールヘッダ(ARC-*)中の電子署名 -
認証対象ドメイン エンベロープFromドメイン DKIM署名で指定のドメイン ヘッダFromドメイン ARC署名で指定のドメイン -
DNSレコード登録 必要 必要 必要 必要
(DKIMと兼用可)
必要
メール送信元の設定(※1) - 必要 - 任意 必要
専用メールヘッダ有無(※2) - あり - あり あり
(省略可)
その他 - 改ざん検知 ポリシー(p=)、
レポート
改ざん検知 ロゴ画像表示
  • ※1
    送信元ドメインからメールを配送するメール配送システムにおいて、固有の設定が必要かどうか
    (例:自ドメインから他ドメイン宛にメールを配送するMTAとして動作するPostfixが送信ドメイン認証を使用する場合、SFPであればPostfix内に固有の設定は基本的に不要だが、DKIMであれば固有の設定が必要(OpenDKIMの設定等))

  • ※2
    DKIMの場合はDKIM-Signatureヘッダ、ARCの場合はARC-*(3種類)ヘッダ、BIMIであればBIMI-Selectorヘッダ
    (別途、検証結果を格納するAuthentication-Resultsヘッダは共通的に使用される)

送信ドメイン認証に対応していない場合の影響

メールを送信するドメイン

あるドメインにおいて、何も送信ドメイン認証に対応していない場合、以下のような事象が生じる可能性があります。

  • 三者がそのドメインを詐称してメールを送信した際、メールを受け取る中継者側や受信者側のメールシステムが、ドメイン詐称を検知できず、詐称メールが最終的な宛先まで正規メールと同様に届いてしまう
  • 三者がそのドメインを詐称して送信したメールが通過するメールスキャンシステム(スパム対策等)において不正メールの可能性が高いと判定された場合、そのドメインに対するレピュテーションが低下し、正規メールの送受信にも支障が出る

重要なメールをやり取りする際にこのような事象が発生すると、そのドメインを所有する組織の社会的な信頼性低下にもつながります。

メールを受信する側

メールを受信する側において、何も送信ドメイン認証の検証を行わない場合、以下のような事象が生じる可能性があります。

  • ドメインを詐称したメールを正規メールと同様に受け取ってしまう
  • メールを受信する側のメールシステムが、メーリングリストや自動転送といった再配送機能を使用している場合、ドメインを詐称したメールを受け取った際に正規メールと同様に再配送してしまう
    (また、メールを受信する側であっても、自ドメインとして送信ドメイン認証に対応していないと、再配送の際、さらに前述の"メールを送信するドメイン側"と同様の影響が生じる可能性がある)

メール受信時の詐称メール対策が不十分になるだけでなく、再配送を行っているとさらに影響が大きくなる場合があります。

詳細

送信ドメイン認証の導入ステップ例

メールを送信するドメイン側の導入ステップ例

送信ドメイン認証を適用するためのステップやオプションについて例示します。
あくまで例ですので、ステップや優先度は環境によって異なる場合があります。

  • ステップ0:メール送信環境の整理
    • まず、送信ドメイン認証を適用しづらい環境になっていないかを確認します。
      • (当たり前ですが)送信ドメイン認証を適用したい自ドメインを所有しているか
        • ドメイン:自組織がレコード管理でき(権威を持つ)、また自組織の活動のために使用するDNSドメインのこと
      • 送信ドメイン認証を適用したいメールは、すべて送信元が自ドメインのものであるか(以降、"自ドメインから送信されるメール")
        (他ドメインを送信元ドメインとして使用するようなイレギュラーな運用が無いこと)
      • ドメインから送信されるメールを、宛先ドメインに対して配送する役割を担うホスト(利用しているサーバやサービス)をすべて把握できているか
      • ドメインから送信されるメールは、すべてヘッダFrom、エンベロープFromの両方が同じドメインであるか (メール配信サービス等、外部に送信業務を委託したメール等も注意)
        この2つのFromのドメインが異なる場合、同じにできるか(すぐ同じにできない場合、以下の各ステップと並行して対応)
  • ステップ1:SPF
    • まずSPF対応するケースが多いです。
    • SPF対応することにより、何も送信ドメイン認証に対応していない場合に比べ、多少でも"自ドメインを守る"ことができます。
      メールの中継者や受信者が送信元ドメインを詐称したメールを受け取った際、その詐称方法がSFP認証を失敗させるものであれば、不正なメールであると判断できるようになります。
    • SPF対応に必要な設定は、DNSレコード登録のみです。
  • ステップ2:DKIM、DMARC
    • 複数の送信ドメイン認証を組み合わせることにより、より広範なパターンの詐称メール対策が可能になります。
    • 本格的にDMARC対応するかどうかに関わらず、まず試験的にポリシー"p=none"にてDMARCレコードを公開し、DMARCレポートを受信することで、自ドメインから送信されるメールの配送状況(送信ドメイン認証失敗の状況)を分析することも有益です。
    • DMARC対応の前提として、SPFDKIMのいずれか、もしくは両方に対応している必要性があります(両方に対応していることが望ましいです)。
    • なお、自ドメインから送信されるメールが、再配送されるケース(indirect mail flow:メーリングリストに投稿されたり、別ドメインのメールアドレス宛に転送されるケース)が多い場合、DKIM、DMARC(SPFも含む)の認証が失敗する可能性があるため、別途ARC対応や利用者への案内等を検討すべきです。
    • DKIM対応に必要な設定は、DNSレコード登録の他、DKIM署名追加機能の実装(鍵の準備を含む)が必要です。
    • DMARC対応に必要な設定は、基本的にDNSレコード登録のみですが、DMARCレポートを受け取る場合にはレポートを受信するための管理者用のメールアドレスが必要です。
  • オプション1:ARC
    • DMARC(DKIMSPF)がメールの再配送に対応できない部分を補完するためにARCを使用できます。自ドメインから送信されるメールの中継者や再配送の環境に応じ、ARC対応を検討すると良いでしょう。
    • ARC対応に必要な設定は、DNSレコード登録の他、ARC署名追加機能の実装が必要です(鍵の準備を含む)。DNSレコードや鍵は、DKIMで使用するものと兼ねることができます。
  • オプション2:BIMI
    • ドメインからのメールが詐称されていないことを受信者に分かりやすく画像で示すため、あるいはブランド確保等のため、BIMIを利用できます。
    • また、BIMI対応の前提として、DMARCポリシーをp=none以外(reject/quarantine)で運用している必要性があります。なお、p=quarantine、かつ、pctタグがある場合は、pct=100である必要性があります。
    • BIMI対応に必要な設定等は、基本的にロゴ画像の準備とDNSレコードの登録なのですが、そのために多くの準備が必要です。商標登録済みのロゴ画像や、ロゴ画像を配置するWebサーバ、さらにロゴ画像が正当なものであることを証明するためのVMC証明書の購入等です。

ドメインのメール運用状況によって、"自ドメインを守る"ために効果的なステップやオプションは異なります。まず運用状況を整理することが重要です。

メールを受信する側の導入ステップ例

メールを受信する側では、基本的に不正メール対策の一部として、受信したメールを送信ドメイン認証に沿って検証します。ほとんどのメール受信者が何らかの不正メール対策を行っているはずですので、本記事ではごく簡単に例示します。
あくまで例ですので、ステップや優先度は環境によって異なる場合があります。

  • ステップ0:メール受信環境の整理
    • まず、不正メール対策を適用しづらい環境になっていないかを確認します。
      • ドメインから受信したメールが配送される経路 (利用しているサーバやサービス)を把握できているか
        (受信したメールを最初にスキャンするゲートウェイや、その後メールを格納するメールボックス(スプール)等)
      • メールを受信した際、メーリングリストや自動転送といった再配送機能により自ドメイン以外にメールを再配送する機能を使用しているか
        (使用している場合、単に"受信する側"でなく、"送信する側"にもなり得るため、前述のメールを送信するドメイン側の導入ステップ例に沿って対策が必要)
      • 詐称メール対策(あるいは不正メール対策全般)のポリシーとして、判定の厳しさを決定できるか
        • 例えば、多少誤判定(FP)を許容してでもより多くの不正メールを拒否/隔離するのか、あるいは誤判定(FP)が無いことを重視するのか、等
        • 目標とするセキュリティレベルを設定の上、利用者のリテラシーや業務への影響度を考慮しつつ総合的な判断が必要
  • ステップ1:各送信ドメイン認証の検証設定
    • 一般的には、組織外から受信するメールをスキャンするゲートウェイにおいて、送信ドメイン認証の検証を行います。以下のような点を検討する必要性があります。
      • 検証したい送信ドメイン認証の種類(SPFDKIM、DMARC、ARC)
      • 検証結果に対するアクション(拒否、隔離、何もせず受信、等)
      • 複数の送信ドメイン認証の検証を行う際、検証成功(pass)と検証失敗(fail)の結果が混在している場合のアクション
        (DMARC認証が失敗してもARC検証が成功すれば、ARCの結果を優先して配送許可する等。ただし、複雑な条件を設定できるかどうかは使用しているメールシステムの機能による)
      • DMARC検証を行う場合、DMARCレポートの送信有無
  • オプション1:BIMI
    • 受信者のWebメールやアプリケーション側でBIMIをサポートしていれば、BIMIによるロゴ画像を表示できます。
      • 例えば、GmailWebメールを利用している場合、既にBIMIのロゴ画像を表示できる環境になっています。
    • その他の環境におけるBIMI対応状況については別記事に記載予定です。

メールを"送信しない"ドメイン側の設定例

メールを送信しないドメインであっても、それが分かるよう送信ドメイン認証用のDNSレコードを登録しておくと良いです。
三者から送信元として自ドメインを詐称したメールが送信された際、受信する側でそのメールがより確実に拒否されるようにするためです。自ドメインの悪用を防ぐための設定です。

例えば、以下のようなDNSレコード設定です。

  • SPF用のTXTレコード: “v=spf1 -all”
    そのドメインを送信元とするメールは全てSPF fail

  • DKIM用のTXTレコード: v=DKIM1; p=
    公開鍵無し(p=の値無し)のため、そのドメインを指定したDKIM署名を検証してもpassになることは無い

  • DMARC用のTXTレコード: v=DMARC1; p=reject
    SPFDKIMがどちらもpassにならないため、DMARC認証は必ずfail
    拒否ポリシー(p=reject)により、メールを受信する側としては拒否して良いメールであることを判断しやすい
    (上記に加え、sp=reject; adkim=s; aspf=sを追加で記載すると、より厳しい設定となる(DMARC認証がpassになりにくい))

  • BIMI用のTXTレコード: v=BIMI1; l=; a=;
    BIMIは送信ドメイン認証そのものではありませんが、BIMI対応しないこと(辞退)を明示的に示す場合のレコード記載方法です。

参考URLを記載しておきます。

補足として、メールを"受信しない"場合は、さらに以下のようなDNSレコードを設定します。

  • MXレコード: 0 .
    優先度0、該当するホスト無し(".") ※Null MX
    そのドメインのメールを受信するためのホストは無し

本記事はここまです。
個々の送信ドメイン認証に関する運用や設計の参考情報は別記事にまとめる予定です。