DMARCレポートではSPF合格、DKIM合格と表示される。すべての認証チェックは緑を返す。それでもメールはスパムに入る、あるいは全く届かない。

認証成功と配信失敗のギャップは、しばしば誤解されている技術的境界に辿り着く:DMARCアライメント。認証チェックに合格することは、自動的にDMARC合格を意味しない。そしてDMARC合格は受信トレイへの配置を保証しない。

本記事では、認証されたメールがなぜ失敗するのか、DMARCアライメントが認証とどう異なるのか、システムがどこで破綻するのか、そして組織が緑のチェックマーク以外に何を検証すべきかを解説する。

I. 認証合格がDMARC合格を意味しない理由

SPFとDKIMの検証後にアライメントチェックを行い、DMARCの結果を判定する4ステップのフロー。

SPFとDKIMは送信者のアイデンティティを検証する。DMARCは認証された識別子と表示されるFromアドレスの間のアライメントを強制する。

メールはSPFとDKIMに合格しても、認証されたドメインがヘッダーFromドメインとアライメントしていなければDMARCに失敗する可能性がある。

SPFが実際に検証するもの

SPFは、送信IPアドレスがエンベロープ送信者ドメイン(SMTP中のMAIL FROMコマンドのドメイン)の代理で送信する権限があるかをチェックする。

SPFがサイレントに失敗する場合:

  • DNS検索タイムアウトで合格または不合格ではなくtemperrorを返す
  • 10回を超えるDNS検索で検証完了前にpermerrorをトリガーする
  • エンベロープ送信者ドメインがヘッダーFromドメインと異なる—SPFは合格するが、DMARCアライメントは失敗する

例:トランザクションメールサービスがbounce.sender.com(エンベロープ)から送信するが、表示されるFromヘッダーにはyour-company.comが表示される。SPFはbounce.sender.comで合格する。DMARCはドメインがアライメントしないため失敗する。

DKIMが実際に検証するもの

DKIMはメッセージに暗号署名し、署名がDKIM署名ドメイン(DKIM-Signatureヘッダーのd=)のDNSで公開された公開鍵と一致することを検証する。

DKIMがサイレントに失敗する場合:

  • 署名鍵がローテートされてもDNSレコードが更新されない、またはキャッシュされている
  • メーリングリストや転送者が件名、フッター、添付ファイルを変更—署名が破損する
  • DKIM署名ドメインがヘッダーFromドメインと異なる—DKIMは合格するが、DMARCアライメントは失敗する

例:マーケティングプラットフォームがd=platform.comでメッセージに署名する。表示されるFromアドレスにはyour-company.comが表示される。DKIMは合格する。platform.comがyour-company.comとアライメントしないため、DMARCは失敗する。

II. DMARCアライメント:認証単独では提供しない強制レイヤー

サブドメインの違いを許容する緩和アライメントと、ドメインの完全一致を要求する厳格アライメントを比較した表

DMARCアライメントは、少なくとも1つの認証された識別子がヘッダーFromアドレスの組織ドメインと一致することを要求する。

DMARCが合格する条件:

  • アライメントされたSPF合格:エンベロープ送信者ドメインがヘッダーFromドメインと一致する(または同じ組織ドメインを共有する)
  • またはアライメントされたDKIM合格:DKIM署名ドメインがヘッダーFromドメインと一致する(または同じ組織ドメインを共有する)

DMARCが失敗する条件:

  • SPFは合格するがエンベロープ送信者ドメインがヘッダーFromとアライメントしない
  • DKIMは合格するが署名ドメインがヘッダーFromとアライメントしない
  • SPFとDKIMの両方が失敗する
  • SPFとDKIMの両方が合格するがどちらもアライメントしない

緩和アライメント vs 厳格アライメント

DMARCは2つのアライメントモードをサポートする:

緩和アライメント(デフォルト):組織ドメインが一致する必要がある。サブドメインは許可される。

厳格アライメント:ドメインが完全に一致する必要がある。

ほとんどの組織は、正当なサブドメイン送信者に対応するため緩和アライメントを使用する。厳格アライメントは、サービス固有のサブドメインに依存するトランザクションワークフローを破損する可能性がある。

認証が合格してもDMARCが失敗する場合

認証には成功しているもののアライメントに失敗し、DMARCによってメールが拒否される3つの一般的なシナリオ。

SPFまたはDKIMが合格してもDMARCアライメントが失敗する一般的なシナリオ:

サードパーティのトランザクションサービス:

  • サービスが独自のエンベロープ送信者またはDKIM署名ドメインを使用して送信する
  • ヘッダーFromには顧客のドメインが表示される
  • サービスのドメインで認証は合格する
  • ドメインがアライメントしないためDMARCは失敗する

転送されたメッセージ:

  • 元の送信者がSPFとDKIMに合格する
  • 転送者が新しいIPアドレスからメッセージを中継する
  • SPFが破損する(新しいIPが元のドメインで承認されていない)
  • メッセージが変更されていなければDKIMは生き残る可能性がある
  • DMARCはDKIMアライメントが生き残るかどうかに依存する

メーリングリスト:

  • リストが件名、フッター、添付ファイルを変更する
  • DKIM署名が破損する
  • SPFはリストサーバードメインで合格する可能性があるが、元の送信者では合格しない
  • リストがFromアドレスを書き換えない限りDMARCは失敗する

III. DMARC合格でも受信トレイ配置が保証されない理由

DMARC合格は1つの失敗条件を取り除く。レピュテーション、コンテンツ分析、苦情率、内部不正利用シグナルを上書きしない。

メールボックスプロバイダーが評価するもの:

  • DMARC認証とアライメント
  • 送信IPとドメインのレピュテーション
  • 苦情率とエンゲージメントシグナル
  • コンテンツ特性(リンク、画像、言語パターン)
  • 転送コンテキストとメーリングリストの動作

DMARC準拠にもかかわらずサイレントフィルタリング

p=rejectでDMARCに合格してもメールがスパムにフィルタリングされる、またはブロックされる場合:

  • 送信IPが以前の不正利用による悪いレピュテーションを持つ
  • 苦情率がメールボックスプロバイダーのしきい値を超える
  • コンテンツがスパム分類シグナルをトリガーする
  • 受信者のエンゲージメント履歴が低い開封率または高い削除率を示す
  • 送信ドメインが新規登録されている、または送信履歴がない

強制が受信者の動作に依存する場合:

  • 一部のメーリングリストと転送者はDMARCポリシーを尊重しない
  • 一部のメールボックスプロバイダーは、行動シグナルが協調的な不正利用を示す場合、DMARCシグナルの優先度を下げるレピュテーションオーバーライドを適用する
  • 内部不正利用チームは、行動シグナルが協調的な不正利用を示す場合、認証を上書きする可能性がある

DMARC強制(p=quarantineまたはp=reject)は、受信者に認証されていないメッセージを拒否または隔離するよう指示する。受信者がその指示を尊重するかどうかは、フィルタリングアーキテクチャ、転送処理、ローカルポリシーに依存する。

IV. 失敗する可能性があるものとその検出方法

失敗モード1:認証は合格するがアライメントが失敗する

何が起こるか:

  • SPFまたはDKIMが合格を返す
  • DMARCレポートがreason=alignment_failureでdmarc=failを示す
  • 受信サーバーはDMARCポリシーとレピュテーションに応じてメッセージを配信する可能性がある

検出:

  • auth_results.spf.result=passまたはauth_results.dkim.result=passだがpolicy_evaluated.dmarc=failである行についてDMARC集計レポートを確認する
  • エンベロープ送信者ドメインまたはDKIM署名ドメインがヘッダーFromとアライメントしているかチェックする

修正:

  • サードパーティ送信者をアライメントされたエンベロープ送信者またはDKIM署名ドメインを使用するよう設定する
  • 完全一致が実現不可能な場合はサブドメインアライメントを使用する
  • トランザクションサービスがあなたのドメインでのDKIM署名をサポートしているか検証する

失敗モード2:DMARCは合格するがメッセージがフィルタリングされる

何が起こるか:

  • DMARCレポートがpolicy_evaluated.dmarc=passを示す
  • メッセージが受信トレイに届かない
  • SMTP拒否やバウンスは発生しない

検出:

  • ポストマスターツール(Google Postmaster Tools、Microsoft SNDS)を通じた苦情率モニタリング
  • 低い開封率または高いスパムフォルダー配置を示すエンゲージメント指標
  • 送信IPとドメインのレピュテーションモニタリング

修正:

  • 送信レピュテーションと苦情ソースを監査する
  • スパムトリガーパターンについてコンテンツを確認する
  • 購読者の同意とリストの衛生状態を検証する
  • 複数のメールボックスプロバイダーへの配信性をテストする

失敗モード3:転送が認証を破損する

何が起こるか:

  • 元の送信者がDMARCに合格する
  • 転送者が新しいIPからメッセージを中継する
  • SPFが失敗する(新しいIPが承認されていない)
  • メッセージが変更されていなければDKIMは生き残る可能性がある
  • DMARCはDKIMアライメントの生存に依存する

検出:

  • forwardedディスポジションまたはSPFfailでDKIMpassを示すDMARCレポート
  • 個人アカウントに転送するユーザーから報告される配信問題

修正:

  • 転送の影響を減らすためp=rejectではなくp=quarantineを使用する
  • 転送パターンについてDMARCレポートをモニターする
  • 転送動作についてユーザーとコミュニケーションを取る

失敗モード4:親ドメイン強制にもかかわらずサブドメインスプーフィング

何が起こるか:

  • 親ドメインがp=rejectでDMARCを強制する
  • サブドメインに明示的なDMARCレコードがない
  • 攻撃者がサブドメインからスプーフィングメッセージを送信する
  • DMARCポリシーが適用されるが、アライメント評価はサブドメインの使用に応じて異なる場合がある

検出:

  • サブドメインの認証失敗を示すDMARCレポート
  • サブドメインアドレスを標的とするフィッシングレポート

修正:

  • アクティブなサブドメインに明示的なDMARCレコードを公開する
  • 親ドメインレコードでsp=rejectを使用してサブドメインポリシーを強制する
  • 不正なサブドメイン使用についてDMARCレポートをモニターする

V. 文書化および検証すべき事項

認証合格がDMARC準拠を意味すると仮定する組織は、運用上の盲点を招く。以下を文書化すること:

すべての送信者の認証された識別子:

  • エンベロープ送信者ドメイン(SPFチェックドメイン)
  • DKIM署名ドメイン(d=値)
  • ヘッダーFromドメイン(表示される送信者)
  • アライメントが緩和か厳格か

メールストリームごとの送信者設定:

  • トランザクションメール:CRM、サポートチケット、パスワードリセット
  • マーケティングメール:ニュースレタープラットフォーム、プロモーションキャンペーン
  • 運用メール:内部通知、システムアラート
  • サードパーティサービス:SaaSツール、プラグイン、統合

DMARCレポートで観察される失敗条件:

  • spf=passまたはdkim=passでのdmarc=failの量
  • 転送関連失敗の頻度
  • 不正な送信者の試行
  • サブドメインスプーフィングパターン

レピュテーションとフィルタリングコンテキスト:

  • 送信ドメインとIPごとの苦情率
  • スパムフォルダー配置のトレンド
  • エンゲージメント指標(開封率、削除率)
  • 主要な受信者からのポストマスターツールフィードバック

VI. Skysnagがアライメント検証とモニタリングをサポートする方法

Skysnag Protectは、メールストリームとサードパーティサービス全体でアライメント失敗、不正な送信者、認証ギャップを識別する。

アライメントの可視性:

  • 送信者ごとのSPF、DKIM、アライメントステータスを示す集計DMARCレポート解析
  • アライメント失敗を伴う認証合格の検出
  • アライメントされていない識別子を使用するサードパーティサービスの識別

送信者の承認:

  • 承認済みおよび未承認のメールソースのインベントリ
  • シャドウITと管理されていないサードパーティ送信者の検出
  • SPFインクルードとDKIM署名設定の検証

強制のステージング:

  • ドメイン、サブドメイン、送信者グループごとの段階的なポリシー強制
  • p=noneからp=quarantineまたはp=rejectへ移行する前の影響モニタリング
  • コンプライアンスと監査プログラムのための証拠収集

Skysnagを使用してDMARCモニタリングを開始し、認証された送信者があなたのドメインとアライメントしているか検証する:

VII. 重要なポイント

  • SPFまたはDKIMに合格してもDMARCに合格するわけではありません。 アライメントには、認証されたドメインがヘッダーFromドメインと一致する必要があります。
  • DMARCに合格しても受信箱への配置は保証されません。 メールボックスプロバイダーは、認証と並行して、評判、コンテンツ、苦情率、エンゲージメントを評価します。
  • 認証が合格してもDMARCアライメントは失敗する可能性があります。 エンベロープ送信者ドメインの不一致(SPF)とDKIM署名ドメインの不一致が、アライメント失敗の原因となります。
  • 転送とメーリングリストは認証を壊すことがよくあります。 リレーIPが変更されるとSPFは失敗します。メッセージが変更されるとDKIMは失敗します。
  • サブドメインスプーフィングは親ドメインの強制を回避できます。 明示的なサブドメインDMARCレコードまたはsp=rejectを使用して、サブドメインポリシーを強制します。
  • 認証は必要ですが十分ではありません。 配信性は、認証、評判、コンテンツ、受信者の行動に依存します。
  • DMARCレポートはアライメントが失敗する場所を示します。 spf=passまたはdkim=passであるがdmarc=failとなる行について、集約レポートを監視します。
  • サードパーティ送信者は一般的にアライメントギャップを生じさせます。 トランザクションサービス、マーケティングプラットフォーム、SaaSツールがアライメントされた識別子を使用していることを確認します。
  • 組織はメールストリームごとに認証された識別子を文書化すべきです。 エンベロープ送信者ドメイン、DKIM署名ドメイン、ヘッダーFromドメインを追跡し検証する必要があります。
  • Skysnag Protectはアライメント失敗と不正な送信者を特定します。 Skysnagを使用して、アライメントを検証し、シャドーITを検出し、安全に強制をステージングします。