新標準は全面変更の指示ではない
2026 年 5 月公開の RFC 9989 は従来の DMARC 仕様を置き換え、割合を指定する pct パラメーターを削除しています。
企業が最初に行うのは現状の確認です。DNS のポリシー、運用文書の前提、変更の承認者を明確にします。公開日だけでは、各メール事業者がどの版を実装しているか分かりません。実際に使う環境について事業者へ確認してから、正常な設定を変更するか判断します。 [1]
通常のメールボックスだけで判断しない
日常のメールに加え、Web フォーム、請求ソフト、サポート窓口、ニュースレターも一覧に含めます。経路ごとに担当者、表示される送信元、送信サービス、確認済みのメールを記録してください。Web メールで送信できても、サイトの送信経路が正常とは限りません。
例えば、請求システムが予定したドメインで請求書を送信し、その事実を受信した原文から確認できるかを調べます。必要なヘッダーと確認日時を保存します。認証情報や本文を、広く共有する DNS 台帳に含めないようにします。
SPF または DKIM の少なくとも一方が成功し、そのドメインが選択したアライメント方式で表示上の From ドメインと整合すれば、DMARC は成功します。 [1]
送信経路
メール、Web サイト、CRM、請求サービスと担当者を記録。
認証
実際に受信したメールの SPF と DKIM の結果を確認。
アライメント
認証されたドメインと表示上の From ドメインを比較。
経路ごとの確認記録
結果、日時、必要な変更を記録します。ドメインの使用が認められていても、本文の信頼性は保証されません。
確認手順の概念図です。認証方式を個別に調べ、表示される From ドメインとの関係も確認します。
古い段階導入の前提を確認する
pct=10 や pct=25 だけを使って段階導入する手順が残っていないか確認します。旧仕様にその仕組みがあっても、現在のすべての受信側が同じ動作をする根拠にはなりません。
変更対象の経路を限定し、担当者と検証失敗時に戻す設定を決めます。対応状況は利用事業者へ確認してください。この点検のために、動作実績のある厳しいポリシーを先に弱める必要はありません。 [5]
表は左右にスクロールできます。
| 対象 | 必要な確認記録 | 判断 |
|---|---|---|
| 送信経路 | 承認された各送信サービスに担当者がいる。 | 不明な送信元を先に調べる。 |
| ポリシー | 現在の DNS 値と復旧時の値を記録。 | 追跡可能な変更を承認する。 |
| 互換性 | 事業者が対象環境の動作を確認。 | 全受信側の対応を推定しない。 |
| 受入確認 | 合意した経路を個別に検証。 | 完了後に次の対象へ進む。 |
レポートを具体的な確認作業につなげる
DMARC の集計レポートは、観測された送信元と認証結果を示します。失敗レポートは別の種類で、より詳しいメールデータを含む場合があります。
想定外の経路について、承認済みサービスか、誰が調査するか、いつ再確認するかを記録することを勧めます。不明な記録は、まず調査すべき事項です。異常がないレポートも、自社の送信台帳の代わりにはなりません。レポートの閲覧権限と削除時期も決めてください。 [2] [3]
事業者の送信要件は別に確認する
Gmail は一般の送信者と大量送信者を区別しています。後者に Google は SPF、DKIM、DMARC を求め、DMARC の要件では none も認めています。
この最低条件だけでは、自社ドメインに適した保護方針は決まりません。受信事業者の要件を満たすことと、承認された送信経路を確実に把握することを分けて確認します。実際の到達や迷惑メールへの分類も別途観測します。 [4]
重要な経路を一つ選んで始める
見積書や請求書など、業務上重要な経路を選びます。以下の項目で確認可能な変更作業を定義すれば、メール運用全体を一度に変更せずに進められます。
- 現在の DMARC レコードと運用手順を保存する。
- 稼働中の送信サービスと担当者を一覧にする。
- 関連する各経路で、承認されたテストメールを確認する。
- 古い割合指定の導入手順と事業者の対応状況を確認する。
- 変更時間、受入基準、復旧手順を決める。
- 変更後はレポートと実際の到達を合わせて確認する。