Yahoo 554 5.7.9「Message Not Accepted for Policy Reasons」— 送信者の修正方法（2026）

公開日 2026-07-08

データは 2026-06-29 時点 · メソドロジー v7。 261 百万採点済みドメインを対象とした集計センサスデータ。採点方法を参照。

Yahoo はメッセージが送信者ポリシーに違反すると 554 5.7.9 を返す — 通常は SPF/DKIM 認証の失敗または Yahoo が適用している DMARC ポリシーだ。SPF または DKIM を合格させ、From ドメインとアライメントさせることで修正する。Defaults.Exposed の 261,086,232 ドメインのセンサス（2026-06-29）によると、DMARC を適用しているのはわずか 10.59%（27,640,987）だ。

修正は申請フォームではなく DNS とリスト整理だ：どのポリシーに抵触しているかを診断し、正しいドメインで SPF または DKIM を合格させ、勝ったレグを From アドレスとアライメントさせ、ボリューム送信の場合は DMARC を公開し、ワンクリック配信停止を追加する。以下にステップ順と Yahoo の関連コード（553 5.7.1、553 5.7.2、421 遅延）のデコーダーを示す。

Yahoo エラー 554 5.7.9 とは何を意味するか？

2024 年 2 月以来、Yahoo は Gmail と同じ送信者ルールセットファミリーを適用している：すべての送信者は SPF または DKIM に合格すべき；バルク送信者は両方に合格し、合格のメカニズムを From ドメインとアライメントさせ、DMARC ポリシーを公開し、サブスクリプションメールに RFC 8058 ワンクリック配信停止を提供し、苦情率を低く保つ必要がある。Yahoo は「バルク」のボリューム閾値を意図的に公開していない — Google の並行ルールは1日 5,000 通に線を引いており、それがほとんどの送信者が使用する実用的なベンチマークだ。AOL のメールボックスは同じインフラで動作するため、1つの修正で両方をカバーする。

554 5.7.9 は Yahoo の永続的なポリシー拒否だ。典型的な形式は：“554 5.7.9 Message not accepted for policy reasons. See https://postmaster.yahooinc.com/error-codes” と読む — 意図的に汎用的で、ポリシーファミリー全体をカバーするからだ：認証の失敗、DMARC の適用（送信ドメイン自身の p=reject を含む）、送信者ガイドライン違反。Gmail の 550-5.7.26 とは異なり、テキストはどのレグが失敗したかをめったに教えてくれない。そのためステップ1（ドメインの外部からのスキャン）は、ここではより重要になる。

根本的なギャップは大きい：2026-06-29 センサスの 261,086,232 ドメインのうち、46.4%（121,145,609）は SPF レコードを全く公開しておらず、DMARC を適用しているのはわずか 10.59% だ。Yahoo は奇妙なものを要求しているのではない — 未認証の多数派からのメールを拒否しているのだ。

どの Yahoo バウンスコードを持っているか？

NDR をこのテーブルと照合する — 各エントリを「このようなバウンス：」として扱う。Yahoo は正確な文字列ではなくエラーカテゴリーを公式に公開しており、正確な表現と括弧内の理由タグ（[TSS04] など）は現場で観察されて時間とともに変化するからだ。フラグメントを実際のバウンスと Yahoo の Sender Hub エラーコードリストと照合する。

コード	このようなバウンス（断片）	意味	修正の場所
554 5.7.9	”Message not accepted for policy reasons”	永続的なポリシー拒否 — 認証、DMARC、または送信者ガイドライン違反	このガイド、ステップ2〜6
553 5.7.1	IP またはコンテンツポリシーのテキスト、多くの場合括弧内の理由タグ（ブロックリスト参照など）	Yahoo はこの IP/送信元からの受け入れを拒否 — レピュテーションまたはポリシーブロック	ステップ2〜3、その後クリーンな送信；認証は再発を防ぐが IP をリストから除外しない
553 5.7.2	”will be permanently deferred” / 再試行は成功しない	送信 IP の継続的なレピュテーション失敗 — 遅延のハードバージョン	ステップ2〜7、自己ホストの場合は新しい IP のウォームアップ
421 4.7.0	”temporarily deferred due to unexpected volume or user complaints”（[TSS] タグが多い）	一時的な遅延 — レートまたは苦情の急増、永続的なブロックではない	再試行キューが消化される；ステップ5〜7を修正して再発を防ぐ

そのテーブルについての正直な2点。421 遅延は Yahoo があなたを判断している間スロットリングしている — 再試行を尊重し、送信量を減らし、苦情の側を修正する；キューを叩き続けると遅延が 553 に変わる。そして DNS レコードはブロックリストされた IP をリストから除外しない：認証はポリシー拒否を止め再発を防ぐが、IP レピュテーションは時間をかけたクリーンな送信によってのみ回復する。

554 5.7.9 をステップバイステップで修正するには？

最初に defaults.exposed で無料スキャンを実行する。 Yahoo が取得するのと同じ外部からの視点でライブの SPF、DKIM、DMARC レコードを読み取り、DNS を変更する前にどのレグが失敗しているかを表示する。
Yahoo が実際にチェックするドメインで SPF を合格させる。 すべての送信者の半数を捕まえるガードレール：受信側は SPF を From ヘッダーではなく Return-Path（RFC5321.MailFrom）ドメインに対して評価する。 ニュースレタープラットフォームや CRM がメールを代わりに送る場合、SPF は通常そのバウンスドメインに対して評価される — だから自分の SPF レコードが完璧でも無関係な場合がある。バウンスがどのドメインに返るかを確認し、そのドメインの SPF が送信元をカバーしていることを確認する。
自ドメインで DKIM 署名を有効にする。 プロバイダーまたは ESP でカスタムドメイン DKIM をオンにし（通常は CNAME レコードを2〜3件）、署名がプラットフォームのデフォルトではなく d=yourdomain.com を示すようにする。プラットフォームのウォークスルー：Mailchimp、Brevo、Klaviyo の DMARC 失敗。
合格したレグを From ドメインとアライメントさせる。 Yahoo の要件（DMARC と同様）はアライメントを重視する：From アドレスのドメインと一致するドメインで SPF または DKIM が合格すること。スキャンが SPF と DKIM を緑と表示しているのに Yahoo が依然拒否する場合、アライメントの落とし穴に入っている — DMARC が失敗するが SPF と DKIM は合格するを参照。
ボリューム送信の場合は DMARC レコードを公開する。 Yahoo はバルク送信者に少なくとも p=none とレポートアドレスを要求する — ハードなボリューム数を公開していないため、Google の 5,000 通/日を実用的なベンチマークとして扱う。_dmarc への TXT レコード1件だ — レコードと漸増プランについては DMARC 修正ガイドを、コントロールパネルの例については IONOS DMARC 設定ガイドを参照。適用することで 89.41% のドメインより先を行くことになる。
RFC 8058 ワンクリック配信停止（List-Unsubscribe + List-Unsubscribe-Post ヘッダー）をマーケティングおよびサブスクリプションメールに追加し、2日以内にリクエストに応じる。評判の良い ESP はドメイン認証がオンになると自動的にこれらを追加する — 送信済みメッセージのヘッダーで確認する。
苦情を低く保つ。 Yahoo はユーザーの「迷惑メールとしてマーク」の操作を重く見る — スパム率を 0.3% 未満に保つ — そして継続的な苦情の急増が 421 遅延から 553/554 拒否への主な道だ。Yahoo の Sender Hub 経由で苦情フィードバックループに登録し、非アクティブなアドレスを整理し、購入リストには絶対にメールしない。

ほとんどの送信者はステップ2〜4で 554 5.7.9 を解消する；ステップ5〜7がその後遅延サイクルに入らないために必要なものだ。両プロバイダーの完全な要件リスト（閾値、ヘッダー、スパム率の数値）については、Google と Yahoo の送信者要件に関する参考記事を参照；このガイドはバウンスの修正に集中している。

Yahoo のルールは小規模送信者にも適用されるか？

バルクチェックリスト（SPF と DKIM の両方、アライメント、DMARC 公開、ワンクリック配信停止）は正式には相当なボリュームの送信者に適用され、Yahoo は「相当な」という数値を明示的に拒否している（Google の並行ルールは 1 日 5,000 通を使用し、一般的な実用ベンチマークだ）。しかし基本認証はすべての人に期待されており、554 5.7.9 は発射前にボリュームを確認しない：小規模送信者は ESP の共有インフラ経由で、またはアライメントしていないメールを持つ自ドメインの p=reject 経由で、または単に認証のないドメインから送信することで — SPF レコードがない 46.4% のドメイン（2026-06-29 センサス）だ — これに当たる。ステップ1〜4はどの送信量でも必須として扱う。

これは Gmail の 550-5.7.26 と同じか？

同じルールセットファミリーで、異なる方言だ。Google と Yahoo は 2023 年末に同時に要件を発表し、両者は 2024 年 2 月から適用を開始した。そのため一方のために修正されたドメインは本質的にもう一方のためにも修正される。実際の違い：Gmail のバウンステキストは通常失敗したメカニズムを示すが、Yahoo の 554 5.7.9 は通常そうではない；そして Yahoo はコンプレイントドリブンの IP 遅延により重点を置く。両方でバウンスしている？ここで一度修正し、次に 550-5.7.26 ガイドで Gmail 固有の詳細を確認する。

よくある質問

554 5.7.9 は Yahoo がドメインをブロックリストに載せたことを意味するか？ 通常はそうではない。ポリシー拒否だ — ほとんどの場合は認証 — レピュテーションの判断ではなく、DNS で完全に修正できる。また、非常に一般的な状況でもある：2026-06-29 センサス時点で、261,086,232 ドメインのうち DMARC ポリシーを適用しているのはわずか 10.59% だ。認証をクリーンにした後の永続的な 553 5.7.2 拒否がレピュテーションのケースだ。

From アドレスが @yahoo.com のニュースレターが Yahoo でバウンスするのはなぜか？ Yahoo は 2014 年に自社のコンシューマードメインに p=reject を公開したからだ — @yahoo.com から送信するサードパーティサービスは Yahoo 自身の DMARC で失敗し、設計通りに拒否される。修正は構造的なものだ：フリーメールアドレスではなく、独自の認証を持つ自ドメインから送信する。ESP のカスタムドメイン設定が道筋だ — ニュースレタープラットフォームガイドを参照。

DNS を修正してから、Yahoo がメールを受け入れるまでどれくらいかかるか？ 認証の修正は新しいレコードが見えるようになるとすぐに作用する — 数分から数時間、遅い TTL では最大 48 時間。レピュテーションの回復は遅い：421 遅延は数日のクリーンで苦情のない送信で消え、553 5.7.2 の永続的な遅延は数週間または新たなウォームアップが必要になる場合がある。

オーナーにレポートを送る

クライアントのためにこのバウンスを解消している場合、「Yahoo が再びメールを受け入れるようになった」でチケットをクローズしない。変更後に無料スキャンを再実行し、採点レポートをビジネスオーナーに転送する。平易な言葉で、ドメインが今やメールを認証しており、まだ不足している点がどこかを示す — サイバー保険更新や取引先セキュリティアンケートに必要な証拠だ。バウンスを修正した；レポートがそれを証明する。

ドメインをチェックする → · Gmail 550-5.7.26 ガイド → · DMARC を修正する → · 採点方法 → · 集計データのみ使用。データは EU 内で保存・処理。