Gmail「550-5.7.1 Message Blocked」— バウンスをデコードして修正する（2026）

公開日 2026-07-08

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

Gmail は、レコードの欠落ではなくポリシー上の理由でメッセージをブロックする場合に 550-5.7.1 を返す：送受信ドメインのポリシー、逆引き DNS のない IPv6 接続、またはスパムの疑い。Defaults.Exposed の 261 百万ドメインのセンサスによると、SPF で Google 自身のサーバーを認可する 12,145,313 ドメインのうち、DMARC を適用しているのはわずか 18.5% だ。

550-5.7.1 は Gmail の最も古い包括的拒否コードであり、修正方法はバウンスのコードの後に続く文章によって異なる。以下に正確な表現のデコーダーテーブルと、バリアントごとの修正パス — ポリシー拒否、逆引き DNS のない IPv6 サーバー、スパムまたはコンテンツブロック — に加え、混同される似たコードを示す。古いリファレンスが 5.7.1 に分類していた DMARC ポリシー拒否を Google が現在使用する 5.7.26 ファミリーを含む。

Gmail の 550-5.7.1 とは実際に何を意味するか？

SMTP 拡張ステータスのスキーム（RFC 3463）では、すべての 5.7.x コードは「永続的な失敗、ポリシー上の理由」を意味する。Gmail は 550-5.7.1 をレガシーのポリシーファミリーとして使用する：送信者または受信者ポリシーブロック、スパムレピュテーションブロック、そして — 多くの管理者が驚くバリアント — 逆引き DNS（PTR）レコードのないサーバーからの IPv6 経由で届くメール。

Google は時間をかけてバリアントを再コード化している。DMARC ポリシー拒否（「ドメインの DMARC ポリシーにより受け付けられない」）は Google の現在のリファレンスでは 550-5.7.26 に分類されているが、現在も流通している古いバウンスでは 5.7.1 として表示される場合がある；コンテンツセキュリティブロックは現在 552 5.7.0 とコード化されている。5.7.1 と混同される2つの関連コード：550-5.7.26（認証要件ファミリー、独自のガイド）と 550-5.7.25（任意の IP バージョンでのPTR 欠如コード）。コードが何であれ、以下のテキストをデコードする。

どの 550-5.7.1 バリアントを持っているか？

不達レポート（NDR）の表現を照合する。Google はこれらの文字列を年によって調整する — 句読点ではなく要旨を照合する。

バウンスの内容	意味	修正パス
”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.”	サーバーが逆引き DNS なし（または一致しない）で IPv6 経由で配信した	IPv6 アドレスの PTR レコード、またはプロバイダーのスマートホスト経由リレー（下記）
“The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.”	ポリシーブロック — 受信者のもの、または自ドメインのもの	受信側の管理者に連絡；自ドメインの DMARC がポリシーの場合は下記を参照
”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.”	コンテンツ、IP、またはドメインのスパム/レピュテーションブロック	Postmaster Tools + リスト整理 + ワンクリック配信停止（下記）
“This message is likely suspicious due to the very low reputation of the sending domain”（または”…sending IP address”）	レピュテーションブロック — ドメインまたは IP	同じレピュテーションパス（下記）
“Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — Google の現在のリファレンスでは 550-5.7.26 とコード化；古いバウンスでは 5.7.1 と表示される場合がある	自ドメインの DMARC ポリシーが、未認証メッセージを拒否するよう Gmail に指示した	未認証の送信元を特定する — 最初にポリシーを緩めない（下記）
“…blocked because its content presents a potential security issue.” — 現在は 552 5.7.0 とコード化	コンテンツ/ポリシーブロック（添付ファイルの種類、リンクレピュテーション）	フラグが立ったコンテンツクラスを削除；リンクと添付ファイルを確認
コードが 550-5.7.25、“the sending IP address doesn’t have a PTR record”	任意の IP バージョンで逆引き DNS が欠如	IPv6 バリアントと同じ rDNS 修正
コードが 550-5.7.26	認証要件ファミリー、5.7.1 ではない	550-5.7.26 ガイドを参照
コードが 421-4.7.0、“Try again later, closing connection.”	一時的な遅延 — レートまたはレピュテーション、永続的なブロックではない	送信量を減らし、認証とスパム率を修正；通常は解消される

550-5.7.1 バウンスを修正するには？

defaults.exposed で無料スキャンを実行する — DNS を変更する前に SPF、DKIM、DMARC を世界が見るように採点し、DMARC バリアントがドメインで起こりうるかを表示する。
NDR の全文をデコーダーテーブルと照合する — 原因を特定するのはコードではなく文章だ。
**DMARC バリアント：**認証に失敗した送信元を特定してその送信元を修正する（次のセクション）。
**IPv6/PTR バリアント：**サーバーの IPv6 アドレスに一致する逆引き DNS を追加するか、プロバイダーのスマートホスト経由でリレーする。
スパム/ポリシーバリアント： Postmaster Tools、スパム率 0.10% 未満（Google のハード要件上限は 0.30%）、リスト整理、RFC 8058 ワンクリック配信停止。
Gmail メールボックスへのテストメールを再送して再スキャンする — バウンスが解消され採点に反映されていることを確認する。

バウンスが自ドメインの DMARC ポリシーに言及している — なぜそれはポリシーが機能している証拠か

Google の現在のリファレンスはこの文字列を 550-5.7.26 としてコード化しているが、古いバウンスとサードパーティのドキュメントでは 5.7.1 として表示される場合がある — いずれにせよ仕組みは同一だ。見方がわかるまでは逆説的に見える：Gmail は自ドメインを名乗るメッセージをチェックし、SPF も DKIM もアライメント付きで合格しなかったことを確認し、DMARC レコードを調べ、あなたが指示した通りのことをした — 拒否。フェンスが機能した。問題はその中に何が捕まったか：忘れていた正規の送信者（CRM、請求ツール、ニュースレタープラットフォーム）なのか、それとも実際のなりすましなのか。

だから最初のステップとしてポリシーを緩めない。未認証の送信元を特定する。ほとんどのケースを説明する2つの落とし穴：

SPF は合格しているが、間違ったドメインで合格している。 受信側は SPF をFrom ヘッダーではなく Return-Path（RFC5321.MailFrom）ドメインに対して評価する。「あなたから」送信する SaaS ツールは通常、自社のバウンスドメインで SPF を合格させる。それは From ドメインとアライメントしないため、DMARC は依然失敗する。ウォークスルー：DMARC が失敗するが SPF と DKIM は合格する。
DKIM は合格しているが、デフォルト署名で合格している。 Google Workspace の gappssmtp.com と Microsoft の onmicrosoft.com のデフォルトは検証は通るが何ともアライメントしない。DKIM は合格するが DMARC が失敗するを参照。

このバリアントは思ったより稀だ：27,640,987 の 261,086,232 ドメイン（10.59%）が quarantine または reject の DMARC ポリシーを適用している（Defaults.Exposed センサス 2026-06-29）。残りの 89.41% はフェンスがないため、このバウンスを見ることはない。ポリシーではなく送信元を修正することは、DMARC 修正ガイドでエンドツーエンドでカバーしている。

バウンスが IPv6 送信ガイドラインに言及している — 逆引き DNS の修正

最新のサーバーはデフォルトで IPv6 経由で Gmail に接続することが多く、Google は接続 IPv6 アドレスに同じアドレスに解決するホスト名に解決する PTR レコード（前進確認逆引き DNS）があることを要求する。それを満たさないと、SPF がどれだけクリーンでもすべてのメッセージが 550-5.7.1 を受け取る。

優先順序で3つの修正方法：

サーバーの IPv6 アドレスの PTR レコードを設定する — IP が存在する場所（ドメインの DNS ゾーンではなく、VPS ホストまたは ISP のコントロールパネル）で設定し、折り返す AAAA レコードを一致させる。
プロバイダーのスマートホスト経由でリレーする。 rDNS をコントロールできない場合は、すでに適切な rDNS を持つメールプロバイダーまたは ISP のリレー経由でアウトバウンドメールをルーティングする。
一時的な回避策として IPv4 転送を優先する。 IPv4 アドレスには PTR があるため通常は症状を隠せる — 修正ではなく回避策だ。できる時は IPv6 PTR を設定する。

バウンスが「unsolicited email の可能性がある」と言っている — レピュテーションパス

ここでは認証は問題ないかもしれないが、Gmail のフィルターがメールを信頼していない。認証は床であり天井ではない — _spf.google.com を認可する 12,145,313 ドメインのうち、strict な -all で SPF をロックダウンしているのはわずか 8.0% なので、合格したチェックだけでは意味が少ない。（完全な比較：どのメールプロバイダーが最も強い SPF デフォルトを提供するか。）

レピュテーションチェックリスト：

Google Postmaster Tools に登録しスパム率ダッシュボードを監視する — 0.10% 未満に保ち、Google のバルク送信者ガイドラインがハード要件として設定している 0.30% の上限に達させない。
リストを整理する。 非エンゲージのユーザーと購入またはスクレイプされたものをすべて削除；申し込んだ人にのみ送信する。
バルクメールに RFC 8058 ワンクリック配信停止を実装する — Google のルールで必須であり、「スパム」クリックではなくなるすべての配信停止がレートを守る。
認証をアライメントした状態に保つ（自ドメインで SPF と DKIM）ことで、レピュテーションが自分でコントロールするドメインに蓄積する。

よくある質問

550-5.7.1 と 550-5.7.26 は同じか？ いいえ。550-5.7.26 は Gmail の認証要件ファミリー（SPF/DKIM の欠如または失敗）— そして Google の現在のリファレンスは DMARC ポリシー拒否もそこに分類する。550-5.7.1 は古いポリシーファミリー：受信者および送信者ポリシーブロック、IPv6 と PTR なし、スパムとレピュテーションブロック。どの修正が適用されるかを教えるのはバウンスのテキストであり、番号ではない（2026-06-29 時点および Google の現在のガイドラインによる）。

バウンスを止めるために DMARC ポリシーを p=none に戻すべきか？ そうするとフェンスを取り壊すことでバウンスを止めることになる。Defaults.Exposed センサス（2026-06-29）の 261,086,232 ドメインのうち DMARC を適用しているのはわずか 10.59%；そのうちの1つであれば、それを維持して未認証の送信元を修正する — ポリシーを緩めると、完全ドメインなりすましへの扉を再び開く。

SPF レコードがすべてのチェッカーで合格しているのに、なぜ Gmail がメールをブロックするのか？ チェッカーはレコードをテストする；Gmail はメッセージをテストする。SPF は表示上の From アドレスではなく Return-Path ドメインに対して評価されるため、ベンダーのバウンスドメインでの合格は DMARC アライメントに何もしない — そしてレピュテーションブロックは SPF を完全に無視する。無料スキャンがどのレイヤーが実際に失敗しているかを表示する。

550-5.7.1 は IP がブラックリストに載っていることを意味するか？ 必ずしもそうではない。Gmail は独自のレピュテーションシステムを運用している；公開のブロックリストには載っていなくても Google にブロックされる場合がある。Postmaster Tools で Google の見方を確認する — 認証を修正することで将来のダメージを防ぐが、それだけでは送信レピュテーションの低下がリセットされるわけではないことに注意。

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

バウンスが修正されたら、スキャンを再実行し、メールがバウンスしていたビジネスオーナーまたはクライアントに採点レポートを転送する。平易な言葉で、何が壊れていたか、何を修正したか、そしてドメインが今 261 百万ドメインのベースラインに対してどこに立っているかを示す — 「メールを認証しているか？」と尋ねる保険更新やクライアントセキュリティアンケートに正確に必要なものだ。サイレントに修正されたバウンスは見えない作業だ；前後のレポートが証明になる。

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