ホーム › 解説記事

メールが届かない・ブラックリスト解除の手順と原因の調べ方

公開 2026-11-03 ／ 更新 2026-11-03 ／ 運営者 中澤祐樹

送信したメールが届かない、またはエラーメールが返ってくるときは、まずエラーメール（バウンス）に書かれた3桁のコードと本文を確認してください。4で始まれば一時的なエラー、5で始まれば恒久的なエラーです。本文にブロックリスト（いわゆるブラックリスト）の名前が書かれていれば、送信元のIPアドレスやドメインが掲載されている可能性があります。

原因は宛先の入力ミスや相手の容量不足のような単純なものから、SPF・DKIM・DMARCの未設定、送信元の評判低下まで幅があります。ブラックリストの確認は大切ですが、単純な原因から順に切り分けたほうが早く解決します。ブラックリスト解除は「原因を直してから、申請は一度だけ、あとは待つ」が基本です。

この記事の内容は2026年11月時点の公式ページに基づきます。各リストやメール事業者の方針は変わることがあるため、最終的には運営者のページで確認してください。

エラーメール（バウンス）の読み方

エラーメールには、受信側のサーバーが返した応答がそのまま引用されています。たとえば次のような形です。

<user@example.com>: host mx.example.com[203.0.113.25] said:
    550 5.7.1 Service unavailable; Client host [203.0.113.10]
    blocked using bl.example.org (in reply to RCPT TO command)

読むべきところは3つあります。

1. 先頭の3桁（例: 550）: SMTPの応答コードです。RFC 5321 では、4で始まるコードは一時的なエラーで同じ要求を再度試してよいもの、5で始まるコードは恒久的なエラーで同じ要求をそのまま繰り返すべきでないもの、と定められています。
2. 続く「5.7.1」のような数字: 拡張ステータスコード（RFC 3463）です。真ん中の数字が原因の分野を表し、1はアドレス、2はメールボックス、4は経路、7はセキュリティやポリシーです。
3. 本文の英文: 上の例の「blocked using bl.example.org」のように、ブロックに使ったリストの名前や、参照すべきURLが書かれていることがあります。ここに名前が出ているリストが、最優先で確認すべき相手です。

よく見かけるコードの意味は次のとおりです。表のうち 5.7.25・5.7.26 と 4.7.0 の説明は Gmail のエラーコード一覧に基づくもので、ほかの受信サーバーでは同じ番号でも文面や使い方が異なる場合があります。

4で始まるエラーの場合、送信サーバーは自動で再送を続けます。RFC 5321 は再送の間隔を少なくとも30分、あきらめるまでの期間を一般に少なくとも4〜5日としているため、「遅延しています」という通知のあとで最終的な不達通知が届くこともあります。

メールが届かない原因を切り分ける順番

ブラックリストを疑う前に、次の順番で確認すると無駄が少なくなります。上のほうほど確認が簡単で、よくある原因です。

1. 宛先アドレスの誤り: 5.1.1 が返っているなら、まず綴りを見直します。ブラックリストとは無関係です。
2. 相手のメールボックスの容量: 4.2.2 や 5.2.2 は相手側の問題です。別の連絡手段で知らせるのが近道です。
3. 相手側だけの問題か: 特定の相手にだけ届かず、ほかの会社やGmailには届くなら、相手側の受信設定やフィルタの可能性があります。相手の管理者に、エラーの全文を添えて確認してもらいましょう。
4. SPF・DKIM・DMARC: Gmail はすべての送信者にSPFかDKIMを、1日5,000通を超える大量送信者にはSPF・DKIM・DMARCのすべてを求めています。Yahoo も同様で、Outlook.com も2025年5月5日から1日5,000通超のドメインに同じ要件を適用しています。設定方法はSPF・DKIM・DMARCの設定ガイドで解説しています。
5. 送信元IPとドメインの評判: 逆引き（PTR）レコード、TLSでの送信、迷惑メール報告の多さを確認します。Gmail と Yahoo は迷惑メール率を0.3%未満に保つよう求めており、Gmail は0.10%以下を推奨しています。
6. ブラックリストの確認: エラー本文にリスト名がある場合や、複数の宛先で 5.7.1 が出る場合は、送信元IPとドメインをブラックリストチェッカーで調べます。
7. 内容と送信量: 急に大量に送った、古いリストに一斉送信した、問い合わせフォームが悪用された、といった変化がないかを確認します。Gmail は異常な送信量を検知すると 421 4.7.28 で一時的に制限します。

Gmail宛てだけが届かない場合は、Gmailに届かないときの対処法もあわせてご覧ください。

ブラックリスト（DNSBL）の仕組みと調べ方

メールの「ブラックリスト」の多くは、DNSBL（DNSを使ったブロックリスト）です。受信サーバーは送信元IPが載っているかをDNSで問い合わせ、結果に応じて拒否したり迷惑メール扱いにしたりします。

RFC 5782 によると、IPv4アドレスの場合は4つの数字を逆順に並べてリストのドメイン名の前につけて問い合わせます。掲載されていればAレコード（慣例として 127.0.0.2）が返り、TXTレコードに理由が入っていることがあります。掲載されていなければ、そのアドレスのレコードは存在しません。

$ dig +short 10.113.0.203.bl.example.org A
127.0.0.2
$ dig +short 10.113.0.203.bl.example.org TXT
"Listed - see https://bl.example.org/lookup"

調べるときの注意点は次のとおりです。

• 調べるのは送信サーバーのIPです。自分のパソコンや回線のIPではありません。エラー本文の「Client host [ ]」や、送信済みメールのヘッダー（Received 行）で確認できます。
• IPだけでなく、送信元ドメインや本文中のURLのドメインを対象にしたリストもあります。両方を確認しましょう。
• リストは数多くあり、1つずつ問い合わせるのは手間です。ブラックリストのチェックツールを使うと、主要なリストをまとめて確認できます。

どの掲載が問題になるのか

どのリストを使うかは受信側が決めるため、載っていても、そのリストを使わない相手には影響しません。優先順位は次のとおりです。

• エラー本文に名前が出ているリストが最優先です。実際にそのリストが理由で拒否されています。
• 多くの受信サーバーで使われている大規模なリストへの掲載は、広い範囲に影響します。
• 小規模なリストや、運営状況がはっきりしないリストに1つ2つ載っているだけで、エラー本文にも名前が出ていないなら、届かない原因ではないことがほとんどです。認証設定や評判など、ほかの原因を先に疑いましょう。

代表的なリストの性質を、2026年11月時点の各公式ページから整理すると次のとおりです。

UCEPROTECT のレベル2・3のように範囲ごと掲載するリストでは、自分は迷惑メールを出していなくても、同じ範囲のほかのIPが原因で載ることがあります。有料の早期解除があるリストでも無料の自動失効は別にあり、原因が残っていれば支払っても再び載ります。Spamhaus の詳しい扱いはSpamhausの解除方法で解説しています。

ブラックリスト解除の正しい手順

どのリストでも、解除の手順は基本的に同じです。

1. 原因を特定して止める: 乗っ取られたアカウント、感染した端末、悪用されたフォーム、第三者の中継を許す設定（オープンリレー）、同意のない一斉送信などを確認して止めます。
2. 運営者のページで掲載理由と解除方法を読む: 多くのリストは、IPを入力すると掲載理由や手続きを表示するページを用意しています。
3. 自動失効型なら待つ: SpamCop（報告が止まって24時間）や UCEPROTECT レベル1（最後の迷惑メールから7日）のように、原因が止まれば自然に消えるリストがあります。
4. 申請型なら一度だけ申請する: 何が原因で、何を直したかを具体的に書きます。Barracuda のように重複した申請を無視すると明記しているリストもあります。
5. 解除後に再送して様子を見る: 解除が反映されるまで時間がかかることがあります。SpamCop は、ミラーや利用者に反映されるまで最大4時間かかる場合があると説明しています。

原因を直さないまま解除申請を繰り返すのは逆効果です。通ってもすぐ再掲載されますし、解除するかどうかは運営者が決めるため、申請すれば解除されるとは限りません。

なお、Gmail の「送信元IPの評判が非常に低い」という 550 5.7.1 のような受信側独自の判断による拒否は、DNSBLから解除されても直りません。認証や送信内容、苦情率の改善が必要です。

共有サーバー・VPSでIPを共有している場合

レンタルサーバー（共有ホスティング）では、多くの利用者が同じ送信用IPを使っています。自分が何も問題を起こしていなくても、同じサーバーの別の利用者が原因で掲載されることがあります。

• 共有サーバーの場合: 送信用IPの管理者はサーバー会社です。自分で解除を申請するより、エラーの全文と送信元IPを添えてサポートに連絡するほうが確実です。範囲ごとの掲載（UCEPROTECT レベル2・3など）は、事業者でなければ対応できません。
• VPSや専用サーバーの場合: 割り当てられたIPに以前の利用者の履歴が残っていることがあります。使う前に掲載状況を確認し、逆引き（PTR）を送信ホスト名に合わせて設定しましょう。
• 家庭用回線や動的IPから直接送っている場合: Spamhaus PBL の対象になりやすい範囲です。プロバイダやメールサービスの送信サーバーに、ポート587か465で認証して送る形に切り替えるのが本来の対処です。

再掲載を防ぐために

解除されても、原因が残っていればまた載ります。次の点を日頃から整えておきましょう。

• 認証と基本設定: SPF・DKIM・DMARC、逆引き（PTR）、TLSでの送信を維持します。送信サーバーを変えたらSPFも見直します。
• アカウントの管理: 強いパスワードと二段階認証を使い、送信件数の急な増加がないかを見ます。
• フォームの悪用対策: 問い合わせフォームの自動返信が第三者への迷惑メールに使われないよう、送信回数を制限します。
• 宛先リストの管理: 同意を得た相手にだけ送り、届かないアドレスは削除します。Gmail と Yahoo は大量送信者にワンクリックの配信停止を求めています。
• 定期的な確認: 送信元IPとドメインの掲載状況をときどき確認しておくと、早めに気づけます。

よくある質問

参考にした公式ページ

本文の事実関係は、公開時点で次の公式ページに基づいて確認しています。仕様や運用は予告なく変わるため、重要な判断の前に各公式ページをご確認ください。

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3463: Enhanced Mail System Status Codes
• RFC 5782: DNS Blacklists and Whitelists
• Google Workspace: Gmail SMTP errors and codes
• Google: Email sender guidelines
• Yahoo Sender Hub: Best Practices
• Microsoft: Outlook.com Postmaster
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: SpamCop Blocking List delisting
• Barracuda Central: Removal Request
• UCEPROTECT: Removal Policy Level 1
• UCEPROTECT: Removal Policy Level 2
• UCEPROTECT: Removal Policy Level 3

関連記事

記事一覧を見る →