DKIM 設定は、独自ドメインの送信環境を整えるうえで重要です。鍵の欠落、破損、切り詰め、署名ドメインの誤りは、認証結果や受信トレイへの到達に影響し得ます。このガイドでは、鍵の生成、DNS レコードの公開、コマンドラインでの確認、正常表示の後でも DMARC を失敗させるアライメントの問題を扱います。
MX、SPF、メールボックス、クライアント設定を含む全体の構成は、自分のドメインでメールを作成する方法から確認してください。プラットフォームを選ぶ段階なら、ビジネスメールのガイドが全体像を説明しています。
DKIM の失敗は、多くの場合、暗号技術そのものではありません。DNS のコピー間違い、管理画面によるドメインの二重追加、2048 ビット鍵の破損、配信事業者が自社ドメインで署名するといった設定が原因です。見当違いの調査に時間を費やさないため、再現できる手順を使います。
DKIM 設定が実際に行うこと
DKIM では公開鍵を DNS に公開し、メールサーバーが対応する秘密鍵でメッセージに署名します。受信側は署名を検証し、署名ドメインが責任を持つことと、署名対象の重要なヘッダーや本文が転送中に変わっていないかを確認します。
DKIM は非対称暗号を使います。送信システムが秘密鍵を保持し、DNS が公開鍵を提供します。送信されるメールには DKIM-Signature ヘッダーが付き、署名ドメイン（d=）とセレクター（s=）が示されます。受信サーバーはセレクターを DNS で調べ、内容に対して署名を検証します。仕組みはRFC 6376で定義されています。
Google は 2024 年二月から、一括送信者の要件を厳しくしました。こうした送信者には SPF と DKIM の両方が必要で、少なくとも一方が表示上の From ドメインと一致し、DMARC アライメントを満たす必要があります。最新の表現は Google の送信者ガイドライン FAQで確認してください。
つまり、有効な署名でも目的を満たすとは限りません。DKIM の不具合やアライメント不足は、DMARC の問題や迷惑メールへの振り分けに関係する可能性があります。
DNS を編集する前に確認すること
適切な DKIM 設定は、実際に署名するシステムを特定するところから始まります。移行、転送の変更、プロバイダーの切り替えでは特に見落としやすい点です。DKIM レコードを生成または取得する場所は、送信経路によって決まります。
まず、このドメインの送信を誰が行うか確認します。
- Google Workspace なら、Google Admin で DKIM 鍵を生成します。
- Microsoft 365 なら、そのサービスで DKIM を有効にします。
- SendGrid、Mailgun、Amazon SES なら、そのプロバイダーでドメイン認証を設定します。
- TrekMail 管理の SMTP なら、TrekMail に表示された DKIM 値を使います。
- TrekMail がメールボックスを扱い、送信は外部 SMTP なら、SMTP プロバイダーの署名手順に従い、必要に応じて TrekMail の SMTP を設定します。
TrekMail では両方の経路が紹介されています。Nano は BYO SMTP を使い、有料プランでは管理された SMTP を利用できると説明されています。Bring Your Own SMTPの文書には SES、SendGrid、Mailgun の例があります。到達性のトラブルシューティングでは、管理された SMTP が独自ドメインの DKIM 鍵で署名するとされています。署名が有効かつ整合したままなら、転送やリレー後の DMARC に役立つ場合があります。最新のプラン内容は確認してください。
例として、メールボックスは TrekMail にあり、送信が SendGrid を経由するなら、署名するのは SendGrid です。TrekMail にメールを保存しても、SendGrid の DKIM が自動的に設定されるわけではありません。
最初の原則は、実際に署名するシステムで鍵を生成することです。別の場所で生成した鍵は、DNS に存在しても送信に使われないことがあります。
DKIM のレコード形式: TXT と CNAME
一般的には、公開鍵を含む TXT レコードを公開します。一部のプロバイダーでは、ホストされている鍵を参照する一つ以上の CNAME レコードを要求します。どちらも利用でき、重要なのは送信者から指定された値を正確に使うことです。
従来の TXT 型 DKIM の公開先:
selector._domainkey.example.com値の例:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...管理されたサービスが CNAME を使うのは、利用者が DNS を編集し直さずにプロバイダーが鍵をローテーションできるためです。TXT は直接管理できますが、必要な鍵の更新も自分で担当します。
| 方式 | 公開するもの | 適した用途 | 主なリスク |
|---|---|---|---|
| TXT | DNS 内の公開鍵全体 | Google Workspace、多くの自己管理や直接接続の構成 | 長い鍵の切り詰めや貼り付け間違い |
| CNAME | プロバイダーの DKIM レコードへの別名 | 管理された基盤や簡単な鍵のローテーション | 参照先の誤り、必要な複数レコードの不足 |
注意したいのはホスト欄です。ドメインが example.com、セレクターが k1 なら、通常のホスト名は次のとおりです。
k1._domainkey次の形式ではありません。
k1._domainkey.example.com多くの DNS 管理画面はドメインを自動で追加します。その画面に完全な名前を入力すると、k1._domainkey.example.com.example.com になる場合があります。受信サーバーが探す位置にレコードがなくなります。
TrekMail の必要な DNS レコードも参考になります。一部の DNS プロバイダーが DKIM TXT を引用符付きの部分に分ける必要がある点も説明されています。
DNS で DKIM を設定する手順
実務の流れは、セレクターの取得、レコードの公開、DNS 更新の待機、正確な応答の確認、必要なら署名の有効化です。検証を省くと、正しく設定されたか確認できません。
次の手順を使ってください。
- 送信プロバイダーで DKIM レコードを生成または表示します。
- セレクターを正確にコピーし、プロバイダーが認めない限り変更しません。
selector._domainkeyに DNS レコードを作成します。- TXT 全体または CNAME の参照先を指定どおり貼り付けます。
- 別の要件がなければ TTL を 3600 に設定します。
- DNS 更新を待ちます。
- 本番送信前に
digまたはnslookupで確認します。 - プロバイダーに最終的な有効化スイッチがあれば、署名を有効にします。
TXT 型の設定例:
; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."CNAME 型の設定例:
; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.DNS 更新は早く見える場合もありますが、すべての場所で即時に反映されるわけではありません。TrekMail の文書にある約 5 から 15 分はよくある目安で、保証ではありません。状態が変わらなければ、書式、重複レコード、ホスト名に加え、TTL とキャッシュを確認してください。
DKIM と 2048 ビット鍵の問題
送信プロバイダーと DNS ホストが対応していれば、現代の DKIM には 2048 ビットの RSA 鍵を使うのが適切です。暗号学的に強い一方で長いため、古い DNS 管理画面で問題になることがあります。切り詰められた鍵は、存在しているように見えるのに検証が失敗するため、特に紛らわしいものです。
Google の文書でも、対応していれば 2048 ビットを推奨し、長いレコードを扱えないホスト向けに 1024 ビットを代替として示しています。問題は DNS 自体より、その管理画面にあることが少なくありません。
2048 ビットの DKIM 設定で起きやすい問題:
- 管理画面が通知せず値を短くする。
- 引用符付きの文字列分割が必要なのに説明しない。
- Base64 鍵の途中に改行を入れる。
- プロバイダーの想定と異なる方法で文字をエスケープする。
分割した文字列が必要なら、次のように公開します。
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"受信側が引用符付きの部分を結合するのは正常です。ただし、実際の鍵の中に空白を追加してはいけません。余分な一文字でも検証できなくなる可能性があります。
多数のドメインを管理すると、この違いが運用負担になります。あるレジストラは長い TXT を正しく扱い、別のものは扱えず、さらに別のものは書き換えます。そのため、代理店はレジストラを標準化したり、可能ならプロバイダーがホストする CNAME 鍵を使ったりします。複数顧客の運用全体は複数ドメインのメールホスティングで説明しています。
DKIM の検証: DNS と実際のメールを確認する
ダッシュボードの「有効」表示だけでは不十分です。公開 DNS を直接問い合わせ、返されたレコードを確認し、実際のメールヘッダーで期待する署名ドメインとセレクターを確かめます。それより少ない確認は部分的なものです。
まずコマンドラインを使います。
# macOS / Linux
dig txt k1._domainkey.example.com +short
# Windows
nslookup -type=txt k1._domainkey.example.com完全な v=DKIM1 レコード、または結合すると鍵全体になる引用符付き文字列を確認します。結果が空なら、順に調べてください。
- セレクターが正しいか。
- ホスト欄でドメインが二重になっていないか。
- レコード形式がプロバイダーの指定と合っているか。
- 値が完全で、切り詰められていないか。
- 古いレコードがまだキャッシュされていないか。
続いて、Gmail などヘッダーを確認できるメールボックスへテスト送信します。認証結果と DKIM 署名を探してください。
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...DNS が正しくても受信トレイに届きにくければ、別の要因も確認します。TrekMail の迷惑メールに入る場合のガイドでは、DNS の状態、ドメインのウォームアップ、リストの品質、内容も重要としています。DKIM は認証の一部を整えますが、良好なレピュテーションを自動的に得るものではありません。
転送にも注意が必要です。転送後は SPF が失敗することがあります。署名対象が変わらなければ、有効で整合した DKIM 署名により、こうした経路でも DMARC を通過できる場合があります。メール転送を読み、転送による SPF の失敗を認証全体の失敗と混同しないようにしてください。
DKIM 設定とアライメントの落とし穴
正常に見える DKIM がアライメントで問題になることがあります。署名が有効でも、署名ドメインと表示上の From ドメインが整合せず、整合した SPF も成功していなければ、DMARC は失敗し得ます。DNS が原因の場合もありますが、多くはプロバイダーの設定です。
よくある例:
From: ceo@example.com
DKIM 署名ドメイン:d=sendgrid.net
結果: DKIM は成功しても、署名ドメインがexample.comと整合しないため、DMARC アライメントは失敗する可能性があります。
Google は一括送信者に、表示上の From ドメインが SPF または DKIM と、少なくとも組織ドメインのレベルで整合することを求めています。配信事業者が自社ドメインだけで署名するなら、その署名は独自ドメインの DKIM アライメントを満たしません。
必要な機能はプロバイダーによってドメイン認証やホワイトラベル化と呼ばれます。カスタム Return-Path は主に SPF アライメントに関係し、それだけでは DKIM 署名ドメインを変更しません。DKIM の最終的な署名は、次のような形を目指します。
DKIM-Signature: ... d=example.com; s=s1; ...整合した DKIM は DMARC を支える重要な設定です。ただし、受信トレイへの到達を保証するものではありません。
DKIM 設定の従来の方法と新しい方法
従来の方法は、ドメイン、プロバイダー、セレクター、DNS の違いを個別に手作業で処理するため、ミスが起きやすいものでした。新しい方法は標準化です。繰り返せる送信モデルを選び、DNS 確認を集約して、ドメインごとに同じ解決策を作り直さないようにします。
| 従来の方法 | 新しい方法 |
|---|---|
| 任意のツールで鍵を作り、送信元と合うことを期待する | 実際に署名する送信システムで DKIM を生成する |
| TXT を一つずつ貼り、問い合わせが来てから対応する | 可能なら管理された署名を使い、CLI で検証する |
| すべてのドメインを特別扱いする | 顧客とチームの全ドメインで共通の手順を使う |
| キャンペーン失敗後に迷惑メールを調査する | 最初の本番送信前に DNS、アライメント、ヘッダーを確認する |
TrekMail では、このモデルに沿って複数の独自ドメインを一つのダッシュボードで管理し、メールボックスごとの課金ではなく共有ストレージを使い、IMAP で既存のメールを移行できると説明されています。BYO SMTP または含まれる SMTP の選択はプランによります。紹介されている有料プランは月額 $3.50からですが、最新の料金と機能を確認してください。チーム、中小企業、代理店、MSP のインフラ管理負担を減らすことを目指した基盤です。
大きな問題が DNS より運用手順にあるなら、顧客メールの管理も参照してください。複数ドメインの到達性問題では、管理責任の曖昧さが原因になることも多いものです。
最後の DKIM 設定チェックリスト
適切な設定には、正しい署名システム、DNS 名、欠損のない鍵、公開 DNS の確認、DMARC に必要な整合性が含まれます。どれかが誤っていると、認証全体が弱くなります。
- 送信を署名するシステムを確認する。
- プロバイダーのセレクターとレコード形式を正確に公開する。
- DNS ホストが完全な名前を明示的に要求しない限り、ホスト欄は
selector._domainkeyにする。 - 2048 ビット鍵を完全に保ち、管理画面が要求する場合だけ引用符付きの文字列を分割する。
digまたはnslookupで検証する。- テスト送信して、
dkim=passと整合したheader.dをヘッダーで確認する。 - 運用開始後に DMARC の結果を確認する。
DKIM で重要なのは複雑さではなく正確さです。依存関係を減らしたいなら、TrekMail でドメインと送信経路を標準化し、DNS を一か所で確認できる形にできます。そのうえで、実際に使う各送信経路を検証してください。
