DKIMは、送信ドメインが正当であることを受信側に示すための仕組みです。設定が正しくないと、迷惑メール判定が増えたり、受信拒否の原因になったりします。特に多いのが「selectorの取り違え」「DNSの貼り付けミス」「反映待ちによる見え方の揺れ」です。
この記事では、Okada NoteBook の DKIMチェッカーを使って、DKIMレコードを確認する手順と結果の見方、よくあるエラーの切り分けまでをまとめます。DNSが苦手な方でも、読む順番通りに進めれば3分で確認できます。
結論：DKIMは「ドメイン」と「selector」が分かれば3分で確認できます
DKIMのチェックで必要なのは、基本的に次の2つだけです。
- Domain（ドメイン）：例
example.com - Selector（セレクタ）：例
default/google/s1/202401など
この2つが分かれば、チェック対象は次のFQDNに決まります。
- selector._domainkey.example.com
あとは、その名前に対してDNS上の TXT（またはCNAME） が正しく存在し、内容がDKIMとして妥当かを確認するだけです。
DKIMとは（最低限これだけ分かればOK）
DKIM（DomainKeys Identified Mail）は、メールに「署名」を付けて送信し、受信側がDNS上の公開鍵で検証する仕組みです。
- 送信側：メールに署名（秘密鍵）
- 受信側：DNSの公開鍵（
p=）で署名を検証 - 結果：受信側で DKIM=pass/fail となる
ここで重要なのは、秘密鍵は送信システム側が保持し、DNSには 公開鍵 を置く点です。つまり、確認作業で見るべきなのはDNS上のレコード（公開鍵）であり、秘密鍵を入力したり共有したりする必要はありません。
なお、関連用語としてSPF/DMARCがありますが、役割は次のイメージで押さえておけば十分です。
- SPF：送信元IPが正当か（経路寄り）
- DKIM：メール内容に署名があるか（署名寄り）
- DMARC：SPF/DKIMの結果をどう扱うか（運用ポリシー）
ツールの使い方
入力するのは2つだけ
- Domain に確認したいドメインを入力します
- 例：
example.com
- 例：
- Selector に送信サービスが指定しているselectorを入力します
- 例：
default
- 例：
送信サービスによってselectorは変わります。分からない場合は、後述の「selectorの調べ方」を先に読んでください。
入力例
- Domain：
example.com - Selector：
default
この場合、ツールが確認するのは次の名前です。
default._domainkey.example.com
ツールが裏で見ていること
ツールは、selector._domainkey.<domain> に対して、DNSの TXT または CNAME を確認します。
（手元でCLI確認したい場合は dig などでも同等に確認できますが、この記事ではツールだけで完結します。）
結果の見方（OK/NGの判断基準）
DKIMチェック結果を読むときは、細かいタグの暗記よりも、次の「要点」を押さえるのが実務的です。
v=DKIM1があるか（DKIMレコードとして宣言されているか）p=が空でないか（公開鍵が正しく入っているか）- レコードが1つに整理されているか（古い残骸や重複がないか）
- 反映の揺れがないか（DNS伝播・キャッシュにより見え方が変わらないか）
重要ポイント早見表
| 見るポイント | OKの目安 | NGの典型 | 対処 |
|---|---|---|---|
v=DKIM1 | 存在する | 無い / 別用途のTXT | DKIMとして正しいTXTに修正 |
p=（公開鍵） | 空ではない（長い文字列） | 空 / 短すぎ / 欠落 | 公開鍵を再発行し再設定 |
k= | rsa または ed25519 | 不明値 | プロバイダ推奨値で再生成 |
| レコード数 | 原則1つ（selectorごと） | 複数出る | 不要レコード削除・整理 |
| TXTの分割 | 分割されても結合後に妥当 | 途中欠落/余計な記号 | DNSの貼り付けミス修正 |
| 反映状況 | どこから見ても安定 | 環境で出たり出なかったり | TTL待ち、伝播確認 |
p= が空の場合は要注意
p= が空のDKIMレコードは、一般に「公開鍵なし＝無効化（失効）」扱いになります。意図して無効化しているなら別ですが、到達率改善やなりすまし対策が目的なら、公開鍵を再発行して正しい値をセットしましょう。
selectorの調べ方
DKIMで最も詰まりやすいのは「selectorが分からない」ケースです。調べ方は主に2つあります。
1) 最短：送信サービスの管理画面で確認する
Google Workspace / Microsoft 365 / Amazon SES / SendGrid などは、DKIM有効化の手順の中で selector（または同等の識別子）を表示します。基本はここを見に行くのが確実です。
- 表示例：
default/google/selector1/s1/202401など
2) 補助：受信したメールのヘッダーから見る
受信したメールの詳細（ヘッダー）に DKIM-Signature: があります。そこに以下のような項目が含まれます。
d=：署名ドメインs=：selector
例（イメージ）：
d=example.com; s=default;
この s= が selector です。管理画面が見られない場合の手がかりになります。
よくあるエラーと対処法（切り分けで最短復旧）
ここからは、DKIMチェッカーでつまずく典型パターンと対処です。症状ベースで読めるようにしています。
NXDOMAIN（レコードが存在しない）
症状：selector._domainkey.<domain> が存在しない／見つからない
よくある原因
- selectorが違う（最頻出）
- ドメインが違う（サブドメイン運用など）
- まだDNSに追加していない
対処
- 送信サービスの管理画面でselectorを再確認
- DNSにレコードを追加（TXT or CNAMEは指示に従う）
- 反映まで待つ（TTL/キャッシュの影響あり）
SERVFAIL / タイムアウト
症状：DNSの応答が不安定、失敗する
よくある原因
- DNS障害（権威DNS側）
- DNSSECや委任の不整合
- 特定Resolverでのみ問題が出る
対処
- 時間をおいて再チェック（瞬間的な障害もある）
- DNS提供元のステータス確認
- 別Resolverでも同様か確認（見え方が一貫するか）
TXTが複数出てくる（複数レコード）
症状：同じ名前に複数のTXTがぶら下がり、判定が不安定になる
よくある原因
- 旧プロバイダのDKIMが残っている
- 移行時に削除漏れがある
対処
- 現行の送信サービスが使っているselectorのレコードだけを残す
- 使っていないselectorのレコードは整理（削除・退避）
文字列が途中で切れている／余計な記号が入った
症状：p= が不自然に短い、途中に不要な文字が混ざる
よくある原因
- DNS管理画面でのコピペ事故（改行、ダブルクォート、スペース）
- 値の分割時に欠落が出た
対処
- 送信サービスの指示通りに再貼り付け
- 分割が必要でも「欠落しない」ことが最重要
- 不安なら一旦、指示値をそのまま入れ直す
まとめ：直したら再チェックし、ヘッダーで DKIM=pass を確認する
DKIMの確認は、最終的には次の2点に集約されます。
selector._domainkey.<domain>のDNSレコードが正しく存在し、v=DKIM1とp=が妥当である- 実際に届いたメールのヘッダーで DKIM=pass になっている
設定を修正したら、まずは DKIMチェッカー で再チェックし、次に実メールのヘッダーで合格を確認してください。
DKIMだけでなく総合的に改善したい場合は、SPF/DMARCも合わせて点検すると到達率の改善につながります。
