DKIM（ディーキム）とは、送信するメールに電子署名を付け、署名したドメインと、署名の後に内容が変わっていないかを受信側が確かめられるようにする仕組みです。正式な仕様はRFC 6376で、署名を確かめるための公開鍵は、署名した側のドメインのDNSから取得すると定めています。
今日やることは、自社のメールを実際に開いて確かめることです。自社から外部のアドレスへ1通送り、受信側でメッセージのヘッダーを表示します。Gmailならメニューの「メッセージのソースを表示」から見られます。
見る所は2つあります。
- Authentication-Resultsの行に
dkim=pass があるか
- DKIM-Signatureの行の
d= が、Fromのアドレスと同じ組織のドメインか
日常のメールだけでなく、配信サービスから送るメールと、業務システムから送る通知も1通ずつ同じように見ます。抜けが出やすいのは、後者の2つです。
DKIMの電子署名はどう動く？
DKIMでは、秘密鍵と公開鍵を1組作り、役割を分けて使います。Googleの説明のとおり、秘密鍵は送信側のメールサーバーに置き、公開鍵はドメインのDNSに公開します。
| 順番 |
どこで |
何をする |
| 1 |
送信側 |
宛先や件名などのヘッダーと本文から、秘密鍵で署名を作る |
| 2 |
送信側 |
署名をDKIM-Signatureというヘッダーに入れて送る |
| 3 |
受信側 |
d=のドメインのDNSから公開鍵を取得する |
| 4 |
受信側 |
公開鍵で署名を確かめ、結果を判断に使う |
Microsoftの解説は、DKIMの主な目的を、メールが転送中に変更されていないことの確認だとしています。途中のメールシステムが署名の対象を変えると、確認に失敗します。
ここで、会社の印鑑に置き換えて考えると分かりやすくなります。秘密鍵は社内で保管する印鑑で、公開鍵は誰でも照合できるように公開した印影です。印影の置き場所がDNSなので、ドメインを管理している人の作業が必ず発生します。
会社のメールになぜ必要なの？
理由は、受信側が送信元を判断する材料にしているからです。
Googleのメール送信者のガイドラインは、Gmailへ送るすべての送信者にSPFかDKIMの設定を求めています。個人のGmailへ1日5,000件以上送る場合は、SPF、DKIM、DMARCの3つが必要です。認証されていないメールは、迷惑メールに分類されたり、拒否されたりすることがあるとも書かれています。
鍵の長さにも条件があります。個人のGmail宛ては1,024ビット以上が必要で、Googleはドメインのプロバイダが対応していれば2,048ビットを勧めています。
5,000件という数字は、同じドメインから送るメールを合わせて数えます。GoogleのFAQの例では、本体のドメインから2,500件、サブドメインから2,500件送ると、一括送信者として扱われます。また、これらの要件が対象にしているのは個人のGmailアカウント宛てで、Google Workspace宛てのメールは対象外です。
自社には関係のない数字だと感じるかもしれません。ただ、顧客や取引先の担当者が個人のGmailを使っている場合はあります。送信量が少なくても、認証の状態は届きやすさに関わります。
社外の配信サービスで忘れやすい設定は？
いちばん抜けやすいのは、メールを送る仕組みごとに署名の設定が要ることです。
DKIMの設定はドメイン全体で1回やれば終わり、というものではありません。Microsoft 365の設定は、Microsoft 365から送るメールにしか効きません。別のサービスから送るメールには、そのサービスの鍵で署名を付ける必要があります。Microsoftの解説も、多くのメールサービスは最初はサービス側のドメインで署名し、顧客が設定した後に顧客のドメインで署名すると説明しています。
設定の形はサービスによって違います。
| サービスの例 |
公式の案内にある設定 |
| Google Workspace |
管理コンソールで鍵を作り、公開鍵をTXTレコードとしてDNSに登録し、有効にする |
| Microsoft 365 |
独自ドメインごとに2つのCNAMEレコードを作り、署名を有効にする |
| Mailchimp |
DKIM用の2つのCNAMEレコードと、DMARC用の1つのTXTレコードを登録する |
| Twilio SendGrid |
案内されたレコードをDNSに登録する。SPF、DKIM、DMARCのレコードをTwilio側で管理する機能が標準で有効 |
配信サービス、予約システム、問い合わせフォーム、基幹システムの通知。こうした送信元は部署ごとに契約されていて、情シスや総務が把握していないことがあります。
たとえば、部品メーカーの場合で考えてみます。日常のやりとりはMicrosoft 365、製品案内は配信サービス、出荷通知は基幹システムのサーバーから送っているとします。このとき、Microsoft 365だけ設定しても、残りの2つは自社ドメインの署名が付かないままです。担当者には普通に届いて見えるので、外から確かめないと気づけません。
配信サービスで確かめる4つのこと
- Fromに自社のドメインを使っているか
- DKIMの設定画面に「認証済み」のような表示が出ているか
- 実際に届いたメールのd=が自社の組織のドメインか
- やめたサービスのレコードがDNSに残っていないか
DMARC・なりすましメール対策サービスの比較には、こうした送信元の把握を助けるものがあります。自社で読み解くのが難しいと感じたら、選択肢に入ります。
サブドメインを使う考え方
Microsoftは、直接管理していない一括配信サービスには、本体のドメインではなくサブドメイン（例：mail.自社ドメイン）を使うことを勧めています。配信側で問題が起きても、普段のメールへの影響を分けやすくするためです。
Microsoft 365とGoogle Workspaceでは何をする？
多くの会社は、この2つのどちらかを使っているはずです。
Microsoft 365の場合
初期の onmicrosoft.com のドメインから送るメールには、自動で署名が付きます。一方で、独自ドメインで送るメールには、管理者が署名を設定します。Microsoftの解説は、各サブドメインにも個別の設定が要るとしています。
手順は、ドメインごとに2つのCNAMEレコードをDNSに作り、管理画面で署名を有効にする流れです。
Google Workspaceの場合
Googleの手順は、鍵の作成、DNSへの登録、有効化と確認の3段階です。鍵の長さは、ドメインのプロバイダが対応していれば2,048ビットを選びます。登録した後も、管理画面に更新を促す表示が最長で48時間ほど残ることがあります。
Googleパートナーからドメインを購入した場合など、すでに設定済みのこともあります。作業の前に、今の状態を見てください。
共通の注意
自社の送信ゲートウェイでメールの末尾に定型文を足している場合、署名に干渉することがあるとGoogleは注意を促しています。署名の後に本文が変わるためです。社外向けの免責文を自動で付けている会社は、実際のメールで確かめます。
もう1つは鍵の交換です。Microsoftは、パスワードと同じ理由でDKIMの鍵を定期的に変えるよう案内しています。交換の担当と時期も、設定と一緒に決めておきます。
DKIMを入れれば、なりすましは防げる？
DKIMだけでは防げません。理由は2つあります。
1つ目は、署名のドメインとFromのドメインが同じである必要がないことです。Microsoftの解説にも、一致する必要はないと明記されています。別のドメインの署名が正しく付いていても、DKIMの検証だけなら合格します。そこで、Fromのドメインと揃っているかを見るのがDMARCです。役割の分担はSPF・DKIM・DMARCの違いと揃える順番で整理しています。
2つ目は、署名が示す範囲です。分かるのは、そのドメインが署名したことと、対象が変わっていないことです。中身が安全かどうかは分かりません。
IPAの解説（2026年8月）は、攻撃者が取引先のメールアカウントに不正ログインし、正規のアカウントからメールを送る場合があると説明しています。この場合、メールは正規の経路から出ています。振込先の変更のような依頼は、経理の手順で止める仕組みが別に必要です。受信側の守りを比べるなら、メールセキュリティ製品の比較が参考になります。
誰に何を頼めばいい？
DKIMの作業は、次の3者にまたがります。
- メールサービスの管理者：鍵を作り、署名を有効にする
- DNSの管理者：レコードを登録する
- 配信サービスや業務システムの担当部署：送信元を申告し、設定画面を操作する
DNSの管理を制作会社やプロバイダに任せている会社は、誰がレコードを変更できるのかを先に確かめます。DNSの守りも合わせて見直すなら、DNSセキュリティの比較も手がかりになります。メールの守りの全体像はメールのセキュリティ対策にまとめています。
最初の一歩は、送信元の一覧を作ることです。一覧の行ごとに、届いたメールのd=を書き込んでいけば、残っている作業が見えてきます。
