Defaults.Exposed › 修正 › Guides

Gmail 550 5.7.26「送信者が認証されていない」：要件順の修正方法（2026）

公開日 2026-07-08

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

Gmail はメッセージが SPF と DKIM の認証チェックの両方に失敗すると 550 5.7.26 を返す。送信ドメインで SPF または DKIM の少なくとも一方を合格させることで修正する — ほとんどの送信者はこれを満たしていない：Defaults.Exposed の採点済み 261,086,232 ドメインのセンサスによると、_spf.google.com 経由で Google のサーバーを認可する 12,145,313 ドメインのうち、DMARC を適用しているのはわずか 18.5% だ。

修正は DNS 作業であり、サポートチケットではない：送信 IP に逆引き DNS があることを確認し、Gmail が実際にチェックするドメインで SPF または DKIM を合格させ、DKIM を From アドレスとアライメントさせ、DMARC レコードを公開する。以下に要件の完全な順序と、550 5.7.26 ファミリーおよびその関連コードのデコーダーテーブルを示す。

Gmail エラー 550 5.7.26 とは何を意味するか？

Google の 2024 年送信者要件以来、Gmail へのすべての送信者（バルク送信者だけでなく）は、送信ドメインで SPF または DKIM の少なくとも一方に合格しなければならない。両方に失敗すると、Gmail はスパムに配信するのではなく、SMTP の段階で 550 5.7.26 で拒否する。

現在の完全なテキストは：“This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” と表示される。現在も流通している古いバウンスには Google の旧表現（“This mail is unauthenticated, which poses a security risk…”）が含まれる場合があり、レート制限の関連コード — 421 4.7.26 This email has been rate limited because it is unauthenticated — も同じ原因だ。

550 5.7.26 は単一のメッセージではなく、コードのファミリーの一部であり、表現がどのレグが失敗したかを教えてくれる：Google の現在のリファレンスは3つの 5.7.26 文字列を保持し（未認証、SPF ハードフェイル、DMARC ポリシー）、バルク送信者の SPF のみおよび DKIM のみの失敗を独自のコード 5.7.27 と 5.7.30 に移動した。DNS を変更する前に正確なテキストを読む — それが最初の診断だ。

このギャップの大きさがこのバウンスがこんなに一般的な理由だ：12,145,313 ドメインが SPF レコードに Google のメールサーバーを認可している（SPF を公開している全 138,927,207 ドメインのうち）が、適用済み DMARC ポリシーを持つのはわずか 18.5% で、strict SPF（-all）を使用しているのは 8.0% に過ぎない。ほとんどの Google ホスト送信者が Google 自身のバルク送信者ルールを満たしておらず — Gmail は今やすべての人に基本事項を強制している。

どの 550 5.7.26 バリアント — または関連コード — を持っているか？

受け取ったバウンステキストをこのテーブルと照合する。引用されているフラグメントは Google の現在の SMTP エラーリファレンスに従っている — Google は定期的に表現を改訂するため、実際の NDR と照合すること。

550 5.7.26 を要件順に修正するには？

Google は文字通りの「チェック順序」を公開していない — しかし要件は論理的に積み重なるため、この要件順序で進める。ほとんどの送信者はステップ3の後にブロックが解除される；とにかくリストを最後まで完了する。後のステップが、バウンスを抜け出した後にスパムを避けるために必要なものだからだ。

1. 最初に無料スキャンを実行する。 ライブの SPF、DKIM、DMARC、DNS 設定を読み取り、どのレグが失敗しているかを正確に表示する — DNS を変更する前に診断する。
2. 送信 IP に逆引き DNS（PTR）を設定する。 接続 IP には、同じ IP に解決するホスト名を持つ PTR レコードが必要だ。主要プロバイダーはこれを自動処理する；独自サーバーからの送信者を悩ませる（そして関連コード 550 5.7.25 の全内容だ）。
3. SPFまたはDKIM を合格させる。 1つのガードレール：受信側は SPF を From ヘッダーではなく Return-Path（RFC5321.MailFrom）ドメインに対して評価する — SPF が「合格すべき」と判断する前に、メールが実際にどのドメインにバウンスするかを確認する。そのドメインの SPF レコードに実際の送信サービスを追加する（完全な SPF ウォークスルー）か、プロバイダーで DKIM 署名を有効にする（完全な DKIM ウォークスルー）。どちらか一方が合格すれば基本的な 550 5.7.26 のブロックが解除される。
4. DKIM を From ドメインとアライメントさせる。 バルク送信、そして DMARC のために、Gmail は From アドレスのドメインでの認証を求める。ベンダーのデフォルトではない。Google Workspace ユーザー：独自の DKIM キーを公開する（Workspace DKIM 設定）；デフォルトの gappssmtp.com 署名は DKIM を合格させるがアライメントしない — 独自のガイドがある落とし穴だ。アライメントされた DKIM は転送にも耐えるが、SPF はそうではない。
5. DMARC レコードを公開する。 Google の送信者要件は少なくともレポートアドレス付きの p=none を求める。5分の DNS 編集だ — 正直な最初のステップと p=none が守ること/守らないことについては「DMARC ポリシーが有効になっていない」を参照。
6. TLS で送信する。 最新のメールサーバーやプロバイダーはデフォルトでこれを行う；独自の MTA を実行する場合は、アウトバウンド TLS がオンであることを確認する — TLS なしのバルクメールは独自のコード 550 5.7.29 でバウンスするようになった。
7. マーケティングおよびサブスクリプションメールに RFC 8058 ワンクリック配信停止（List-Unsubscribe + List-Unsubscribe-Post ヘッダー）を追加する。
8. Google Postmaster Tools でスパム率を 0.10% 未満に保ち、0.30% に達させないようにする。 Google の要件上限は 0.3%；推奨は 0.10% 未満。ドメインを登録する；それが Google 自身があなたを評価する成績表であり、スパム率のしきい値はどの DNS レコードでも修正できない要件だ。

このリストができないこと：サードパーティのブロックリストから外すこと。認証は Gmail の未認証拒否を止める；スパム歴のある IP はレピュテーションの問題であり独自のクリーンアップパスがある — 認証を修正することで再発を防ぐが、リストから除外するわけではない。

1日あたり 5,000 通未満の送信にもバルク送信者ルールは適用されるか？

完全なチェックリスト（アライメントされた認証、DMARC 公開、ワンクリック配信停止、スパム率）は、正式には Gmail への 1 日 5,000 通以上に適用され、バルク専用コード（5.7.27、5.7.29、5.7.30）はその層から来る。しかし認証の基本事項（SPF または DKIM の合格、有効な PTR）はすべての人に適用され、それが小規模送信者も 550 5.7.26 に当たる理由だ。ステップ1〜5はどの送信量でも必須、ステップ7〜8はバルク送信を始めた瞬間から必須として扱う。両プロバイダーの要件の完全なセットは、Google と Yahoo の送信者要件に関するデータ記事にある。

よくある質問

550 5.7.26 はドメインまたは IP がブロックリストに載っていることを意味するか？ いいえ。認証の失敗であり、レピュテーションの判断ではない — Gmail は「スパマーだとわかっている」のではなく「誰であるか証明せよ」と言っている。これは良いニュースだ：DNS で完全に修正できる。悪いニュースはこれがいかに普通かということだ — 261,086,232 ドメインのセンサス（2026-06-29 時点）で、適用済み DMARC ポリシーを持つのはわずか 10.59% だ。

SPF のみを修正すればバウンスは止まるか？ 通常は基本バリアントには止まる — Gmail は SPF または DKIM の少なくとも一方を要求する。しかし SPF は Return-Path ドメインに対して評価され、転送で壊れるため、アライメントされた DKIM（ステップ4）が長持ちする修正だ。12,145,313 の Google ホスト送信者ドメインのうち strict SPF を使用しているのはわずか 8.0%（2026-06-29 時点データ）なので、いずれにせよ先を行くことになる。

Google Workspace を使っているのに、なぜ Google が自分のメールをバウンスするのか？ Gmail はメールボックスプロバイダーではなくドメインを認証するからだ。SPF レコードもカスタム DKIM キーもない Workspace ドメインは、Google 自身が検証できないメールを送信する — Google のサーバーを認可する 12,145,313 ドメインのうち、適用済み DMARC を持つのはわずか 18.5%（2026-06-29 時点データ）。Google の顧客であることと、Google のルールを満たすことは別のことだ。

DNS の修正後、Gmail がメールを受け入れるまでどれくらいかかるか？ 新しいレコードが見えるようになるとすぐ — 通常は数分から数時間、遅い TTL では最大 48 時間。認証の修正は 550 5.7.26 チェックに即座に作用する；スパム率とレピュテーションの回復（421-4.7.0、5.7.28）にはクリーンな送信を数日〜数週間継続する必要がある。

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

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

ドメインを無料でチェックする

SPF、DKIM、DMARC のどのレグで Gmail が失敗しているかを — プライベートかつオーナー限定で確認する。

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