2026 Cloudflare Email ServiceでDeliveredなのにメールが届かない？

Cloudflareの公式説明では、Deliveredは受信側メールサーバーがメールを受け入れた状態で、受信トレイへの到着を示すものではありません。トラブルシューティングの説明に沿って、Activity log、抑制状態、受信先の各フォルダー、メールヘッダーを順に確認してください。

向いている人： Cloudflare Email Serviceで自社製品のメールを送り、ログはDeliveredなのにテスト用受信先で見つからない開発者、QAエンジニア、個人開発者です。
向いていない人： 他社サービスへの一括登録や、許可のない宛先への送信手順を探している人には適しません。

「Delivered」と受信トレイ到着は別の状態です

Cloudflare Email ServiceでDeliveredと表示されても、それだけでは受信者がメールを読める状態になったとは判断できません。受信側メールサーバーが受け入れた後、迷惑メールや隔離フォルダーに振り分けられたり、メールクライアント上で別の分類に置かれたりする可能性があります。

Deliveredなら受信トレイに届いたと考えてよいですか？
いいえ。確認できるのは受信側サーバーがメールを受け入れたことまでです。メールのフォルダー分類や画面上での表示は、受信先の環境でも確認する必要があります。Cloudflareの説明も、Deliveredを受信トレイへの到着保証とはしていません。

まず、迷惑メール、隔離済みメール、アーカイブなど、受信先で利用できるフォルダーを確認します。さらに、いま開いている受信箱が、今回のテストで指定したアドレスと完全に一致しているか照合してください。宛先のタイプミスや、別のテストアカウントを見ていることも、ログと受信状況が食い違う原因になります。

Activity logで送信結果を特定します

Cloudflare Email ServiceのActivity logでは、表示された状態だけでなく、対象の送信記録と宛先を照合します。Cloudflareのログに関する説明にある状態名を確認し、アプリケーション側の送信記録とも突き合わせてください。

ここでは、送信要求が処理されたこと、受信側サーバーが受け入れたこと、ユーザーがメールを見つけて読めることを分けて考えます。これらはそれぞれ異なる確認結果です。

送信ログがDeliveredなのにテストメールが見つからないときは、何から調べますか？
Activity logの今回の記録から、宛先と状態を確認します。アプリケーションログのMessage-IDと送信先を照らし合わせ、同じメールの記録を見ていると確認できてから、受信側のフォルダーやヘッダーの調査に進みます。

受信先の抑制状態とDNS認証を確認します

宛先が抑制状態にある場合、送信の扱いが通常と異なることがあります。自分が管理するアカウントと、送信を許可されたテスト環境に限って、Cloudflareの抑制設定の説明と現在の設定を確認してください。

テスト用アドレスが抑制されているか、どう確認しますか？
Cloudflare側の抑制に関する記録と、該当する送信イベントを照合します。抑制保護を無効にしたり、仕組みを回避したりすることを一般的な解決策として扱わず、まず対象アドレスが意図したテスト先か、抑制に至った理由を確認してください。

次に、送信に使うドメインについて、Email Sending用のDNS認証レコードを確認します。ドメイン設定の公式ガイドを参照し、受信メールの転送などに使う設定と、送信の認証設定を取り違えていないか確かめてください。SPF、DKIM、DMARCの認証が通っていても、受信側の判定によるフォルダー分類までは保証されません。

受信側で見つけるための確認手順

次の手順は、自社製品または許可を得たテスト環境で行います。配信結果と、実際に受信メールを読めたかを別々に記録すると、どの段階で食い違いが起きたかを説明しやすくなります。

• [ ] テスト宛先を照合する。 今回の送信で指定したアドレスと、実際に開いている受信箱のアドレスを確認します。
• [ ] Activity logの送信記録を絞る。 該当する宛先とイベントを探し、Sent、Delivered、Delivery failed、Rejected、Failedのどの状態かを確認します。
• [ ] Message-IDを記録する。 アプリケーションログとActivity logで同じ送信を追えるよう、メッセージ識別子を照合します。
• [ ] 抑制状態を確認する。 対象のテスト宛先と設定を調べ、抑制の扱いを許可された範囲で確認します。
• [ ] 受信先の各フォルダーを探す。 迷惑メールや隔離フォルダーなどを確認し、検索条件に宛先やMessage-IDを使える場合は利用します。
• [ ] 完全なメールヘッダーを取得する。 受信側で確認できる場合は、メールの完全なヘッダーを表示する手順を参考にし、Authentication-Resultsなどの情報を調べます。
• [ ] 同じ条件でテストを再実行する。 新しい送信の状態、受信側の受け入れを示す情報、メールを実際に開けたかを別々に記録します。

メールが迷惑メールフォルダーにある場合も、Deliveredだけから分類理由を断定することはできません。Authentication-Resultsや受信側が提供する情報を使い、認証結果と受信側の判定を切り分けます。受信側による分類の一般的な確認では、送信者向けガイドラインも参照できます。

受信先の選択で確認できる範囲が変わります

どの受信先を使うかで、「送信側の状態」だけでなく、「メールを人が実際に読めたか」まで確認できるかが変わります。開発時の目的に合わせて、次のように選んでください。

テストで証明したいことが「送信処理が動いた」だけなら、アプリケーションログで足りる場合があります。一方、「ユーザーが受信して読める」ことまで検証するなら、管理下の受信先でメールを開き、実際の表示結果を確認してください。テスト用アドレスを選ぶ際は、検証コードの受信と確認方法も参考にし、テストで必要な受信確認ができるかを確かめてください。

テストメールを実際に読めるところまで検証します

受信側のフォルダーにメールがある場合、原因を特定できたと言えますか？
メールが存在することは確認できますが、分類理由まで分かったとは限りません。Message-IDで送信記録とメールヘッダーを関連付け、Authentication-Resultsなどの受信側情報を確認して、認証とフォルダー分類を別の証拠として扱います。

実際のテストでは、宛先を管理できる受信先を選び、アプリケーションとActivity logで同じ送信を追えるようにします。その後、受信側がメールを受け入れた記録と、フォルダー内でメールを開いて読めた結果をそれぞれ残してください。CloudflareのDeliveredだけでは、受信側が最終的にどのフォルダーへ置いたかは分かりません。

受信先にテスト用の一時アドレスを使う場合は、現在の機能を確認したうえで、実際に読み取れるメールの確認に適するか判断してください。Emailbyeも選択肢の一つですが、特定のアドレスへの到着を保証するものではありません。自社製品のテスト受信先として使う前に、Emailbyeのページで利用できる受信方法を確かめ、テストメールを実際に読めるかを確認してください。銀行、決済、行政など、長期的な受信やアカウント復旧が必要な用途には、管理を続けられるメールアドレスを使うのが適切です。