DKIM fail: 鍵と DNS、転送を調べる

DKIM fail は署名の検証失敗であり、メールの信頼性を最終的に判断した結果ではありません。受信や迷惑メール判定に影響する可能性はありますが、配信結果を単独で決めるものではありません。SPF、DKIM、DMARC、経路、メールボックスを整えるには、ビジネスメールのガイドも参考になります。

送信側では正常に見えても、Gmail、Microsoft、Yahoo で dkim=fail と表示されることがあります。ほかの認証結果や受信側の方針によって、迷惑メール判定、制限、拒否につながる場合があります。原因は DNS、送信システム、署名後にメールを書き換えるセキュリティ機器などです。

推測ではなく障害調査として扱いましょう。認証結果を読み、失敗の種類を分け、セレクターと鍵を確認します。署名後の処理を調べてから、問題の箇所を修正します。

dkim fail は何を意味するか

DKIM fail は、受信サーバーが暗号署名を正常に検証できなかったことを示します。本文や署名対象ヘッダーの変更、鍵の不一致、処理上の問題などが考えられます。鍵の欠落や DNS の問題は永続的エラーや一時的エラーになる場合があり、区別して確認します。

RFC 6376 は、bh= の本文ハッシュと b= のヘッダー署名などを定義しています。検証失敗が必ずなりすましを意味するわけではありません。署名後の変更や、送信側に対応しない公開鍵が原因の場合もあります。

DKIM は荷物の封印に似ています。受け取った荷物と封印が一致しなければ検査は失敗しますが、理由の調査は別に必要です。それだけで全体の信頼性を判断することはできません。

まず対象メールの Authentication-Results を確認します。結果と補足説明が原因の分類に役立ちます。次の例は診断項目を示していますが、通常の整合した結果ではありません。同じアライメントを満たすドメインで SPF が成功すれば、通常は DMARC も成功します。

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
  spf=pass smtp.mailfrom=example.com;
  dmarc=fail header.from=example.com

送信側を変える前に DNS を確認したい場合は、TrekMail の必要な DNS レコードと照合してください。

DKIM の問題を四つに分類する

最初の切り分けでは、本文ハッシュの不一致、セレクターや鍵、DNS 公開鍵の書式、転送やリレーによる変更を確認します。分類を誤ると、不要な鍵の交換に時間を使ってしまいます。

認証結果	考えられる意味	最初に調べる場所
`dkim=fail (body hash did not verify)`	正規化後の署名対象本文が一致しない	送信リレー、免責文、リンク変更、正規化
`dkim=fail (signature did not verify)`	鍵が一致しない、または署名対象ヘッダーが変更された	セレクター、鍵交換、送信システム、ヘッダー処理
`dkim=permerror (no key for signature)`	使用できる公開鍵が見つからない	セレクター名、DNS の参照可否、レコードの書式
`dkim=temperror`	一時的な DNS 照会の問題	権威 DNS、TTL、ネームサーバーの可用性

表は切り分けの入口です。実際の原因を追加の検証で確かめます。

原因 1: 本文ハッシュの不一致

受信した署名対象の本文を正規化して計算したハッシュが、署名の値と一致していません。元の本文とバイト単位で等しいかどうかが基準ではなく、DNS が正しいと判断できる結果でもありません。

RFC 6376 は、再計算した本文ハッシュが bh= と一致しない場合の検証失敗を説明しています。署名後の変更がよくある原因ですが、メッセージの処理方法も調べる必要があります。

主な原因は次のとおりです。

Microsoft 365、Exchange、セキュリティゲートウェイが署名後に法的注意書きを追加する。
Mimecast、Barracuda、Proofpoint などのフィルターがリンクを書き換える。
リレーが正規化ルールで許容されない空白や改行の変更を行う。
アプリが先に署名し、その後のゲートウェイが MIME 境界や [External] の表示を追加する。

c= を確認します。c=simple/simple は緩和方式より厳しいルールです。RFC 6376 の緩和本文正規化は行末の空白を無視し、行内の連続する空白をまとめます。一部の書式変更は許容できますが、実質的な内容変更を修復することはできません。

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=tm1; h=from:to:subject:date:mime-version;
 bh=...; b=...

署名の位置も見直しましょう。内部での内容変更が完了してから、管理できる最後の送信地点で署名するのが有効です。ただし、その後の外部システムによる変更まで防げるわけではありません。

転送ではメール転送の設定とドメインのメールを Gmail に転送するも参考になります。直接送信のテストが成功しても、実際の転送経路で認証が維持されるとは限りません。

原因 2: セレクターや鍵の不一致

署名がセレクター X を指定していても、DNS に使用できる鍵がない、または公開鍵が署名に使った秘密鍵に対応しない場合があります。鍵の欠落は永続的エラー、鍵の不一致は署名検証失敗につながる場合があります。

署名ヘッダーのドメインとセレクターを確認します。

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...

そのセレクターを正確に照会します。

dig txt k1._domainkey.example.com +short

応答がない場合は、レコード不足、名前の誤り、キャッシュ、照会エラーなどが考えられます。応答があれば完全な公開鍵を現在の送信設定と比べます。移行や複数サービスの運用では、別の送信側が古い鍵ペアを使い続けている場合があります。

アプリは SES、サポートは Microsoft 365、キャンペーンは別の ESP という構成では、共通セレクターの変更後も古い秘密鍵を使う送信側があると、一部のメールだけ失敗することがあります。

TrekMail の管理型送信では管理型 TrekMail SMTPと実際の署名経路を確認します。Nano や自分の送信サービスでは持ち込み SMTP（BYO）をご覧ください。TrekMail は SMTP クライアントであり、実際の送信側で署名を設定する必要があります。

原因 3: 長い鍵の DNS 登録ミス

公開鍵を正しく登録できないと検証が失敗する場合があります。例えば DNS 画面が 2048 ビットの鍵を完全に保存しなかった場合です。permerror、書式エラー、不完全な公開鍵の応答などが考えられます。

RFC 8301 は RSA 鍵に最低 1024 ビットを要求し、少なくとも 2048 ビットを推奨しています。画面の入力問題だけを理由に推奨鍵長を諦めず、入力ルールを確認しましょう。

値が切り詰められたり、引用符が誤って保存されたりすると、送信側の秘密鍵が正しくても検証できません。次の例は書式を示すもので、完全な有効鍵ではありません。

; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
  "restOfThePublicKeyContinuesHere..."
)

最初の断片だけでなく、同じ TXT レコードのすべての文字列を確認します。

dig txt k1._domainkey.example.com +short

DNS プロバイダーの変更、ゾーンの移行、手動コピーの後は、値を完全に照合してください。

原因 4: 転送、リレー、アライメントの問題

転送で SPF が失敗し、さらに署名対象の変更で DKIM も失敗する場合があります。DMARC が失敗するのは、ほかに成功したアライメント付き認証経路がない場合です。実際の配信判断は受信側にも依存します。

例えば example.com から大学に送り、大学が Gmail に転送します。転送サーバーでは SPF が失敗する場合があります。DKIM は署名対象が正規化ルール上維持されれば成功できますが、フッター、リンク変更、署名対象の件名への追加で失敗する場合があります。ほかに成功したアライメント付き認証がなければ DMARC は成功しません。

Google は個人用 Gmail への通常の直接送信者に SPF または DKIM を要求します。一括送信者には SPF と DKIM、および少なくとも一つの成功経路でアライメントを満たす DMARC が必要です。転送やメーリングリストでは ARC も扱います。ARC は元の認証情報を伝えられますが、採用するかは受信側が判断します。

SRS と経路設計も重要です。SRS は書き換えたエンベロープ送信者の SPF に役立ちますが、元の From への SPF アライメントを復元しません。TrekMail の対応と実際の転送設定を確認してください。SRS は DKIM や DMARC アライメントの代わりではありません。

エイリアスが多い環境では、メールエイリアス転送と独自ドメインのメール作成も参考になります。原因が分かりにくい DKIM 失敗は、エイリアス名より転送経路に問題がある場合もあります。

dkim fail の調査手順

認証結果、セレクターと DNS、署名経路、アライメントの順に確認します。実際にはゲートウェイの変更が原因なのに、DNS を何度も変えることを避けられます。

元のメールを開き、Authentication-Results で正確な結果を記録します。
d=、s=、c= を DKIM-Signature ヘッダーで確認します。
dig でセレクターを照会し、selector._domainkey.example.com の名前を確認します。
実際に署名するプラットフォームを特定します。複数サービスでは設定が異なる場合があります。
ゲートウェイ、フィルター、転送が署名後に本文や署名対象ヘッダーを変えていないか確認します。
d= ドメインと表示上の From: ドメインのアライメントを確認し、DKIM が DMARC を満たすか調べます。

外部チェッカーに断片を貼ると、書式変更で誤った本文ハッシュエラーが出る場合があります。完全な元のメールや、書き出した .eml を使って調べましょう。

TrekMail の送信経路を整理して問題を調べる

DNS、リレー、フッターをばらばらに変えると原因を追いにくくなります。内部変更後の署名、検証できる DNS、管理型と持ち込み送信の明確な分離によって、調査しやすい構成にできます。

問題が起きやすい構成	管理しやすい構成
内部の複数ノードが署名後に変更する	管理できる最後の送信地点で変更後に署名
複数ツールで手動の鍵交換	管理型 SMTP の手順で署名と鍵を保守
自由な DNS 編集で SPF 重複や DKIM 名の誤り	統一した手順とレコードごとの検証
SRS や ARC を考慮しない転送	可能な範囲で認証を維持し、受信側の判断を考慮

TrekMail は Nano を持ち込み SMTP の無料プランとして提供しています。有料プランは月額 $3.50 からの価格目安で、管理型 SMTP を提供します。希望する鍵管理に合う実際の送信サービスを選び、SES、SendGrid、Mailgun を使う場合はそちらで DKIM を調査します。有料プランは 14 日間の試用を提供する場合があり、クレジットカードが必要です。最新の価格、機能、条件はTrekMail の料金をご確認ください。

持ち込み SMTP では送信経路全体を調べます。セレクター、鍵、署名後の変更は重要な確認点ですが、一つの DKIM 結果だけでほかの問題を否定できるわけではありません。