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

概要

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証(Sender Domain Authentication)。

本記事は、各送信ドメイン認証の俯瞰的なまとめや、導入ステップの例を記載するものです。SPF、DKIM、DMARC、ARCが対象です。参考までに関連技術としてBIMIも記載します。

本記事の目的

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

関連記事

送信ドメイン認証全般
- 送信ドメイン認証まとめ(SPF、DKIM、DMARC、ARC)(+BIMI)　※本記事
- 送信ドメイン認証のベストプラクティス文書 (M3AAWG)
- 2024年、Gmailと米Yahooによる "No Auth, No Entry" 等
個々の送信ドメイン認証に関する運用や設計の参考情報
送信ドメイン認証で使用されるAuthentication-Resultsヘッダまとめ　(機会があれば作成予定)
送信ドメイン認証に関する設定や構成に関する補足

概要
基本
詳細
- 送信ドメイン認証の導入ステップ例
まとめ

基本

背景

送信ドメイン認証は、重要なインフラの1つである電子メールを安心して使う上で必須の技術です。

メールの受信者にとっては"迷惑メール対策"の1つのような役割にもなりますが、メールの送信元ドメインの所有者にとっては"第三者が自分のドメインを詐称してメールを送信できないようにするもの(※)"です。つまり、"自ドメインを守る"ことにつながります。

これは、自ドメイン所有者(=自組織)の信頼性の確保にもつながります。逆に、詐称メールを簡単に送られてしまうようなドメインの所有者は社会的信頼を失いかねません。
(※)ここで"送信できないようにする"というのは、送信できたとしても中継者側や受信者側が不正なメールだと気付き、適切に拒否等の対処ができるという意味も含みます。

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

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

(2022年8月時点)

	SPF	DKIM	DMARC	ARC	(参考) BIMI
RFC等	RFC 7208 (Proposed Standard)	RFC 6376 (Internet Standard)	RFC 7489 (Informational)	RFC 8617 (Experimental)	(Internet Draft)
認証対象	メール送信元ホストのIPアドレス	メールヘッダ(DKIM-Signature)中の電子署名	ヘッダFromドメインに対するSPF / DKIM結果	メールヘッダ(ARC-*)中の電子署名	-
認証対象ドメイン	エンベロープFromドメイン	DKIM署名で指定のドメイン	ヘッダFromドメイン (SFP/DKIMとのAlignment)	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ヘッダは共通的に使用される)

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

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

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

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

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

メールを受信する側

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

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

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

詳細

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

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

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

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

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

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

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

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