Zendeskでメールバウンスを処理する方法：完全ガイド

メールのバウンスは、顧客体験を静かに損なう可能性のあるサポート問題の1つです。チケットに返信したと思っても、メッセージが顧客に届かないことがあります。顧客は待ち、不満を感じ、無視されていると考えます。

Zendeskでは、メールバウンスの処理は必ずしも簡単ではありません。このプラットフォームには、堅牢な配信ツールがありますが、1つの重要な機能が欠けています。それは、自動バウンス通知です。このガイドでは、Zendeskでのバウンスの理解、配信問題のトラブルシューティング、およびプロアクティブな監視のための回避策の設定について説明します。

Zendeskでのメールバウンスの理解

メールバウンスは、メッセージが宛先に届かない場合に発生します。カスタマーサポートでは、これは、丁寧に作成した返信が顧客に届かず、顧客が状況を把握できないことを意味します。

知っておく必要のあるバウンスには、次の2種類があります。

ハードバウンス（Hādo baunsu）

ハードバウンスは、永続的な配信エラーです。ハードバウンスが発生した場合、そのメールアドレスは何度再試行しても機能しません。

一般的な原因は次のとおりです。

• 無効なメールアドレス アドレスが存在しないか、タイプミスがある
• 存在しないドメイン ドメイン部分（@の後）が登録されていない
• 受信サーバーのブロック 受信サーバーがドメインからのメールを永続的にブロックしている

ハードバウンスは、送信者の評価を損ないます。メールサービスプロバイダーはこれらを追跡し、多すぎるとドメインがブロックリストに登録される可能性があります。

ソフトバウンス（Sofuto baunsu）

ソフトバウンスは、一時的な問題です。メールアドレスは有効ですが、何らかの理由でその時点で配信が妨げられました。

一般的な原因は次のとおりです。

• メールボックスがいっぱい 受信者の受信トレイがストレージ制限に達した
• 一時的なサーバーの問題 受信サーバーがダウンしているか、過負荷になっている
• メールサイズの制限 メッセージ（添付ファイルを含む）が受信者のサイズ制限を超えている

ほとんどのメールプロバイダーは、ソフトバウンスを自動的に再試行します。複数の試行後も問題が解決しない場合は、ハードバウンスとして扱われる場合があります。

Zendeskでのメール配信ステータスの確認

バウンスの問題を修正する前に、それらが存在することを知っておく必要があります。 Zendesk Supportで配信ステータスを確認する方法を次に示します。

エージェントワークスペース（Ējento wākusupēsu）での配信ステータスの表示

Zendeskからメールを送信するときは、チケットの受信者セクションを確認してください。配信が失敗した場合、受信者の名前の横に警告アイコンが表示されます。

警告アイコンをクリックして、特定のエラーを表示します。Zendeskは、ハードバウンス、ソフトバウンス、またはその他の問題であるかどうかを通知するバウンス理由コードを提供します。

チケットイベント（Chiketto ibento）の確認

詳細については、任意のチケットURLの末尾に/eventsを追加します。これにより、すべてのメール配信試行を含む、チケットに対して実行されたアクションの完全な履歴が表示されます。

「メール通知」または「トリガー」に関連するエントリを探して、メールが実際に送信されたかどうかを確認します。トリガーが起動に失敗した場合、またはメールがバウンスした場合は、ここに表示されます。

制限事項は？手動で確認する必要があります。Zendeskは、メールがバウンスしたときにプロアクティブに警告しません。つまり、顧客が苦情を言うまで問題に気付かない可能性があります。

送信メールのバウンスの修正

顧客がメールを受信していない場合は、次の手順を順番に実行してください。

ステップ1：SPFレコード（SPF rekōdo）の確認

Zendeskでカスタムメールアドレスを使用している場合は、Zendeskがユーザーに代わってメールを送信することを承認するSPFレコードが必要です。それがないと、受信サーバーがメッセージを拒否する可能性があります。

SPFレコードには、include:mail.zendesk.comを含める必要があります。

現在のSPFレコードを確認するには：

1. MxToolboxなどのツールを使用して、ドメインを検索します。
2. include:mail.zendesk.comがレコードに表示されることを確認します。
3. 見つからない場合は、ドメイン管理者に連絡して追加してもらいます。

ドメインごとにSPFレコードは1つしか存在できません。すでに存在する場合は、管理者は新しいTXTレコードを作成するのではなく、既存のTXTレコードを編集する必要があります。

ステップ2：通知トリガー（Tsūchi torigā）の確認

Zendeskは、トリガーを使用してメール通知を送信します。デフォルトのトリガーが無効になっている場合、他のすべてが正しく構成されていても、メールは送信されません。

タイトルに「リクエスタに通知」が含まれるトリガーがアクティブであることを確認します。これらは、顧客に応答を送信する標準トリガーです。無効になっている場合は、再度アクティブにするか、標準条件に一致する新しいトリガーを作成します。

チケットイベントを確認することで、トリガーのアクティビティを確認できます。エージェントがコメントした後、イベントリストにトリガーが表示されない場合は、それが問題です。

ステップ3：メール転送（Mēru ten'sō）の確認

Zendeskに転送されるカスタムサポートメールアドレス（support@yourcompany.comなど）を使用している場合、転送の問題により配信の問題が発生する可能性があります。

Zendesk管理センターで、転送エラーがないかメールチャネル設定を確認します。一般的な問題は次のとおりです。

• 転送アドレスでのSPF検証の失敗
• DNSレコードの構成ミス
• 期限切れの転送設定

Zendeskは、転送の問題に関する特定のエラーメッセージを提供します。ドキュメントに従って、各タイプのエラーを解決してください。

ステップ4：受信者への連絡

SPFレコードが正しく、トリガーがアクティブで、転送が機能している場合、問題は受信者側にある可能性があります。受信者のサーバーがドメインからのメールをブロックしている可能性があります。

別のチャネル（電話、チャット、または別のメールアドレス）を介して顧客に連絡し、次のことを依頼します。

• スパムまたは迷惑メールフォルダを確認する
• サポートメールを連絡先または安全な送信者リストに追加する
• ITチームに連絡して、ドメインをホワイトリストに登録してもらう

メール配信は最終的に受信者のサーバー構成に依存し、これはZendeskの制御外です。

受信メールの問題の処理

問題が送信配信ではなく受信である場合があります。顧客のメールがZendeskでチケットを作成していません。

保留中のチケット（Horyū-chū no chiketto）の確認

Zendeskのスパムフィルターは、攻撃的になる可能性があります。正当なメールがキャッチされ、保留中のチケットビューに配置されることがあります。

このビューを定期的に確認してください。正当なメールが見つかった場合は、フィルターをトレーニングするために復元します。保留の一般的な理由は次のとおりです。

• 送信者のドメインからのSPF、DKIM、またはDMARCの失敗
• 疑わしい書式設定またはコンテンツパターン
• 認証されていないソースからのメール

サポートメールアドレス（Sapōto mēru adoresu）の確認

当然のことですが、顧客が正しいアドレスにメールを送信していることを確認してください。Zendeskで構成されていないエイリアスまたは古いサポートアドレスに送信すると、メールはどこにも行きません。

顧客が使用したメールアドレスが、Zendeskメールチャネル設定に表示されていることを再確認してください。

送信者の認証（Sōshin-sha no ninshō）の確認

送信者の認証に失敗した場合、厳格なSPF、DKIM、またはDMARCポリシーを持つドメインからのメールは拒否される可能性があります。これは、企業のメールシステムで特に一般的です。

特定のドメインからのメールが保留になっているパターンに気付いた場合は、メールチャネル設定を調整するか、それらの送信者に認証設定を確認するように依頼する必要がある場合があります。

バウンス通知の自動化

ここで不満な点は、Zendeskはメールがバウンスしたときにエージェントにネイティブに通知しないことです。この機能リクエストは2014年からアクティブですが、解決されていません。

ただし、回避策があります。

Zapier（Zapier）とMailerSend（MailerSend）の使用

1つのアプローチは、MailerSendなどのサービスを介してトランザクションメールをルーティングし、Zapierを介してZendeskに接続することです。

MailerSendがハードバウンスを検出すると、ZapierはZendeskでチケットを自動的に作成するか、既存のチケットにコメントを追加できます。これにより、手動で確認しなくても、バウンスの問題を把握できます。

欠点は？スタックに別のサービスとコストを追加することです。

ZeroBounce（ZeroBounce）によるメール検証

予防は治療に勝ります。ZeroBounceは、Zendesk Sellと統合されたメール検証を提供します。メールアドレスがシステムに入力される前に、配信可能性が検証されます。

これにより、入力時にタイプミスや無効なアドレスがキャッチされ、送信する前にバウンス率が低下します。

メール追跡アプリ（Mēru tsuiseki apuri）

GrowthDotのEmail Tracking for Zendeskのようなアプリは、メールに開封追跡を追加します。バウンス通知と同じではありませんが、メールが開かれていないことがわかると、配信の問題の可能性を警告できます。

これらのアプリは、顧客がメールを開いたときに内部メモを作成し、エンゲージメントパターンを把握できるようにします。

バウンスを防ぐためのベストプラクティス

プロアクティブな管理により、バウンス率を低く抑え、送信者の評価を健全に保ちます。

• バウンス率を2％未満に保つ 許容可能なバウンス率の業界標準。レートが高いほど、スパムフィルターがトリガーされる
• メールリストを定期的にクリーンアップする 一貫してバウンスするアドレスを削除する
• 入力時にメールを検証する 新しい連絡先には、ダブルオプトインまたは検証サービスを使用する
• 配信メトリックを監視する バウンス率、開封率、応答時間を追跡する
• 適切な認証を設定する SPF、DKIM、およびDMARCレコードが正しく構成されていることを確認する

eesel AI（eesel AI）でメールの問題をよりスマートに処理する方法

メールのバウンスについて言えば、通常、より大きな問題の兆候です。無効なメールアドレス、スパムフィルターのトリガー、認証の失敗 これらの問題は単独で存在するわけではありません。これらは、顧客とのコミュニケーションの管理方法のギャップを示しています。

そこで私たちの出番です。eesel AIは、サポートパターンから学習するAIチームメイトとしてZendeskと連携します。

手動でバウンスを確認したり、複雑な自動化を設定したりする代わりに、eesel AIは過去のチケットから学習します。以前にバウンスしたメールアドレス、スパムフィルターをトリガーする応答テンプレート、バウンス率が高いタイミングなど、配信の問題につながるパターンを特定します。

当社のAIエージェントは、一般的なスパムトリガーを回避する応答を作成します。AIトリアージは、配信されない応答の作成に時間を無駄にする前に、問題のあるメールアドレスを含むチケットにフラグを立てます。

違いは？従来のツールのようにeesel AIを構成しません。チームメイトのように採用します。既存のチケット、ヘルプセンター、およびマクロからビジネスを学習します。複雑なセットアップも、エンジニアリングリソースも必要ありません。

顧客がすでに解約した後でバウンスの問題を発見することにうんざりしている場合は、eesel AIが別のアプローチを提供します。それは、顧客に影響を与える前に問題をキャッチする、プロアクティブでインテリジェントなサポートです。