メールの送受信に問題がある場合は、次のトラブルシューティング手順に従ってください。
MX レコードが正しく解決されているかを確認するには、ターミナルで次の dig コマンドを実行します（example.com を自分のドメインに置き換えます）。
dig example.com mx +shortまたは、サードパーティのツールで MX レコードを調べることもできます。選択肢の一覧は、推奨するサードパーティツール を参照してください。
これで、ドメインのメールサーバー一覧が返ります。出力を、Cloudflare の DNS レコードページにある MX レコードと比較してください。
Records を開く ↗一覧のメールサーバーが、メールプロバイダーの想定値と一致しない場合は、MX レコードの内容を正しい値に更新します。正しい MX レコードの値は、メールプロバイダーのセットアップドキュメントで確認してください。
DNS クエリが、_dc-mx や dc-##### サブドメインなど、覚えのないレコードを返す場合は、想定外の DNS レコード を参照してください。
ドメインの MX レコードに対して dig が結果を返さない場合は、レコードが作成されていないか、誤って削除された可能性があります。
MX レコードが正しくても、メール認証レコードが不足していると配信に失敗することがあります。
SPFレコードがない: 受信サーバーは、送信サーバーをドメインが許可しているかを検証できません。メッセージが拒否されたり、迷惑メール扱いされたりすることがあります。DKIMレコードがない: メッセージがドメインから送信されたことを暗号的に検証できません。受信サーバーからの信頼が低下します。DMARCレコードがない:SPFまたはDKIMのチェックに失敗したメッセージの扱いについて、受信サーバーにポリシーがありません。配信が不安定になったり、ドメインのなりすましにつながったりすることがあります。
不足しているレコードの追加は、メールレコードを設定する を参照してください。
NS レコードは、サブドメインを別の DNS プロバイダーに委任 します。MX レコードが NS レコードで委任されたサブドメイン（例: mail.example.com）を指している場合、メールサーバーのレコードはその外部プロバイダーが管理しており、Cloudflare ではありません。外部プロバイダーに、メール用サブドメインの正しい A または AAAA レコードがあることを確認してください。
一部のメールプロバイダーは、DKIM 認証や autodiscover などの機能で CNAME レコードを必要とします。CNAME flattening が有効な場合（すべての CNAME レコードに対してグローバルに、または特定のレコードに対して個別に）、CNAME は A レコードにフラット化されます。そのため、メールプロバイダーがレコードを正しく読めないことがあります。
メールプロバイダーが CNAME レコードを必要としており、それらのレコードが想定どおりに解決されない場合は、CNAME flattening をオフにする必要があることがあります。
SMTP、IMAP、POP3 などのメールプロトコルは、Cloudflare の標準 HTTP プロキシでは動作しません。
メールに使うホスト名が Cloudflare の IP アドレスに解決される場合、そのレコードはプロキシされており、メールクライアントは正しく接続できません。
よくある例は次のとおりです。
- SMTP、IMAP、または POP3 に使う
mail.example.com MXレコードが対象とする任意のホスト名- プロバイダーの実際の DNS ターゲットを返す必要がある、Autodiscover またはメールサービス用のホスト名
この問題を修正するには、次の手順を実行します。
-
DNS Records ページを開きます。
Records を開く ↗ -
メール関連のホスト名を探します。
-
プロキシ状態 を DNS only に変更します。
MX レコード自体は常に DNS-only です。ただし、それが指すホスト名も、DNS-only のターゲットに解決される必要があります。
DNS の内容自体が正しいか分からない場合は、プロバイダーの値と比較してください。
よくある例は次のとおりです。
| プロバイダー | MX レコード | SPF レコード |
|---|---|---|
| Google Workspace | ASPMX.L.GOOGLE.COM（priority 1）、ALT1.ASPMX.L.GOOGLE.COM と ALT2.ASPMX.L.GOOGLE.COM（priority 5）、ALT3.ASPMX.L.GOOGLE.COM と ALT4.ASPMX.L.GOOGLE.COM（priority 10） |
v=spf1 include:_spf.google.com ~all |
| Microsoft 365 | <your-domain>.mail.protection.outlook.com（priority 0） |
v=spf1 include:spf.protection.outlook.com -all |
| iCloud Mail | mx01.mail.icloud.com と mx02.mail.icloud.com（priority 10） |
v=spf1 include:icloud.com ~all |
| Mailgun | mxa.mailgun.org と mxb.mailgun.org（priority 10） |
v=spf1 include:mailgun.org ~all |
変更する前に、必ずプロバイダーで正確な値を確認してください。
Cloudflare は、デフォルトではメールトラフィック（SMTP、ポート 25）をプロキシしません。Cloudflare Spectrum で SMTP トラフィックを明示的にプロキシする設定をしていない限り、メールはメールサーバーに直接配信され、Cloudflare ネットワークを通りません。メール用の DNS レコードは DNS only に設定し、プロキシの影響を受けないようにしてください。
Spectrum を開く ↗Email Routing が有効な場合、Cloudflare が MX レコードを管理し、追加の DNS レコードを自動作成することがあります。
Email Routing を開く ↗Email Routing が有効なのに別のメールプロバイダーを使っている場合、Email Routing の MX レコードがプロバイダーのレコードと競合することがあります。Email Routing をオフ にすると、管理対象レコードが削除され、自分で設定できます。
可能であれば、保護したい Web リソースと同じサーバーでメールサービスをホストしないでください。存在しないアドレス宛のメールは攻撃者に返送され、メールサーバーの IP アドレスが露見します。
Cloudflare は、異なる IP レンジから連続していない IP を使うことをおすすめします。
DNS レコードを編集した直後にメールが動作しない場合は、表示されている具体的なエラーまたはバウンスメッセージを添えて、メール管理者またはメールプロバイダーに問い合わせてください。問題が DNS 解決、メールサーバーの設定、メッセージ配信のどれにあるかを確認してもらえます。
プロバイダーが Cloudflare に関連する問題だと確認した場合は、Cloudflare サポートに連絡 してください。