トラブルシューティング

メール認証は、メール配信の成功に欠かせません。このガイドでは、Email Service でのよくある SPF、DKIM、DMARC の問題をトラブルシューティングします。

ドメインに複数の SPF レコードがあることは許可されておらず、Email Service が正しく動きません。ドメインに複数の SPF レコードがある場合:

1. Cloudflare ダッシュボードにログインし、アカウントとドメインを選び、DNS > Records を開きます。

   Records を開く ↗

2. v=spf1 で始まる TXT レコードが複数ないかを確認します。

3. 正しくない SPF レコードを削除します。

4. 正しい SPF レコードがあることを確認します。

   • Email Routing（ルートドメイン）向け: v=spf1 include:_spf.mx.cloudflare.net ~all
   • Email Sending（cf-bounce サブドメイン）向け: v=spf1 include:_spf.mx.cloudflare.net ~all

どれが残すべき正しい SPF レコードか不明な場合は、すべて削除し、Cloudflare に必要なレコードを再生成させられます。

1. DNS > Records で、対象の名前にある v=spf1 で始まる TXT レコードをすべて削除します。
2. Compute > Email Service を開き、対象サービスを再オンボードまたは再有効化します。Cloudflare が正しい SPF レコードを自動で戻します。

SPF 失敗によりメールが拒否される場合:

1. Cloudflare ダッシュボードにログインし、アカウントとドメインを選び、DNS > Records を開きます。

   Records を開く ↗

2. 対象サービス向けの TXT レコードを追加します。

   • Email Routing 向け: Name: @（ルートドメイン）、Content: v=spf1 include:_spf.mx.cloudflare.net ~all
   • Email Sending 向け: Name: cf-bounce、Content: v=spf1 include:_spf.mx.cloudflare.net ~all

3. ルートドメインにすでに SPF レコードがある場合は、include:_spf.mx.cloudflare.net を含めるように変更します。

よくある SPF レコードの構文の問題:

• バージョンがない: SPF レコードは v=spf1 で始まる必要があります
• include が複数ある: 複数のサービスは、別々の include: ステートメントで結合します
• DNS ルックアップが多すぎる: SPF レコードの DNS ルックアップは合計 10 回までです
• all メカニズムが正しくない: ~all（SoftFail）または -all（Fail）を使い、+all は使わないでください

正しい形式:

v=spf1 include:_spf.mx.cloudflare.net include:other-service.com ~all

SPF レコードが正しく設定されていることを確認します。

dig TXT example.com +short | grep spf

期待する結果には次が含まれます。

"v=spf1 include:_spf.mx.cloudflare.net ~all"

Email Service はドメインの DKIM 鍵を自動生成しますが、DNS レコードを正しく設定する必要があります。Email Sending と Email Routing は別々の DKIM セレクターを使います。

1. Cloudflare ダッシュボード ↗ で、Compute > Email Service を開きます。
2. ドメインを選びます。
3. 対象サービスの Settings ページを確認します。
   • Email Sending: Email Sending > Settings を開き、送信 DKIM レコード（cf-bounce._domainkey）を確認します。
   • Email Routing: Email Routing > Settings を開き、ルーティング DKIM レコード（cf2024-1._domainkey）を確認します。
4. DKIM レコードの詳細をコピーします。
5. DNS > Records を開き、正しいセレクター名と公開鍵で DKIM TXT レコードを追加します。

DKIM 鍵をローテーションする必要がある場合:

1. Cloudflare サポートに連絡し、鍵のローテーションを依頼します。
2. 新しい DKIM 鍵が提供されたら、DNS レコードを更新します。
3. 移行期間中のメール配信を監視します。

DKIM レコードが正しく設定されていることを確認します。

# Check Email Sending DKIM
dig TXT cf-bounce._domainkey.example.com +short

# Check Email Routing DKIM
dig TXT cf2024-1._domainkey.example.com +short

いずれかに期待する結果:

"v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DKIM 検証が失敗している場合:

1. DNS に DKIM レコードがあることを確認します
2. レコード名が正しいセレクターと一致することを確認します。
   • Email Sending: cf-bounce._domainkey.yourdomain.com
   • Email Routing: cf2024-1._domainkey.yourdomain.com
3. DNS レコードに余分なスペースや文字がないことを確認します
4. DNS の伝播を待ちます（最大 48 時間）
5. オンラインの DKIM バリデーターで構成をテストします

必須ではありませんが、DMARC はメール到達性を大きく向上します。

1. Cloudflare ダッシュボードで DNS > Records を開きます。

   Records を開く ↗

2. TXT レコードを追加します。

   • Name: _dmarc
   • Content: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

厳しい DMARC ポリシーが配信問題の原因になっている場合:

1. 緩いポリシーから始めます: p=none（監視のみ）
2. 数週間、DMARC レポートを監視します
3. 段階的に厳しくします: p=quarantine、そのあと p=reject
4. SPF と DKIM の両方が正しくアラインしていることを確認します

DMARC は SPF または DKIM のアライメントを必要とします。

SPF アライメント: Mail From ヘッダーのドメインが From ヘッダーのドメインとアラインする必要があります DKIM アライメント: DKIM 署名ドメインが From ヘッダーのドメインとアラインする必要があります

Email Service は適切なアライメントを自動で保証します。

DMARC レコードを確認します。

dig TXT _dmarc.example.com +short

結果の例:

"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; sp=quarantine"

このエラーは、wrangler dev でのローカル開発中に、添付フィールドへ ArrayBuffer コンテンツを渡すと起きます。ローカルのメールバインディングシミュレーターは ArrayBuffer 値をシリアライズできません。

解決策: npx wrangler deploy で Worker をデプロイし、デプロイ済みバージョンに対してバイナリ添付（画像、PDF）をテストします。テキストベースの添付の文字列コンテンツは、ローカル開発でも通常どおり動きます。詳細は メール送信のローカル開発 を参照してください。

メールがスパムフォルダーに入る場合:

1. 認証を確認する: SPF、DKIM、DMARC が正しく設定されていることを確認します
2. ドメインレピュテーション: 新しいドメインは、最初はレピュテーションが低いことがあります
3. コンテンツ品質: スパム誘発ワードや過度な HTML 書式を避けます
4. 送信者レピュテーション: バウンス率と苦情率を監視します
5. リスト衛生: バウンスした無効なメールアドレスを削除します

バウンス率を下げるには:

1. メールアドレスを検証する: リアルタイム検証を使います
2. リストを清潔に保つ: ハードバウンスはすぐに削除します
3. フィードバックループを監視する: ISP のフィードバックループに登録します
4. 段階的なウォームアップ: 新しいドメインでは、少ない量から始めます

各送信ドメインには Drop suppressed recipients 設定 があります。設定はデフォルトでオフです。

設定がオフのとき、REST API は 400 を返し、Workers バインディングは E_RECIPIENT_SUPPRESSED をスローし、SMTP はメッセージを拒否します。抑制された受信者が 1 人でもいると、送信は失敗します。

設定がオンのとき、Email Service は抑制された受信者を除外し、残りの受信者を処理します。残りの受信者がいない場合、SMTP は Message-ID なしで 250 2.0.0 Ok を返し、何も配信しないことがあります。

抑制された受信者を調査するには:

期限切れのエントリは、expires_at タイムスタンプを過ぎると公開一覧から表示されなくなります。配信の強制停止には、さらに時間がかかることがあります。

更新と削除も非同期で伝播します。管理一覧と配信の強制適用は、短時間ずれることがあります。

強制適用の遅れを調査するには:

バウンス抑制は、バックグラウンドの配信処理で作成されます。進行中のメッセージは、新しい抑制が効く前にバウンスすることがあります。

苦情抑制は、Cloudflare がプロバイダーのレポートを受信して検証したあとに表示されます。レポートの到着タイミングはプロバイダーが決めます。

すべての失敗が抑制になるわけではありません。Email Service は、対象となる受信者側の失敗に対してのみ自動エントリを作成します。送信者認証、送信者レピュテーション、無関係なインフラ障害では受信者は抑制されません。具体的な失敗は メール送信ログ で確認してください。

ISP ごとに固有の要件があります。

• Gmail: 強いドメインレピュテーションと認証が必要です
• Outlook/Hotmail: コンテンツと送信者レピュテーションに敏感です
• Yahoo: 厳しい DMARC の強制適用があります
• 企業: 厳しいフィルタルールがあることが多いです

次のツールでメール認証のセットアップを検証します。

1. MX Toolbox: SPF、DKIM、DMARC レコードを確認します
2. DMARC Analyzer: DMARC ポリシーとアライメントを検証します
3. Mail Tester: メール到達性と認証をテストします
4. Google Admin Toolbox: Google のメール認証チェッカーです

認証の問題が続く場合:

1. 配信メトリクスは Email Service アナリティクス で確認します
2. 具体的なエラーコードはバウンスメッセージで確認します
3. Cloudflare Support ↗ に次を添えて連絡します。
   • ドメイン名
   • メールヘッダーの例
   • 具体的なエラーメッセージ
   • SPF、DKIM、DMARC レコードの構成