Authentication-Resultsを読むときは、SPFやDKIMの値だけでなく、その行をどの受信サーバーが書いたかを確認します。複数行があるメールでは、途中の成功と最終受信側の結果が異なる場合があります。最初に見つけたpassだけを抜き出さず、原文と配送経路を合わせて調べてください。

調査対象を絞る

日本の取引先へ提出する調査資料では、スクリーンショットより原文の方が経路を確認しやすくなります。メールを通常の転送操作で送り直すと、新しい配送が加わってしまいます。権限のある担当者が原文を保存し、共有用にはアドレスなどの不要な個人情報を隠した写しを作りましょう。

読み取る項目は、見えるFrom、SPFの検証対象、DKIMの署名ドメイン、DMARC結果です。SPFの対象とFromは別の場合があるため、両方を控えます。DKIMが複数あるなら、どの署名が成功したかも分けます。一つの緑色表示にまとめると、どのドメインが認証されたかを説明できません。

確認の順序

ヘッダー中のすべての認証行を無条件に信用することも避けます。信頼できる受信基盤が追加した結果かを管理者と確認してください。利用者の画面で判断できない場合は、Message-IDと原文を管理者へ渡します。外部からの記述を最終受信側の検証結果と取り違えないことが重要です。

想定例として、転送後のメールにSPF passとfailがそれぞれ一行ある場合を考えます。どちらかを都合よく選ぶのではなく、それぞれの書き込み元と経路を整理します。最終側ではDKIMが整合して成功しDMARCが成功しているかもしれません。認証方式ごとの結果と最終判定を一つずつ確認してください。

原文の時刻は表記する時差も確認します。日本時間の問い合わせと違う日付に見えても、同じ一通の可能性があります。新設定の検証では必ず新しいメールを使い、過去の原文を現在の成功の証拠として流用しないでください。変更前後の識別子を並べれば、担当者が追跡しやすくなります。

認証結果は受信箱への配置やリンク先の安全性の保証ではありません。Inbox Checkで原文を取得できる場合も、対象標本で受け取った一通の証拠として使います。顧客の実メールとは別に記録し、どちらの受信側が書いた結果なのかを報告書で明示してください。

テストの対象と限界を確かめ、Inbox Checkの検証を準備してください。観測した標本と顧客の実配信は区別して記録します。