DKIMにおけるTXTとCNAMEの主な違いとベストプラクティス
著者: Milena Baghdasaryan
翻訳: 古川 綾乃
この記事はPowerDMARCのブログ記事 DKIM in TXT vs. CNAME – Key Differences & Best Practicesの翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
DKIMは、公開鍵暗号（公開鍵／秘密鍵）を用いて送信メールに署名するメール認証標準です。
DKIMレコードを参照することで、受信したメールが、DKIMキーに紐づくドメインから送信されたものであるかを判別できます。
これにより、メールが配送途中で改竄されていないか、また受信側がメールの正当性を判断するうえでの根拠になります。
DKIMレコードは通常、DNSにTXTレコードとして設定します。
一方で、一部のメール配信サービスでは、CNAME（Canonical Name）レコードを使って参照先をプロバイダ側に切り替え、プロバイダが管理するTXTレコードを参照させる方式もあります。
TXTを使用すべきか、それともCNAMEによる委任を使うべきかは、いくつかの要因によって異なります。
本記事ではそれぞれの違いとどちらを選ぶべきかの考え方を整理します。
主なポイント
- DKIMは、送信メールが改竄されていないことを検証するためのメール認証標準です。
- DKIMレコードは本来TXTレコードとして設定されます。
- ただし一部のプロバイダでは、CNAMEによる委任を使い、プロバイダ側で管理されているTXTレコードを参照させる方式を提供しています。
- これらの方式には、それぞれ利点と制約があります。
- どちらを選ぶかは、「自社でしっかり管理したいか」それとも「運用を楽にしたいか」で決まります。
- 一般的な落とし穴としては、セレクタ形式の誤り、同一セレクタでのTXTとCNAMEの混在、鍵ローテーション時のTTL遅延などがあります。
DKIMレコードの仕組み
ここでは、DKIMレコードがどのような要素で構成されているのかを見ていきます。
DKIMレコードの構成要素
DKIMレコードは、主に以下の要素で構成されます。
- DKIMセレクタ
- 公開鍵
- アルゴリズム
なお、DKIMレコードはPowerDMARCのオンラインツールを使って生成することもできます。
- DKIMセレクタ
- DKIMセレクタは、受信側のメールサーバが送信者の公開鍵を特定し、署名を検証するために使用されます。
複数のDKIM公開鍵が存在する場合でも、どの鍵を検証に使うべきかをセレクタで判別できます。
セレクタは、署名されたメールのDKIM-Signatureヘッダ内に記載されており、「s=」パラメータとして確認できます。 - 公開鍵
- DKIMの公開鍵は通常、ドメインのDNSにTXTレコードとして公開されますが、運用によってはプロバイダ側の鍵を参照するCNAMEとして設定する場合もあります。
この公開鍵は、送信者が秘密鍵で作成した署名を受信側サーバが検証するために使われ、配送途中でメールが改竄されていないか確認できます。
公開鍵の設定方法は、自社で鍵を用意してTXTで直接設定する、プロバイダの公開鍵を参照するようCNAMEで委任する、の2通りです。 - アルゴリズム
- ハッシュ化に使用されるアルゴリズムはDNSレコードではなく、DKIM-Signatureヘッダの「a=」タグで指定されます。
代表的なDKIM署名アルゴリズムは以下の通りです。- rsa-sha256（推奨・最も一般的）
- rsa-sha1（セキュリティが弱いため非推奨）
- DNSでの設定場所と書き方
- DKIMレコードは通常、セミコロンで区切られた複数のタグと値のペアを含むTXTレコードとして設定されます。
v=DKIM1; k=rsa; p=PUBLIC_KEY- v=DKIM1：DKIMのバージョンを指定します
- k=rsa：「k」は鍵の種類を示します（一般的にはRSAが使われます）
- p=PUBLIC_KEY：署名検証に使用する公開鍵そのものです
selector._domainkey.example.com
ここで、selectorはDKIM鍵の識別子（セレクタ）であり、example.comは対象のドメインです。
方法1 ― DKIMをTXTレコードとして設定する場合
この方法では、DKIMの公開鍵を selector._domainkey.example.com にTXTレコードとして設定します。
送信メールは秘密鍵で署名され、受信側のメールサーバはDNS上の公開鍵を参照して署名を検証します。
メリット
- 管理をすべて自社で完結できる
- DKIMをTXTレコードとして設定することで、DKIM鍵とDNSを自社で完全に管理できます。
- 第三者に依存しない
- この方式では外部プロバイダに依存する必要がありません。
鍵情報を自社で保持できるため、プライバシーやセキュリティの向上が期待できます。
デメリット
- 鍵ローテーションが手動になる
- 鍵の更新を自分で行う必要があり、技術に詳しくないユーザにとっては難しい場合があります。
- 設定ミスのリスクが高い
- 自分で設定するため、セキュリティ低下につながる設定ミスが起きやすくなります。
ミスを防ぐために、無料のDKIMチェックツールを使って設定を確認することが推奨されます。
方法2 ― CNAME委任によるDKIM設定
TXT方式とは異なり、この方法ではDKIMの公開鍵を自ドメインのDNSに直接書き込みません。
代わりに、selector._domainkey.example.comにCNAMEレコードを設定し、メールサービスプロバイダ（ESP）が管理するDKIMレコードを参照させます。
受信側のメールサーバがDKIM鍵を検索すると、DNSはCNAMEの参照先をたどり、最終的にESP側のDNSにあるTXTレコードを参照します。
そこに、公開鍵を含む実際のTXTレコードがホストされています。
SendGrid、Mailchimp、Amazon SESなどの主要プロバイダがこの方法が使われています。
メリット
- 鍵ローテーションが自動
- 手動で更新する必要がなく、鍵のローテーションはプロバイダ側で自動的に行われます。
- 設定が簡単>
- 初心者や、複数ドメインを運用している場合でも扱いやすい方法です。
手間を増やさずに、継続的な管理をスムーズに行えます。
デメリット
- 管理の自由度が下がる
- 設定が簡単な反面、DKIM鍵やDNSの管理性・可視性は制限されます。
- CNAMEの制約がある
- CNAMEの参照が多段になると、DNSの参照回数制限に引っかかったり、名前解決が遅くなったりすることがあります。
一部のプロバイダでは特定の形式が求められたり、CNAME委任をサポートしていなかったりします。
そのため、プロバイダが指定する形式になっていないと、DKIMが正しく動作しない場合があります。
TXTとCNAMEのどちらを使用すべきか
DKIMをTXTで設定するかCNAMEで設定するかを決める際には、以下の一般的な指針を参考にしてください。
- TXTを使用すべき場合
-
- 自社でメールサーバをホスティングしており、技術的な知識がある場合です。
- DKIMとDNSを完全に管理したい場合です。
- 鍵の管理やローテーションを自分で行いたい場合です。
- CNAMEを使用すべき場合
-
- Mailchimp、SES、SendGridなどのESPを利用している場合です。
- DKIM管理を自動化したい場合です。
- 手動設定を行うための時間や技術的な知識が不足している場合です。
- 同一セレクタでのTXTとCNAMEの混在について
-
- DNSでは、同一のドメイン名、つまり同じDKIMセレクタに対して、TXTレコードとCNAMEレコードを同時に設定することはできません。(例：同じDKIMセレクタ)
- セレクタごとに使用できるレコードタイプは、TXTまたはCNAMEのいずれか一方のみです。
- 手動での管理を行いたい場合はTXTを選択し、ESPに委任する場合はCNAMEを選択してください。
実際の使用例
ここでは、DKIMをTXTで設定した例とCNAMEで設定した例を、それぞれ簡潔に説明します。
- DKIM TXTの例
google._domainkey.example.com. IN TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG…”
このレコードは、指定されたセレクタとドメインの下に、DKIMの公開鍵をDNS内に直接保存しています。- DKIM CNAMEの例
em1234._domainkey.example.com. IN CNAME em1234.example.dkim.emailsvc.com.
このレコードは、第三者プロバイダがホスト型DKIMレコードを参照することで、DKIM鍵の検索を委任しています。
まとめ
DKIMをTXTで設定するかCNAMEで設定するかの選択は、難しく感じられるかもしれません。
どちらの方法も問題なく機能し、一般的に広く利用されているため、最終的な判断は多くの場合あなた自身に委ねられます。
この選択は、利便性よりも完全で直接的な管理を重視するのか、あるいはその逆なのかといった優先事項によって決まることが多いです。
最終的にどの方法を選ぶにしても、現在のDKIM設定が正しく反映されているか、必ず確認してください。
これにより、セキュリティ上の抜け漏れを防ぎ、通信の安全性を最高レベルに保つことができます。