SPF・DKIMがpassでも、DMARCに失敗するのはなぜ？
メールの認証結果にはpassがあるのに、DMARCはfailになる。これは矛盾とは限りません。認証に成功したドメインと、受信者に見えるFromのドメインが違うことがあるからです。メールの中に出てくる3つのドメインを並べると、どこが食い違っているか見えてきます。
まず、どのドメインの話かをそろえる
SPFは接続元IPがMAIL FROMなどのドメインを使って送信する許可を調べます。DKIMは署名を検証し、署名ドメインがそのメールに責任を表明したことを確かめます。どちらも、単独では画面に見えるFromとの対応を保証しません。
似ていても役割は違う
SPFにはHELO/EHLOの確認もありますが、DMARCで使うSPFの識別子はMAIL FROM側です。表示名やReply-To、DKIMのセレクタs=はalignmentの比較対象ではありません。根拠はRFC 7208 §2、RFC 6376 §3.5、RFC 9989 §4.4です。
| 場所 | 例 | 役割 |
|---|---|---|
| Fromヘッダー | news@example.com | 表示上の著者。DMARCが基準にするドメインはexample.com |
| SMTP MAIL FROM | bounce@mailer.example.net | 配送中に使う差出人。通常、配送エラーの返送先にも使う |
| DKIM-Signatureのd= | example.com | 署名に責任を持つドメイン |
alignmentは、認証したドメインとFromのつながり
適用するDMARCポリシーがあるメールでは、SPFがpassかつFromと整合する、またはDKIMがpassかつFromと整合する、のどちらかでDMARCはpassになります。両方のpassは必須ではありません。DKIM署名が複数ある場合も、少なくとも1つがこの条件を満たせば足ります。
strictとrelaxed
adkimとaspfでそれぞれ指定し、省略時はrelaxedです。組織ドメインは単純に末尾2区切りを取る規則ではありません。現行のRFC 9989 §4.10.2はDNS Tree Walkで求めます。旧RFC 7489のPublic Suffix Listに基づく説明とはここが異なります。
| 方式 | 比較する範囲 | 例 |
|---|---|---|
| strict | ドメイン名そのものが一致 | Fromがexample.com、認証側もexample.com |
| relaxed | 組織ドメインが一致 | 組織ドメインが共にexample.comと判定されるなら、news.example.comとmail.example.comも整合 |
同じFromで3通を比べる
Fromをnews@example.com、適用するDMARCポリシーありとします。次の例は、受信側が実際に認証した結果を使う前提です。ヘッダーにpassと書くだけでは認証になりません。
認証結果からDMARCへ進む
2行目が「SPFもDKIMもpassなのにDMARCはfail」の例です。配送サービス自身のドメインで認証するだけでなく、Fromに使うドメインとどう対応させるかが必要になります。
| SPF | DKIM | DMARCの読み方 |
|---|---|---|
| pass / mailer.example.net | pass / d=example.com | DKIMが認証成功し、Fromとも完全一致するのでpass |
| pass / mailer.example.net | pass / d=example.org | どちらもFromと整合しないのでfail |
| fail | pass / d=example.com | SPFが失敗しても、整合するDKIMがあるのでpass |
転送と配信ポリシーは、passだけでは決まらない
転送で接続元が変わるとSPFの結果が変わることがあります。DKIMは署名対象が保たれれば転送後も検証できますが、メーリングリストが件名や本文を書き換えると失敗し得ます。失敗から即座に不正メールと断定する前に、実際の配送経路を見ます。こうした間接配送の課題はRFC 7960 §3にも整理されています。
p=none・quarantine・rejectは受信側への希望
DMARCのp=は失敗したメールについての扱いを示します。受信側には独自の判定もあるため、rejectで必ず拒否、passなら必ず受信箱へ配達、とは限りません。認証はリンク先や本文の安全性も保証しません。ポリシーを強める前に、正規の配信元・転送経路・集計レポートを照合すると、正常なメールへの影響を見積もれます。
DNSの公開状態と、1通の認証結果を分けて調べる
Online Toolsのメール認証チェッカーは、入力したドメインやDKIMセレクタをサーバーへ送り、DNSのTXT/CNAMEを調べます。例としてexample.comとセレクタs1なら、s1._domainkey.example.comが鍵の照会先になります。実際に使っているセレクタは、送信サービスの設定やメールのDKIM-Signatureのs=から探せます。
この結果だけではDMARC passを判定できない
チェッカーは受信したメールの署名を検証せず、SPFのinclude先を再帰評価したりDMARCの組織ドメインを探索したりもしません。表示するSPF照会数は表面の項目数による概算です。セレクタ自動候補で鍵が見つからなくても、DKIM未設定とは限りません。1通の記録を読むときはメールヘッダーの読み方へ進むと、DNS設定と受信側の観測を結び付けられます。
現行仕様と関連する解説
RFC 9989 §4.4：alignmentと§5.3：受信側の処理がDMARCの根拠です。RFC 9989はRFC 7489・9091を置き換え、集計報告はRFC 9990、失敗報告はRFC 9991に分かれています。DNS設定変更後の見え方はDNSのTTLとキャッシュへ。