Gmail や Google Postmaster Tools の認証エラーをきっかけにDKIM レコード生成ツールを探しているなら、まず基本設定を確認しましょう。独自ドメインのメール作成ガイドでは、MX、SPF、DKIM、DMARC と配信に影響する DNS の間違いを解説しています。
ウェブツールで説明が不足しがちな点があります。DKIM には、DNS に公開する公開鍵と、署名システムで保管する秘密鍵が必要です。サイトのサーバーで生成すれば、サイトが秘密鍵にアクセスできます。検証済みの実装がブラウザー内だけで生成する場合は異なりますが、未確認の実装を信用すべきではありません。秘密鍵はドメインの署名に使うもので、表示上の From の個人としての身元を証明しません。
このガイドでは、2025-2026 年のDKIM レコード生成ツールの実用的な使い方として、自前のメールサーバーで OpenSSL を使う方法と、TrekMail、Amazon SES、SendGrid、Mailgun、Google Workspace など実際の送信プロバイダーの指示に従う方法を紹介します。
DKIM レコード生成ツールとは
DKIM レコード生成ツールは DomainKeys Identified Mail に使う DNS データを準備します。RSA 鍵ペアを生成して公開鍵を TXT に登録する方法や、対応するプロバイダーの場合は、別の場所に公開された鍵へ CNAME で委任する方法があります。
DKIM は秘密鍵で送信メールに署名します。受信サーバーは DNS から対応する公開鍵を取得し、正規化ルールに従って署名対象データの署名を検証します。検証するのはドメインの署名であり、表示上の差出人の身元ではありません。
RFC 8301 は RSA 署名に rsa-sha256 を要求し、RSA 鍵長を最低 1024 ビット、推奨を少なくとも 2048 ビットとしています。そのため、適切なDKIM レコード生成ツールでは RSA 2048 を基本とし、1024 を目標にしないことが重要です。これは RSA への要件であり、ほかの対応 DKIM アルゴリズムを排除するものではありません。
未確認のウェブ生成ツールのリスク
公開サイトを使う際は、秘密鍵がローカルで生成されるのか、サービスに渡るのかを確認する必要があります。実装を検証できなければ、最初の手軽さがドメイン署名の長期的なリスクにつながる可能性があります。
DKIM は DNS の書式を整えるだけの作業ではありません。秘密鍵は本番の認証情報と同様に保護し、署名システムに保管します。外部サイトが生成、記録、保存した場合、理論上はその鍵で後からドメインの署名を生成できます。
公開鍵は DNS に、秘密鍵は署名システムに。ウェブフォームが両方を提供するなら、生成場所と秘密鍵の送信有無を確認してください。
どのDKIM レコード生成ツールでも、秘密鍵がどこで生成され、誰がアクセスできたかを確かめましょう。サイトの実装を確認できないなら、生成された鍵を本番で使うのは避けます。
OpenSSL をローカルで使う
自分の端末や署名サーバー上の OpenSSL は、ウェブのDKIM レコード生成ツールより管理しやすい選択肢です。外部サイトへ秘密鍵を渡す機会を減らせますが、端末と鍵ファイルを保護する必要はあります。
Postfix、Exim、Exchange、OpenDKIM などを自分で運用する場合に適した方法です。ローカルで鍵を生成し、秘密鍵を署名ホストに配置して、公開鍵だけを DNS に登録します。
2048 ビットの RSA 鍵ペアを生成します。
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.keypublic.key の構造は次のとおりです。省略された鍵は書式を示す例で、実際には使えません。
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr...
-----END PUBLIC KEY-----続いて内容を整えます。
BEGIN PUBLIC KEYとEND PUBLIC KEYの行を削除します。- すべての改行を削除します。
- DKIM タグを付けます。
手動の TXT レコードは通常、次の形になります。省略された例ではなく、自分の完全な公開鍵を使ってください。
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."鍵だけでは足りません。適切なDKIM レコード生成ツールは有効なレコードを出力します。v=DKIM1 は省略可能ですが、記載する場合は先頭に置く必要があります。p= は必須です。s=email や t=s などの任意タグもありますが、基本設定では通常不要です。
DNS の 255 オクテット制限
DNS 管理画面の長さ制限で、DKIM レコード生成ツールの出力が正しく保存されない場合があります。2048 ビットの RSA 公開鍵は長いため、画面によっては TXT 値を同じレコード内の引用符付き文字列に分割する必要があります。
古い管理画面では、長い値が拒否されたり一部しか保存されなかったりします。その結果、permerror、鍵の書式エラー、セレクターがあるのに DKIM の問題表示が出るといった事態が起こり得ます。
完全な TXT 値を直接扱えない場合は、同じ TXT リソースレコード内で複数の引用符付き文字列に分けます。次の例は構文の説明用で、有効な鍵ではありません。
default._domainkey.example.com. IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArFirstPart"
"SecondPartOfTheSamePublicKey"
)検証するアプリケーションが文字列を連結して論理的な値として扱います。リゾルバーの出力では分割されたまま表示される場合があります。これは通常の TXT の扱いです。役立つDKIM レコード生成ツールは、管理画面の入力規則と必要な分割方法を説明します。
プロバイダーの設定で鍵の自己管理を減らす
多くの企業では、DKIM レコード生成ツールを直接管理する必要はなく、送信プロバイダーが秘密鍵を管理します。一部は CNAME と自動ローテーションを提供しますが、TXT や追加手順が必要なサービスもあります。半年ごとの DNS 更新が不要かどうかも、実際の手順を確認してください。
TrekMail、Amazon SES、Google Workspace、SendGrid、Mailgun では、実際の送信サービスの指示を使います。CNAME 委任ならセレクター CNAME を公開し、プロバイダーが参照先のホスト名に DKIM TXT を公開します。TXT が提示された場合は、その TXT を使います。
| 項目 | 自己管理 | プロバイダー管理 |
|---|---|---|
| 鍵の作成 | RSA 鍵を手動で作成して保管 | プロバイダーが管理 |
| DNS レコード | 長い TXT 値 | 指定される場合はセレクターへの CNAME |
| ローテーション | 計画して手動で実施 | プロバイダーの手順に従う |
| 障害の原因 | 構文の誤り、切り詰め、古い鍵 | DNS の誤り、レコード不足、送信設定 |
| 適した環境 | 自分で運用する MTA | ホスト型メールや SMTP サービス |
TrekMail では DNS 確認を含む設定フローを利用できます。ただし、TXT か CNAME かは実際の送信設定に従い、一律に決めないでください。ドメイン追加時はドメインの追加にある最新の指示から始めます。
設定は送信経路によって変わります。Nano は持ち込み SMTP を使い、対象の有料プランでは管理型 SMTP を利用できる場合があります。価格の目安として Starter は月額 $3.50 からと案内されています。有料プランは 14 日間の試用を提供する場合があり、クレジットカードが必要です。Nano はその試用を使わず、カード不要の選択肢として提供されています。最新の条件をご確認ください。
TrekMail ユーザーのDKIM レコード生成ツールの選択は、実際の送信経路に依存します。
- TrekMail の管理型 SMTP が署名する場合は、ダッシュボードの DNS レコードを使います。
- 持ち込み SMTP のリレープロバイダーは、設定されている場合に署名します。そのプロバイダーが実際に要求する DKIM レコードを公開します。
- CNAME セレクターが提示されたら、それを使います。一般的なブログの TXT 説明だけを理由に変換しないでください。
転送、エイリアス、実際のメールボックスを選ぶ際は、ドメインのメールエイリアスとメールボックスの違い、メールエイリアス転送をご覧ください。実際に送信するシステムが変われば、必要な DKIM 設定も変わります。
セレクターを公開する場所
DKIM レコード生成ツールのレコードはドメインのルート用ではありません。公開鍵は default._domainkey、google._domainkey、tm1._domainkey などのセレクターホスト名で検索されます。
DNS 画面には相対名を求めるものと完全なホスト名を求めるものがあります。ゾーン名を自動追加する画面に完全な名前を入れると、default._domainkey.example.com.example.com のように重複する場合があります。誤った名前では受信側が必要な鍵を取得できません。
よく使われる相対名の例です。
default._domainkey
selector1._domainkey
tm1._domainkey顧客ドメインが多いと、このようなミスも積み重なります。代理店には個別の修正だけでなく、再利用できる DNS の手順が重要です。複数ドメインのメールホスティングでは、多数のドメインでの運用をさらに説明しています。
DKIM レコード生成ツールの結果を検証する
ダッシュボードの正常表示に加えて、DNS を直接確認します。DKIM レコード生成ツールの結果は dig でセレクターを照会し、応答を読み取って確認できます。
まず直接検索します。
dig txt default._domainkey.example.com +shortレコードが取得できれば、DKIM 値または引用符付きの TXT 文字列が表示されます。DNS 更新後は公開リゾルバーへの照会も追加できます。
dig txt default._domainkey.example.com @8.8.8.8 +short次の点を確認します。
- 応答がない場合: セレクター、ホスト名、DNS キャッシュ、照会エラーを調べます。空の応答だけでは原因は確定しません。
- 一部しか表示されないように見える場合: すべての TXT 文字列と保存値を比べ、実際に切り詰められているか確認します。
- 同じセレクターに矛盾する複数の DKIM TXT がある場合: 整理してから再検証します。
- DNS は正しいが署名が失敗する場合: ヘッダーを調べ、送信側のセレクターと秘密鍵の対応を確認します。
Gmail の問題が続く場合は、Google の最新の一括送信者向け SPF、DKIM、DMARC 要件を確認します。DKIM の問題が制限につながる場合はありますが、SPF が成功しアライメントを満たせば DMARC が必ず失敗するわけではありません。現在の運用要件は Google のメール送信者ガイドライン FAQをご覧ください。
TrekMail ユーザーも実際の送信経路を確認しましょう。IMAP と SMTP の設定リファレンスでは、Nano の持ち込み SMTP と、対象の有料プランの TrekMail SMTP を説明しています。DNS が正しくても迷惑メールになる場合は、メールが迷惑メールに入る場合の手順を進めます。
まとめ: メール構成に合う DKIM 設定を選ぶ
適切なDKIM レコード生成ツールはメール構成に合ったものです。自前のサーバーではローカル生成を検討し、ホスト型サービスでは提示された TXT または委任レコードを使い、鍵の切り替え方法を確認します。
自分で MTA を運用する場合はローカルの OpenSSL を使い、秘密鍵を本番の認証情報と同様に保護します。TrekMail、SES などのサービスでは実際の指示に従い、警告を消すだけのために未確認のウェブ鍵を貼り付けないでください。
まとまった認証設定と分かりやすい検証は、手作業のミスを減らせる可能性があります。複数ブランド、顧客ドメイン、進行中の移行がある場合には特に有用です。環境を構築中なら、まずドメインのメールを Gmail に転送するを読み、その後でTrekMail の料金を比較しましょう。
DKIM レコード生成ツールは、仕組みを理解できる設定工程であるべきです。重要な鍵の生成をブラックボックスに任せないようにします。
