Marketing Cloud Engagement - メールの到達性問題 (バウンス・迷惑メール) に関するFAQ

*本記事では、Sender Authentication Package を SAP 、Private Domain (プライベートドメイン) を PD と表記します。

<Salesforce Marketing Cloud Engagement メール到達性 FAQ>
Q: SAP や PD で認証されていないドメインからメールを送信できますか？
A: 技術的には可能ですが、推奨しません。SAP または PD として登録・認証されていないドメインからメールを送信すると、送信ドメイン認証（SPF および DKIM）に失敗する可能性が非常に高くなります。
認証に失敗したメールは、受信サーバーによって迷惑メールとして扱われたり、ブロックされたりするリスクが増大します。そのため、Marketing Cloud Engagement で認証された SAP/PD に登録されているドメインを送信元として使用することを強く推奨します。


Q: 差出人アドレスの後ろに「経由 (via [bounce.SAPドメイン])」と表示されるのはなぜですか？
A: この「経由 (via)」表示は、Gmail をはじめとする一部のメールクライアントが表示するものです。これは、メールの From: ヘッダーに記載されているドメインと、実際にメールを送信したサーバーのドメインが異なる場合に、受信者に対して送信経路の透明性を高める目的で表示される場合があります。
具体的には、From: アドレスに SAP で認証されていないドメインを使用した場合、メールクライアントは「表示上の送信者ドメイン」と「実際の送信経路のドメイン」の不一致を検知し、「経由 (via)」として実際の送信経路の一部 (例: bounce.SAPドメイン) を表示することがあります。


Q: DMARC ポリシーを変更したい場合どれに設定すべきですか？
A: DMARC レコードは、ご自身のドメインから送信されるメールの認証状態（SPF および DKIM の検証結果）に基づき、認証に失敗したメールを受信側サーバーがどのように処理すべきかを指示するための DNS TXT レコードです。DMARC ポリシーの選択は、お客様にて決定いただいて構いません。
なおドメインを弊社に委任している場合はサポートケースを通じて DMARC レコードの変更が可能です。既存のものから変更したい場合は対象の委任ドメインと、 DMARC レコード (TXTレコード) の全文を添えてお問い合わせください。またセルフホストの場合はお客様のDNSサーバーで管理されているため、そちらを直接変更してください。

またDMARCに関しての詳細は下記も併せてご参照ください
参考: Marketing Cloud Engagement 送信ドメインのシンプル DMARC ポリシーのリクエスト


Q: SAP/PD を利用して送信しているにもかかわらず、外部のレポートで SPF/DKIM 認証が失敗したと報告されました。主な原因は何でしょうか？
A: Marketing Cloud Engagement において、SAP や PD が正しく設定・認証されていれば、これらのドメインを From: アドレスとして送信される限り、通常は成功します。（※ただし受信メールサーバーによって判断基準が異なり、この限りでない場合があります。詳細は次の Q を参照してください）

認証が失敗する場合、主に以下の技術的な原因が考えられます。

• メール転送： 受信者側の設定やメールシステムによって、別のアドレスへ転送された場合。転送の過程で認証情報が損なわれることがあります。
• Marketing Cloud Engagement 以外のメールサーバーからの送信： 対象ドメインを使用して、SPF/DKIM が適切に設定されていない他のメールサーバー（例: 企業内の別システム、他のメール配信サービス）からメールを送信した場合や、第三者が対象ドメインを不正に使用してなりすましメールを送信した場合。
• DKIM/SPF 関連のDNS設定不備： SAP/PD の設定初期段階や設定変更時に、DNS レコード設定に誤りがあったり、反映が遅れていたりする場合。また、送信サーバー側での DKIM 署名設定が不完全な場合も該当します。

上記いずれにも該当しない、または原因の特定が困難な場合は、実際に SPF/DKIM 認証に失敗したメールの完全なメールヘッダー情報（Gmail であれば “原文の表示”）を取得してください。 メールヘッダーには、メールの配送経路や各経由サーバーでの認証結果が詳細に記録されており、原因究明の重要な手がかりとなります。

判断が難しい場合は、Marketing Cloud Engagement からテスト用の購読者へメールを送信し、受信側で認証失敗が確認されたメールのヘッダー情報を取得の上、Salesforce サポートへお問い合わせください。

Q: SAP, PD で配信した場合に DMARC が Fail する場合にはどのような要因が考えられますか
A: 受信側のメールサーバーの基準によりますが、DKIM/SPF 双方のアラインメントに合格することを求められる場合、PDでは SPF のアラインメントに合格せず、DMARC が失敗に終わることがあります。この場合、マルチバウンス ドメイン機能の有効化により解消することがあります。詳細については下記ドキュメントをご覧ください。

参考 : Marketing Cloud Engagement - マルチバウンス ドメインの有効化について


Q: Marketing Cloud Engagement から送信したメールが、Gmail や Outlook.com、Microsoft Exchange Online などで「なりすましメール」として判定されました。なぜでしょうか？
A: 正しく設定・認証された SAP/PD を From: ドメインとして使用している限り、Marketing Cloud Engagement から送信されたメールが主要なメールプロバイダでなりすましと判定される可能性は低いと考えられます。 もし、なりすましとして判定された場合は、Q「SAP/PD を利用して送信しているにもかかわらず、外部のレポートで SPF/DKIM 認証が失敗したと報告されました。主な原因は何でしょうか？」で解説した主な原因（メール転送、Marketing Cloud Engagement以外のサーバーからの送信、DNS設定不備など）に該当しないか、まずご確認ください。


Q: 迷惑メールフォルダに振り分けられたメールや、受信サーバーで検疫・削除されたメールを Marketing Cloud Engagement のレポートで確認できますか？
A: いいえ、できません。メールが受信サーバー側でどのように処理されたか（例: 迷惑メールフォルダへの振り分け、検疫、削除）という情報は、セキュリティ上、ISPが送信側にフィードバックすることはありません。そのため、MCE からこれらを直接確認することはできません。迷惑メールへの振り分けはバウンスではないため_bounce データビューにも記録されません。

Q: _bounce データビューには、どのタイミングでバウンス情報が記録されますか？
A: _bounce データビューには、メールのバウンスが最終的に”確定”したタイミングで情報が記録されます。

• ハードバウンスの場合: 最初の送信試行でハードバウンス（恒久的な配信エラー）が発生した時点で、MCEはそのアドレスへの今後の送信を基本的に停止し、バウンス情報を記録します。
• ソフトバウンスの場合: 最初の送信試行でソフトバウンス（一時的な配信エラー）が発生すると、Marketing Cloud Engagement は15分間隔で、設定された期間（デフォルトでは72時間）、メールの再送を試みます。この再送期間が終了し、最終的なリトライでも配信に成功しなかった場合に、ソフトバウンスとしてバウンス情報が記録されます。

Q: ソフトバウンスの再送試行期間中の詳細（リトライ回数、時刻、SMTPメッセージなど）を確認できますか？
A: いいえ、できません。前述の通り、_bounce データビューにはバウンスが最終的に確定したタイミングの情報のみが記録されます。リトライ期間中の個々の再送試行の回数、時刻、およびその都度のSMTPメッセージといった詳細情報を確認することはできません。

Q: ソフトバウンスのリトライ期間は、いつを基準に開始されますか？
A: ソフトバウンスのリトライ期間（デフォルト72時間）は、Marketing Cloud Engagement のメール (MTA) サーバーが該当メールの最初の送信を試みた時刻を基準として開始されます。これは _sent データビューの EventDate の項目の値とは異なります。

Q: _Sent データビューの EventDate の日付は受信者がメールを受信した日時と解釈してよいですか？
A: いいえ、これは内部でメール作成が完了し、メールサーバー (MTA) にわたった時間が記録されます。残念ながら MTA からメールが送信された時刻や、受信者のメールボックスにメールが届いた時刻を確認する方法はありません。

Q: 受信者からメールの受信遅延が報告されました。どのように調査可能ですか？
A: 最も正確に調査するには、受信者からメールヘッダーを取得してもらう方法が確実です。 メールヘッダーには Received という、メールをリレーしたメールサーバーの情報とタイムスタンプが書かれるヘッダーがあり、これによりどの時点で遅延が発生したかを確認することができます。

受信者からこれを取得することが難しい場合、_Sent データビューの EventDateが想定より遅い時間になっているかを確認することができま。しかしながら上述の通り、これは MTA から外部メールサーバーへ送信した時間を示しません。よって判断がつかない場合はJobID と 購読者キー、おおよその送信日時を添えて弊社までお問い合わせください。弊社 MTA サーバー側で問題が無かったかなどを確認することができます。

Q: SPF/DKIM認証がパスしているにもかかわらず、送信したメールが迷惑メールとして判断されるのはなぜですか？
A: SPF/DKIM認証がパスしていることは、送信ドメインの正当性を示す重要な要素ですが、それだけでメールが必ずしも受信トレイに届くことを保証するものではありません。受信側のメールサーバーやメールサービスプロバイダは、迷惑メールかどうかを判断する際に、送信ドメイン認証の結果に加えて、非常に多くの要因を複合的に評価しています。

ISP はセキュリティの観点から、具体的な判定理由（なぜ迷惑メールとしたか）を送信者に対して開示しません。そのため、サポートへお問い合わせいただいても、プロバイダー内部の判定理由を特定することはできません。 そのため Postmaster tools や 外部のIPレピュテーション確認ツールなどを用い、状況を把握します。

■迷惑メール判定に影響を与える主な要因

• 受信者からの迷惑メール報告: 多くの受信者から「迷惑メール」として報告されると、レピュテーションが著しく低下します。
• 送信ドメインおよびIPアドレスのレピュテーション: 過去の送信実績（例：バウンス率の高さ、スパムトラップへのヒット履歴、IPアドレスの共有状況など）に基づく評価が低い場合。なお、共有の IP アドレスがブロックされているように見受ける場合は、弊社側での対応が必要となりますので、確認されている内容を踏まえて弊社までお問い合わせください。
• コンテンツの品質と構成:
  • 誤解を招く、または過度に扇情的な件名や本文。
  • 本文中の画像比率が高すぎる、テキストがほとんどない。
  • 信頼性の低い短縮URLの多用、リダイレクトが多いリンク。
  • 迷惑メールで頻繁に使用されるキーワードやフレーズの過度な使用。　など
• 受信者のエンゲージメント:
  • 開封率やクリック率が著しく低い。
  • 購読解除率が高い、または購読解除のプロセスが複雑。
• 送信リストの品質と収集方法:
  • 長期間反応のない古いメールアドレスや無効なアドレスが多数含まれている。
  • 確認のプロセスがないなど誤ったメールアドレスが蓄積されやすい。
• 送信頻度と送信量:
  • 受信者が予期しないタイミングや頻度での送信。
  • 短期間での急激な送信量の増加（特に新しい送信ドメインやIPアドレスの場合）。
• メール認証の不備（DMARCポリシーなど）: SPF/DKIMはパスしていても、DMARCポリシーが p=reject または p=quarantine であり、aspf や adkim が s (strict) になっておりアラインメントに失敗している場合など。

Q: 送信したメールがあるユーザーでは迷惑メールとして、あるユーザーでは正常に受信トレイに振り分けられる、あるいはプロモーションタブに振り分けられるんなど違いが出るのはなぜですか？ (ふるまいを送信側で指定できますか?)
A:  Gmail や Outlook などの高度なメールサービスプロバイダーは、ユーザーごとの過去の行動（エンゲージメント）に基づいて高度なロジックにより振り分けを行っています。 そのため、送信されたメール自体が全く同じであっても、受信者個人の利用状況（開封頻度、過去の反応など）によって、受信トレイ、プロモーション、迷惑メールなど、振り分け先が異なる場合があります。 送信者側でこの振り分け先を技術的に強制・制御することはできません。前述の「迷惑メール判定に影響を与える主な要因」を参考に、エンゲージメントを高めるための継続的な改善を行うことで想定する挙動に近づけるかを試すなど、送信の工夫により改善を試みます。