独自ドメインで送信するなら、DNS に DKIM レコードを設定してください。正しい構成は認証と到達性を支えます。DKIM がなければ、受信側はこの方式で署名対象の内容の完全性を確認できません。Google、Yahoo、Microsoft は送信者の種類に応じた要件を公開しており、少量送信のドメインにも DKIM は有用です。各サービスの最新の条件を確認してください。
このガイドは、鍵の生成、DNS レコードの公開、署名の有効化、動作確認を扱います。手順、構文、よくある間違いに絞って説明します。手作業でも管理された基盤でも、DKIM の基本は同じです。
DKIM レコードとは？
暗号鍵のペアのうち公開鍵を保持する DNS TXT レコードです。送信サーバーは秘密鍵でメッセージに署名します。受信側は DNS から公開鍵を取得して署名を検証し、署名ドメインが責任を持つことと、署名されたヘッダーや対象の本文が変更されていないかを確認します。DKIM は RFC 6376で定義され、現代のメール認証の重要な要素です。
4 ステップで DKIM レコードを作成する
ステップ 1: DKIM の鍵ペアを生成する
レコードを公開する前に鍵ペアを用意します。秘密鍵は実際に署名するシステムに置き、公開鍵を DNS に公開します。生成方法は送信構成によります。
ホスト型のメールサービスを使う場合、Google Workspace、Microsoft 365、Zoho などのプロバイダーが鍵と DNS の設定値を提供します。Google Workspace では、管理コンソール > アプリ > Google Workspace > Gmail > メールを認証から新しいレコードを生成します。画面の名称は変わる場合があります。
自分でメールサーバーを運用する場合、Postfix、Exim、OpenDKIM などの環境でコマンドラインから生成できます。
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem可能なら 2048 ビット鍵を使います。古い資料には 1024 ビットも登場しますが、2026 年の構成としては暗号学的な余裕が少なくなります。ただし、1024 ビットをすべての受信側が一律に拒否するわけではありません。受信側の要件と DNS ホストの対応を確認してください。
セレクターも選びます。これは特定の鍵を識別する名前です。鍵のローテーションや、サービスごとに別の鍵を使うために利用します。よくある名前は google、s1、mail2026、サービス名の sendgrid などです。
ステップ 2: 公開鍵を DNS に追加する
ドメインの DNS ゾーンに DKIM を作成します。Cloudflare、Route 53、GoDaddy、Namecheap などの管理画面で TXT レコードを追加し、プロバイダーの入力形式に従ってください。
ホストまたは名前の欄:
selector._domainkey.yourdomain.comselector はステップ 1 で選んだ名前に置き換えます。s1 とドメイン example.com の場合、完全な名前は次のとおりです。
s1._domainkey.example.com値の欄:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u...truncated...base64encodedpublickeyp= には公開鍵全体を Base64 で指定します。-----BEGIN PUBLIC KEY----- などの PEM マーカーと改行を取り除きます。鍵のデータに区切りを挿入せず、連続した形にしてください。
重要: TXT の一つの文字列は最大 255 オクテットです。一般的な 2048 ビット RSA 鍵には複数の文字列が必要です。自動で分割する画面もあれば、手動の引用符付き分割が必要なものもあります。その場合は各部分を最大 255 文字にし、別々の TXT レコードではなく同じレコード内に置きます。DKIM 検証では部分が結合されます。
ステップ 3: メールサーバーで署名を有効にする
DNS に公開しただけでは署名されません。送信システムが秘密鍵を実際に使う必要があります。
Google Workspace: 鍵を生成した管理画面で「認証を開始」を有効にします。
OpenDKIM（Postfix/Exim）: /etc/opendkim.conf を編集します。
Selector s1
KeyFile /etc/opendkim/keys/example.com/dkim_private.pem
Domain example.com
Socket inet:8891@localhostPostfix では /etc/postfix/main.cf に milter を追加します。
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891両サービスを再起動します。
sudo systemctl restart opendkim
sudo systemctl restart postfix外部の送信サービスである SendGrid、Mailgun、Amazon SES は、それぞれ独自の有効化手順があります。一般には CNAME または TXT を指定され、DNS に追加した後でダッシュボードから検証します。最新のプロバイダーの手順に従ってください。
ステップ 4: レコードを検証する
動くと決めつけず、実際の結果を確認してください。
コマンドラインから:
dig TXT s1._domainkey.example.com +short応答には公開鍵が表示されるはずです。空の結果は未更新のキャッシュや名前の誤りでも起きます。粗い待機の目安として最大 48 時間と案内される場合もありますが、数分で見える更新もあります。TTL、プロバイダー、正しい公開によって変わるため、設定ミスなら待つだけでは直りません。
テストメールで: Gmail に送信し、元のヘッダーを調べます。次の結果を探してください。
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s1dkim=pass は、そのテストメールの署名検証が成功したことを示します。アライメントや他の送信経路も確認してください。dkim=fail または dkim=neutral なら、設定と次のよくある間違いを調べます。
DKIM レコードの構文
各タグを理解すると、初めての設定でも間違いを減らせます。構造の例:
v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQE...| タグ | 必須 | 意味 |
|---|---|---|
v=DKIM1 | はい | バージョン。DKIM1 を指定する。 |
k=rsa | いいえ | 鍵の種類。RSA は既定で広く使われる。Ed25519 も標準化されているが、送信側と受信側の対応を確認する。 |
p= | はい | Base64 の公開鍵。空の p= は鍵の失効を示す。 |
t=s | いいえ | DKIM の識別子 i= のドメインを署名ドメイン d= と一致させ、サブドメインを認めない。DMARC の From アライメントを制御するものではない。 |
t=y | いいえ | テストのフラグ。RFC は DKIM テスト失敗によって扱いを変えないことを求めるが、受信を保証しない。検証後に削除する。 |
DKIM レコード作成でよくある間違い
初めて設定するときには、同じ間違いが繰り返されがちです。
1. 公開鍵の改行。 PEM からコピーするときに起きやすい問題です。DNS の値に改行が入ると鍵が壊れる可能性があります。Base64 のデータから改行と空白を取り除きます。
2. DNS 名のセレクターが違う。 鍵は s1 なのに、サーバーは default を使っている場合です。受信側は default._domainkey.example.com を探し、鍵を見つけられません。DNS と署名のセレクターを正確に一致させます。
3. 同じセレクターのレコードが複数ある。 SPF はドメインごとに一つですが、DKIM は別々のセレクターを使えます。ただし、各セレクターの鍵は一意に参照できる必要があります。s1._domainkey の TXT が二つあると検証できないことがあるため、受信側が正しい鍵を選ぶと期待してはいけません。
4. 署名を有効にし忘れる。 DNS は公開鍵を提供するだけです。サーバーが秘密鍵で送信を署名しなければ、公開されたレコードは使われません。
5. 1024 ビット鍵を使う。 技術的に使える場合はありますが、余裕は小さくなります。Google の送信者ガイドラインは、可能なら 2048 ビットを推奨しています。新しい鍵ペアを新しいセレクターで公開し、送信側を更新します。以前の署名メールが旧鍵を必要としなくなってから、p= を空にして失効させてください。
DKIM、SPF、DMARC: 認証全体の構成
DKIM は三つの要素からなる認証の一部です。
SPF は、送信 IP が検証対象ドメインで許可されているか調べます。転送で IP が変わると失敗することがあります。まだ設定していなければSPF レコード設定ガイドとメールでの SPF の仕組みを読み、DNS を使う項の上限が 10 であることや他の制約を確認します。
DKIM は IP ではなく内容に署名するため、転送後も有効な場合があります。ただし、署名対象が検証に影響する形で変わらないことが条件です。そのため SPF の重要な補完になります。
DMARC は両者を表示上の From ドメインに結び付けます。どちらも整合して成功しない場合、公開されたポリシーは監視、隔離、拒否を求めますが、最終判断は受信側が行います。少なくとも SPF または DKIM が成功し、かつ From と整合する必要があります。
目標の一例は、SPF と DKIM の両方を整合させ、正規の送信経路を確認してから DMARC を p=reject にすることです。ドメインのなりすましを抑えますが、良好なドメインレピュテーションや受信トレイへの到達を保証するものではありません。
企業では、この構成は安全なメール運用の基礎の一つです。ただし、他の保護対策も必要です。
TrekMail が DKIM を支援する方法
一つのドメインなら手作業も現実的です。多数のドメインでは鍵のローテーション、複数サービスのセレクター管理、設定ミスの検出が負担になります。適切な自動化と明確な管理責任が役立ちます。
TrekMail は DNS 値を示し、ドメインの状態を確認する SPF/DKIM/DMARC ウィザードを紹介しています。鍵を生成、管理する範囲は送信経路によります。外部 SMTP では実際のプロバイダーの値を使ってください。検証は問題の発見に役立ちますが、すべての配送障害を防ぐものではありません。
- Nano（$0）: Amazon SES、Mailgun などの BYO SMTP。DKIM は実際の SMTP プロバイダーの手順に従う。カード不要と説明されているが、最新の条件を確認する。
- Starter（月額 $3.50）: 管理された SMTP と DKIM 支援が紹介されている。鍵の自動生成やローテーションの範囲を確認する。記載の 14 日間無料試用はカードが必要。
- Pro（月額 $10）: 複数の送信ドメイン向けとして紹介されている。独立した DKIM セレクターと管理機能を確認する。記載の無料試用は 14 日間。
- Agency（月額 $23.25）: 一つの画面で 100+ の顧客ドメインを管理すると紹介されている。現在の上限、ローテーション、監視機能を確認する。記載の無料試用は 14 日間。
単なる便利さのためではありません。DKIM のミスは認証や配送に影響が出るまで気づかれないことがあります。自動検証で早く見つけられる場合もありますが、すべての問題を検出するわけではありません。
まとめ
正しい作成には適切な鍵ペア、可能なら 2048 ビット、正しいセレクターの TXT、実際の署名、結果の確認が必要です。一つのドメインの入力は約十分で済む場合もありますが、DNS 更新や調査には別の時間がかかります。
DKIM の後は SPF と DMARC も設定します。認証を改善し、一部のなりすましを抑えますが、ドメインをすべてのリスクから完全に守るものではありません。
DNS をすべて手作業で管理したくないなら、TrekMail を無料で試す方法もあります。ウィザードを使っても、実際の送信者に合う値を確認してください。
