現在のプランを確認
Suite すべてのプラン
Support すべてのプラン

自分のメールアドレスを使ってサポートリクエストを受信したい場合、Zendeskのサポートアドレスとして自分のメールアドレスを追加していれば、カスタムメールドメインを設定して、Zendeskが自分のメールサーバーに代わってメールを送信できるかどうかを確認できます。

たとえば、help@acme.comでカスタマーからのメールを受信し、受信したすべてのメールをSupportに転送するように自動リダイレクトを設定している場合は、自分のメールアドレス(例:help@acme.com)から発信されているかのように、Zendeskから通知を送信することができます。こうすることで、プロセス全体を通してブランドを維持することができます。

この方法でメールドメインを設定する必要はありませんが、カスタムメールドメインを使用していて、外部のメールアドレスへの転送を設定している場合には、この方法をお勧めします。@gmail.comや@yahoo.comで終わるアドレスなど、カスタムではないドメインを使用している場合は、アカウントのDNS設定にアクセスできないため、この機能は使用できません。

メモ:​メール送信にZendesk Connector for Gmailを使用する場合は、SPFレコードを設定してZendeskが代理でメールを送信できるようにすることをお勧めします(「Gmail受信トレイでの自動チケット作成の有効化」を参照)。
この記事では、以下のトピックについて説明します。
  • この設定のメリット
  • ドメインのレコードの設定
  • ドメインの確認
  • SPFチェックについて

この設定のメリット

メモ:この設定を使用するには、メールアドレスを事前にZendeskでサポートアドレスとして追加しておく必要があります。

自社のメールサーバーに代わってZendeskにメールを送信させる設定は必須ですか?いいえ、 必須ではありません。 この設定を行う必要があるのは、エンドユーザー宛のメッセージにZendeskの社名を表示したくない場合だけです。

Zendeskが外部メールアドレスを使用してメールを送信する場合(サポートアドレスの転送設定を行った場合)、相手先で受信拒否されないように、メールの送信元はzendesk.comとみなされます。ただし、会社のメールドメインの代わりにZendeskがメールを送信できるように設定した場合、Zendeskはzendesk.comからメールを送信せずに会社のドメインから送信することで、ブランドの設定を完全に保持します。

この記事で説明されているタスクを実行しないと、エンドユーザーに次のような画面が表示されることがあります。 

次の警告は、外部サポートアドレスの横にあるエージェントインターフェイスにも表示されます。

ただし、この記事で説明したタスクを実行した場合には、「via」文と警告は表示されません。

ドメインのレコードの設定

メモ:ドメインのレコードを設定することは、めったに行なわない作業なので、混乱を招く恐れがあります。システム管理者がいる場合は、作業を進める前にシステム管理者にお問い合わせください。

SPFレコードを設定する方法は、ドメイン登録業者によって異なります。たとえば、GoDaddy、Namecheap、1&1、Network Solutions、Google Domainsなどの業者ごとに手順の指示は異なります。

Zendeskを参照するようにSPFレコードを作成または編集するには

  • ドメインのDNS設定を編集してTXTレコードを追加します。設定の手順は、ドメイン登録業者によって異なります。TXTレコードは、SPFレコードを検証する際に必要となります。

Zendeskでは、次のSPFレコードを使用することを推奨しています。

v=spf1 include:mail.zendesk.com -all
以下の点に注意してください。
  • include:mail.zendesk.comを使う場合、それが第1層のルックアップに含まれていなければならない
  • SPFマクロがサポートされている
  • redirect:構文がサポートされている
  • レコードフラット化サービスは動作するが、このやり方はinclude:、redirect:、マクロ構文よりも安定性が低い可能性がある
メモ:どのSPFメカニズムを選択するかはドメイン管理者次第ですが、メールスプーフィングに対して最大のセキュリティを提供するハードフェールSPFメカニズム(-all)を採用することをお勧めします。無効なSPFレコードは、確認に失敗する原因となります。Zendeskでは、DNSやセキュリティレコード、ポリシーの管理についてはサポートできないため、ドメインプロバイダーにサポートを依頼してください。

すでに別の目的でSPFレコードを設定してある場合は、そのSPFレコードにZendeskへの参照を追加します。​SPFの仕様では、ドメインにSPFレコードが1つだけ必要です。​複数のレコードがあると、問題が発生したり、メールアドレスが拒否されたりする可能性があります。

たとえば、v=spf1 include:_spf.google.com -allとv=spf1 include:mail.zendesk.com -allのような2つのレコードを別々に作成するのではなく、次のように1つに結合して作成します。

v=spf1 include:_spf.google.com include:mail.zendesk.com -all

これまでZendeskでは、SPFレコードに代わる記述としてinclude:smtp.zendesk.comやinclude:support.zendesk.comなどを提案してきました。どちらもSPFレコードとしては使われなくなりました。まだ機能するかもしれませんが、最良の選択肢ではありません。これらを使用している場合は、古くなったレコードをまだ設定していることを示す警告フラグが表示されます。

ヒント:カスタマーのメールクライアントによってメールがブロックされないようにするため、追加の更新として、Zendeskから発信するメールにデジタル署名することを検討してください。メールにデジタル署名することで、メールが実際に組織から送信されたものであり、組織を装った人物から送信されたものではないことの証明となります。詳細については、「DKIMまたはDMARCを使用したメールのデジタル署名」を参照してください。

旧バージョンのDNSエントリを削除する

以前は、Zendeskは以下の4つのcnameレコード(エイリアス)を追加することを推奨していました。現在は、これらの旧バージョンのDNSエントリを削除することを推奨しています。害はありませんが、機能しないレコードは削除するのがベストプラクティスです。
zendesk1.yourdomain.com >> mail1.zendesk.com
zendesk2.yourdomain.com >> mail2.zendesk.com
zendesk3.yourdomain.com >> mail3.zendesk.com
zendesk4.yourdomain.com >> mail4.zendesk.com
メモ:これらのcnameレコードは、DKIMレコードとは異なります。誤ってDKIMレコードを削除しないようにしてください。レコードが上記のレコードと一致する場合にのみ対処してください。

ドメインの確認

メモ:​このセクションで説明するタスクは現時点で必須ではありませんが、Zendesk Supportの改善計画の一環として将来的に必要になるため、今のうちに実行することをお勧めします。

Zendesk Supportがユーザーに代わってメールを送信するには、そのユーザーが、Supportで使用するドメインの所有者であることを確認する必要があります。この確認は、SupportがチェックするDNSサーバーにTXTレコード(ドメイン確認レコード)を追加することによって行います。ドメイン確認レコードは、Supportアカウントとドメインの組み合わせごとに一意です。

ドメイン確認レコードを追加しないと、SupportはZendeskから提供されたメールアドレスからメールを送信します。Zendeskのブランドをすべて隠して、カスタマーにホワイトラベル体験を提供したい場合は、このレコードを追加する必要があります。

ドメインが自分の所有下にあるかを確認するには

  1. SPFレコードの設定が完了していることを確認します。
  2. 管理センターで、サイドバーの「 チャネル」をクリックし、「Talkとメール」>「メール」を選択します。

    DNSレコードの確認チェックが表示されます。

  3. 「詳細を参照」をクリックすると、ドメイン確認の値が表示されます。

    ドメイン確認TXTレコードチェックの横に値が表示されます。この例では、値は「abcdef123456」です。

    メモ:サポートアドレスを管理する権限のあるエージェントは、必要に応じ、サポートアドレスAPIエンドポイントを使用して、サポートアドレスのドメイン確認コードを検索できます。この場合、「domain_verification_code」の値を探します。詳細については、サポートアドレスに関する開発者向けドキュメントを参照してください。
  4. ドメインのDNS設定を編集して次のTXTレコードを追加します。
    タイプ 名前 値 TTL
    TXT zendeskverification <Support内に表示される固有値> 3600またはデフォルトを使用
    メモ:ドメインは自動的にzendeskverificationに追加されます。ドメインを複数のZendeskアカウントで使用する場合は、アカウントごとにTXTレコードを追加する必要があります。
  5. TXTレコードを追加したら、「DNSレコードを確認」ボタンをクリックして、レコードが有効になったことを確認します。ドメイン確認レコードは現在使用されておらず、送受信の動作には影響しません。

    レコードが有効であれば、赤いエラーメッセージは消えます。DNSレコードを正しく設定できない場合は、「エラーが表示される理由:DNSレコードが正しく設定されていないのでしょうか?」を参照してください。

ドメインが確認されたら、ドメイン確認レコードをそのままの状態にします。

Supportサブドメインまたはホストマッピングを後で変更する場合は、ドメイン確認レコードを更新する必要はありません。

SPFチェックについて

Sender Policy Framework(SPF)はドメインレベルのメール認証プロトコルです。これを使用して、自社のドメインから発信したものとしてメールを送信できるIPアドレスを宣言します。

それには、DNS(Domain Name System)TXTレコードを追加します。DNSは、だれでもアクセスできるインターネット用のレコードです。このレコードにより、Zendeskがあなたのドメインで送信者として許可されていることを公に宣言することができます。

メールクライアントがメッセージを受け取ると、送信元のドメインでSPFチェックを行い、メールがメールの送信元から送られてきたメールであることを検証します。この検証チェックに通らなかった場合、またはZendeskが許可された送信者であることを示すDNSレコードが存在しない場合、レシーバーによっては、そのメールをスパムやフィッシングの試みとして判断し、信頼できないものとしてフラグを立てたり、受信者であるエンドユーザーに表示しない場合もあります。

この状況を回避するには、外部ドメインの使用が許可されない場合にZendeskドメインを使ってメールを送信する方法と、SPFレコードでZendeskに権限が付与されている場合のみ外部ドメインを使用する方法があります。通常はこれでZendeskアカウントからカスタマーへ送られたメールが、誤ってスパムとして判定されるのを防ぐことができます。それでも、このスパムの誤判定が起きる場合は、「メールがカスタマーのスパムフォルダに振り分けられないようにする方法」を参照してください。

この問題が気になる場合は、www.openspf.orgでSPFレコードに関する詳細情報を参照してください。SPFレコードを確認できない場合は、「なぜ自分のSPFレコードが認証されないのでしょうか?」を参照してください。

Powered by Zendesk