SendGrid 550 5.4.1 access denied の対処
目次
この記事では、SendGrid から送ったメールに 550 5.4.1 recipient address rejected: access denied が返ってきたときの意味、切り分け、対処を Web 担当者の目線で整理します。
エラーコード 550 5.4.1 の意味
SendGrid から返ってくるバウンスのうち、本文に次のような表記が含まれているケースが対象です。
550 5.4.1 <user@example.com>: Recipient address rejected: Access denied
550 は SMTP の永続的失敗、5.4.1 は受信側が「このアドレスは受け取らない」と明示的に拒否した状態を示します。SendGrid 自体は中継しただけで、拒否しているのは受信側 MTA（Gmail / Outlook / Microsoft 365 / 受信側自前のゲートウェイ等）です。Microsoft 365 が独自拡張で同コードを多用するため、宛先が Microsoft 365 のときに頻発します。
550 5.4.1 全般の意味と他要因の切り分けは550 5.4.1 Access denied の原因と対処早見表で整理しています。本記事は SendGrid から送ったときに何が起きていて、どこを見るか に絞ります。
まず見るべき場所: SendGrid Activity Feed
切り分けの起点は SendGrid 管理画面の Activity Feed（Email Activity）です。該当宛先で検索し、イベント詳細から次の 3 点を取ります。
- Event の種類（
bounce/blocked/dropped） - Reason 欄の SMTP 応答文（受信側 MTA の生メッセージ）
- 該当アドレスが Suppression List のどこに入っているか（Bounces / Blocks / Invalid Emails）
dropped で「Bounced Address」と表示される場合は SendGrid 側が送信前に止めています（後述のケース 5）。bounce で Reason に 550 5.4.1 が含まれていれば、受信側 MTA まで届いた上で拒否されています。
5 つのケース
ケース 1: 受信者アドレスが存在しない
退職者アドレス、組織変更で消えたメールボックス、タイポなど。Reason 欄に user unknown mailbox not found no such user が併記されることが多いです。
対処：
- 配信リストから当該アドレスを除外
- SendGrid の Suppression Management → Bounces から削除しないこと（残しておくと再送防止になる）
- 法人アドレス管理側に異動・退職反映漏れがないか棚卸し
ケース 2: 受信側ドメインの認証ポリシーで拒否
受信側が DMARC p=reject を採用しており、送信元の SPF / DKIM が成立していないと、宛先 MTA が 550 5.4.1 で弾くケース。SendGrid を使い始めた直後にこのパターンが多発します。
対処：
- 送信ドメインで SendGrid 用の CNAME（Domain Authentication）を完成させる
- DKIM 署名が
d=で自社ドメインを通っているかDKIM 検証の確認方法で確認 - SPF の include 整理はSPF レコード 10 ルックアップ超過の対処を参照
ケース 3: 送信 IP が受信側のブロックリストに入っている
SendGrid の共有 IP プールは多数のテナントが利用するため、他テナントの挙動で一時的に評価が下がる時間帯があります。受信側が Spamhaus / Barracuda / 独自 RBL を参照していれば access denied で弾かれます。Reason 欄に blocked using や listed at が含まれていればこれです。
対処：
- まず Reason 欄の URL（多くの場合 RBL 側の Removal URL）にアクセス
- 削除手順はSpamhaus ブロックリスト削除手順を参照
- 慢性化していれば SendGrid の Dedicated IP を検討（量と単価のバランスは事業条件次第）
ケース 4: 受信側の内部ポリシーで拒否
Microsoft 365 のメールフロー ルール、Google Workspace のコンテンツコンプライアンス、企業ゲートウェイの DLP 等で、件名・本文・送信ドメインの条件に一致したメールを明示拒否しているケース。配信メールで「予約」「請求書」「お振込」などの語が含まれていると、社内ポリシーで弾かれることがあります。
対処：
- 受信側 IT 部門に「送信ドメインからのメールがメールフロー ルールでブロックされていないか」を確認依頼
- 自社ドメインを許可リストに追加してもらう
- 本文テンプレートを見直し、誤検知しやすい語句や添付を整理
ケース 5: SendGrid 側で自動抑制（Suppression List 入り）
過去にハードバウンスを起こした宛先は SendGrid が自動的に Bounces に登録し、以後同一宛先への送信を API 受領時点でドロップ します。このとき Activity Feed では dropped と表示され、Reason に「Bounced Address」と出ます。この状態を「アクセス拒否」と読み違えるケースが多いので注意。
対処：
- 原因（アドレス変更 / 一時不在 / 受信側の一時障害）を解消
- Suppression Management → Bounces / Blocks / Invalid Emails で該当アドレスを検索し、確実に解消したものだけ削除
- 確認せずに一括削除すると、また同じバウンスを生んでドメインレピュテーションを下げるので必ず根本原因の確認を先に
切り分けの最短手順
- Activity Feed で対象メールを開き、Event 種別と Reason 文面を控える
- Reason 文面で 5 ケースのどれかに分類
- 受信側起因（ケース 1/2/4）なら、本文・宛先・受信側設定の確認依頼に着地
- 送信側起因（ケース 3/5）なら、RBL 解除と Suppression 整理に着地
近接エラーである Gmail の 550 5.7.26（認証失敗）と混同しやすいので、Gmail 550 5.7.26 の対処も併読すると判別が早くなります。また、550 系コードのケース別の原因と対処はOutlook・Microsoft 365 の 550 エラーのケース別の原因と対処で体系的に整理しており、照合するとより細かく切り分けられます。送信全般で届かない場合は会社のメールが届かないときの原因と対処から入ると整理しやすいです。
予防
- 配信前のテスト送信で受信側ドメイン認証を確認しておく
- 退職・異動の都度、配信リストを更新する運用を組む
- ハードバウンスを検出した宛先は当日中に Suppression と CRM の双方を整える
よくある質問
Suppression List から削除すれば即座に再送できますか
技術的には可能ですが、根本原因が解消していなければ同じバウンスを再発させ、ドメインの信頼スコアを下げます。原因確認を先に行ってください。
受信側が Microsoft 365 のときだけ起きるのはなぜですか
Microsoft 365 は内部で 5.4.1 を「受信者拒否」の汎用コードとして広く使うため、Connector / メールフロー / ライセンス未割当のどれでも同じコードが返ります。本文 Reason の追加情報で見分けます。
Dedicated IP に切り替えれば解決しますか
ケース 3 の慢性化には有効ですが、ウォームアップ運用が必要で、月間配信量が一定以上ないと逆効果になります。先にケース 1/2/4/5 を潰してから判断するのが現実的です。
まとめ
550 5.4.1 recipient address rejected: access deniedは受信側起点の永続拒否- 5 ケース（受信者不在 / 受信側認証 / IP ブロック / 内部ポリシー / SG 自動抑制）に分類
- Activity Feed の Reason 文面が切り分けの鍵
- Suppression は削除より「なぜ入ったか」を先に確認
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で SPF / DKIM / DMARC の状態を数十秒でチェックできます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。