DMARCが成功しているのに迷惑メールに入る場合、認証成功と受信箱の分類を別の結果として扱います。DMARCはドメインの利用が認証上整合しているかを示す仕組みであり、内容の安全性や受信箱への配置を保証しません。認証を何度も作り直す前に、実際の症状を整理してください。

最初に分ける条件

国内の会員向け配信で、注文確認と販促を同じブランド名で送っていても、受信者の期待は異なります。どの種類のメールについて報告されたのか、登録時に想定された内容と違っていないかを確認します。担当者が見た一通の結果だけで、全体の送信評価を推定しないことが大切です。

まず受信した原文のDMARC結果が、本当に最終受信側の判定かを確認します。転送された資料の途中の結果や、別の通知の画面を使っている場合があります。認証ドメインと送信経路が合っていると確かめたら、フォルダーの位置、受信者の個人ルール、手動操作を記録します。

証拠を残す確認手順

送信側では、拒否・遅延・苦情など取得できる実運用の情報を確認します。これらは標本の配置とは別の証拠です。件名だけ、画像の枚数だけといった単一の説明に飛び付かず、問題が生じた時期に何を変えたかを調べます。変更があるなら、文面と接続設定を一度に戻さず、比較できる検証を組み立てます。

想定例として、長く利用しているショップが配信頻度を急に増やし、一部の会員から迷惑メールに入ったと連絡された場合を考えます。DMARC passの事実は保存し、頻度や受信の希望、配信停止の機能も確認します。認証済みだから報告が誤りだと扱わず、会員の実際の状況を別に調べてください。

改善案の評価は、何を変え、何が観察できたかで行います。受信を望まない相手へテストを繰り返すのではなく、許可された標本や自社管理のアカウントを使います。解除操作をした会員は検証の対象へ戻さず、実配信の対象管理と技術的なテストを分けて運用しましょう。

Inbox Checkの標本で受信箱に入っても、報告した会員の履歴や個人フィルターは再現していません。反対に標本で迷惑メールになっても、顧客全員の結果とは言えません。認証の成功を維持しながら、内容、受信の期待、実運用の情報を整理し、未知の点を残したまま結論の範囲を限定します。

測定方法と対象の制約を読み、Inbox Checkのテスト対象を確認してください。標本結果は個々の実顧客への保証ではありません。