DMARCのp=none、quarantine、rejectは、DMARCに失敗したメールについてドメイン側が示す処置の希望です。noneへ変えても誤ったアライメントが直るわけではなく、rejectにしても受信箱への到達が良くなる保証はありません。方針を変更する前に、正規の送信経路と実メールの結果を確認します。
最初に分ける条件
日本の事業者が認証方針を設定するとき、スタッフのメールだけを見て進めると、予約や請求など別サービスの通知を見落とすことがあります。Fromのドメインを使うすべての業務を棚卸しし、それぞれの管理担当者と署名の設定を確認します。使っていないように見える経路でも、月次通知が残っていないか調べましょう。
現行のDMARC仕様では、受信組織が方針をどう扱うかに裁量があります。そのため、quarantineは必ず特定のフォルダー、rejectは必ず同じ画面のエラーになる、といった一律の表示保証はできません。宣言した方針と、各受信サービスが実際に行った処理を別に記録します。
証拠を残す確認手順
- Fromを使う全サービスと正規の送信元を棚卸しする。
- 実メールの認証と現行DMARC方針を保存する。
- 変更の影響範囲と戻す条件を担当者が確認する。
- 各経路の新しいメールで宣言と実際の処理を比較する。
変更前にはDNSの現状と実メールの認証結果を保存します。レポートを使う場合は、取得した範囲や集計単位を確認し、表示されない送信を存在しないものとして扱いません。第三者へレポートを渡す設定では宛先や権限も確認し、不明な値を例からそのままコピーしないようにしてください。
想定例と対処後の確認
想定例として、会社メールの認証が成功したので方針を厳しくしたところ、店舗の発送連絡だけに問題が出たとします。方針自体を悪いものと考える前に、発送サービスのFromと署名の整合を確認します。戻す必要がある場合も、担当者が影響と復旧条件を判断し、未対応の正規経路を放置しないことが重要です。
検証は経路ごとに行い、変更前後の新しいメールを比較します。DNSの保存時刻と実際に確認した応答も残します。新しい設定を見た受信側と古い値を参照した受信側が混ざる可能性があるため、結果が違う場合は時刻と問い合わせ先をそろえて追加調査します。
認証方針の強化は、同意のない配信や紛らわしい文面を正当化しません。Inbox Checkも個別の標本を観察する補助であり、方針を変更した後に全顧客へ届くことの証明にはなりません。障害が起きた際に戻す設定と、未確認経路の確認担当を明示してから変更を進めましょう。
公式の参照先
RFC 9989：DMARC。Yahoo! JAPAN：DMARCの説明。
測定方法と対象の制約を読み、Inbox Checkのテスト対象を確認してください。標本結果は個々の実顧客への保証ではありません。