Yahooコンプライアンスは、別のプロバイダーのコピーされたチェックリストではなく、受信サービスの実際の要件から始まります。ほとんどの組織は、開始するのに十分な構成情報をすでに持っていますが、有用な結果は、各要件からメッセージの証拠、所有者、および修正計画へのマップです。
ユニバーサル要件とバルク要件を分離する
Yahooリスト SPF または DKIM, a スパム苦情率 0.3%未満、有効な先物および 逆引きDNS IP の送信については、すべての送信者についてRFC 5321およびRFC 5322に準拠しています。その一括要件には、有効なSPFとDKIM両方が追加されます。 DMARC 少なくとも p=none DMARCを通過し、関連するマーケティングと購読トラフィックの購読を簡単に解除できます。リラックスした アライメント 許容されます。 Yahoo送信者の要件.
別のプロバイダーのボリューム番号をインポートしないでください。 Yahooの FAQ には、一括しきい値は指定されておらず、認証済みドメインや From ドメイン、その他の入手可能な情報を使用して送信者を評価していると記載されています。したがって、1 つのキャンペーンにおける少量の場合には免除は確立されません。未発表の制限値をわずかに下回る数値を見つけようとするのではなく、不確実性を記録し、音声認証を実装します。
実際のルートごとに認証を検証する
参考文献: RFC 9989 §4.4, RFC 9989 §5.3.5.
承認されたすべての送信サービスから最終メッセージを収集します。表示されている From を識別し、 封筒の差出人 とDKIM署名ドメインを比較し、認証と調整の結果を比較します。出版された DMARCレコード それだけでは、メッセージが通過したことは示されません。同様に、無関係なサービス ドメインに対するSPF成功は、ブランドの From ドメインとの整合性の証拠にはなりません。
インフラストラクチャ所有者に、送信 IP の逆マッピングと対応する転送アドレスを確認するよう依頼してください。これらの観察は、ドメインのメール受信MX構成とは別にしてください。管理対象サービスが IP を所有している場合は、組織が制御していないDNSゾーンを編集しようとするのではなく、サービスの実際のルート証拠を取得してください。
文書化された購読解除動作を実装する
参考文献: RFC 8058 §3.
Yahooの現在の要件では、機能する mailto メソッドを受け入れますが、 RFC 8058 POST メソッドを強く推奨しています。また、目に見える本文の購読解除リンクと 2 日以内のリクエストに応じることも必要です。ボディリンクだけでは不十分です。 FAQ では、プロモーションのワンクリック要件からトランザクション メッセージを除外しています。 Yahooよくある質問.
マルチプロバイダー プログラムの場合、 RFC 8058実用的な共通実装ですが、 Yahoo mailto を禁止していると主張するのではなく、設計上の選択として説明してください。制御されたサブスクリプションの実際の削除をテストします。抑制を変更せずに Web 応答が成功したとしても、運用上の成功とは言えません。
苦情データを正しい分母で解釈する
Yahoo 、スパム率は受信箱に配信されたメールに基づいていると述べている。受信した苦情レポートをすべての送信試行数で割ることによって計算される割合は、別の尺度です。内部的には役立つかもしれませんが、 Yahoo独自のレートというラベルを付けてはなりません。すべてのダッシュボード メトリクスのソース、カバレッジ、分母を保持します。
たとえば、架空の内部レポートには 3 件の苦情通知と 10,000 件の提出試行が含まれています。結果の 0.03% は内部比率のみです。受信箱で配信される分母とレポートの対象範囲が不明なため、 Yahooコンプライアンスを確立できません。この教育例は、プロバイダーの評価や組織の評判に関する声明ではありません。
保証を請求せずにギャップを埋める
認証の問題を送信者の所有者に割り当て、IP/ DNS問題をインフラストラクチャに割り当て、伝播の購読解除をサブスクリプション システムの所有者に割り当てます。新しい認可されたサンプルを使用して、修正されたストリームを再確認します。抑制のタイミングと残りの不明な苦情報道の証拠を保管してください。
日付の付いた要件レビューと観察された結果で終了します。これらの手順により、防御可能なコンプライアンス記録を確立できますが、将来の受信トレイの配置を証明したり、実際のYahoo認定を構成したりするものではありません。