SPF vs DKIM

このガイドはメール認証ガイドの一部です。関連記事: DKIM vs DMARC と SPF vs DMARC。

SPF は、接続してきた IP と SMTP エンベロープ送信者（MAIL FROM や HELO）があなたのドメインとして送信する権限を持つかを検証します — これは DKIM には評価できない領域です — 一方で DKIM は、SPF には保護も証明もできない、選択されたヘッダーとメッセージ本文の暗号的完全性とドメイン識別を、署名（d=）を通じて検証します。

背景と経緯として、Sender Policy Framework（SPF）は SMTP トランザクションに結び付いた DNS ベースの認可チェックです。サーバーがメールを配信しようと接続してくると、受信側は、エンベロープの MAIL FROM または HELO/EHLO に現れるドメインについて、その送信元 IP が送信を許可されているかをテストします。対照的に、DomainKeys Identified Mail（DKIM）はコンテンツレベルの認証システムです。送信者は選択したヘッダーと本文に署名し、受信側は selector._domainkey.domain から公開鍵を取得して、何も改ざんされていないこと、そして署名者のドメイン（d=）が実在することを検証します。

なぜこの区別が重要なのでしょうか。攻撃者が異なる隙間を悪用するからです。SPF がなければ、誰でも任意の IP から SMTP レベルであなたのドメインを装って送信できます。DKIM がなければ、中継者（フォワーダー、メーリングリスト）や悪意ある者が、受け渡し後にメッセージ内容を検出されずに改変できます。現代の受信側は通常、両方を DMARC のもとで評価します。DMARC は、ユーザーが From: で目にするドメインと、SPF 認証済みのエンベロープドメインまたは DKIM の d= ドメインとの整合を要求し、その上であなたのポリシーを適用します。

AutoSPF は、SPF を隙のないものにし — IP やベンダーが変わってもその状態を保ち続け — さらに DKIM/DMARC を意識した診断を提供して、両方の仕組みが一貫して合格し整合するようにするために作られています。90 日間の AutoSPF ベンチマーク（仮想だが現実的なもの）では、28 の中堅市場ドメインと 180 万通のメッセージを対象に、自動的な include 統合と安全なフラット化の後で SPF permerror が 92% 減少し、顧客がこれらの SPF 修正を DKIM 整合性の調整と組み合わせたところ、DMARC 合格率は 88% から 96% に改善しました。

それぞれが何を検証するか — そしてなぜもう一方にはできないのか

このセクションは単独で成立します。SPF はトランスポート層の認可を確認し、DKIM はトランスポート後のメッセージ完全性とドメイン識別を確認します。

• SPF の範囲
  • 検証内容: 接続してきた IP がエンベロープドメイン（RFC5321.MailFrom）または HELO/EHLO ホストに対して認可されていること。
  • 仕組み: ip4/ip6、include、a、mx、exists、および redirect などの修飾子を持つ DNS TXT レコード v=spf1。合否はコンテンツが信頼される前に判定される。
  • なぜ DKIM にはできないか: DKIM は接続してきた IP や SMTP エンベロープを見ない。もっぱらメッセージ内容と DNS 鍵に対して動作する。
• DKIM の範囲
  • 検証内容: From、To、Subject、Date、Message-ID といった選択されたヘッダー（h=）と本文ハッシュ（bh=）に対する暗号署名。署名者のドメイン d= に結び付けられている。
  • 検出対象: 転送中の改ざん（例: Subject の改変、リンクの注入、本文の変更）を検出し、経路とは独立に署名者のドメインを認証する。
  • なぜ SPF にはできないか: SPF はコンテンツに署名も記憶もしない。受け渡し後、フォワーディングや改変は、元の SMTP セッションに結び付いた SPF 結果に影響しない。

一目で分かる比較

• SPF が固有に検証するもの:
  • 接続元 IP の認可
  • エンベロープ MAIL FROM/HELO の識別
• DKIM が固有に検証するもの:
  • 署名によるヘッダー/本文の完全性
  • フォワーディングの影響を受けない署名者ドメイン（d=）の真正性

AutoSPF がどう役立つか: AutoSPF は、あなたのドメインとして送信する権限を持つすべてのサービスと IP が、10 ルックアップの予算内で SPF に明示的に表現されていることを継続的に検証し、SPF neutral/permerror を引き起こす隙間を指摘し、DKIM/DMARC の整合結果を可視化するので、フォワーディングが SPF を壊す場面では DKIM に委ねられます。

SMTP とメッセージの内部で各仕組みがどう適用されるか

このセクションは単独で成立します。SPF は接続時に動作し、DKIM は配信後に動作します。

SPF: SMTP トランザクションの一部（MAIL FROM と接続元 IP）

• SPF は Return-Path（エンベロープ MAIL FROM）や HELO/EHLO ドメインを送信元 IP に照らしてチェックする。
• MAIL FROM が空の場合（バウンス）、受信側はしばしば HELO/EHLO ドメインで SPF を評価する。
• SPF はトランスポートに束縛されるため、ホップごとに評価される。フォワーダーが SRS（Sender Rewriting Scheme）なしで別の IP から再送すると、次のホップでは SPF はしばしば失敗する。

AutoSPF との関連: AutoSPF は複数の観測点から受信側の SPF 評価をシミュレートし、include 間で DNS ルックアップを予算配分し、フォワーダーや第三者が SRS または明示的な include を必要とする場面を強調します。

DKIM: ヘッダーと本文の暗号的な結び付け

• DKIM は h= に列挙された選択済みヘッダー（一般的には From、Date、Subject、To、MIME-Version、Message-ID）に署名し、simple/relaxed の正規化を用いて本文ハッシュ bh= を計算する。
• 署名の d=domain と s=selector は、公開鍵（p=）を持つ DNS TXT レコードを指す。
• 受信側はハッシュを再計算する。転送中のいかなる改ざん（例: フッター注入、Subject タグの変更）も検証を破綻させる。

AutoSPF との関連: AutoSPF はあなたの DKIM 鍵を発行しませんが、Authentication-Results ヘッダーと DMARC 集計を解析して、どのメッセージが DKIM に依存し、どれが SPF に依存しているか、フッター注入で DKIM がいつ壊れるか、どの送信者がセレクター更新を必要とするかを示します。

事例（仮想だが現実的）: あるヘルステックのニュースレターが、Subject に [List] を付加し法的フッターを追加するリストサーバーを経由してルーティングされていました。SPF は元のホップでは合格しましたが、フォワード後に失敗しました。DKIM は当初、リストが署名済みヘッダーと本文を改変したため失敗しました。送信者が DKIM を relaxed/relaxed に切り替え、Subject を h= から除外（From と Date は維持）したところ、DKIM は一貫して合格するようになりました。その後 AutoSPF は DMARC における DKIM の役割を高める（adkim=s）ことを推奨し、初回ホップ用の SPF include を維持しました。

導入の違い、DNS 形式、そして避けるべき落とし穴

このセクションは単独で成立します。実装者は SPF の 10 ルックアップ制限と DKIM のセレクター/鍵要件をやりくりしなければなりません。

SPF レコードの仕組み

• 形式: ルート（または/およびサブドメイン）に置く TXT で、v=spf1 … -all を含む。
• Includes/redirect: include:vendor.example.com はベンダーの仕組みを追加する。redirect=domain は評価全体を別ドメインの SPF に委ねる。
• 10 ルックアップ制限: include、a、mx、exists、ptr がそれぞれカウントされる。ネストした include も加算される。10 を超えると permerror を返す。SPF ルックアップ制限は、多数のベンダーがあると容易に超過してしまう。
• TTL の助言: 1 時間（3600 秒）が機動性の面で実用的。緊急変更は 1 日単位の TTL より速く伝播する。

よくある SPF の落とし穴

• 同一ラベルに複数の SPF TXT レコード（受信側は permerror として扱うことがある）。
• ネストした include や多数のホストにわたる mx/a の使用により 10 ルックアップを超過する。慎重な SPF include の管理がこれを避ける。
• ptr や +all の使用。これらは非推奨で悪用されやすい。
• include を意図しているのに redirect を誤用する（redirect は評価を上書きする）。

AutoSPF との関連: AutoSPF は冗長な仕組みを自動統合し、ベンダーのネットを重複排除し、変動しやすい include をヘルスチェック付きでキャッシュされた ip4/ip6 へと安全にフラット化し、10 ルックアップの予算配分を強制します — ベンダーの機動性を犠牲にせずに permerror を防ぎます。

DKIM レコードの仕組み

• 形式: selector._domainkey.example.com に置く TXT で、k=rsa; p=base64key; t=y（任意のテスト用）。
• セレクター: s2026q1 のような人間が読めるセレクターや時刻符号化されたセレクターにより、ローテーション用に重複した導入が可能になる。
• 鍵長: 2048 ビット RSA が推奨。1024 ビットは非推奨。ECDSA（ed25519）は台頭しつつあるが、まだすべての受信側に普遍的に受け入れられてはいない。
• TTL の助言: 1〜4 時間。二重公開の期間を設けて鍵をローテーションする。

よくある DKIM の落とし穴

• 余分な引用符や改行を付けて鍵を公開し、無効な base64 を生じさせる。
• DNS で適切な 255 バイトのチャンク分割をしない、サイズ超過のレコード。
• 正規化のミス（改変されやすいヘッダーへの署名、または中継者が空白を調整する場面での simple/simple の使用）。
• l=（本文長制限）の使用。これはリスクが高く、部分的に改変されたコンテンツで誤った合格を招きうる。

AutoSPF との関連: AutoSPF の DKIM チェックは、欠落した/無効なセレクター DNS レコードを指摘し、複数の受信側からの検証をテストし、あなたのメールフロー（例: メーリングリスト）がメッセージを改変しやすい場合に、より安全な正規化/ヘッダーセットを提案します。

SPF が失敗しても DKIM が救ってくれるとき — そしてその逆

このセクションは単独で成立します。現実のフローでは片方の仕組みが頻繁に壊れます。もう一方が DMARC を担えるよう計画しましょう。

• SRS なしのフォワーディング
  • SPF: フォワーダーのホップでしばしば失敗する（送信元 IP がもはや認可されていない）。
  • DKIM: 改変されていなければ合格する。DMARC は DKIM 整合を経由してなお合格しうる。
  • AutoSPF: フォワード後に SPF が失敗するドメイン/ASN を報告し、それらのストリームについて DKIM 整合の強化を推奨する。
• メーリングリスト（Subject へのタグ付け、フッター挿入）
  • DKIM: 本文/ヘッダーの変更により頻繁に失敗する。
  • SPF: 元のホップでは合格しうるが、再送されると失敗する。SRS 対応のリストは SPF を保持できるが、多くはそうでない。
  • AutoSPF: Authentication-Results 内のリストサーバーのパターンを識別し、DMARC を保持するための relaxed 正規化と From: 書き換え戦略（RFC 5322）を提案する。
• 第三者送信者と一括マーケティング
  • SPF: ベンダーの include を含め忘れたり、ルックアップを超過すると失敗する。
  • DKIM: ベンダーがあなたのドメインで署名し（d=yourbrand.com）、セレクターが正しければ合格する。ベンダーが自分のドメインで署名し、DMARC が厳格な整合を要求する場合は失敗する。
  • AutoSPF: カタログ化された include エンドポイントを通じてベンダーをオンボードし、ベンダーの IP の入れ替わりを追跡し、DMARC を壊す非整合ドメインで DKIM が署名されているときに警告する。
• トランザクションメール対企業リレー
  • 企業リレーは Return-Path や HELO を書き換えることがあり、SPF に影響する。一方、元のアプリケーションからの DKIM は、再ラップされなければ残存する。
  • AutoSPF: エンベロープとヘッダーの両方の整合をシミュレートし、ストリームごとにどちらの仕組みが DMARC を満たすかを示す。

独自のデータポイント（仮想、集計）: 匿名化された 40 ドメインの AutoSPF コホートでは、フォワーディング中の DMARC 合格の 27% が DKIM 整合のみに依存していました。2 つの EDU テナントでフォワーダーに SRS を有効化したところ、DKIM を損なうことなく、フォワードされたメールの SPF 失敗が 61% 減少しました。

DMARC の整合性、ポリシー、そして両者の共通ベストプラクティス

このセクションは単独で成立します。DMARC はヘッダー From: との整合に基づいて判断します。

• 整合ルール
  • SPF: RFC5321.MailFrom のドメイン（MAIL FROM が空なら HELO）が、ヘッダー From: と整合していなければならない（組織単位＝relaxed、または完全一致＝strict）。
  • DKIM: DKIM 署名の d= ドメインが、ヘッダー From: と整合していなければならない。
  • 整合した SPF または整合した DKIM が合格すれば、DMARC は合格する。
• ポリシーの道筋
  • p=none から始め、rua= 集計レポートを収集する。失敗率と誤検知が安定するにつれて、quarantine、そして reject へ移行する。
  • なりすまされやすいブランドには adkim=s と aspf=s を使う。移行中は破損を減らすため relaxed（r）を維持する。
• 鍵とレコードの衛生管理
  • DKIM: 2048 ビット鍵を 6〜12 か月ごとにローテーションする。重複したセレクターを維持し、侵害された場合は古い鍵を速やかに廃止する。
  • SPF: 10 DNS ルックアップ以内に収める。自動更新がない限りフラット化よりも include を優先し、IP の入れ替わりによる不意の事態を避ける。AutoSPF のようなツールがその更新を自動化する。

AutoSPF との関連: AutoSPF は送信者ごとの整合カバレッジを算出し、送信元ごとに DMARC 合格が SPF 由来か DKIM 由来かを示し、ストリームのリスクに応じた adkim/aspf モードを推奨し、SPF を自動維持するので、フォワーディングが SPF を妨げる場面では DKIM に寄りかかれます。

ケーススタディ（仮想）: 小売業者 AcmeFit は 12 の SaaS 送信者をオンボードし、14 の SPF ルックアップと頻繁な permerror を生じさせていました。AutoSPF は include を統合し、変動しやすい 2 つのベンダーを安全にフラット化し、マーケティング用サブドメインの SPF を独立したレコードに分割しました。permerror はゼロに落ち、DMARC を quarantine かつ DKIM relaxed 整合に設定したところ、30 日間で Gmail の受信トレイ配置が 4.8 パーセントポイント改善しました。

失敗モード、診断、そしてツール

このセクションは単独で成立します。それぞれがどう失敗し、どう素早く直すかを知りましょう。

よくある SPF 失敗の原因

• 受信側が他のシグナルを否定的に評価するときの、~all による Neutral/SoftFail。
• 10 超の DNS ルックアップ、構文エラー、複数の SPF TXT レコード、または再帰的な redirect ループによる Permerror。
• SPF レコードが存在しない、あるいは空/無効な場合の None。

診断の仕方

• Authentication-Results を確認する: spf=permerror（DNS ルックアップが多すぎる）smtp.mailfrom=…
• dig/nslookup を使って include チェーンを展開し、ルックアップ数を数える。
• 異なるネットワークから複数のチェッカーで検証する。

AutoSPF との関連: AutoSPF のリアルタイム評価器は、受信側がするのとまったく同じようにあなたの SPF を展開し、ルックアップ予算を示し、再帰を指摘し、ワンクリックで修正済みレコードを提案します。

よくある DKIM 失敗の原因

• simple 本文正規化でのフッター注入や空白変更による、本文ハッシュの不一致。
• 中継者が Subject タグを追加したり、relaxed でカバーされないヘッダーを並べ替えたときの、ヘッダーリストの不一致。
• セレクターの DNS エラー: p= 鍵の欠落、誤ったラベル、TXT の書式/引用符の問題。
• 送信者側で更新されていない、失効または取り消された鍵。

診断の仕方

• Authentication-Results: dkim=fail（本文ハッシュが検証されなかった）header.d=example.com header.s=s2026q1
• セレクターの DNS レコードを取得し、余計な引用符のない有効な base64 の p= を確認し、2048 ビットを検証する。
• 各ホップを通す合成送信でテストし、正規化を変えてみる。

AutoSPF との関連: AutoSPF は DKIM 失敗をホップごとの Received チェーンと突き合わせ、どの MTA がメッセージを改変したかを指摘し、耐性のあるヘッダーセット（例: From、Date、MIME-Version、Message-ID を含める。Subject へのタグ付けが予想される場合は Subject を避ける）を推奨します。

不可欠なテストと監視のツール

• 合成送信: Gmail、Outlook、および中立の検証器（例: check-auth@verifier.port25.com）宛てに送り、SPF/DKIM/DMARC の結果を取得する。
• DNS ツール: SPF/DKIM TXT 用の dig/host/nslookup、およびオンラインの SPF フラット化シミュレーター。
• DMARC レポート: 量的なパターンには集計（rua）、詳細な失敗にはフォレンジック（ruf）（プライバシー/規制上の制約に留意する）。

AutoSPF との関連: AutoSPF は rua XML を取り込み、送信元ごとの合否を正規化し、異常なスパイク（例: 突然の include 変更）を強調し、受信側の解釈を比較するテスト送信ハーネスを提供します。

鍵のライフサイクルと変更管理

このセクションは単独で成立します。DKIM 鍵は計画的にローテーションし、SPF は生きたインフラとして管理しましょう。

• DKIM のライフサイクル
  • 2048 ビット RSA を使う。ローテーション中は 2 つのアクティブなセレクターを維持する。
  • セレクターの命名: sYYYYqN、または s2026q1-marketing のようなベンダー・目的別。
  • ローテーション頻度: 6〜12 か月。侵害された場合は即座に取り消して再鍵化する（p= を空にするかレコードを削除し、そのセレクターでの署名を停止する）。
• SPF のライフサイクル
  • ベンダーの入れ替わり: include を速やかにオンボード/オフボードする。古いベンダーを認可したまま放置しない。
  • サブドメインのスコープ設定: 大量ストリーム（例: mail.m.example）を別個の SPF で分離し、ルックアップ予算を管理可能に保つ。
  • 緊急変更: 低めの TTL と変更ログを維持する。

AutoSPF との関連: AutoSPF はベンダーの include を追跡し、プロバイダーが IP レンジを追加/削除したときに警告し、フラット化済みレコードを予定どおり自動更新し、監査証跡をエクスポートします。さらに、DMARC データで観測された DKIM セレクターを棚卸しするので、どの鍵をローテーションすべきか分かります。

ARC: フォワーディングの限界に対処する

このセクションは単独で成立します。ARC は複雑なフローにおいて SPF/DKIM/DMARC を補完します。

• ARC の役割
  • Authenticated Received Chain（ARC）は、中継者が元の SPF/DKIM/DMARC の結果と通った経路を証言できるようにする。
  • 受信側は ARC セットを勘案し、リストやフォワーダーによって改変されたメッセージが入口では正当であったと信頼できる。
• 使うべき場面
  • DKIM や SPF を日常的に壊すフォワーディングサービス、メーリングリスト、キャンパス/企業ゲートウェイを運用している場合。
  • ARC は SPF/DKIM/DMARC を置き換えるものではない。ホップをまたいだ連続性を提供する。

AutoSPF との関連: AutoSPF は、ARC によって DMARC 失敗を緩和できる可能性がある場面（例: ARC-Seal が存在する状態で 2 番目のホップにおいて一貫した dkim=fail）を強調し、最も重要な中継者への ARC 導入を優先できるよう運用者を支援します。

FAQ

SPF では -all と ~all のどちらを使うべきですか？

• -all（ハードフェイル）は強いポリシーを示しなりすましを減らすが、移行中に誤った拒否を増やしうる。
• ~all（ソフトフェイル）はオンボーディング中により安全。DMARC p=none/quarantine と組み合わせ、DMARC データが安定したら -all へ移行する。
• AutoSPF はドメインごとのポリシー段階を推奨し、-all によってブロックされてしまう正当な送信元を警告する。

厳格な DMARC 整合（adkim=s, aspf=s）は必要ですか？

• 厳格な整合はいとこドメインによるなりすましを阻止するが、正当なフロー（例: ベンダーが自分の d= で署名する場合）を壊しうる。
• relaxed から始め、ベンダーがあなたのドメインで署名するようになったら、リスクの高いブランドやストリームについて strict へ移行する。
• AutoSPF の整合カバレッジレポートは、ストリームごとの準備状況を示す。

DKIM 鍵はどのくらいの頻度で、どのサイズでローテーションすべきですか？

• 6〜12 か月ごとにローテーションする。現在は 2048 ビット RSA を使う。
• ローテーション中は中断を避けるため 2 つのセレクターをアクティブに保つ。
• AutoSPF はトラフィックで観測されたセレクターを棚卸しするので、ローテーションのリストが漏れなく揃う。

複数の SPF レコードを持てますか？

• いいえ。ドメインは単一の SPF TXT レコードを公開しなければならない。複数のレコードは permerror を生じさせうる。
• AutoSPF は仕組みを単一の標準準拠レコードにマージし、構文を検証する。

SPF は合格するのに DMARC が失敗するのはなぜですか？

• SPF 認証されたドメイン（MAIL FROM または HELO）が、ヘッダー From: ドメインと整合していないから。
• エンベロープドメインが可視の From: と一致する（または同じ組織ドメイン内にある）ようにするか、d= が整合した DKIM に頼る。
• AutoSPF は SPF の上に DMARC 整合をシミュレートし、これを捕捉する。

結論と製品の統合

SPF と DKIM は、メールの信頼問題の異なる半分をそれぞれ解決します。SPF は送信 IP と SMTP エンベロープドメインを認可し、DKIM はメッセージそのものの完全性とドメイン識別を証明します。DMARC のもとで両者が組み合わさることで、あなたが実際に運用するフローにおいて、なりすましをブロックし改ざんを検出します。実務上の課題は継続的な衛生管理です。ベンダーが変わっても SPF を 10 ルックアップ制限内に保ち、DKIM が現実の改変を生き延びるようにし、受信側がユーザーの目にするものを信頼できるよう両者を DMARC ポリシーと整合させることです。

AutoSPF はその衛生管理を運用化します。具体的には:

• ドメインごとに単一で正しい SPF レコードを構築し維持する。仕組みを重複排除し、ルックアップを予算配分し、変動しやすいベンダーをヘルスチェック付きで安全にフラット化する。
• DMARC 集計を監視し、DMARC 合格が SPF 由来か DKIM 由来かを示すので、整合を最適化しフォワーディングを生き延びられる。
• 受信側のように include チェーンを展開し、permerror を指摘し、現場で観測された DKIM セレクターの問題を突き合わせることで、失敗を素早く診断する。
• あなたのトラフィックのデータに基づいて — 当て推量ではなく — ~all から -all へ、relaxed から strict 整合へと、ポリシーの強化を導く。

次の四半期に新しいマーケティングプラットフォームのオンボーディング、ESP の統合、あるいは DMARC を reject へ強化することが含まれているなら、AutoSPF はそれを自信を持って行うための安全柵を提供します — こうして SPF が DKIM にできないことを検証し、DKIM が SPF にできないことを検証し、DMARC があなたのブランドの信頼を端から端まで強制します。