要約

  • DMARCは、SPFまたはDKIMで認証されたドメインの少なくとも一つがRFC5322.FromのAuthor Domainと整合すれば pass になる。認証されるのはドメイン使用であり、ローカル部、表示名、人、本文ではない。
  • fail も不正の確定ではない。正当な転送やメーリングリストがSPF整合を失わせ、DKIM署名対象を変更することがある。
  • DNSの p、sp、np は要求された処理方針である。受信者はローカル方針でpassを拒否することもfailを受け入れることもでき、最終処理の制御を保持する。

認証結果を構成する三つの時点

メールの結果を理解するには、送信時、変換時、受信時を分けなければならない。送信時に正しく署名された事実は、途中で本文が変わった後も自動では残らない。最終受信者が得た fail は、出発点で誰も認証していなかったことを意味しない。逆に、到着時の pass は、その時点の内容が安全であることを意味しない。

2026年5月にStandards Trackで公開されたRFC 9989は、RFC 7489と9091を置き換えた。編集者はTodd M. HerrとJohn Levineである。文書は冒頭で、passが示すのはDomain Ownerによって許可されたAuthor Domainの使用だけだと述べる。その許可はメッセージやDomain Ownerへの価値判断を含まず、受信箱への配送が安全または望ましいことも保証しない。

この限定は実装上の注意ではない。後の判断が何を継承してはならないかを決める仕様である。

整合が加えるもの、加えないもの

SPFはSMTP接続を見て、クライアントが MAIL FROM やHELOのドメインを使う許可を持つか調べる。DMARCはSPFから MAIL FROM ドメインを使う。DKIMは署名されたヘッダーと本文を検証し、d= の署名ドメインを認証する。どちらも、それだけでは利用者がFrom欄で見るドメインとの関係を作らない。

DMARCはRFC5322.FromからAuthor Domainを取り出し、認証済みドメインと比較する。strictなら同一、relaxedなら同じOrganizational Domainであることを求める。aspf と adkim がモードを示し、RFC 9989は実務上ほぼ全てのDomain Ownerがrelaxedで必要を満たしていると記す。

一つの整合した認証識別子があればpassになる。複数のDKIM署名のうち一つが有効で整合していれば、別の署名が失敗していてもよい。SPFが通っても、それが転送者のドメインでFromと整合しなければDMARCの根拠にはならない。

したがって記録すべき事実は、「この受信者が、この時刻に、このSPFまたはDKIMドメインを認証し、この方式でAuthor Domainとの整合を確認した」である。「表示された人物が書いた」は別の命題だ。

アドレスの左側と表示名は残る

ローカル部 president とドメイン example.com を組み合わせたアドレスで、DMARCが扱うのは example.com である。president というローカル部の実在、メールボックスの管理者、役職、執筆者を検証しない。RFC 9989はローカル部を認証しないと明記する。

人が最初に読む表示名も範囲外である。本物の役員名を別ドメインのアドレスに付けられる。見た目が似たドメインを登録し、SPFもDKIMも正しく設定できる。文書は表示名攻撃と視覚的類似ドメインをDMARCが直接解決しない問題として挙げる。

本文分析も対象外だ。正規サービスのアカウントが奪われれば、攻撃メールは正規ドメインを通る。攻撃者が所有する新しいドメインなら、その攻撃者自身が使用を正しく許可できる。添付、URL、請求先、依頼の真偽、受信者の状況は、評判、コンテンツ検査、業務承認、本人確認の別証拠を必要とする。

passの後に検査を続けることは、DMARCへの不信ではない。DMARCが答えた問いと、まだ答えていない問いを尊重する行為である。

壊れたのは正当性ではなく証拠かもしれない

RFC 7960は間接配送の現実を整理した。転送者が元の MAIL FROM を保てば、転送先で見えるIPは元ドメインのSPFに許可されていないことがある。転送者が自分の MAIL FROM に書き換えればSPFは通ってもFromとの整合を失う。

メーリングリストは件名にタグを付け、フッターを加え、MIME部分を変更する。これらは現在の機能に必要でも、元のDKIM署名を無効にし得る。最終受信者は、途中で失われた署名の正当性を結果だけから復元できない。

RFC 9989がfailを「必ずしもAuthor Domainと無関係とは限らない」とするのはこのためだ。failは、適用できるDMARC処理の時点で整合した認証識別子が見つからなかったことを示す。詐欺の判決ではない。

赤い結果を機械的に拒否へ結び付けると、正当なリスト投稿、転送された通知、既存の仲介サービスが失われる。passを安全と読む誤受け入れと、failを不正と読む誤拒否は対になる障害である。

DNSレコードが届くのは判断材料まで

ポリシー探索では、まずAuthor Domainそのもの、次にOrganizational Domain、最後にPublic Suffix Domainを調べる。レコードの位置と対象サブドメインの存在に応じて p、sp、np を選ぶ。IANAの登録もこれらをrequested policyと表現する。

要求は遠隔命令ではない。RFC 9989は最終処理を常にMail Receiverのローカル方針に残す。別の危険信号があればpassを隔離できる。既知の正当な間接経路なら、p=reject の下でfailしたメールを受け入れることもできる。文書は、正当なメールやメーリングリストを害さないよう、rejectという公開値だけで拒否しないことを勧める。

DNS問い合わせが完了しなければ、結果はpassでもfailでもない。その場合、Domain Ownerの方針を適用できず、配送、一次拒否、保留などは受信者が決める。公開者はDNS上の主張を制御し、受信者は自分のキューと損失を制御する。

Heng Luの The Policy Mirror は、共同層に置く規則が必要な技術的不変条件を守るか、それとも別主体の判断を奪うかを問う。RFCの根拠はIETFプロセスにあるが、この範囲テストはDMARCの境界を読む助けになる。相手の希望を可視化することと、相手に実行権を渡すことは違う。

報告先の公開は観測の所有ではない

rua は集約報告、ruf はメッセージ単位の失敗情報を求める。集約報告は詐称だけでなく、正規の送信経路に残る設定漏れを見つけるために有用である。しかし、参加する全受信者が全報告を送る義務はない。集約報告は推奨、失敗報告は任意であり、プライバシーのため削除・縮小されることもある。

DNSにURIがあるのは要求の証拠にすぎない。受信済み報告は特定受信者、期間、実装範囲の観測であり、全配送の台帳ではない。報告がないことを違反や安全の証明にしてはならない。

none から quarantine、reject へ進めるなら、正規送信元、サブドメイン、転送、リスト、署名の継続、実際の報告カバレッジを確認し、戻す条件も先に決める。ポリシー変更は文字列ではなく運用変更である。

Todd Herrを中心にしても共同作業を消さない

2026年9月1日に取得したIETF Datatrackerは、Todd Herrの公開プロフィールにRFC 9989を一件掲載し、ART Area Review TeamのReviewer役を示している。公式写真は本人の外見を確認する資料である。RFCはHerrをValimail、共同編集者John LevineをStandcore LLCとして記録し、謝辞ではDMARC Working GroupとRFC 7489以前の多数の貢献を残す。

人物記事で評価できるのは、Herrが共同編集した文書がpassの限界と受信者の裁量を曖昧にしなかった点である。彼をDMARCの唯一の発明者、世界中の署名の検証者、受信者の管理者にしてはならない。役割の分離を守ることが、共同編集者への正しい帰属でもある。

色ではなく証拠列を保存する

監査可能な列には、受信バイトとFrom、全SPF/DKIM結果とドメイン・selector・理由・時刻、整合方式と決定識別子、DNS探索先と適用タグ、問い合わせエラー、間接変換、ローカル評判と本文検査、実際の処理、利用者の後続結果、送受信された報告が必要だ。

列を分ければ継承を止められる。ドメインは人を証明しない。整合は本文を証明しない。passは安全を証明しない。公開方針は実行を証明しない。SMTP受理は受信箱を証明せず、受信箱は無害を証明しない。

DMARCの価値は残る。完全一致ドメインの詐称を難しくし、評判を結び付ける安定した単位を作り、Domain Ownerに送信実態を返す。小さな結果を大きく見せる必要はない。小さいからこそ再現できる。

出典