DomainKeys Identified Mail(RFC 6376)。送信側ドメインが秘密鍵でメールヘッダーと本文の一部にデジタル署名し、受信側が DNS の TXT レコードに公開されている公開鍵で署名を検証することで、メール送信元ドメインの真正性を保証する仕組み。
仕組み
[送信側] [受信側]
1. メール本文 + 一部ヘッダーから 4. DNS TXT を引いて公開鍵を取得
ハッシュを生成 (selector._domainkey.<domain>)
2. 秘密鍵で署名 5. 公開鍵で署名を検証
3. DKIM-Signature ヘッダー追加 6. PASS / FAIL を判定
DNS TXT レコードの形式
google._domainkey.example.com TXT "v=DKIM1; k=rsa; p={Base64 公開鍵}"
| 構成 | 意味 |
|---|---|
selector._domainkey.<domain> | レコード名。selector はサービスごと(google, s1 等) |
v=DKIM1 | バージョン |
k=rsa | 鍵アルゴリズム(RSA / ed25519) |
p=... | Base64 エンコードされた公開鍵 |
255 文字制限の罠
DNS の TXT レコードは 1 つの文字列あたり 255 文字以内という仕様。2048 bit RSA 公開鍵(Base64 で 400 文字超)はそのままでは登録できない。ダブルクォートで複数文字列に分割して登録し、DNS リゾルバ側が自動連結する。AWS Route 53 / Cloudflare 等で頻発する。
SPF / DMARC との関係
| 仕様 | 検証対象 | 役割 |
|---|---|---|
| SPF | 送信元 IP | 送信サーバーが正しいか |
| DKIM | 署名 | メール内容が改竄されていないか・送信ドメインが正しいか |
| DMARC | SPF / DKIM の整合 | 失敗時の挙動を送信側が宣言 |
3 つ揃って初めて業界標準のなりすまし対策となる。Google Workspace / Microsoft 365 等のクラウドメールでは DKIM 自動設定機能が用意されているが、共有ドメイン(gappssmtp.com 等)での署名になりがちで、自社ドメインで署名するには専用キーの DNS 登録が必要。
関連用語
- SPF — 送信元 IP ベースの認証
- DMARC — SPF / DKIM の結果を統合するポリシー宣言
- Google Workspace — DKIM 自動有効化される代表的なクラウドメール
- Microsoft 365 — 同上