ガイド · Yahooメールの認証失敗

プロダクトチームはYahooメールの認証失敗をどのように安全に診断すべきか

Yahooがメールの認証失敗を報告したら、広範な再試行を止め、完全なSMTP応答、受信者の範囲、送信元IPアドレス、エンベロープ送信者、表示されるFromドメイン、DKIMのd=ドメインとセレクター、メッセージのタイムスタンプを保存します。まず、一時的な4xxの応答と恒久的な5xxの拒否を区別します。次に、管理されたメッセージ1通で再現し、SPFの許可を検証し、受信したDKIM署名を公開鍵と照合して検証し、DMARCのアライメントを評価します。特定されたIDやDNSの問題を修正し、DNSが収束するのを待ってから、範囲を絞って再テストし、トラフィックを徐々に再開します。認証に成功しても、Yahooの受信トレイへの到達が保証されるわけではありません。

DNSを変更する前に失敗の意味を明確にする

「Yahoo mail authentication failed（Yahooメールの認証失敗）」という言葉は、2つの異なる問題を指すことがあります。メールクライアントがYahooアカウントにログインできない場合と、送信者の認証を確立できなかったためにYahooの受信システムがプロダクトのメールを拒否した場合です。このガイドでは後者、つまりSMTPでの配送時のSPF、DKIM、DMARC、および関連する受信側のポリシーを扱います。受信側のMXが認証関連の拒否を返したというだけの理由で、ユーザーのパスワードをリセットしたり、アプリパスワードを作成したり、本番の送信用の認証情報をローテーションしたりしないでください。正確な証拠から始めます。診断テキストを切り詰めずに完全な拡張SMTP応答を記録し、リモートのMXのホスト名、タイムスタンプ、受信者、配信試行の識別子、送信元IPアドレス、SMTPのMAIL FROMドメイン、表示されるRFC 5322のFromドメイン、そしてすべてのDKIM署名のドメインとセレクターも記録します。共有するチケットでは、本当に必要な場合を除き、ローカルパートとメッセージの内容を伏せてください。ステータスコードとIDの文脈がない、コピーされたフレーズ1つだけでは、安全な修正方法を特定するには不十分です。

Yahooの一時的な応答と恒久的な応答を分類する

YahooのSender Hubでは、421のSMTP応答を一時的な遅延、553または554の応答を恒久的な配信の問題として分類しています。現在のエラーのガイダンスには、一時的なエラーのために認証結果を判定できなかった一時的なケースと、メッセージが送信ドメインのDMARCまたはDKIMのポリシーに照らしたチェックに失敗した恒久的なケースが含まれています。「認証」という言葉が含まれていればすべて同じ状況だと決めつけず、実際の応答を使ってください。4xxの応答では、キューにあるメッセージを保持し、上限を設けた指数バックオフ、ジッター、キューの最大滞留時間、試行回数の上限を設けて再試行します。5xxの応答では、設定や内容の問題が理解できるまで、その受信者とメッセージのIDについて自動的な再実行を止めます。恒久的な拒否に何度も送りつけても、DNSは直らず、ノイズと重複のリスクが増えるだけです。最終的な応答を受け取る前にSMTPセッションがあいまいな形で終了した場合は、すぐに新しい論理的なメッセージを作成するのではなく、その試行を不明としてマークし、突き合わせを行ってください。

管理されたメッセージ1通についてIDの連鎖をたどる

管理された形で失敗させたサンプルについて、コンパクトなIDの表を作ります。接続元IPアドレス、逆引きDNSの名前、EHLOの名前、SPFで使われるSMTPのMAIL FROMドメイン、DMARCで使われる表示されるFromドメイン、各DKIMのd=署名ドメインとs=セレクター、そして現在SPF、DKIM、DMARCのレコードを公開しているドメインを含めます。これらの名前を、権威DNSと、少なくとも2つの独立したキャッシュリゾルバーで照会します。応答、TTL、否定応答をタイムスタンプとともに保存します。そのうえで、送信したサンプルの正確なバイト列とヘッダーと比較します。ベンダーのダッシュボードに表示される一般的なドメインのステータスだけをテストしないでください。本番では、別のサブドメイン、セレクター、Return-Path、ストリーム、テナントが使われている可能性があります。別のプロバイダーやテンプレートからのメッセージがパスしても、失敗している経路が正しいことの証明にはなりません。受信者は管理されたものに限り、1回のテストで変更する変数は1つにし、認証されるドメインの設定は同じままで、新しいトレース識別子を使ってください。

SPFの許可をFromのアライメントと混同せずに確認する

SPFは、接続元IPアドレスがSMTPのID、通常はプロトコルのルールに基づくMAIL FROMドメインまたはHELOのIDに対して許可されているかどうかを評価します。失敗した試行で使われた正確なドメインを照会してください。構文的に有効なSPFレコードが1つだけあること、includeとredirectの参照先がすべて解決できること、プロバイダーの実際の送信元IPアドレスがカバーされていること、DNSの評価がプロトコルの上限内に収まっていることを確認します。テストをパスさせるためだけに、既存のポリシーの横に2つ目のTXTレコードをコピーしたり、範囲の広すぎるメカニズムを追加したりしないでください。SPFの結果がpassであっても、認証されたドメインが表示されるFromドメインとアライメントしていなければ、DMARCでは失敗することがあります。同様に、転送によって接続元IPアドレスが変わり、元の送信者が許可されていてもSPFが壊れることがあります。原因となっているReturn-Pathやプロバイダーの設定を修正し、DNSチェッカーだけに頼らず、管理されたメッセージとそのAuthentication-Resultsの証拠を確認してください。

Yahooが評価したメッセージに対してDKIMを検証する

管理されたサンプルにあるすべてのDKIM-Signatureヘッダーを探します。表示される送信者を認証するための署名について、d=ドメイン、s=セレクター、正規化のモード、署名対象ヘッダーのリスト、本文のハッシュ、アルゴリズム、タイムスタンプや有効期限があればそれも抽出します。s._domainkey.dでセレクターを照会し、公開されている鍵が最新であり、正しい形式で、外部のリゾルバーから取得できることを確認します。署名は元のメッセージのバイト列に対して検証してください。チケットを経由して本文をコピーしたり、MIMEを再シリアライズしたりすると、テスト用の成果物が無効になることがあります。よくある問題には、想定外のドメインで署名している、鍵を誤ったセレクターやゾーンに公開している、キャッシュが収束する前にローテーションしている、署名後に署名対象のヘッダーや本文を変更している、署名を経由しないテンプレートやリレーの経路を使っている、などがあります。1つのストリームを直すために、DKIMのポリシーを削除したり、すべての署名を弱めたりしないでください。どのコンポーネントがメッセージを作成または変更したかを特定し、その経路を修正してください。

DMARCのパスとアライメントを明示的に評価する

DMARCは表示されるFromドメインを使い、アライメントしたSPFまたはDKIMのパスを必要とします。認証メカニズムは、技術的にはパスしていてもアライメントしていないことがあります。SPFがプロバイダーのReturn-Pathドメインを認証していたり、DKIMが表示されるFromとは無関係なベンダーのドメインで署名していたりする場合です。該当する組織ドメインまたはサブドメインのポリシーについて_dmarcを照会し、現在のタグを記録します。そのうえで、SPFの結果とそのドメインのアライメント、DKIMの結果と各署名ドメインのアライメント、そして結果としてのDMARCの判定を評価します。Yahooの送信者要件では現在、すべての送信者に最低限SPFまたはDKIMが必要とされています。一斉送信者には、SPFとDKIMの両方、少なくともp=noneの有効なDMARCポリシー、DMARCのパス、そしてFromドメインとSPFまたはDKIMのドメインとのアライメントが必要です。これらはYahooの現時点での要件として扱い、公式ページを再確認してください。p=noneのポリシーは処理の結果を監視するものであり、失敗したメッセージを認証済みにしたり、配信上の特権を与えたりするものではありません。

Authentication-Resultsは指示ではなく証拠として使う

RFC 8601は、信頼できる認証サービスが結果を伝えるためのAuthentication-Resultsヘッダーフィールドを定義しています。受信側または信頼できるゲートウェイが追加した結果を、メソッド、結果、評価されたID、説明用のプロパティも含めて読み取ります。信頼できない送信者が付けたAuthentication-Resultsヘッダーや、無関係なホップからコピーされたものを信用しないでください。YahooのSMTP応答を、自分で管理する受信側の結果やプロバイダーのログと比較します。ただし、受信側によってDNSの見え方、ポリシー、メッセージの変換が異なることがある点に注意してください。インシデントの分析のため、元のヘッダーはアクセス制御をかけて保存します。受信したサンプル1通からは、そのサンプルがパスまたは失敗した理由はわかりますが、すべての送信ストリームが正しいことは立証できません。DMARCの集約レポートでより広いアライメントの傾向がわかることもありますが、レポートは遅れて届く集計データであり、プライバシーに配慮した保持と、承認されたレポートの送付先が必要です。

範囲を絞って修正し、DNSの収束をテストする

観測されたIDを修正する最小限の変更を選びます。たとえば、既存のSPFポリシーに実際の送信元を追加する、アライメントしたカスタムのReturn-Pathを使うようにプロバイダーを設定する、正しいDKIMセレクターを公開する、署名が省略されていたストリームで署名を有効にする、リレーが署名済みの内容を変更しないようにする、アライメントしたd=ドメインを設定する、などです。DNSの構文と所有者を確認し、変更前のレコードを保存し、計画的な変更であれば事前にTTLを下げ、通常の変更管理の手順を使います。秘密情報や秘密鍵をチケットやDNSレコードに公開しないでください。DKIMのDNSに含まれるのは公開鍵だけです。変更後は、意図した応答が見えるようになるまで、権威サーバーと複数のキャッシュリゾルバーに照会します。別々のYahooのテスト用受信者に管理されたメッセージを数通送り、SMTPとヘッダーの完全な証拠を保存し、変更したメカニズムそのものを検証します。SPF、DKIM、DMARC、IPアドレス、テンプレート、送信量の変更を1つのテストにまとめないでください。パスしても、どの変更が効いたのかわからなくなります。

ゆっくり再開し、配信の結果を区別し続ける

管理されたメッセージが認証に成功したら、影響を受けたストリームだけを段階的に増やします。一時的な遅延、恒久的な拒否、プロバイダーのバウンス、苦情のシグナル、キューの滞留時間、認証結果を、ドメイン、セレクター、送信元IPアドレス、メッセージの種類ごとに監視します。受信者のアドレスやメッセージの内容は指標に含めず、範囲を限定した識別子や粗い集計値を使ってください。Yahooのベストプラクティスでは、認証に加えて、低い苦情率、送信元IPアドレスの有効な正引きと逆引きのDNS、RFCに準拠したメールが求められており、一斉送信者の要件には簡単に配信停止できることも含まれています。そのため、認証結果が修復されても、すべてのメッセージが受信サーバーに受け付けられること、受信トレイに届くこと、反応が得られることが約束されるわけではありません。プロバイダーによるサブミッションの受け付け、YahooのSMTPでの受け付け、その後の配信の証拠、メールボックスのフォルダへの振り分け、ユーザーの行動を区別してください。拒否率が再び上がった場合は、認証されていないトラフィックを別のIPアドレスやドメインに移すのではなく、影響を受けたグループを一時停止します。そのような回避は根本原因を隠し、レピュテーションの悪化を広げるおそれがあります。

SendHQのドメインおよびDNSドキュメントを使用する

SendHQ固有の設定については、送信者ID、DNS、SES、反映、修復状態を扱う最新のDomains and DNSドキュメントに従ってください。

よくある質問

YahooはSPFとDKIMの両方を必須としていますか？

Yahooは現在、すべての送信者に最低限SPFまたはDKIMを求めており、一斉送信者にはSPFとDKIMの両方に加え、有効なDMARCポリシーとDMARCのパスを求めています。影響を受けているストリームについて、Yahooの最新の要件を再確認してください。

SPFはパスしているのにDMARCが失敗することはありますか？

はい。SPFは、表示されるFromドメインとアライメントしていないReturn-Pathのドメインを認証することがあります。DMARCには、アライメントしたSPFまたはDKIMのパスが必要です。

DKIMはパスしているのにDMARCが失敗することはありますか？

はい。無関係なd=ドメインを使った有効な署名は、表示されるFromドメインとアライメントしていない場合があり、そのFromのIDについてはDMARCを満たしません。

Yahooの554の認証による拒否は再試行すべきですか？

553または554の応答は、その試行については恒久的なものとして扱ってください。自動的な再実行を止め、特定された設定やメッセージの問題を修正してから、管理されたメッセージで再テストします。

Yahooから認証関連の421の遅延が返されたら、どうすべきですか？

キューにある同じメッセージを保持し、ジッターとキューの滞留時間の上限を設けたバックオフを使ってください。一時的なDNSや評価のエラーは恒久的なポリシーの失敗とは異なるため、完全な応答を保存しておきます。

認証に成功すれば、Yahooの受信トレイへの到達は保証されますか？

いいえ。認証によって得られるのは、範囲の限られたIDの証拠です。Yahooはそれでも、レピュテーション、苦情、コンテンツ、送信レート、メールボックスでのフィルタリングに基づく判断を適用できます。受信側のレピュテーション、苦情、コンテンツ、送信レート、メールボックスのフィルターは、引き続きそれぞれ独立して適用されます。

このページは、SendHQがYahooの認証失敗を解決できることを証明していますか？

それだけでは不十分です。SendHQ固有の設定については、最新のDomains and DNSドキュメントを使用し、影響を受ける送信経路を管理されたYahooテストで検証してください。

出典

さらに学ぶ

アプリケーションメールのSPFレコードを確認する方法アプリケーションメールについて、正しいSPFドメイン、構文、メカニズム、ネストしたDNSルックアップの予算、送信元IPの許可、評価結果、DMARCアライメントを確認します。アプリケーションメールのDKIMを確認する方法実際の署名を調べ、セレクターとドメインを照会し、メッセージを検証し、受信側の結果を読み、アライメントをテストしてDKIMを確認します。アプリケーションメールのDMARCチェック方法DMARCレコードの検出、構文、SPFとDKIMのアライメント、ポリシー、レポート、実際のアプリケーションメッセージを、DNSルックアップと配信を混同せずに確認します。メール到達率サービスの評価方法対象範囲、証拠、認証、フィードバックループ、サプレッション、プライバシー、ポータビリティ、運用への適合性の観点から、メール到達率サービスを評価します。SMTPメールプロトコル：アプリケーションメールが届く仕組みSMTPのサブミッション、リレー、エンベロープ、応答コード、TLS、再試行、メッセージの内容が、アプリケーションメールのワークフローをどう形作るかを解説します。