DKIM レコード：鍵更新、整合と診断

開封率が下がったら、件名や測定の制約だけでなく DNS、特にDKIM レコードも確認します。ただし、開封率の低下だけで DKIM の問題とは判断できません。

SPF がエンベロープドメインの接続 IP を検査するのに対し、DKIM、DomainKeys Identified Mailは署名対象データに封印を付けるような仕組みです。暗号学的な検証を可能にしますが、個人の身元や受信トレイまで全データが変わらないことを保証しません。2024 年以降、Google と Yahoo は対象となる大量送信者への要件を強化しています。有効な DKIM がないと拒否や振り分けに影響する場合がありますが、全メールが必ず見えなくなるわけではありません。

一人で起業する場合は、例として十分間ほどの設定作業になるかもしれませんが、所要時間の保証ではありません。500 ドメインを扱う MSP では、鍵の更新、セレクター、DNS 構文の確認は継続的な仕事で、金曜の夜 9 時に問題が発覚する場合もあります。

本ガイドはDKIM レコードの DNS 上の仕組み、TXT の一文字列あたり 255 バイトの制約、ESP の緑の表示が実際の送信状態と合わない場合の診断を扱います。

DKIM レコードとは

DKIM レコードは通常 TXT として公開鍵を DNS に置きます。受信側はそれで署名ドメインの署名と対象データを検証します。表示上の From や作者個人が正当であることを自動的に証明するものではありません。

公開先は selector._domainkey.yourdomain.com で、selectorは署名者が選ぶ鍵の識別名です。省略例は次のとおりです。

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

v=DKIM1はバージョン、k=rsaはアルゴリズム、p=は Base64 の公開鍵です。この断片は不完全で、そのまま配備できません。対応する秘密鍵は署名側で安全に保管し、DNS に公開しません。DKIM レコード作成ガイドで各項目と全体の手順を確認できます。

DKIM の署名対象

DKIM は単なる安全性のチェックではありません。署名対象を署名ドメインに結び付け、指定規則で完全性を検証します。個人の身元や全バイトの不変性を証明するわけではありません。

署名サービスは通常 From、Subject、Date、To、Message-IDなどの選択したヘッダーと本文を正規化し、通常 SHA-256 でハッシュを計算します。From の署名は必須で、他の列挙項目は例です。秘密鍵で対応するデータに署名し、DKIM-Signatureヘッダーに入れて送ります。

Gmail、Outlook などの受信側は、次のように確認します。

DKIM-Signatureからドメインとセレクターを読み取る。
DNS の selector._domainkey.yourdomain.comで公開鍵を取得する。
公開鍵で暗号学的な署名を検証する。メール内容の復号ではない。
受信した署名対象から指定されたハッシュを再計算する。
値とその他の有効性条件を確認する。成功すれば DKIM pass、問題があれば DKIM fail になる場合がある。

成功で確認できるのは二つの限定された性質です。公開鍵に対する署名の真正性と、正規化や署名範囲に従った完全性です。正規化前のバイト列の一部が変わっても許容される場合があり、全ヘッダーが署名されるわけでもありません。有効な鍵がこの検証を可能にします。仕組みはRFC 6376にあり、実装の適合性を管理者と確認する際にも役立ちます。

転送と DKIM の役割

顧客の経営者が請求書を企業の連絡先に送り、相手が個人 Gmail に転送する例を考えます。元のエンベロープが維持され、転送 IP がその SPF で許可されていなければ SPF は失敗する場合があります。しかし DMARC が失敗するのは、成功して整合した SPF も、有効で整合した DKIM 署名もない場合です。その後の拒否や振り分けは受信側によります。

署名対象が正規化後も有効で、適切な公開鍵を取得できれば、DKIM は転送後も検証できる場合があります。最終受信側は別の接続 IP から届いた元の署名を確認できます。中間の経路だけで必ず失敗するわけではありませんが、その変更が影響することはあります。

重要な経路を SPF だけに頼らせないでください。適切な DKIM とSPF 設定を用意し、メールの SPF レコードで基礎を確認します。DMARC は二つの認証経路のどちらかが整合して成功すればよく、両方の同時成功を要求しません。

TrekMail の対応する転送では SRS が利用できる場合があります。エンベロープを転送者のドメインへ書き換え、その SPF を確認可能にしますが、元の From への SPF 整合は復元しません。管理型と SMTP 持ち込みそれぞれの実経路で、現行の DKIM 対応と署名を確認してください。全送信が既定で署名されるとは決めつけないでください。

複数の DKIM 鍵を扱うセレクター

DKIM セレクターは受信側に取得すべき公開鍵を示します。誤りはよくある原因ですが、設定失敗の大多数がこれに起因するという検証済みの統計ではありません。

SPF は検査する DNS 名に一つの SPF 方針を公開します。DKIM は selector._domainkey.yourdomain.comのように異なるセレクター名で複数の鍵を使えます。必要なら十のセレクターを同時に使う例もありますが、事業者の制限と実際の構成を確認します。無制限のプラン機能を意味しません。

複数のセレクターが役立つ理由

業務メールに Google Workspace、ニュースレターに Mailchimp を使うなら、通常は別々の鍵とセレクターが適切です。秘密鍵の共有は技術的に可能でも、アクセス範囲と漏えい時の影響を広げます。各サービスを分けて設定します。

Google Workspace：例として googleを使い、google._domainkey.yourdomain.comに公開します。
Mailchimp：k1やk2、公開先 k1._domainkey.yourdomain.comは例です。実際の割り当てを確認します。
TrekMail：tm1とtm1._domainkey.yourdomain.comは例です。実際の案内に従って TXT または CNAME を使います。

マーケティングサービスが侵害されたら、その k1だけを取り消し、Google の鍵を意図的には変えずに対応できます。ただし、無停止や評価の完全な分離は保証されません。セレクターのガイドで構文、命名、ESP が指定した値の調べ方を確認してください。

典型的な設定ミス

DNS 画面がドメインを自動で追加すると、google._domainkey.yourdomain.comのつもりが google._domainkey.yourdomain.com.yourdomain.comになることがあります。誤った名前のレコードが存在しても、正しい名前は NXDOMAINかもしれません。以前の ESP 確認では分からない場合もあります。DNS 状態の確認を参考に、対象名を直接調べます。即座の診断を保証するものではありません。

鍵長と更新方針

鍵の強度は DKIM の重要な要素です。要件は変わるので、五年前の構成も現行規則で確認します。

2048 ビット RSA 鍵を検討する

1024 ビット RSA は長く使われてきました。Google は公開された最低要件を適用し、対応していれば 2048 ビットを推奨します。Yahoo の要件は別途確認してください。古い cPanel や Postfix の 1024 ビット設定、例えば 2019 年より前の構成は点検対象ですが、古いだけで自動的に無効ではありません。

512 ビット鍵は現行要件に不十分です。dkim=perm_failと「weak key」や「policy」は手掛かりになりますが、具体的な理由を確認します。新しい 2048 ビット鍵を用意して管理された切り替えを行い、配送中のメールを考えず旧公開鍵を削除しないでください。現行規則はGoogle の送信者ガイドラインにあります。

更新の頻度

年次更新は運用方針の例で、全環境で必須の最低周期ではありません。侵害、秘密管理の誤り、過剰なアクセスで秘密鍵が漏れたら、速やかな封じ込め、取り消しと置き換えが必要です。攻撃者は鍵が受け入れられている間に署名できるのであり、取り消し後も永遠に使える、あるいはメールドメイン評価が壊れるまで必ず気付かないという意味ではありません。

秘密鍵は重要な秘密情報として扱います。本番で五年も確認しないことを既定の方針にしないでください。アクセス保護、更新、事故対応を合わせて考えます。

TXT の 255 バイト制約への対応

2048 ビットへ移行すると長さが問題になる場合があります。2048 ビット公開鍵の Base64 はおよそ 400 文字です。DNS TXT の一文字列は 255 バイトまでなので、画面によって自動分割、拒否、誤処理などがあり得ます。大多数が無通知で切り詰めるとは言えません。

長い値は同じ TXT レコード内の引用符付き文字列に分けられます。RFC 6376 はそれらを連結して検証する方法を定めます。同じセレクターに複数の独立した鍵 TXT を置くこととは異なります。

不完全な単一文字列の例で、実際の鍵として配備できません。

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

二つの文字列に分ける考え方です。省略部分を完全な実鍵に置き換えてください。

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

入力構文は DNS 事業者によります。括弧はゾーンファイルなどの記法で、画面が別の入力を求める場合があります。一般的な事業者の DNS 設定では Cloudflare、Route 53、GoDaddy などを扱います。一つの TXT として公開されたことを確認します。

対応する CNAME 委任では長い鍵を自分の DNS 画面に入れる作業を減らせます。例の名前は 255 文字より短いですが、CNAME には別の DNS 制約があり、同名の TXT と共存できません。対象 TXT、キャッシュ、鍵の一致、古い署名への配慮は残ります。同じセレクターで鍵だけ置き換えると古い署名の検証が失敗し得るので、セレクターを重ねた計画的な更新が必要です。

設定の確認手順

公開後は「Verified」だけに頼りません。画面とリゾルバーのキャッシュが残り、実際の名前や内容が変わっている場合があります。権威 DNS、他の必要なリゾルバー、実際のメールを確認します。一つの DNS 問い合わせだけで全体は証明できません。

手順 1：公開名を問い合わせる

Linux/macOS は次のコマンドを使えます。Windows はコマンドプロンプトで nslookupを使います。

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

selectorを実際のセレクター、yourdomain.comを自分のドメインに置き換えます。

取得した鍵データを確認します。v=DKIM1はバージョンを示せますが、鍵 TXT では省略可能です。NXDOMAINはそのリゾルバーで名前が存在しない応答です。NXDOMAINならセレクター、完全な名前、権威 DNS とキャッシュを調べます。30 分後の再確認は例であり、世界全体での反映期限ではありません。

手順 2：鍵の内容を検証する

名前が存在しても失敗するなら、実際の応答を調べます。

dig txt selector._domainkey.yourdomain.com +short

二つの点を確認します。

切り詰め：Base64 が 200 文字未満で、想定が 2048 ビット鍵なら不完全な可能性があります。ただし長さだけで確定せず、連結内容とデコードした公開鍵形式を検証します。
データの変更：画面は Base64 の改行、空白、バックスラッシュを異なる形で表示や処理する場合があります。許可された空白が必ず失敗原因になるわけではありません。デコードした鍵を信頼できる元データと比較し、表示上のエスケープと実際の文字を区別します。

手順 3：テスト送信とヘッダー確認

管理する Gmail に送り、三点メニューから「メッセージのソースを表示」を開きます。信頼できる受信システムが追加した Authentication-Resultsを確認します。

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=passは該当署名の成功で、DMARC 整合や受信トレイ入りの保証ではありません。fail、neutral、perm_fail、temperrorは実装と理由を合わせて読みます。名前は実装で異なり、Neutral が常に設定不良とは限りません。全体の設定ガイドと初期設定チェックリストで関連する認証も確認します。

DKIM 失敗の三つの例

レコードもセレクターも正しく、DNS が利用可能に見えても、署名が失敗することがあります。実際のデータと処理順序を調べ、「動くはず」で終わらせないでください。

詳しい失敗のガイドでは他の結果も扱います。次の三例は実務上の例であり、本番の頻度順位を証明するものではありません。

例 1：「Body Hash Did Not Verify」

本文ハッシュの不一致はメール到達性に影響する場合があります。受信した署名対象の本文が正規化後に記録されたハッシュと一致しない状態です。ヘッダー側の暗号学的署名が成功したことや、原因が送信者だけにあることを自動では示しません。

考えられる原因：

外部送信者の警告：ゲートウェイが「外部からのメール：注意してください」などを追加する場合があります。DKIM 検査前に対象本文を変えると失敗する可能性があるので、Microsoft 365 のメールフロー規則などの順序を確認します。
法的な免責文：ゲートウェイが 15 行の免責文を付けます。その前に署名すると本文ハッシュを変える場合があります。必要なら最後の管理下の変更後にゲートウェイで署名します。
安全対策の URL 書き換え：Mimecast、Proofpoint、Defender for Office 365 は google.comをprotect.mimecast.com/s/...のように変える場合があります。対象本文の変更が検証を損なうことはありますが、正規化と署名範囲も確認します。

自分が管理するインフラでの最後の変更後に署名します。しかし受信側の後の変更は、それだけでは防げません。変更前に検査するか、具体的なフローを別途調整します。TrekMail の署名位置も実経路で確認し、受信内容が常に同一になる保証とは捉えないでください。詳しくは送信エラーの診断を参照します。

例 2：整合の問題

信頼できるヘッダーには次があるかもしれません。

dkim=pass (signature was valid)

DKIM は成功しても DMARC は失敗する場合があります。原因の一つはDKIM が整合しないことで、他の有効な整合経路もない場合です。迷惑メール入りが自動で決まるわけではありません。

DMARC は署名の有効性に加え、d=のドメインをHeader Fromと照合します。Strict は完全一致、relaxed は対応する組織ドメインの一致を認めます。

例：

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

署名はsendgrid.net に対して有効です。受信側は送信ドメインとその DMARC 方針に基づき、yourcompany.comへの整合を確認します。sendgrid.net != yourcompany.comはこの署名が整合しない例です。成功して整合した SPF も、別の有効で整合した DKIM もない場合に限って DMARC は失敗します。

ESP が対応するドメイン認証や独自署名では、適切なDKIM 鍵を使い、d=にyourcompany.comをsendgrid.netの代わりに設定できる場合があります。提供機能と値は事業者によります。説明とDMARC 整合を理解し、事業者署名だけで問題と決めつけないでください。

例 3：古い鍵や弱い鍵

古い鍵が恒久的な DKIM エラーを起こす場合があります。dkim=perm_failと「policy」「weak key」は、例えば 512 または 768 ビット鍵を示す可能性がありますが、長さを断定できません。こうした長さは現在の関連要件に不十分です。受信側の診断を確認し、恒久的な DKIM 結果と恒久的な SMTP 拒否を同一視しないでください。

新しい 2048 ビット鍵と新セレクターを準備し、公開と検証後に署名を切り替えます。事故で緊急の取り消しが必要な場合を除き、古いメールの検証用に旧公開鍵を残します。以下のローカル生成と DKIM 生成ガイドを参考にしてください。

安全な鍵生成

DKIM には鍵のペアが必要です。検索で見つけたサイトが画面に鍵を表示しても、まず生成場所と秘密鍵へのアクセスを確認します。

ブラウザー表示だけで漏えいと定義されるわけではなく、検証できるローカル生成もあります。しかし未知のサーバー側サービスは秘密を保存や公開するかもしれません。十分な信頼なしに本番鍵を任せないでください。攻撃者が署名できるのは鍵が受け入れられる間であり、取り消し後も永遠に使える、必ず兆候がないという意味ではありません。

生成方法を比較する

方法	安全性の評価	対象	注意点
事業者管理：TrekMail、Google、Microsoft	適切に保護されていれば有用	事業者と管理モデルを信頼する利用者	保存とアクセス保護を確認。全事業者に HSM があるとは仮定しない。DNS は公開鍵だけを使う。
OpenSSL でローカル生成	安全なシステムと鍵管理なら適切	自社 Postfix、Exim の運用者	権限、バックアップ、転送経路を管理する手動作業。
Web の DKIM 生成ツール	未知のサービスは使い捨てテストに限る	分離した開発環境とテストドメイン	本番秘密鍵を未知のサービスに渡さず、ローカルブラウザー生成は別途評価する。

安全に管理する自社サーバーなら OpenSSL を利用できます。

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

秘密鍵ファイルを適切な権限で保護し、DNS や管理外の転送へ出さないでください。最後のコマンドは公開鍵の PEM を表示するだけで、囲みの行を自動で除去しません。DKIM 用には公開鍵データを正しく整えます。「確認」のために秘密鍵をメールで送る要求は、重大なソーシャルエンジニアリングの警告です。

創業者や代理店などは、適切に保護する事業者へ鍵生成を任せる選択もできます。「管理型」という名前だけでなく、対策と責任を確認します。

手動管理と自動化

更新時には各 DKIM レコードの維持作業が見えます。公開した鍵は定期的に確認します。年次の手順例は次のとおりです。

ドメインごとの手動年次更新例

新しい RSA 鍵とセレクター、例えば s2026を生成する。
s2026._domainkey.yourdomain.comに新公開鍵を置く。
48 時間は例の余裕。切り替え前に実公開と関連キャッシュを確認する。
署名サービスを新秘密鍵へ管理された手順で切り替え、テストする。
例では両方の公開セレクターを 7 日残す。実際はキュー、配送中のメールと検証期限で調整する。
適切な移行期間後、または必要な安全上の取り消しで旧公開セレクターを削除する。
安全な切り替え後、保存や事故対応の方針に従って旧秘密鍵を廃棄する。

例は 7 手順で、50 ドメインなら年間 350 作業です。実際の負担と誤りへの耐性はツールによります。手順 5 を省くと古いメールの検証に影響し得ます。手順 6 では必要な移行期間と、不必要に長い信頼を区別します。

方式	各ドメインの年次作業	人為的な誤り	100+ ドメインに適するか	費用
手動の自社 Postfix	7 手順の例とテスト	確認とツールによる	適切な自動化で可能	インフラと運用時間
ESP の独自ドメイン認証	初期設定と事業者の更新手順	ESP の仕組みによる	ESP ツールによる	事業者と契約による
TrekMail の CNAME 方式	委任を設定し継続確認する	ローカル変更は減るがゼロではない	1,000+ は現行プランと運用条件で確認	現行の含まれる機能を確認

一ドメインなら手動管理が適する場合もあります。50 ドメインでは一覧、監視、自動化が更新漏れを防ぐ助けになります。なければ金曜の診断作業につながるかもしれませんが、必然ではありません。

TrekMail の DKIM 管理

TrekMail は複数ドメインを扱う運用者、例えば五つのサイドプロジェクトを持つ創業者や 800 顧客ドメインの MSP を対象にしています。実際の DKIM 機能を現行説明で確認します。

CNAME による更新

対応する CNAME 設定で、ウィザードは次のような例を示す場合があります。実際に割り当てられた名前と対象を使います。

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

委任によって自分の DNS 変更を減らせる場合があります。対象は事業者が管理しても、同じセレクターで鍵だけ更新すると古い署名が失敗し得ます。重複期間を設けたセレクターと、キャッシュや配送中の署名を考えた更新が必要です。CNAME が変わらなくても無停止や確認不要の保証ではありません。80 ドメインでは集中管理が役立つ場合がありますが、全確認が消えるわけではありません。

原文は Pro を月額 $8、100 ドメインとして、年間 700 の手動作業と比較します。現行価格、上限、実際の作業負担を確認し、保証された削減とは考えないでください。

DNS 設定ウィザード

利用できるウィザードは MX、SPF、DKIM、DMARC をまとめて準備し確認する助けになります。送信元一覧、実値、DNS 公開、キャッシュ、実際のメールは引き続き検証します。確認表示も一律の保証ではありません。必須 DNS レコードを参照してください。

ユーザー課金だけではない固定モデル

原文は Starter を月額 $3.50、50 ドメイン、各ドメイン 100 ユーザー、Pro を月額 $8、100 ドメイン、各ドメイン 300 ユーザー、Agency を 1,000+ ドメインとします。こうした過去の条件と共用ストレージモデルは現行プランで確認します。多くのアカウントを作れることは無制限や追加料金なしの保証ではありません。

DKIM の提供、設定、署名経路は現行プランと SMTP モデルによります。固定料金から全経路の認証が同じと推測せず、機能範囲を確認します。

自社管理と TrekMail の比較

	自社管理	現行範囲に応じた TrekMail
最初の DKIM 設定	鍵生成、Postfix 設定、DNS 公開、テスト	ドメイン追加、適切な委任の公開、実署名の確認
年次の鍵更新	7 手順の手動例	対応する事業者更新と残る確認作業
新ドメイン追加	適切な設定と検証を行う	割り当てた CNAME または TXT を公開し確認する
DKIM 失敗の診断	ログ、DNS、必要なら SSH	DNS 画面と説明を実ヘッダーに照合する
100 ドメインの費用	インフラと運用時間	過去の例は月額 $8。現行条件を確認する

まとめ

適切なDKIM レコードは 2025 年以降も安定したメール構成の重要な部分で、対象送信者には要件として適用されます。しかし欠落で全メールが DMARC に失敗したり、全転送で評価が失われたりするとは限りません。要件とすべての有効な整合経路を確認します。

対応する場合は適切な 2048 ビット RSA 鍵、正しいセレクター、完全な TXT と表示上の From への整合から始めます。計画的な更新、適切な DMARC 方針とGoogle Postmaster Toolsの利用可能なデータを合わせます。データが不完全だったり、反映が遅れたりする場合があります。

SPF、DKIM、DMARC の比較で関係と準備順序を確認できます。現在の問題には迷惑メールへの振り分けを改善するガイドの順序を、確認できた原因に合わせて使います。

多数のドメインの手動管理は負担と誤りの機会を増やします。名前、切り詰め、更新の誤りは対象経路に影響し得ます。CNAME 管理はローカル作業を減らせても、すべての失敗をなくしません。プランを見るか無料サービスを確認してください。10 ドメイン、クレジットカード不要は原文の条件で、現行条件の確認が必要です。