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

2022年8月17日2024年1月19日

当サイトには広告を含みます。

当サイトでは、広告掲載ポリシーに沿って広告を掲載しています。

"オススメ" として紹介している商品やサービスは、個人的にそう思えたものだけです。

共感、興味をもっていただけるものがあればご利用ください。

タブレットが気になる

高解像 (FHD+) な8インチタブレットを比較

クレカ積立10月買付分まで10万円×5%還元

【10万Pチャレンジャー求む】プラチナプリファード初年度フル活用

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

本記事では、各送信ドメイン認証の簡易的なまとめや、各記事へのリンクを記載します。

SPF、DKIM、DMARC、ARCが対象です。参考までに関連技術としてBIMIも挙げます。

基本

背景

送信ドメイン認証は、電子メールを安心して使う上で重要な技術です。

メールの受信者にとっては “迷惑メール対策” の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であれば固有の設定が必要 (Milterの設定等) )

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

送信ドメイン認証関連記事

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

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

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

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

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

メールを受信する側

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

ドメインを詐称したメールを正規メールと同様に受け取り、それらのメールが不正な目的 (フィッシングやウィルス等) によるものであった場合には被害が生じてしまう
メールを受信する側のメールシステムが、メーリングリストや自動転送といった再配送機能を使用している場合 (つまり中継者である場合)、ドメインを詐称したメールを受け取った際に正規メールと同様に再配送してしまう
(つまり、メールを受信する側であっても、再配送により、前述の “メールを送信するドメイン側” と同様の事象が生じる可能性がある)

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

詳細

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

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

送信ドメイン認証を適用するためのステップやオプションについて例示します。

あくまで2022年くらいの時点でリストアップしてみた例なので、状況に応じ調整しないといけません。実際、2024年には以下のようなルール強化もありますので、時勢に応じた対応が必要です。

あわせて読みたい

2024年、Gmailと米Yahooによる “No Auth, No Entry” 等 2023年10月、Google (Gmail) と米Yahoo (※) から、メール送信者向けのルール強化についての発表がありました。それら2社が提供するメールサービスに対して送信した電子…

ステップ０：メール送信環境の整理
- まず、送信ドメイン認証を適用しづらい環境になっていないかを確認します。
  - (当たり前ですが) 送信ドメイン認証を適用したい自ドメインを所有しているか
    - 自ドメイン：自組織がレコード管理でき (権威を持つ)、また自組織の活動のために使用するDNSドメインのこと
  - 送信ドメイン認証を適用したいメールは、すべて送信元が自ドメインのものであるか (以降、”自ドメインから送信されるメール”)
    - 他ドメインを送信元ドメインとして使用するようなイレギュラーな運用が無いか
  - 自ドメインから送信されるメールを、宛先ドメインに対して配送する役割を担うサーバやサービスをすべて把握できているか
  - 自ドメインから送信されるメールは、すべてヘッダFrom、エンベロープFromの両方が同じドメインであるか (メール配信サービス等、外部に送信業務を委託したメール等も注意)
    この2つのFromのドメインが異なる場合、同じにできるか (すぐ同じにできない場合、以下の各ステップと並行して対応できるか)
ステップ１：SPF
- まずSPF対応するケースが多いです (参考1、参考2)。
- 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 対応しないこと (辞退) を明示的に示す場合のレコード記載方法です。