
550 5.7.1エラーの意味と対処法:バウンスメールの読み方
550 5.7.1のバウンスは、受信側のサーバーがメールを確認したうえで受け取りを拒否したことを示します。理由の多くは、セキュリティやポリシーのルールです。メールアドレスが使われていない、または削除されたという意味ではありません。ほとんどの場合、相手のメールボックスに問題はありません。難しいのは、同じコードがまったく違う問題に使われる点です。SPFレコードがない場合もあれば、社内のメールしか受け付けない配布グループが原因の場合もあります。そのため、コードだけでは何を直せばよいかわかりません。わかるのは、コードの後に続く一文と、バウンスを返したサーバーの名前です。
まずバウンスの3つの項目を確認する
メール配信サービスが表示する要約ではなく、バウンスの全文を開いてください。確認するのは、コード、メールを拒否したサーバー、コードの後に続く文面の3つです。
Gmailが拒否した場合、バウンスの原文は次のようになります。
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550-5.7.1 [203.0.113.10] Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. - gsmtp
この例では、応答したサーバーはRemote-MTAの行にあるgmail-smtp-in.l.google.comです。コードはDiagnostic-Codeの行に550-5.7.1として表示されています。IPアドレスの後の文面は、Gmailのフィルタがこのメールをスパムと判断したことを示しています。末尾の- gsmtpは、Gmailがこのバウンスを作成したことを示します。代わりにgcdpという文字列がある場合は、受信者側のGoogle Workspace管理者が作成したルールによる拒否です。たとえば550 5.7.1 This message violates example.com email policy. - gcdp <sessionid> - gsmtpのような文面です。
Outlook.comから返る同じコードは、まったく違う文面になります。
Remote-MTA: dns; outlook-com.olc.protection.outlook.com
Diagnostic-Code: smtp; 550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150).
ホスト名がprotection.outlook.comで終わる場合は、Microsoftのサーバーが拒否しています。outlook-com.olc.protection.outlook.comのような名前は、企業のMicrosoft 365ではなく、個人向けのOutlook.comとHotmailのものです。コードはGmailの例と同じですが、原因はまったく違います。S3150は、送信に使ったIPアドレス、またはそのネットワークの一部がMicrosoftのブロックリストに載っていることを示します。受信者のアドレスとは関係ありません。
自分の550 5.7.1の文面を探す
550 5.7.1の文面は、メールシステムごとに異なります。バウンスの文面を下の表の行と照らし合わせてください。
| バウンスの文面 | 送信元 | 意味 | 対処できる人 |
|---|---|---|---|
| Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to Gmail, this message has been blocked. - gsmtp | Gmail | 送信者レピュテーション、送信量の急増、ユーザーからの苦情が原因で、スパムフィルタがメールをブロックした | 送信者 |
| This message violates example.com email policy. - gcdp <sessionid> - gsmtp | Google Workspace | Workspaceの管理者が作成した独自のルーティングルール、コンプライアンスフィルタ、添付ファイルのポリシーがメールをブロックした | 受信者側の管理者 |
| Invalid credentials for relay [IP]. | Google Workspace | 送信アプリが有効な認証情報なしでGoogle WorkspaceのSMTPリレーサービスを使おうとした | 送信者 |
| Daily SMTP relay sending limit exceeded for this customer. | Google Workspace | Workspaceアカウントが1日の送信リレーの上限に達した | 送信者 |
| Unfortunately, messages from [IP] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). | Outlook.com | Microsoftが送信元のIPアドレスまたはネットワーク範囲を個人向けサービスのブロックリストに追加した | 送信者またはISP |
| Unable to relay | Exchangeとその他の多くのサーバー | SMTP認証が行われなかった、またはコネクタの設定が誤っていたため、サーバーがメールの転送を拒否した | 送信者または送信側の管理者 |
| Delivery not authorized, message refused | さまざまなメールサーバー | 受信側サーバーが内部ポリシーに基づいてメールを拒否し、詳しい理由を示さなかった | 送信者または受信者側の管理者 |
| Relaying denied | さまざまなメールサーバー | クライアントが先に認証しない限り、サーバーが第三者のメールを受け付けない | 送信者 |
最もあいまいなのは、RFC 3463の文言そのままの「550 5.7.1 Delivery not authorized, message refused」で、その後に何も書かれていない場合です。スパム送信者にフィルタの条件を知られないよう、あえて理由を短くしているサーバーもあります。リレーサーバーやスマートホストを経由して送信している場合は、まずアプリが送信前に実際にログイン(SMTP AUTH)しているかを確認してください。認証なしの接続は、送信者側でよくある原因です。ログインしている場合は、受信者に、受信者側のメールログでそのメールを調べてもらってください。本当の理由が記録されているのは、たいていそこだけです。
原因が送信者側にある場合
バウンスが認証、レピュテーション、リレーのいずれかを示している場合は、受信者の協力なしで直せます。最初に認証を確認してください。SPFやDKIMが失敗している間は、レピュテーションを改善しても効果がありません。
現在、GmailとOutlook.comはどちらも、認証のないメールの多くをそのまま拒否します。そのため、DNSから確認を始めてください。送信ドメインにはSPF、DKIM、DMARCのレコードが必要です(DKIMは、メール配信サービスから提供されるCNAMEであることが多いです)。最初にSPFレコードを確認してください。SPFレコードには、自社の代わりにメールを送るすべてのサーバーのIPアドレスと配信サービスを記載する必要があります。RFC 7208では、1つのドメインにつきSPFレコードは1つ、DNSルックアップは10回までと決められています。レコードを複数公開したり、ルックアップが10回を超えたりすると、自動的にPermErrorで失敗します。次に、自分宛てにテストメールを送り、ヘッダーを開いてください。Gmailの「メッセージのソースを表示」画面には、SPF、DKIM、DMARCの結果がPASSまたはFAILで表示されます。DNSレコードを読むより早く確認できます。DMARCレコードは_dmarc.yourdomain.comに置きます。また、Fromアドレスのドメインは、SPFまたはDKIMに合格したドメインと一致している必要があります。
認証に合格しているのに、Gmailが「likely unsolicited mail」(迷惑メールの可能性が高い)と返す場合、原因はたいていレピュテーションです。レピュテーションとは、過去のメールに対して受信者がどう反応したかの記録です。Google Postmaster Toolsでは、自社のスパム率を確認できます。Googleは送信者に対し、スパム率を0.1%未満に保ち、0.3%に達しないよう求めています。スパム率が上がっている場合は、送信量を増やさずにキャンペーンを一時停止してください。レピュテーションが下がり続けると、迷惑メールフォルダに入っていたメールが、そのままバウンスするようになる傾向があります。
リストの品質は、このレピュテーションに直接影響します。古いリストには、使われなくなったメールボックスが多く含まれています。長く使われていないアドレスをスパムトラップに転用するメールサービスもあります。スパムトラップとは、スパム送信者を見つけるためのアドレスです。スパムトラップに送信したり、存在しない多くのアドレスでバウンスしたりすると、フィルタはリストを管理していない送信者だと判断します。リストが数か月以上前のものである場合や、スクレイピングや購入で集めたものである場合は、送信前にリストをチェック(英語)してください。
リレーのエラーは別の問題です。「Unable to relay」や「Invalid credentials for relay [IP]」は、送信に使っているサーバーが、自社のアプリを、利用が許可された送信元として認識していないことを示します。
Google WorkspaceのSMTPリレーサービスを経由して送信している場合は、Google管理コンソールを開き、[アプリ]、[Google Workspace]、[Gmail]の順に進んで[ルーティング]を表示します。そこでSMTPリレーサービスの設定を確認してください。IPアドレスで認証している場合は、サーバーのIPアドレスが許可リストにあるかを確認します。認証情報で認証している場合は、アプリがTLSを使ってポート587で接続し、正しいアカウントの認証情報を使っているかを確認します。Microsoft 365経由で送信している場合は、Exchange管理センターを開き、メールフローのコネクタを確認してください。CRMや事務所のスキャナーなど、Microsoft 365経由で送信するアプリや機器は、通常コネクタを通ります。そのコネクタのIPアドレスや証明書名の誤りは、「550 5.7.1 Unable to relay」のよくある原因です。
受信者側でしか直せない場合
ブロックが意図的な場合もあります。Microsoft 365やGoogle Workspaceを使う企業は、社外の送信者が特定のアドレスに送れないようにルールを設定していることがよくあります。
よくある例は、all-staff@のように社内からのメールしか受け付けない配布リストです。社外からこのアドレスに送ると、Exchange Onlineは550 5.7.1でバウンスを返し、多くの場合グループ名も表示します。Microsoftのトラブルシューティングのページによると、通常は送信者側では解決できません。グループの所有者かExchangeの管理者が、Microsoft 365管理センターでグループを編集し、送信者のアドレスを許可された送信者のリストに追加する必要があります。
Google Workspaceも同じです。Gmailのバウンスにgcdpという文字列がある場合、管理者がGoogle管理コンソールで作成した独自のルールが、内容、添付ファイル、送信者のドメインに基づいてメールを拒否しています。送信者側で何を変更しても、このルールは回避できません。
この場合は、受信者にバウンスを社内のIT部門へ渡してもらうよう依頼してください。送信元アドレス、宛先アドレス、バウンスした日時、バウンスの全文を伝えます。たとえば次のような文面です。
〇〇様、[日付] [時刻]にお送りしたメールが、550 5.7.1のポリシーエラーで返ってきました。貴社のメールシステムのルールでブロックされたようです。私のアドレスからのメールを受信できるよう、下記のバウンス情報をIT部門の方にお伝えいただけますでしょうか。
送信者:[自分のメールアドレス]
受信者:[相手のメールアドレス]
診断情報:[Diagnostic-Codeの行を貼り付け]
550 5.7.1と一緒に表示されることがあるコード
同じバウンスレポートによく出てくるSMTPエラーコードは次のとおりです。アドレスが存在しないことを示すコードもあれば、アドレスに問題はなく送信側の設定を直す必要があることを示すコードもあります。
| コード | 主な送信元 | 意味 | 最初に試すこと |
|---|---|---|---|
| 550 5.1.1 | Gmail、Microsoft、ほとんどのサーバー | 宛先のメールボックスが相手のサーバーに存在しない | 無効なアドレスをメールリストから完全に削除する |
| 550 5.4.1 | Microsoft 365 | Directory-Based Edge Blockingにより宛先アドレスが拒否された | 受信者がまだその会社に在籍しているかを確認する |
| 550 5.7.25 | Gmail | 送信元IPアドレスに有効な逆引きDNS(PTR)レコードがない | ホスティング会社でホスト名と一致するPTRレコードを設定する |
| 550 5.7.26 | Gmail | メールがSPFまたはDMARCの認証チェックに失敗した | SPFレコードの構文を直し、DKIMの署名ドメインを一致させる |
| 550 5.7.27 | Gmail | メールがSPFに失敗した | 送信サーバーのIPアドレスをドメインのSPFレコードに追加する |
| 550 5.7.28 | Gmail | 送信元IPから迷惑メールが異常なペースで送られた | 送信ペースを落とし、ユーザーからのスパム報告を確認する |
| 550 5.7.515 | Outlook.com | 大量送信ドメインに必要なSPF、DKIM、DMARCのレコードがない | SPFとDKIMを一致させ、要件を満たすDMARCレコードを公開する |
一時的なバウンスと恒久的なバウンスの一般的な違いは、ハードバウンスとソフトバウンスの違いの記事で解説しています。実際には、550 5.1.1の後はアドレスを削除し、550 5.7.26の後はアドレスを残してください。550 5.7.26の場合、アドレスには問題がなく、失敗したのは送信者側の認証だからです。
550 5.7.515は、大量に送信する送信者だけが対象です。2025年5月5日以降、Microsoftは、Outlook.com、Hotmail、Liveのアドレスに1日5,000通以上送信するドメインからのメールを拒否しています。受け付けられる条件は、SPFとDKIMに合格し、そのどちらかと一致するDMARCレコード(p=noneで十分)があることです。
ネット上では5.7.15と書かれていることがありますが、これは別のコード(優先度が低すぎる)です。Microsoftのバウンスに表示されるのは5.7.515です。
よくある質問
550 5.7.1エラーはどう直せばよいですか?バウンスの診断情報の行を読み、原因が認証、レピュテーション、受信者側のルールのどれなのかを確認してください。認証に失敗している場合は、SPF、DKIM、DMARCのレコードを更新し、送信用SMTPの認証情報を確認します。受信者側の管理者のルールや制限付きグループが原因の場合は、バウンスのヘッダーを受信者に送り、IT部門に送信者のアドレスを許可してもらってください。
550 5.7.1 unsolicited mailとは何ですか?Gmailのフィルタが、メールをスパムと判断したという意味です。判断の主な根拠は送信者レピュテーションです。よくある原因は、受信者による迷惑メール報告、新しいドメインやIPからの急な送信量の増加、古いリストへの送信です。Google Postmaster Toolsでスパム率を確認し、0.1%未満に戻るまで送信ペースを落としてください。
Outlookのステータスコード5.7.1は何を意味しますか?Microsoft 365では、Outlookからの5.7.1は、通常Exchangeのポリシーまたはグループの制限が配信をブロックしたことを示します。個人向けのOutlook.comとHotmailのアカウントでは、コードS3150が含まれることがよくあります。S3150は、Microsoftが送信元のIPアドレスを個人向けサービスのブロックリストに追加したことを示します。S3150が表示された場合は、送信サーバーの管理者に連絡し、バウンスに記載されたトラブルシューティングのリンクを伝えてください。
「550 5.7.1 outbound relay not allowed」とはどういう意味ですか?送信アプリが、有効な認証なしでSMTPサーバー経由でメールを送ろうとしたことを示すエラーです。メールサーバーは、スパム送信者に悪用されないよう、認証していない送信者のメールを中継しません。解決するには、アプリが有効なユーザー名とパスワードで認証し、ポート587でTLS接続するよう設定してください。
原因が何であっても、バウンスの全文は保存しておいてください。受信者のIT部門やメール配信サービスに最初に求められるのがこの全文です。
バウンスの大半が5.7.1ではなく550 5.1.1である場合は、リストに問題があります。次の送信の前に、Giggal.aiでリストを検証(英語)しておくことをおすすめします。
