スパムスコアが良くても、実際の受信箱へ届くとは限りません。採点ツールが確認する項目と、受信サービスがその一通を処理する条件は同じではないからです。点数を直す前に、送信処理が行われたか、相手に受理されたか、どの場所で見つかったかを調べてください。
調査する条件
文面の検査では、リンクや形式に関する確認が役立つことがあります。ただし、そのツールが特定の受信サービスの内部判定を再現しているとは限りません。日本語に翻訳しただけで点数が変わった場合も、受信箱への効果が確認できたわけではありません。採点規則と実測結果を別資料にします。
実測では、同じ送信サービスと同じドメインから、問題の種類に近い検証用メールを送ります。原文の認証結果と受信場所を確認し、実顧客向けの拒否記録があるならそれも別に調べます。アプリの送信成功やDNSの存在だけを、検証成功という一語にまとめないようにしましょう。
確認の手順
- 採点ツールが何を検査しているかを確認する。
- 配送要求・受理・分類の証拠を一通ごとに集める。
- 確認できた不具合に対応し、変更を一つずつ記録する。
- 点数と配置を別々に比較し、一致しない結果も残す。
改善案は、得点が上がった理由ではなく実際に直した問題で説明します。壊れたリンクならリンクを直し、署名が失敗していたなら送信経路を調べます。複数の変更を同時に行って点数だけを比べると、重要な配送設定の不備が残っていても見落とす可能性があります。
想定例と注意点
想定例として、日本語の見積案内から画像を外したところ採点が改善したが、同じ企業宛てにはまだ未着という状況を考えます。送信ログで宛先の入力誤りが分かれば、画像の有無は今回の未着原因ではありません。スコアを下げるために必要な見積条件まで消さず、実際の問題へ対応しましょう。
採点の結果を社内の判断に使うなら、検査した原文の版とツールの判定項目を保存します。画面の数字だけを資料へ貼ると、後で何を検査したかが分かりません。別のツールへ切り替えたときは尺度も異なる可能性があるため、点数の上下をそのまま改善量としないでください。取引先や上司へ説明する際には、採点で見つけた候補、実メールで確認した不備、まだ仮説の部分を分けます。確認済みの問題から優先して対処すると、無意味な文面の削除を避けられます。
スコアと配置が一緒に改善しても、その一回で因果関係は確定しません。時刻や受信者の設定も影響します。Inbox Checkを利用する場合も、提供される標本と観察範囲を確認してください。特定の点数以下なら日本のどの受信箱にも入る、という境界値は本記事では示しません。
公式資料と検証
Google：メール送信者のガイドライン。RFC 9989：DMARC。
テスト方法と限界を読み、Inbox Checkで対象を確認してください。対応が確認できる標本のみを使い、実際の受信者全体への保証として扱わないでください。