ベスト・プラクティス

これらの電子メール配信到達性のベスト・プラクティスは、送信の評判に影響を与える習慣を学習および管理する際に役立ち、さらに多くの電子メールを配信するのに役立ちます。

これらの推奨事項に従うことで、送信者はバウンス・レートと苦情レートの両方を下げ、ブロックリストを抑え、会社の送信評価を向上させることができます。

オプトイン・プロセスの実装

オプトイン・プロセスでは、受信者が一括/マーケティング・リストに登録する方法で、電子メールを送信する権限が付与されます。メーリング・リストにオプトインしたサブスクライバにのみメッセージを送信し、すべてのコストでリストの購入やレンタルを回避します。

オプトインには2つのタイプがあります。トランザクションEメールは、証明が必要な処理に基づいて送信されるため、これらの方法は一括/マーケティングEメールに適用されます。

  • シングル・オプトイン(未確認):ユーザーは電子メール・アドレスを指定し、送信者に関連するメッセージを受信する権限を付与します。アドレスを指定したら、指定したユーザーに電子メール・アドレスが属していることを確認せずにメッセージを送信できます。シングル・オプトインの使用におけるリスクは、サインアップ・フォームへのターゲット攻撃によるリスト爆破、およびそれらに属していない電子メール・アドレスにサインアップするリスクにさらされています。

  • ダブル・オプトイン(確認済): ユーザーは電子メール・アドレスを指定しますが、最初のキャンペーンが送信される前に、サインアップしたアドレスへの確認の電子メールを受信します。その電子メールには、今後のメッセージが必要であることを確認するためのアカウント所有者からのアクションが必要です。これは、検証クリックで頻繁に実行されます。ダブル・オプトイン方式により、住所が同意なしに追加されなかったことが保証され、将来のデータ・プライバシに関する問合せまたは監査が発生した場合に電子的な証拠が保持されます。
エンゲージしていないユーザーのパージ

マーケティング・リストをクリーンに保つための最も簡単で最良の方法の1つは、関係のないユーザー(一定の時間内にEメール内で開封またはクリックされていないアドレス)を削除することです。エンゲージメント解除は、受信者がコンテンツに関心がなくなったこと、またはアカウントが破棄されたことを示す強力な指標です。

ビジネス・モデルで定義された時間枠に、電子メールに2年も経たない受信者を削除します。これにより、主要な受信ボックス・プロバイダに、送信評価を向上させるのに役立つ更新済データベースを保持していることが示されます。また、一部のメールボックス・プロバイダが非アクティブな受信ボックスを変換して電子メール・アドレスのスクレイピングを防止するため、スパム・トラップが発生する可能性も回避できます。

データベースのクリーン度

全体的なクリーンで最新のデータベースを維持することは、関係のないユーザーを削除することに加えて重要です。クリーンなデータベースを維持する最善の方法は、APIコールを使用してEmail Deliveryと同期することで、ハード・バウンス、登録解除および抑制がそのようにマークされるようにすることです。

この一定の同期により、電子メール送信時の処理時間が短縮され、データベースが常に更新されるようになり、送信する必要がなくなったアドレスに送信される可能性が最小限に抑えられます。

送信頻度の評価

短期間に送信するEメールの数が多すぎると、受信者の怒りが高まり、キャンペーンを登録解除するか、スパムとしてマークする場合があります。戦略、開封率、その他の主要な指標を定期的に見直すことで、リストの疲労を軽減し、彼らがあなたと関わりたい方法をよりよく学ぶことができます。

受信する電子メールの量(年次、四半期ごと、月次など)を削減する機能を提供し、登録を完全に解除するのではなく、保持の機会を改善します。受信者は、時間の経過に伴う電子メールの変更を好み、希望しています。変更していることを確認します。

簡単にアクセスできるサブスクライブ解除URLの指定

登録解除リンクを非表示にしないでください。非表示にすると、受信者に迷惑メール・ボタンをクリックするだけで評判が悪くなります。一部のプロバイダは、購読解除リンクおよび言語に明るい色を使用する場合、アルゴリズムでそれを保持します。

リストから削除する場合は、リンクを見つけやすくし、ヘッダーとフッターの両方に含めます。電子メールの頻度を減らしたり、別のリストにオプトインしたりできるプリファレンス・センターに加えて、シングルクリックのサブスクライブ解除オプションを提供します。

CAN-SPAM、GDPR、CASL、およびプライバシーに関する法律

法的に認められる方法で消費者データを処理、処理、市場投入する方法を知ることは必須です。

世界中の消費者を保護するための規制や法律がいくつかあります。最も古い法律の1つは、CAN-SPAM法です。CAN-SPAM法は、商用Eメールの要件を確立した米国の法律です。

詐欺的な件名を使用せず、登録解除を迅速に遵守し、電子メールのフッターに物理的なアドレスを持つことは、罰金を科す違反について概説された要件の一部にすぎません。

同様に、カナダに拠点を置くスパム対策法であるCASLもあり、CAN-SPAMをベースにしています。カナダに本拠を置く法律は、カナダの住民に電子メールを送る人に適用されます。

データ・プライバシは、ここ数年で重要なトピックとなっており、一般データ・プライバシ規制(GDPR)について理解することが重要です。2018年に制定された法律は、EUにおけるデータのプライバシーと保護を規制し、他国のプライバシーに関する法律のモデルとなっています。

Oracle Cloud Hosting and Delivery Policy

多くの場合、Oracle Cloud Hosting and Delivery Policyは、これらの業界要件のいくつかよりも厳格です。サービスを使用する前にOracleポリシーを確認することが重要です。

社内の適切な担当者とデータ・プライバシおよび規制へのアプローチについて議論することを強くお薦めします。

配信されていない電子メールのトラブルシューティング

次の問題があると、電子メールが配信されなくなる場合があります:

  • 受信者が抑制リストに記載されています。
  • 認証失敗または電子メール・メッセージの書式の問題が発生しました。たとえば、SMTPの「送信元」アドレスが電子メール本文の「送信元」アドレスと同じでない場合、電子メールは拒否されます。アドレスが一致し、承認済送信者である必要があります。送信アプリケーションのログを参照して、問題を確認してください。
  • 電子メールのFromヘッダーで複数のアドレスを使用することはお薦めしません。複数のアドレスを使用すると、メールがスパム・フォルダに配置されたり、破棄されたりする可能性が高くなります(DMARCのFrom整合ルールのため)。すべてのアドレスを承認済送信者として認可する必要があるため、電子メールのパフォーマンスが低下します。SMTPエンベロープのFromアドレスのベスト・プラクティスは、電子メール配信にメールを送信するときにヘッダーのFromアドレスを照合することです。一致しないアドレスを使用すると、両方のアドレスを承認済送信者として認可する必要があるため、電子メールのパフォーマンスが低下します。一致しないアドレスを使用すると、一定の将来のプラットフォーム機能が使用できなくなります。
  • SPFまたはDomainKeys Identified Mail (DKIM)がありません。

問題を解決できない場合は、My Oracle Supportに移動してサービス・リクエストを作成します。詳細は、サポート・サービス・リクエストのオープンを参照してください。

デリバラビリティを向上させるその他のオプション

DomainKeys Identified Mail (DKIM)

DKIMは、良好な電子メール配信の評判を保証するために設定できる認証フレームワークです。DKIMの設定手順は、DKIMの管理を参照してください。

SPF

Sender Policy Framework (SPF)を使用すると、ドメイン所有者は、ドメインにかわって電子メールを送信することを承認したサーバーを識別できます。Oracle統合の場合、ドメイン所有者は承認送信者としてOCIを承認し、ドメインにそのレコードを追加する必要があります。詳細は、SPFの構成に関する項を参照してください。

ドメイン・ベース・メッセージ認証、レポートおよび準拠(DMARC)

DMARCは、組織のグループによって作成される技術仕様で、電子メール認証プロトコルに関連する長期的な操作、デプロイメントおよびレポートの問題を解決することで、電子メール・ベースの不正使用の可能性を低減するのに役立ちます。DMARCは、電子メール受信者がSPFおよびDKIMを使用して電子メール認証を実行する方法を標準化します。これにより、送信者は認証に合格しないメールを制御し、認証されていないメールの処理方法を電子メール受信者に指示できます。

DMARCはSPFとDKIMの両方をチェックしますが、電子メールを送信および配信するには渡す必要があります。DMARCの使用を開始する場合、ベスト・プラクティスとして、より積極的なポリシーを検討する前に、p=noneポリシーを設定し、すべての正当な送信アプリケーションが正しく調整および認証されていることを確認してください。送信ドメインの新しい電子メール関連のサービスが評価される移行期間中に、DMARC p=noneポリシーを使用して、このアドバイスに従うことをお薦めします。

DMARCレコードは、ドメイン_dmarc.<sending-domain>のDNS TXTレコードで、次のような内容が含まれます:
"v=DMARC1\;p=none\;rua=mailto:dmarc_rua@example.com\;ruf=mailto:dmarc_ruf@example.com\;fo=1"

DMARCレポートを受信するには、管理INBOXサービスが必要です(前述の例では、example.comがINBOXプロバイダです)。現在、Email DeliveryではINBOXサービスまたは自動DMARCレポート処理が提供されていません。DMARCレポートを管理および処理しない場合は、DMARCレコードを作成しないでください。

カスタム戻りパスの作成

ノート

DKIMを設定すると、カスタム戻りパスよりも配信到達性が向上する可能性が高くなります。そのため、カスタム戻りパスを設定する前またはそれと同時にDKIMを設定することをお薦めします。

電子メール配信は、バウンスを処理してIPアドレスとドメインの評判を保護する必要があります。そのため、デフォルトでは、戻りパスはバウンス・サーバーのパスに設定されます。電子メール配信には、受信ボックスの配置を改善するためのカスタム戻りパス機能が用意されています。この機能を使用するには、カスタム戻りパス・ドメインのDNSレコードを設定する必要があります。カスタム戻りパス・ドメインは、承認済送信者のドメインと一致するか、そのドメインのサブドメインである必要があります。

詳細は、カスタム戻りパスの管理を参照してください。

カスタム戻りパス・サブドメインに推奨される命名規則は、<REGIONKEY>.rp.<sending-domain>です。この機能の使用を準備するには、次のようにSPFおよびMXレコードの両方またはCNAMEレコードをカスタム・ドメインにプロビジョニングします:

カスタム戻りパス・ドメインのCNAME

キーをリターン・パス・ドメインとし、値をリージョナル・バウンス・ドメインとするCNAMEを作成します。CNAMEキー値ペアは、カスタム戻りパスの作成リクエストに応答して存在します。

カスタム・ドメインのMXレコード

次のレコード構文は商用リージョンにのみ適用されます:

10 bmta.email.<REGION IDENTIFIER>.oci.oraclecloud.com

カスタム戻りパスはリージョナルです。混同を避けるために、REGION IDENTIFIERをエントリに追加する必要があります。リージョンの詳細は、リージョンおよび可用性ドメインを参照してください。

カスタム戻りパス・ドメインのSPFレコード

送信リージョン 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
政府リージョン
  • FedRAMP認可のUS Government Cloudについては、SPFレコード構文を参照してください。
  • DISA Impact Level 5のUS Federal Cloudについては、SPFレコード構文を参照してください。
  • United Kingdom Government Cloudについては、SPFレコード構文を参照してください。
ノート

Oracle Cloud Infrastructureで設定を完了する前に、ドメインでDNSの更新を完了する必要があります。

DNSの変更が完了したら、カスタム・リターン・パスを作成します。