Gmailメール認証トラブルシューティングWeb 担当者

Gmail 5.7.1エラーの原因と対処法｜Web 担当者向け

2026年5月3日ドメイン番人約 6 分で読めます

この記事でわかること

Gmail から返る 550-5.7.1 エラーが何を意味し、なぜ拒否に至るのか
エラー本文の英語フレーズから 3 パターン（認証不備・IP レピュテーション・内容判定）に切り分ける方法
既存記事で扱った 5.7.26（DMARC reject 専用）との違いと、復旧までの優先順位

5.7.1 エラーが出たときに起きていること

Gmail 宛てに送ったメールが届かず、送信者のメールボックスに次のような英文が返ってきたケースを想定してください。

550-5.7.1 [203.0.113.10] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent
550-5.7.1 to Gmail, this message has been blocked.

あるいは、認証側に踏み込んだ次のような文面のこともあります。

550-5.7.1 Email cannot be accepted due to authentication requirements.

どちらも共通するのは、「Gmail 側の判断で受信を断った」という意思表示です。Google は 550 5.7.1 を「権限不足、ポリシー違反、または送信者要件未達による拒否」として定義しています（Gmail SMTP errors and codes｜Google Workspace Admin Help）。

5.7.1 が厄介なのは、1 つのコードに複数の原因が同居している点です。エラー本文に続く英文（Our system has detected ... / Email cannot be accepted ... / Authentication required など）こそが切り分けの鍵で、本文を確保せずに DNS だけを書き換えても直らないことがあります。

Gmail 5.7.1 切り分けフロー

なお、本記事と類似する Gmail 5.7.26 エラーの原因と対処法は DMARC reject 専用のコードを扱った記事です。5.7.26 は「未認証メール」とほぼ同義の限定的な意味を持ちますが、5.7.1 はもう少し広い拒否であり、IP 評価や本文判定まで原因が及びます。

5.7.26 との違いと、エラーコードの位置づけ

両者の差はシンプルに整理できます。

Gmail 5.7.1 と 5.7.26 の違い

5.7.26: 認証 3 点（SPF/DKIM/DMARC、いわゆるディーマーク）または alignment が完全に通っていない。直す場所が DNS と配信サービス設定に絞られる
5.7.1: 認証は通っていても、IP 評価や内容スコアで拒否されることがある。直す場所が DNS だけにとどまらない

このため、5.7.1 を見たら「認証だけ直せば終わり」とは思わず、まずエラー本文の英語を読み切るところから始めてください。

原因を 3 パターンに切り分ける

5.7.1 は事実上、次の 3 系統のいずれかに収束します。

送信者認証の失敗: SPF/DKIM/DMARC のいずれかが fail または none。新興のドメインや認証未設定のドメインで頻発
送信元 IP のレピュテーション低下: 過去にスパムが多数送信された IP、ブロックリスト掲載 IP、または共有送信 IP の評判悪化
メール内容のフィッシング判定: 本文や URL がフィッシング・スパム特徴と一致したと評価された場合

切り分けの起点は、届きかけた（届いた）メールの Authentication-Results ヘッダです。社内の別アドレスや個人 Gmail に同じメールを送り、メッセージのソースを表示すると次のような行が確認できます。

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] ...) [email protected];
       dkim=pass [email protected] header.s=selector1;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.co.jp

ヘッダ確認の詳しい読み方は DKIM 設定の確認方法にまとめています。

パターン A: 認証失敗（Authentication required）

エラー本文に Authentication required Email cannot be accepted の語が出ているケースです。Authentication-Results を見ると、SPF か DKIM のどちらかに fail か temperror が入っているはずです。

直す順序は以下の通りで、いきなり全てを書き換えないことが鉄則です。

SPF レコードに、実際に使っている送信サービスの include: が揃っているか
DKIM 公開鍵が DNS に正しく登録されているか
DMARC レコード _dmarc.example.co.jp が存在し、rua= でレポートを受信しているか

具体的な書き方は SPF レコードの設定方法を参照してください。

パターン B: 送信元 IP の評価低下

エラー本文に Our system has detected that this message is likely unsolicited mail のような英文と、送信元 IP がブラケット表記で示されている場合は、IP レピュテーションが原因です。

このパターンで確認すべきは次の 3 点です。

共有 IP の利用状況: 共有型のメール配信サービスを使っている場合、自社が原因でなくても評判が落ちることがある。配信サービスのサポートに「専用 IP 移行」や「IP の plain warm-up」が可能か相談する
ブロックリスト掲載: Spamhaus などのブロックリストへの IP 掲載状況を確認する
Postmaster Tools の指標: postmaster.google.com に自社ドメインを登録すると、Gmail から見た IP 評価・スパム率・暗号化率が無料で確認できる

IP 評価の改善には数日〜数週間かかります。緊急の業務メールは、評価が安定している別の送信サービス経由に切り替えるのが現実解です。

パターン C: 内容判定によるフィッシング扱い

Suspicious link phishing のような語が含まれているケースは、本文や URL が原因です。次の点を確認してください。

リダイレクトを多段にしている短縮 URL を使っていないか
HTML メールの表示文字列と実 URL（href）の不一致がないか
添付ファイル（特に .html、.htm、暗号化 ZIP）が含まれていないか
過去に同じ URL がフィッシングとして報告されていないか

いずれも、テンプレートの見直しと URL の精査で改善できます。配信サービス側のクリックトラッキング URL が原因のケースもあるため、配信サービスのドキュメントで「リンクラッピングの無効化」を確認してください。

復旧と再発防止のためのチェックリスト

3 パターンの切り分けが済んだら、以下の順で進めると最短です。

エラー本文の英語フレーズを保管する: 後から読み返すために原文をテキストで保存。複数件を比較すると傾向が見える
Authentication-Results を確保する: 受信側に届いた最新ログを 1 件は確保しておく
自社ドメインの設定を /diagnose で確認する: SPF/DKIM/DMARC の状態が数十秒でレポートされる
Postmaster Tools に登録する: IP・ドメインの評価をモニタリングし続ける
DMARC レポート（rua=）の受信を始める: 認証失敗メールの送信元 IP と件数が日次で届く

包括的な原因把握には Gmail にメールが届かない原因と対処法の併読をおすすめします。Gmail 全般の届かない問題が網羅されています。Outlook 側で同種の IP ブロックに遭遇している場合は Outlook 5.7.708 の解除申請手順、Microsoft 365 への配信不能なら NDR 550 5.4.1 配信不能の原因と対処も参照してください。

自社の状況を確認してみませんか

設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。