Email Deliveryに関するよくある質問

一般的な質問

Email Deliveryについてご説明ください。

Oracle Cloud Infrastructure Email Deliveryは、ユーザーの受信トレイに届ける必要がある大量のメールを送信するための高速で信頼性の高いマネージド・サービスを提供するメール送信サービスです。Email Deliveryは、領収書、不正検出アラート、多要素ID検証、パスワードのリセットなどのミッション・クリティカルなコミュニケーションのためにアプリケーションが生成したメールを迅速かつ確実に送信するために必要なツールをお客様に提供します。Email Deliveryは、拡張性に優れ、低コストで信頼性の高いインフラストラクチャ・サービスであり、社内メール配信ソリューションを構築する際の複雑さと費用の問題を解決します。

Email Deliveryの使用が適切な場合を教えてください。

• メール機能を含むクラウドベースのアプリケーションでは、Email Deliveryを活用するのが適しています。
• 費用対効果の高い方法でユーザーの受信トレイに届くメッセージを送信する必要がある企業では、Email Deliveryの使用が適しています。

Email Deliveryが必要な理由を教えてください。

• メールは企業が顧客とやり取りするための最も直接的な手段であり、企業ではメールをユーザーの受信トレイに確実に届けることが不可欠です。さまざまなスパム・フィルタリング・システムが存在するため、自動送信メールの数と頻度が増加するにつれて、メッセージを顧客の受信トレイに確実に届けることが次第に困難になります。
• Email Deliveryは、メール配信の設定、インフラストラクチャ、セキュリティ、および認証の問題を解決する開発者向けのサービスです。

Email Deliveryで送信可能なメールの種類を教えてください。

Email Deliveryは、領収書、不正検出アラート、多要素ID検証、パスワードのリセットなど、アプリケーションが生成する業務上のメールに最適ですが、業界の規制や法律を遵守していれば、どのようなメールでも送信できます。

Email Deliveryは、EloquaやResponsysのようなフロントエンド・プロバイダでしょうか。

Email Deliveryは、EloquaやResponsysなどのフロントエンド・プロバイダと統合できるバックエンド・インフラストラクチャです。Email Deliveryでは、ユーザーがHTMLキャンペーンを開発したり、受信者リストを管理したりすることはできません。

Email Deliveryは、Amazon SESやSendGridと同様のものでしょうか。

はい。Email Deliveryサービスは、Amazon SESやSendGridと同様のサービスです。

Email Deliveryでメールの送信を開始する方法を教えてください。

APIまたはOracle Cloud Infrastructureコンソールで以下の手順に従って、メールの送信を開始してください。

Email Deliveryの構成および使用方法の詳細については、ここをご確認ください

1. Oracle Cloud Infrastructureコンソールから、SMTP資格情報を作成するユーザーを見つけます。そのユーザーが、承認された送信者を管理するポリシーを持っているグループに属していることを確認します。たとえば、グループMyGroupに、コンパートメントMyCompartment内の承認された送信者の使用を許可します。

2. 新しいユーザーの設定で、左側のSMTP資格情報を選択し、SMTP資格情報を生成します。

3. Oracle Cloud Infrastructureコンソールで「メール」を選択します。正しいコンパートメントが選択されていることを確認します。ユーザーは、このコンパートメントで承認済みの送信者を管理する権限を持つグループに属している必要があります。

4. 指定されたコンパートメント内で承認済みの送信者を1人以上作成します。それらの送信者のメール・アドレスが、メールの「From」行に表示されます。承認済みの送信者は、リージョンに固有であることに注意してください。たとえば、フェニックスで承認済みの送信者を作成した場合、アッシュバーンでメールを送信することはできません。

5. 手順に従って、対応するドメインにTXTレコードを追加することにより、送信者ポリシー・フレームワーク（SPF）のDNSを構成します。

6. お客様のシステムからEmail Deliveryを通じて、SMTP接続をセットアップし、テストします。PostfixとSendMailは人気のあるSMTP製品ですが、任意のSMTPライブラリを使用できます。

Email Deliveryがサポートされているリージョンを教えてください。

Email Deliveryは、すべてのOCIリージョンおよびレルムで使用できます。完全なリストについては、「リージョンと可用性ドメイン」を参照してください。

ノート：メールを送信するアプリケーションが送信元のリージョンにある必要はありませんが、パフォーマンスの観点から、送信アプリケーションと同じリージョンでメールを設定することをお勧めします。

承認済みの送信者を追加しようとするとエラーが発生する理由を教えてください。

• 選択したコンパートメント内で、承認済みの送信者を管理する権限があることを確認してください（契約の基本）
• 承認済みの送信者数の上限に達している可能性があります。必要に応じてMy Oracle Supportを使用して、サービス・リクエストを提出し、メール送信の制限を引き上げることができます。
• お客様のアカウントが停止されている可能性があります。その場合、承認済みの送信者数の上限が0になります。

メールの送信

承認済みの送信者についてご説明ください。

承認済みの送信者は、Email Deliveryで一致する送信元アドレスを使用してメールを送信するためのリソースです。承認済みの送信者は、コンパートメントに関連付けられ、それらの送信者が設定されたリージョンでのみ有効です。

Email Deliveryで、メールの一括送信は可能でしょうか。

はい。Oracle Email Deliveryを使用して、プログラムでメールを一括送信できます。

注意 - GAではレポートを利用できません。

SMTPではTLSは必要でしょうか。

• Email Deliveryでは、オラクルが誇る厳格なセキュリティ・ポリシーを遵守しています。そのため、TLS経由のお客様のメールのみを受け付けます。
• TLS（TLSは必須）
• TLSの以前のバージョンは安全性が低いため、TLSバージョン1.2のみをサポートしています。
• Javaアプリケーションは、最新バージョンに更新し、オラクルのセキュリティ・ポリシーを遵守する更新版のセキュリティ・プロトコル、暗号、パッチを確実に適用する必要があります。
• 承認済みの暗号は次のとおりです。
  • TLSv1.2：
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

サポートされているSMTP Authコマンドを教えてください。

• SMTP Plainのみをサポートしています。
• 注意 - 送信アプリケーションでAuthコマンドを柔軟に使用できない場合は、smtp proxy/relayを使用できます。

パブリック・インターネット・アクセスを使用せずに、アプリケーションからEmail Deliveryにメールを送信することは可能でしょうか。

• はい。アプリケーションは、プロキシ・サービスやリレー・サービスなど、インターネットにアクセスできるサービスに送信する必要があります。
• 将来的に、Email Deliveryは、パブリック・インターネットを経由することなく、Service Gatewayサービスを使用してOracle Cloud Infrastructure内からメールを受信できるようになります。

Email Deliveryに関連する制限についてご説明ください。

Email Deliveryプラットフォームは、Oracle Cloud Infrastructureのメール配信到達性チームによって管理されています。サービスとお客様のレピュテーション（評判）を保護するために、アカウントには制限が設けられています。My Oracle Supportからサービス・リクエストを発行すると、大規模な送信要件に応じて、以下の制限を引き上げることができます。

• oracle.comで無償トライアルに申し込んだお客様は、24時間あたり200通のメールに制限されており、送信レートは1分あたり10通を超えてはなりません。承認済みの送信者は2,000人に制限されています。base64エンコーディングとヘッダーを含めたメッセージの最大サイズは、2MBです。
• エンタープライズ・アカウントでは、24時間あたり50,000通までに制限されており、送信レートは1分あたり18,000通を超えてはなりません。企業のお客様の場合、承認済みの送信者は10,000人に制限されています。base64エンコーディングとヘッダーを含めたメッセージの最大サイズは、2MBです。
• Email Deliveryでは、大量のメール送信をサポートしていますが、お客様のレピュテーションを保護するために制限が設定されています。
• My Oracle Supportを通じてご連絡いただければ、お客様と協力して利用状況を把握し、必要に応じて送信制限を引き上げることができます。

Email Deliveryで送信できるメールの種類に制限はあるのでしょうか。

サービスに関する説明に記載されているように、Email Deliveryで送信されるメールの種類について、次の義務が適用されます。

• お客様は、これまでにビジネス上の関係や個人的つながりのない受信者に対して、「スパム」メール、大量の迷惑なインスタント・メッセージ、またはその他の形式の迷惑な電子的通信を一括送信する目的で本サービスを使用しないものとします。

送信可能なメールのサイズを教えてください。

メッセージ・ヘッダー、本文、base64エンコーディング、添付ファイルを含め、最大2MBのメッセージが、初期設定でサポートされています。

サイズの上限を増やす場合、2MBのデータは、「メール」としてそれぞれ毎日の送信量および送信速度制限にカウントされます。

メールの例

• 1人の受信者に送信される10MBのメールは、メール1通あたり10MB/2MB、つまり5通のメールに等しい。
• メッセージ・サイズが10MB、受信者が10人のメール要求は、メール1通あたり10MB/2MB x 受信者10人、つまり50通のメールに等しい。

添付ファイル付きのメールは送信可能でしょうか。

Email Deliveryは、SMTPを介した多目的インターネット・メール拡張（MIME）メッセージの送信をサポートしています。MIMEは、添付ファイルの動作に関連する仕様を含むRFC標準です。詳細については、こちらを参照してください。

利用可能な送信方法を教えてください。

現時点では、SMTPが、Email Deliveryを介してメールを送信する唯一の方法です。Email Deliveryを利用できる各Oracle Cloud Infrastructureリージョンには、固有のSMTPエンドポイントがあります。

Email Delivery用のSDKは提供されているのでしょうか。

はい。Email Deliveryは、Oracle Cloud Infrastructure SDKに含まれています。

配信到達性

Email Deliveryが配信の信頼性を確保する方法を教えてください。

Email Deliveryは、業界のベストプラクティスに準拠したシステムを介して信頼性の高いサービスを提供します。このプラットフォームは、Oracle Cloud Infrastructureのメール配信到達性チームによって管理されています。メール配信到達性チームは、主要な配信到達性メトリックを確認して、できる限り最高の送信レピュテーションを確保します。Email Deliveryでメールを送信する場合、お客様の代わりに次の項目を管理します。

• メールボックス・プロバイダ固有のSMTP構成
• バウンスの収集
• ユーザー・クレームの収集
• メール認証規格（SPFなど）
• IPプール管理

Email Deliveryが、SMTP構成をスタマイズする方法を教えてください。

Email Deliveryは、メールボックス・プロバイダ固有のレート制限、バックオフ・モード、およびSMTP構成で構成されます。これらの構成は、業界での関係とグローバル・メールボックス・プロバイダ全体での長年にわたる調整を通じて設定され、受信トレイへの到達と配信速度を最適化します。

Email Deliveryは、バウンスされたメールを収集するのでしょうか。

はい。バウンスされたメールは収集され、対応するバウンス・コードごとに適切に分類されます。

メールがバウンスされた場合の適切な対応を教えてください。

ハード・バウンスなど、永続的に配信できないと見なされる受信者アドレスは、お客様の配信停止リストに配置されます。配信停止リストにあるアドレスへの送信を繰り返し行っても、Email Deliveryでは配信されず、そのような状況が発生すると、ブロック・レポートに記録されます。送信者が、存在しない受信者アドレスにメッセージを送信しようとすると、ハード・バウンス率（送信されたメッセージに対するハード・バウンスの比率）が高くなります。メールボックス・プロバイダは、送信者にハード・バウンス・コードを返します。ハード・バウンス率は、配信停止リストの品質を示すのに適した指標であり、2%未満である必要があります。

Email Deliveryはユーザー・クレームを収集するのでしょうか。

はい。ユーザー・クレームは、メールボックス・プロバイダのクレーム・フィードバック・ループを介して収集および処理されます。これらのクレーム・フィードバック・ループのセットアップは、Email Deliveryにより完全に自動化されています。

ユーザーからのスパム・クレームが収集されると、お客様の送信レピュテーションを保護するために、そのユーザーは配信停止リストに追加されます。メール配信の高い品質を確保するために、その時点でユーザーをメーリング・リストから削除することもお勧めしますが、他のアクションは必要ありません。

配信停止リストについてご説明ください。

配信停止リストは、Email Deliveryコンソールのユーザー・インターフェイスと、API、SDK、CLIに含まれています。

Email Deliveryは、永続的な失敗またはユーザー・クレームを示すバウンス・コードを含むメール・アドレスを配信停止リストに自動的に追加して、送信者のレピュテーションを保護します。それ以降、Email Deliveryは、それらの受信者にメールを送信しません。配信停止されたメール・アドレスへの送信を繰り返し試みると、ブロック・レポートに表示されます。

現在、配信停止の理由には、迷惑メール苦情、ハード・バウンス、反復的なソフト・バウンス、手動入力、リストからの登録解除リクエストがあります。

送信者ポリシー・フレームワーク（SPF）とは何、また使用方法を教えてください。

SPFは、メール・アドレスのなりすましを防ぎ、スパムの受信を最小限に抑えます。ドメインは、SPFを通じて、そのドメイン名の使用を許可されているホストを明示的に認証できます。SPFは、SPF（コード99）レコードまたはTXT（コード16）レコードを公開することにより機能します。これらのレコードは、ドメイン名の使用を許可するホストを宣言するDNSリソース・レコードです。受信メール・サーバーは、メールの送信元として特定されたドメインのSPFレコードをチェックして、メールの送信元IPがそのドメインからメール送信を許可されていることを確認します。

メールボックス・プロバイダとISPは、SPFをチェックして、送信者（Email Delivery）がドメインに代わってメールを送信する許可を得ていることを確認します。SPFは、お客様のドメインが優れた配信到達性を実現し、スパムやフィッシング攻撃などの悪意のある行為からユーザーを保護するために不可欠な基盤です。

SPFを設定するには、承認済みの送信者が使用するドメインにTXTレコードを含める必要があります。このドメインで許可されている唯一の送信者がEmail Deliveryである場合、次のようになります。

送信場所	SPF
南北アメリカ	v=spf1 include:rp.oracleemaildelivery.com ~all
アジア太平洋地域	v=spf1 include:ap.rp.oracleemaildelivery.com ~all
ヨーロッパ	v=spf1 include:eu.rp.oracleemaildelivery.com ~all
すべての市販リージョン	v=spf1 include:rp.oracleemaildelivery.com include:ap.rp.oracleemaildelivery.com include:eu.rp.oracleemaildelivery.com ~all

「v」は、使用するSPFのバージョンを示します。これ以外の機構で、メールの正当性をテストします。「MX」と「A」は、メールを受け入れるかどうかを決定するために、メールとSPFレコードの間で比較されるリソース・レコードです。「all」は、必ず一致し、デフォルトのアクションとして機能します。これらの機構を修飾子と組み合わせて、一致を処理する方法を決定します。最もシンプルな修飾子は、「+」（修飾子を省略した場合、暗黙的に指定される）および「-」で、それぞれ「合格」（Pass）および「失敗」（Fail）を意味します。これらの結果の処理方法は、受信側ドメインの管理者に任されています。通常、「失敗」（Fail）は拒否され、「弱い失敗」（Soft Fail）は潜在的なスパムとして判定されます。

SPFを使用すると、クライアントの信用と信頼を高めることができます。SPFを実装したドメインは、なりすましをされる可能性が非常に低くなります。SPFを使用しない場合、スパム・メールで特定のドメインを表示してなりすましを行うことができます。その場合、受信者がそのメールをスパムとして報告する可能性があります。そのような報告が十分にあると、ベイジアン・スパム・フィルタはドメインをブロックする可能性が高くなり、潜在的に正当なメールがブロックされます。ただし、ドメインにSPFが実装され、適切に設定されている場合、受信サーバーが、不正なメールをブロックする可能性が高くなります。

専用IPでのメール送信は可能でしょうか。

はい。Email Deliveryは専用IPをサポートしています。デフォルトでは、お客様のアカウントは、メールの特性に応じて、階層化された共有送信プールに設定されます。大量に送信する場合は、専用IPをお勧めします。メール送信の頻度が少ない場合や散発的にしか送信しない場合、専用IPは、適切な送信レピュテーションの確保に効果がなく、メールの配信到達性に影響を与えるためお勧めしません。

それぞれのお客様のメールの特性（メールの量、バースト・レート、レピュテーションなど）によって、専用IP戦略が異なります。オラクルのチームは、このテーマに関するトレーニングを受けており、お客様の専用IPに関するニーズをサポートする準備ができています。この構成については、当社サポート窓口にお問い合わせください。

メールが配信到達性のベストプラクティスに準拠していることを確認するためにすべきことを教えてください。

配信到達性のベストプラクティスは、ユーザーが希望する透過的なメールを提供することが基本になっています。カナダのスパム防止法（CASL）は、法律、ユーザーの希望、および大部分のメールボックス・プロバイダが使用する意図的なフィルタリングへの適合を実現するのに最適なガイドの1つです。CASLの概要と業界をリードする手法については、https://help.dyn.com/casl-faq/でご確認いただけます。

レピュテーションが重要な理由をご説明ください。

メールの送信に関しては、クリーンなネットワークを使用してメールを配信することがこれまで以上に重要になっています。スパム業者やレピュテーションの低い他の送信者とIPアドレスを共有している場合、お客様のメールが受信トレイに配信される可能性は大幅に減少します。オラクルのネットワーク管理では、継続的な警戒を行うことにより、問題がある送信者を排除し、クリーンな環境を実現しています。

レピュテーションに影響を与えるものについてご説明ください。

認証

サードパーティのメール配信サービスを使用する場合、メール認証は、SPFとドメイン・キー（DKIM）の両方をDNSレコードに設定して、送信者（Email Delivery）と受信サーバー（ISPおよび企業メール・サーバー）間での本人確認と信頼性確認を行うのに役立ちます。受信サーバーでは、不要なメールやなりすましメールが受信トレイに到達するのを防ぐため、お客様のドメインのDNSレコードを検索して、サードパーティの送信者がお客様の代わりにメールを送信する権限を持っているかどうかを確認します。

メールの量や頻度

安定したメール送信量と送信頻度は、適切な送信者としてのレピュテーションを構築するのに役立ちます。ランダムなスパイク状のトラフィックの場合、スパム業者であると判断される可能性が高くなります。受信側ISPに、信頼できる送信者として認められるには、お客様のIPから十分な量のメールを送信する必要があります。

バウンス率

バウンス率は、送信したメールの総数に対する配信不能メッセージ（バウンス）の割合です。バウンス率は、2%未満に維持することをお勧めします。バウンス率が高い場合は、リストの管理とクレンジングが不適切であるか、リストが古いか、リストがレンタルまたは購入されていることを示します。Email Deliveryでは、バウンス率を低く抑えるために、バウンスを配信停止リストに自動的に追加します。

スパム・クレーム率

スパム・クレーム率は、送信したメールの総数に対する、ユーザーがISPに送信したクレームの割合です。メール受信者がメール・クライアントのUIで「これはスパムです」ボタンをクリックすると、スパム・クレームが発生します。スパム・クレーム率は、0.05%未満に維持することをお勧めします。Email Deliveryでは、スパム・クレームを配信停止リストに自動的に追加します。

ブラックリスト

ISPは、ブラックリストを使用して、レピュテーションの低い送信者からのスパムをブロックします。正当な送信者が誤ってブラックリストに登録される可能性があります。Email Deliveryでは、送信IPについて、ブラックリストに登録されている上位10件のサービスをリアルタイムでスキャンします。ほとんどのブラックリストでは、登録された送信者は24時間ブロックされ、この時間が経過するとリストから自動的に削除されます。ただし、リストから削除してもらうために、リストに登録された送信者によるアクションが必要な場合もあります。

ハード・バウンス率を下げる方法を教えてください。

送信者が、存在しない受信者アドレスにメッセージを送信しようとすると、ハード・バウンス率（送信されたメッセージに対するハード・バウンスの比率）が高くなります。メールボックス・プロバイダは、送信者にハード・バウンス・コードを返します。ハード・バウンス率は、配信停止リストの品質を示すのに適した指標であり、2%未満である必要があります。

通常、次のような受信者アドレスでハード・バウンスが発生します。

• 入力内容に間違いがある
• 使用されていない（ユーザーがアカウントを削除した）
• WebをスクレイピングしてWebサイトから取得した
• リスト・サービス・プロバイダが作成した

メールボックス・プロバイダは、ハード・バウンスが発生することを想定しています。ただし、ハード・バウンスが多すぎると、配信到達性が低下し始めます。Email Deliveryは、ハード・バウンスされたすべての受信者アドレスを配信停止リストに自動的に追加して、そのアドレスへの以降の配信を防ぎ、お客様の送信レピュテーションを保護します。

次のようにして、バウンス率の上昇を防ぐことができます。

1. オプトイン・プロセスを実装する。一括メール送信（多数の受信者への同時送信）の場合、オプトイン・プロセスを実装します。オプトイン・プロセスは、ユーザーがメーリング・リストに登録する（メッセージを送信する許可をお客様に与える）方法です。オプトインした登録者にのみメッセージを送信することが重要です。オプトイン手順には2つの種類があります。

2. シングル・オプトイン（未確認） - シングル・オプトインとは、ユーザーがメール・アドレスを提供し、該当するメッセージを受信する許可を与えることです。メール・アドレスが提供されると、そのアドレスが提供したユーザーのものであることを確認せずにメッセージを送信できます。

3. ダブル・オプトイン（確認済み） - ダブル・オプトインでは、ユーザーがメール・アドレスを入力します。最初のメール送信の前に、今後のメッセージの受信をアカウント所有者が希望していることを確認するために、必要なユーザー・アクションを含む確認メールが送信されます。所有者にリンクをクリックしてそのメールに返信してもらうことにより、アカウントを確認できます。これにより、アドレスが、所有者の同意なしにサードパーティのメーリング・リストに追加されたものではないことを確認できます。

4. エンゲージメントのないユーザーを削除する。エンゲージメントのないユーザーを削除するプロセスを実装します。受信者がメールを開いたりクリックしたりしていない場合は、そのメール・アカウントが使用されていない可能性があります。その場合、最終的にメールボックス・プロバイダはアカウントを停止するか、スパム・トラップとして利用します。このようなスパム・トラップに引っかかったり、削除されたアカウントに送信されたメールがハード・バウンスされたりすることを避けるため、お客様のビジネス・モデルで指定された期間内にエンゲージメントのない受信者アカウントは削除します。これは、ユーザー・エンゲージメント率を高めて、配信到達性を高めるのにも役立ちます。

5. 登録者リストを確認する。登録者リストを確認するときは、次のことを行ってください。

送信前に重複アドレスを削除します。存在しないアドレスへのメール送信が複数回発生すると、ハード・バウンス率が上昇する可能性があります。

以前の配信停止リスト（たとえば、別のメール・サービス・プロバイダのもの）が誤って含まれていないことを確認します。

登録者がオプトインしていることを確認します（お客様が見つけた古いリストには送信しないでください）。

ユーザーが「すべて選択」方式でメール・クライアントの連絡先リストをアップロードできないようにします。古いアドレスや期限切れの可能性があるアドレスが誤って含まれることを防ぐため、ユーザーにアドレスを個別に選択してもらいます。

6. 送信頻度を評価する。ハード・バウンスされたメッセージがハード・バウンスとして登録されずに、その次のメッセージが同じ受信者に送信されると、メッセージは再びハード・バウンスされます。別のメッセージを送信する前に、メールボックス・プロバイダやメール・サービス・プロバイダのために、バウンスを処理する時間を確保してください。また、送信頻度を減らすと、ユーザーはスパムに指定する可能性のある不要なメッセージを複数回受信することなく登録を解除できます。

ソフト・バウンス率を下げる方法を教えてください。

メッセージが受信者に送信されたときに、受信サーバーが一時的に利用できない場合やメッセージが受信者によってブロックされた場合、ソフト・バウンスが発生します。ソフト・バウンス率は、送信メッセージ数あたりのソフト・バウンス回数の比率です。ソフト・バウンスは一時的な未配信状態であり、メールボックス・プロバイダは送信者にソフト・バウンス・コードを返します。これらの受信者のアドレスは存在するため、配信停止リストに追加されません。

• ノート：あるアドレスに24時間以内に4通のメールが送信されてソフト・バウンスが発生した場合、Email Deliveryはそのアドレスを配信停止リストに追加します。

通常、ソフト・バウンスは、メッセージ・コンテンツの品質と妥当性に関する適切な指標になります。

通常、ソフト・バウンスは次の場合に発生します。

• スパム的なコンテンツ – メッセージ・コンテンツが受信者によってスパムとして識別され、一時的にブロックされています。
• 受信者に関係のないコンテンツ – このようなコンテンツは、多数のクレームを招く可能性があり、受信者は、送信者のIPアドレスまたはドメインからのメッセージを一時的にブロックします。
• 多数のクレーム – 一部の受信者は、クレームがしきい値（IPあたりのある期間にわたるクレームの数）を超えると、該当するIPアドレスからのすべての着信メッセージをブロックします。
• 受信メール・サーバーがビジー – この状況が発生した場合、送信メール・サーバーはメッセージの送信を4回試みた後、メッセージをハード・バウンスします。
• メールボックスのクォータがいっぱいまたは超過 – 受信者のメールボックスのクォータが、いっぱいになったか超過している場合、メッセージがソフト・バウンスする場合があります。

クレーム率を下げる方法を教えてください。

クレームはさまざまな理由で発生する可能性があり、ユーザーがメッセージを「スパム」であるとは考えていない場合もあります。実際には、メールが溜まった受信トレイのメッセージを減らすために、単純にスパム・ボタンをクリックする人もいます。

メッセージに関するクレームが発せられる可能性がある、よくある理由をいくつか示します。

• 本物のスパムである。
• コンテンツが、受信者が期待している内容と関係ない（オプトインした内容と異なる）。
• メールのフッターに埋もれている登録解除URLを見つけることよりも、クレームを発するほうが簡単である。
• 受信者が、登録解除URLよりもISPのユーザー・インターフェイスを信頼している。
• 受信者が、お客様のメッセージの受信にうんざりしている。

クレーム率を改善する方法は次のとおりです。

• スパムを送信しない
• コンテンツの関連性を保つ – 受信者が、お客様のサイトで毎日の食料品クーポンを申し込んだ場合、自動車ローン金利に関するメールの送信を開始しないでください。
• アクセスしやすい登録解除URL— 登録解除できるのは望ましいことです。リストが小さくなるのは残念ではありますが、実際には、メッセージを開いたりクリックしたりしてくれる、エンゲージメントのある受信者にのみ適切にメールを送信できます。ユーザーからクレームが発せられると、お客様の送信レピュテーションが傷つくので、リストからの削除をユーザー自身が簡単に行えるようにします。一番悪いのは、登録解除URLをメッセージの最後に配置することです。メールの最後までスクロールして小さなURLを探すのは、ユーザーのごく一部です。ほとんどのユーザーは、簡単な方法を選び、メールをスパムに指定します。
• list-unsubscribeヘッダーを実装する – この機能がメールボックス・プロバイダでサポートされている場合、ユーザーは、信頼できるISPユーザー・インターフェイスを介して安全にリストから登録を解除できるため、メールをスパムに指定しません。これは、Gmailのフィードバック・ループに非常に近いものです。
• ダブル・オプトイン・プロセスを実装する – 現在のユーザーにメールを送信して、メッセージ受信の希望を確認することは、お客様のメッセージを受信者が引き続き重視しているかを確認するための優れた方法です。この方法を使うと、メッセージがスパムに指定されることなく、受信者を削除することができます。
• メールの頻度を確認する – 短期間に大量のメッセージを送信すると、受信者が不愉快になり、メッセージがスパムに指定される原因になります。メッセージの送信頻度が、お客様のコンテンツに想定される頻度と一致していることを確認してください。頻度を減らすと、スパム・クレームが減る可能性があります。
• エンゲージメントのない受信者を削除する – 受信者がメッセージを開いたり、リンクをクリックしたりしない場合は、メールにうんざりしている可能性があります。受信者とのエンゲージメントを構築するための最後の試みに失敗した場合は、受信者を削除する必要があります。この分野のリスト管理のベストプラクティスを理解するためのヒントを以下に示します。

メールが配信されませんでした。トラブルシューティングの方法を教えてください。

• 受信者が配信停止リストに載っているかどうかを確認します。
• 受信トレイへの到達率を増やすために、SPFが設定されていることを確認してください。
• アプリケーションのログをチェックして、問題（認証の失敗やメール・メッセージの形式の問題など）が発生していないことを確認します。
• エンベロープのFromと本文のFromに2つの異なるアドレスを指定する場合、両方とも承認済みの送信者である必要があります。そうしないと、メールが拒否されます。
• SMTP FROMがメール本文のFromと異なる場合、両方とも承認済みの送信者である必要があります。
• 問題が解決しない場合は、カスタマ・サポート・チケットを開きます

Oracle Email Deliveryは専用IPをサポートしているのでしょうか。

はい。Email Deliveryは専用IPをサポートしており、レピュテーションを制御できます。専用IPは、メール送信用に予約されているOracle Cloud IPアドレスです。デフォルトでは、お客様のアカウントは、メールの特性に応じて、階層化された共有送信プールに設定されます。大量に送信する場合は、専用IPをお勧めします。メール送信の頻度が少ない場合や散発的にしか送信しない場合、専用IPは、適切な送信レピュテーションの確保に効果がなく、メールの配信到達性に影響を与えるためお勧めしません。

それぞれのお客様のメールの特性（メールの量、バースト・レート、レピュテーションなど）によって、専用IP戦略が異なります。オラクルのチームは、このテーマに関するトレーニングを受けており、お客様の専用IPに関するニーズをサポートする準備ができています。この構成については、当社サポート窓口にお問い合わせください。

販売情報

Email Deliveryの提供するサービスについてご説明ください。

レピュテーション管理は、営業部門を通じたアドオン・サービスであり、Universal Cloudサブスクリプションの購入が必要です。

Email Deliveryにかかる料金を教えてください。

Email Deliveryでは、このサービスを介して送信されるメール1,000件ごとに.085ドルかかります。送信される電子メールは、暦月中のユニーク・アウトバウンド配信数として定義されます。アウトバウンド配信数は、ユニークメッセージ数と、メッセージごとのユニーク受信者数によって定義されます。