TXTとCNAMEにおけるDKIM - 主な違いとベストプラクティス

by

最終更新日:
5 読了時間:5分
TXTとCNAMEにおけるDKIM - 主な違いとベストプラクティス

DKIMは、公開鍵/秘密鍵暗号を利用して電子メールメッセージに署名する電子メール認証規格です。DKIMレコードは、受信メールが本当にDKIMキーが関連付けられたドメインから送信されたかどうかを確認するのに役立ちます。その結果、DKIMレコードは、電子メールが転送中に操作されたかどうかを確認し、開いても安全かどうかを確認することができます。

DKIMはTXT(テキスト)またはCNAME(Canonical Name)DNSレコードとしてDNSに存在します。TXTとCNAMEのどちらを使うべきかは、多くの要因に依存します。

主なポイント

  • DKIMは、偽造された電子メールの送信者アドレスを識別するために設計された電子メール認証規格です。
  • DKIMレコードは常にTXTレコードです。しかし、プロバイダによっては、CNAME委任を使用して、そのサーバでホストされているTXTレコードにあなたのドメインを指定します。
  • これらの方法にはそれぞれ利点と限界があります。 
  • どちらを選ぶべきかは、コントロールとセキュリティーを優先するか、それとも手軽さと利便性を優先するかによって決ます。 
  • よくある落とし穴は、間違ったセレクタフォーマット、同じセレクタにTXT/CNAMEが混在していること、キー回転中のTTL遅延などです。

DKIMレコードパブリッシングを理解する

DKIMレコードの構成について説明しましょう。 

DKIMレコードには何があるのか?

DKIMレコードには、セレクタ、公開鍵、アルゴリズムが含まれます。あなたは DKIMレコードを生成するをPowerDMARCのオンラインツールで生成することができます。

DKIMセレクタ

DKIMセレクタは、受信者のメールサーバーが送信者の公開鍵を見つけて検証できるようにします。複数のDKIM公開鍵の中から、どのDKIM公開鍵を検証に使うかを特定するのに役立ちます。各署名済みメールのDKIM-Signatureヘッダーにあります。s=」パラメータです。

公開鍵

DKIM公開鍵は、TXTレコード(またはプロバイダの鍵を指すCNAME)としてドメインのDNSに公開されます。これは受信サーバーが送信者の秘密鍵を使って作成されたメッセージのハッシュを検証するために使われ、メールの完全性と真正性を保証します。

電子メールを送信する組織から提供されるキーは、TXTレコードとしてDNSゾーンに直接挿入されます。あるいは、プロバイダのDNSでキーを指すCNAMEになります。

アルゴリズム

ハッシュに使われるアルゴリズムは a=タグで定義される(DNSレコードではない)。サポートされている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 署名の検証に使われる実際の公開鍵です。

以下はその例です: セレクタ._domainkey.example.com


ここで、"selector "はDKIMキーの一意な識別子で、example.comはあなたのドメインです。

方法1 - TXTレコードとしてのDKIM

この方法では、DKIM公開鍵はDNSのTXTレコードとしてselector._domainkey.example.comの場所に公開されます。送信メールは秘密鍵で署名され、受信サーバーはDNSの公開鍵を使って署名を検証します。

長所

  • 完全なコントロール: DKIMをTXTレコードとして使用すると、DKIMキーとDNSを完全に制御できます。
  • サードパーティに依存しない:この方法を使用する場合、サードパーティプロバイダーに依存する必要はありません。データの所有者はあなた自身なので、プライバシーとセキュリティが強化されます。

短所

  • 手動キーローテーション:技術者でないユーザーにとっては厄介なことです。
  • 設定ミスのリスクが高い:DIYで設定すると、メールのセキュリティを弱めるエラーの可能性が高まります。当社の 無料DKIMチェッカーをご利用ください。

方法2 - CNAME委任によるDKIM

この方法は、最初の方法とはまったく異なる機能です。DKIM公開鍵を直接公開する代わりに、メールサービスプロバイダ(ESP)のDKIMレコードを指すCNAMEレコードをselector._domainkey.example.comに作成します。 

受信サーバがあなたのDKIM鍵を調べると、DNSクエリはCNAMEを辿ってESPのDNSに到達します。ここで公開鍵の実際のTXTレコードがホストされます。SendGrid、Mailchimp、Amazon SESのような主要なプロバイダーはこれを使用しています。 

長所

  • 自動キー回転:この方法では、手動での更新は必要なく、キーのローテーションは自動的に行われます。
  • 設定が簡単:この方法は、初心者や複数のドメインを管理する場合に適しています。重い作業をすることなく、シームレスな継続管理が可能です。

短所

  • 可視性が低い:セットアップが簡単な分、DKIMキーやDNSの制御や洞察が制限されます。
  • CNAMEの制限: 深いネストや連鎖したCNAMEはDNS解決の限界にぶつかったり、パフォーマンスの問題を引き起こす可能性があります。プロバイダによっては特定のフォーマットを要求したり、CNAME委任をサポートしないものもあり、それに従わないとDKIMを壊す可能性があります。

TXTとCNAME - どちらを使うべきか?

DKIMをTXTで使うかCNAMEで使うかを決定する場合、以下の一般的なアドバイスに従うべきです。 

TXTを使用する

  • 電子メールをセルフホストしており、技術的な専門知識がある。
  • DKIMとDNSを完全にコントロールしたい。
  • 自分でキーを管理し、ローテートさせることを好む。

注:場合によっては、プロバイダーが直接TXT入力を要求することがあり、この方法はオプションではありません。 

CNAMEを使用する

  • あなたはMailchimp、SES、SendGridのようなESPを使用しています。
  • 自動化されたDKIM管理を希望する。
  • 手動で設定する時間や技術的な専門知識がない。

同じセレクタにTXT/CNAMEを混在させる

DNSは同じドメイン名(つまり同じDKIMセレクタ)にTXTとCNAMEレコードの両方を持つことを許可していません。セレクタごとに1つのレコードタイプ(TXTまたはCNAME)だけを使用する。手動で制御する場合はTXTを、ESPに委任する場合はCNAMEを選択してください。

実例

TXT対CNAMEでのDKIMの例をお探しでしたら、簡潔な説明とともに、それぞれのDKIMの例をご覧ください。 

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.eメールvc.com。

このレコードは、サードパーティプロバイダーがホストしているDKIMレコードを指すことで、DKIMキーのルックアップをサードパーティプロバイダーに委譲します。

まとめ 

TXTのDKIMとCNAMEの選択は難しいように見えるかもしれません。どちらの方法も問題なく動作し、どちらも一般的に使用されている。あなたの選択は、利便性よりも完全で直接的な制御を優先するか、あるいはその逆を優先するかによって決まることが多いでしょう。 

最終的な選択が何であれ、常に現在のDKIM設定を監査し、コンプライアンスを確認してください。これにより、セキュリティギャップを防ぎ、通信の安全性を最高レベルに保つことができます!

CTA