dnsrobot.net
本文ハッシュが一致しない
メーリングリストが153バイトのフッターを追加しました。ヘッダーはproject.exampleの鍵でまだ検証できるため、偽造ではありません。
対処 本文を変更しないリスト、またはARC（RFC 8617）を使い、あとの受信サーバーに元の結果が見えるようにします。
body-hash-mismatchDKIMチェッカー
ドメインのDKIMレコードを受信メールサーバーが見つけるのと同じ方法で確認するか、メールを貼り付けて署名をテストします：どのセレクターが応答するか、誰が署名しているか、各鍵がどれだけ強いか、DMARCとアラインしているか。
情報源：メールプロバイダー67社の一般的なセレクター140個をGoogle Public DNS経由（背後にCloudflare）で確認 · RFC 6376とRFC 8301による鍵のチェック · メールはお使いのブラウザー内で検証 · あなたに関する情報は保存されません
DNSにはセレクターの一覧を取得する機能がないため、メールプロバイダーが使う140個のセレクターを、selector._domainkey.にドメインを付けた名前で問い合わせます
例
DKIMレコードを確認するには？
上の欄にドメインを入力してください：チェッカーはメールプロバイダーが使う140個のセレクターを問い合わせ、見つかったすべての鍵を長さとプロバイダーとともに表示し、何も見つからなければ、そのとおりに伝えます。セレクターが分かっている場合はドメイン + セレクターを選ぶと、それが最初に確認されます。
手作業で確認するにはセレクターが必要です。DNSにはセレクターの一覧を取得する機能がないためです：dig +short TXT selector._domainkey.example.com、Windowsなら同じ名前でnslookup -type=TXT。セレクターは、どのメールのDKIM-Signatureにもあるs=の値です（RFC 6376 §3.6.2.1）。
digが表示するのはテキストだけで、その意味までは分かりません：鍵の長さを復元せず、プロバイダーのCNAMEをたどらず、待機用の枠と壊れた設定も区別しません。それを補うのが、このDKIMチェックです。
dig +short TXT selector._domainkey.example.comこの名前のすべてのTXT文字列を表示します。連結すると鍵を読み取れます。
digで分かること、分からないこと
$ dig +short TXT 20251104._domainkey.google.com 1
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2
$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3
Public-Key: (2048 bit)
$ dig +short TXT selector1._domainkey.microsoft.com 4
selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.
- 1名前はselector._domainkey.domainセレクターがなければ応答もありません：DNSに「すべての鍵を一覧表示」はありません。
- 2文字列は2つ、レコードは1つTXT文字列は255バイトまでなので、2048ビットの鍵は分割されます。受信サーバーは間に何も入れずに連結します。
- 3鍵の本当の長さopensslはp=を復元します：RFC 8301が求めているのは2048ビットです。
- 4プロバイダーへのCNAMEその先にTXTはありません：Microsoft 365の待機用の枠であり、エラーではありません。
結果の読み方：セレクター探索
最初に1文で答えが表示されます。その下に、誰が署名しているかと鍵そのものが続きます：各タグを実際の文字位置で色分けし、鍵の長さをRFC 8301の基準で表示します。紺色の背景には確認したすべてのセレクターが表示されるため、何を試したかが分かります。
点数はありません：廃止された鍵やプロバイダーの空の待機用セレクターは正常で、「一般的なセレクターに見つからない」は「DKIMなし」を意味しません。
判定1文で、鍵がいくつあるか、何をすべきかを示します。署名者プロバイダーごとに1枚のカード。CNAMEまたは公開されているセレクターから判定します。各セレクターのチップから鍵を開けます。鍵各タグを文字位置ごとに色分けし、鍵の長さをRFC 8301の基準で示します。セレクター探索問い合わせた名前が応答するたびに点灯します：緑は鍵、黄は1024ビット、破線は待機用の枠です。DMARCアライメントこのドメインのd=を持つ鍵が、DMARCポリシーとアラインするかを示します。DKIMとは？
DKIM（DomainKeys Identified Mail）は、送信サーバーが各メッセージに付ける署名で、受信サーバーはドメインがDNSで公開している公開鍵で確認します（RFC 6376）。有効な署名は2つのことを証明します：d=のドメインが署名したこと、そして署名された部分がそれ以降変更されていないことです。
送信側は本文をハッシュしてbh=に入れ、選んだヘッダーとそのハッシュを秘密鍵で署名してb=に入れます。受信側はd=とs=を読み、s._domainkey.dの鍵を取得して、両方をやり直します。本文または署名されたヘッダーが1バイトでも変わると、検証は失敗します。
DKIMは、失敗したときにどうするかについては何も述べず、どのドメインでも署名できます。それを担うのがDMARCで、d=がFrom:ドメインと一致する有効な署名を求めます。
1通のメールを、送信側で署名し、受信側で確認する
example.comのサーバー秘密鍵で署名
DKIM-Signature付きのメッセージ受信サーバーGmail、Outlook.com、Yahoo…
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…
dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048
送信されたままのメッセージ
- 本文ハッシュがbh=と一致
- ヘッダー署名を検証できる
dkim=pass header.d=example.com
途中でSubjectが書き換えられた同じメッセージ
- 本文ハッシュがbh=と一致
- ヘッダー署名を検証できない
dkim=fail (signature-mismatch)
DKIMセレクターとは？自分のセレクターの調べ方
セレクターは1つのDKIM鍵の名前です：署名のs=であり、鍵があるDNS名の最初のラベルでもあります（s1._domainkey.github.com）。ドメインはいくつでも持てます：プロバイダーごと、サーバーごと、年ごとに1つずつ（RFC 6376 §3.1）。
自分のセレクターを調べるには、ドメインが送信したメールを開いて元のメッセージを見ます：Gmailのその他（⋮） › メッセージのソースを表示にDKIM-Signatureが表示され、そのs=がセレクターです。または、上のメールを検証にメールを貼り付けてください。
多くのプロバイダーは固定の名前を使うため、探索で見つかります。Amazon SES、Postmark、SparkPost、HubSpotはアカウントごとに名前を生成するため、メールかプロバイダーの管理画面でしか分かりません。
署名から鍵まで、そしてプロバイダーが使う名前
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …
s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048
| Google Workspace | 管理者がプレフィックスを変更できる | |
|---|---|---|
| Microsoft 365 | selector1 · selector2 | テナントへのCNAME。1つが有効、1つが待機 |
| Twilio SendGrid | s1 · s2 | u<id>.wl<n>.sendgrid.netへのCNAME |
| Mailchimp | k2 · k3 | dkim2/dkim3.mcsv.netへのCNAME |
| Fastmail | fm1 · fm2 · fm3 | CNAMEが3つあり、一度に1つだけ使用 |
| Proton Mail | protonmail · 2 · 3 | domains.proton.chへのCNAME |
| Amazon SES | ランダムなトークン3つ | それぞれランダムな32文字：推測できない |
| Postmark | 20240101000000pm | 日付と「pm」：推測できない |
| SparkPost | scph + MMYY | scphと、鍵を作成した月 |
| HubSpot | hs1-<HubID> | アカウント番号 |
DKIMレコードの形式：すべてのタグの解説
DKIMレコードは、セミコロンで区切ったタグ=値の組からなるTXTレコードで、必須なのは公開鍵のp=だけです。 v=DKIM1は省略可能ですが、ある場合は先頭に置く必要があります（RFC 6376 §3.6.1）。
k=は鍵の種類（ed25519と書かない限りrsa）、t=はフラグ（yはテスト、sは厳格）、h=はハッシュの制限、s=はサービスの制限です。空のp=は、意図的に鍵を失効させます。
タグ名は大文字と小文字を区別し、同じタグを繰り返すとレコードは無効になります。未知のタグは無視されます。
レコードをタグごとに
v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB
| タグ | 設定内容 | 値 | 既定値 | 備考 |
|---|---|---|---|---|
| v= | バージョン | DKIM1 | DKIM1 | 推奨。ある場合は先頭 |
| k= | 鍵の種類 | rsa · ed25519 | rsa | 未知の種類：鍵は無視される |
| p= | 公開鍵（base64） | 鍵、または空 | 必須 | 空 = 失効 |
| t= | フラグ | y テスト · s 厳格 | なし | y：署名なしとして扱われる |
| h= | 許可するハッシュ | sha256（sha1は禁止） | すべて | sha1のみは失敗（RFC 8301） |
| s= | サービスの種類 | * | ほかのサービス専用：無視される | |
| n= | 人間向けのメモ | 任意のテキスト | – | ソフトウェアは読み取らない |
p=の長さと、必要なTXT文字列の数
RSA 1024216文字 · TXT文字列1個
RSA 2048392文字 · TXT文字列2個
RSA 3072564文字 · TXT文字列3個
RSA 4096736文字 · TXT文字列3個
Ed2551944文字 · TXT文字列1個
255バイトごとのTXT文字列の境界（「v=DKIM1; k=rsa; p=」を含めて数えた場合）
1024ビットと2048ビットのDKIM鍵、そしてローテーションの方法
2048ビットのRSAを使ってください。RFC 8301は、検証側に1024ビットの鍵を引き続き受け入れることを求めていますが、署名者には2048ビット以上を求め、1024ビット未満の鍵は拒否するよう検証側に求めています。 M3AAWGは1024ビットを「攻撃されかねない限界」と呼んでおり、512ビットの鍵が約72時間、約75ドルで解読されたと報告しています。
Ed25519鍵は小さく（p=は44文字）、下位互換のため、RFC 8463は署名者がそれと並べてRSA署名も付けることを認めています：セレクター2つ、署名2つです（RFC 8463）。
ローテーションは、新しい鍵を新しいセレクターに公開し、署名を切り替え、転送中のメールのために古い鍵を7〜30日残してから、そのp=を空にします。M3AAWGは半年ごとを勧めています。FastmailやMicrosoft 365のようなプロバイダーは、待機用のセレクターを使って自動で行います。
実際の鍵がRFC 8301の基準のどこにあるか
不合格有効、2048ビットへ移行良好一部の受信サーバーで失敗する可能性
- microsoft.com · selector2
- github.com · k1
- google.com · 20251104
- fastmail.com · fm2
- archlinux.org · dkim-rsa
- archlinux.org · dkim-ed25519 (Ed25519)
切れ目のないローテーション（M3AAWG）
- 0日目新しい鍵を新しいセレクターに公開
- 1日目以降署名を新しい鍵に切り替え
- +7〜30日転送中のメールのために古い鍵を残す
- その後古いp=を空にし、名前は再利用しない
fastmail.comfm1p=が空fm22,048fm3p=が空CNAMEが3つあり、使うのは1つ：ローテーションはFastmail側のDNS変更で行われる
DKIMが失敗する理由は？本文ハッシュ、転送、メーリングリスト
DKIMが失敗するのは、署名されたバイト列が変更されたとき、鍵が見つからないとき、鍵が署名と一致しないときです。 メッセージを変更しない転送ではDKIMは保たれます（SPFとは異なります）。メーリングリストはフッターを追加したり件名にタグを付けたりするため、たいていDKIMを壊します。
このページの検証は、本文ハッシュとヘッダー署名を別々に確認するため、途中で付いたフッターと偽造を区別できます。
署名を検証できない
署名後に署名されたヘッダーが変更された（リストがSubjectに自分の名前を追加する）か、セレクターに別の鍵が入っています。
対処 署名されたヘッダーを書き換えないこと。鍵を置き換えるのではなく、新しいセレクターに新しい鍵を公開します。
signature-mismatch署名に対応する鍵がない
s=2023old._domainkey.shop.exampleがNXDOMAINです：そのセレクターで署名されたメールが転送中なのに、セレクターが削除されました。
対処 切り替え後も古い鍵を7〜30日公開し続け、削除ではなくp=を空にします。
key-not-found転送： メッセージを変更せずに渡す転送サービスはDKIMを有効なまま保つため、SPFが失敗しても、DMARCは通常DKIMによって転送を乗り切ります。
DKIM、SPF、DMARCの違い
SPFはどのサーバーがドメインの代わりに送信できるかを示し、DKIMはドメインが署名したことと変更されていないことを証明し、DMARCはその両方をFrom:アドレスに結び付け、失敗したときの扱いを指示します。
それぞれ別の問いに答えるため、3つとも必要です：GmailとYahooは一括送信者にSPFとDKIM、さらにDMARCレコードを求めており、RFC 9989はp=rejectのドメインに、SPFに頼らずDKIM署名を行うよう求めています。
3つのレコード、3つの問い
| 3つのレコード、3つの問い | SPF | DKIM | DMARC |
|---|---|---|---|
| 何を証明するか | このサーバーがMAIL FROMドメインの代わりに送信してよい | d=のドメインが署名し、署名された部分は変更されていない | From:が、SPFまたはDKIMに合格したドメインと一致する |
| どこにあるか | github.comのTXT | s1._domainkey.github.comのTXT | _dmarc.github.comのTXT |
| 現在のgithub.com | v=spf1 … ~all | 鍵12個、プロバイダー6社 | p=quarantine; sp=reject |
| 転送に耐えるか | いいえ：転送サービスのIPは登録されていない | 耐える。メッセージが変更されずに届く場合 | 耐える。アラインしたDKIMの合格によって |
| 壊れるとき | 新しい送信サービスがレコードにない | 本文または署名されたヘッダーが変更される | From:ドメインについて、どちらも合格しない |
メールのDKIM-Signatureヘッダーの読み方
元のメッセージを開いてDKIM-Signatureヘッダーを探します：d=は署名者、s=はどの鍵か、h=は署名されたヘッダーの一覧、bh=とb=は受信サーバーが確認する2つのハッシュです。
受信サーバーの判定は、到着時に追加される別のヘッダーにあります：Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample。英語表示のGmailの「Show original」ページは、これを「DKIM: 'PASS' with domain example.com」と要約します。
1通のメッセージに、署名者ごとに1つずつ、複数の署名が付くことがあります（あなたのドメインとメールサービス、またはメーリングリスト）。DMARCには、d=がアラインした有効な署名が1つあれば十分です。
サンプルメールの署名をタグごとに
v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9
- 1バージョン v=常に1
- 2アルゴリズム a=rsa-sha256（またはed25519-sha256）
- 3正規化 c=relaxedは折り返しの変更を許容
- 4署名ドメイン d=DMARCのためFrom:と比較される
- 5セレクター s=s._domainkey.dにある鍵
- 6署名時刻 t=Unix時間：2026/10/24 9:12
- 7署名されたヘッダー h=fromが2回 = 重複署名
- 8本文ハッシュ bh=正規化した本文のSHA-256
- 9署名 b=h=のヘッダーとこのフィールドに対する署名
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample
DKIMチェッカーのよくある質問
DKIMレコードとは？
DKIMレコードは、ドメインの公開鍵をselector._domainkey.domain（例：google._domainkey.example.com）で公開するTXTレコードです。タグ=値の組が入っており、p=はbase64の鍵で必須、k=は鍵の種類、t=はフラグです。受信サーバーはこれを取得して、届いたメールのDKIM-Signatureを確認します。ドメインはセレクターごとに複数公開でき、通常は送信サービスごとに1つです。
DKIMセレクターはどうやって調べますか？
ドメインが送信したメールを開き、元のメッセージを表示して、DKIM-Signatureヘッダーを探します。s=の後ろの値がセレクターで、d=がドメインです。Gmailではその他（⋮） › メッセージのソースを表示、Outlook on the webではView › View message sourceを使います。または上の「メールを検証」にメールを貼り付けると、s=とd=を読み取ってくれます。
メールは署名されているのに、チェッカーで鍵が見つからないのはなぜですか？
DNSにはセレクターの一覧を取得する機能がなく、鍵は正確な名前を問い合わせたときにしか見つからないためです。チェッカーはプロバイダーが使う140個の名前を問い合わせます。別の名前で署名している場合（Amazon SESとPostmarkはアカウントごとに生成します）、探索では見えません。メールのs=のセレクターを追加すると最初に確認されます。またはメールを検証してください。
1024ビットのDKIM鍵はまだ使えますか？
まだ動作します：RFC 8301は検証側に1024〜4096ビットのRSA鍵を受け入れることを求めており、GmailとYahooは1024ビットを最小値としています。ただしRFC 8301は署名者に2048ビット以上を求めており、M3AAWGは1024ビットを「攻撃されかねない限界」と呼んでいます。ローテーションを計画してください：Microsoft 365とGoogle Workspaceはどちらも2048ビットの鍵を提供しています。RFC 8301は、1024ビット未満の鍵を拒否するよう検証側に求めています。
p=が空とはどういう意味ですか？
p=が空なのは、鍵が失効しているという意味です：そのセレクターの署名は、鍵が存在しないときと同じように失敗します。たいていは意図的なものです。Googleは古い日付付きのセレクターをこの状態にしており、FastmailとMicrosoft 365はローテーションで切り替える先として、空の待機用セレクターを保持しています。問題になるのは、現在メールの署名に使っているセレクターである場合だけです。
DKIMレコードのt=yとはどういう意味ですか？
t=yは鍵をテスト中として示します：署名が検証できても、受信サーバーはこの鍵で署名されたメールを署名なしと同じように扱うべきとされています。最初の設定時に使うためのもので、外し忘れがよくあります。t=sは別物で、厳格という意味です：署名のi=はサブドメインではなく、署名ドメインと完全に一致する必要があります。一部のメールサービスは、自社の鍵にt=sを公開しています。SendGridのgithub.com用の鍵がその例です。
DKIMが「body hash did not verify」で失敗するのはなぜですか？
受信サーバーがハッシュした本文が、署名のbh=の値と一致しないため、署名後に本文が変更されたということです。フッターを追加するメーリングリスト、リンクを書き換えるセキュリティゲートウェイ、サーバーが付ける免責事項が原因になります。ヘッダー署名がそれでも検証できるなら、メッセージは本物ですが変更されています。このページの検証は両方を別々に確認します。
DKIMはメールの転送に耐えますか？
通常は耐えます。メッセージを変更せずに渡す転送サービスは署名を有効なまま保ちます。DKIMは経路ではなく内容に署名するためです。この点が、転送サービスのIPアドレスで失敗するSPFとの違いです。フッターや件名タグを追加するメーリングリストのように、メッセージを変更する転送はDKIMを壊します。ARCを使うと、元の結果を保証できます。
SPFがあるなら、DKIMは不要ですか？
必要です。SPFはメールが転送されると失敗し、見えないMAIL FROMアドレスしか対象にしません。DKIMは転送に耐え、DMARCが確認するFrom:ドメインとアラインできます。GmailとYahooは一括送信者に両方を求めており、Outlook.comも2025年5月から求めています。RFC 9989は、p=rejectのドメインにメールのDKIM署名を求めています。
DKIM鍵はどのくらいの頻度でローテーションすべきですか？
M3AAWGは少なくとも半年ごとを勧めています。新しい鍵を新しいセレクターに公開し、署名をそれに切り替え、転送中のメールが検証できるよう古い鍵を7〜30日公開したままにしてから、削除ではなくp=を空にします。セレクター名は再利用しないでください。CNAMEセレクターを使うホスティングプロバイダーは、鍵を自動でローテーションします。
ここで検証すると、メールはアップロードされますか？
いいえ。このDKIMバリデーターは、メールをお使いのブラウザー内で確認します：公開DNSに問い合わせるのは鍵の名前（s._domainkey.d）だけで、dnsrobot.netに問い合わせるのはFromドメインと署名ドメインのDMARCポリシーだけです。唯一の例外は、ブラウザーでは確認できないEd25519署名です：その場合、ページは確認を求めたうえでメールを1回だけ当サイトのサーバーに送り、サーバーはメモリ内で確認して何も保存しません。
Ed25519のDKIM鍵は使えますか？
はい。RFC 8463で定義されており、検証側は対応が必須です。下位互換のため、RSA鍵の隣の専用セレクターに公開し、archlinux.orgがdkim-ed25519とdkim-rsaで行っているように、すべてのメッセージに二重に署名してください：Ed25519を検証できない受信サーバーにもRSA署名が残ります。Microsoft 365とGoogle Workspaceが提供するのはRSA鍵だけです。
足りないものはありますか？機能や新しいツールを提案する