自社のメールドメインの代わりにZendeskからメールを送信する方法

Suite、すべてのバージョン

Team、Growth、Professional、EnterpriseまたはEnterprise Plus

Support

Team、ProfessionalまたはEnterprise

検証済みのAI要約◀▼

自社ドメインを差出人としてメールを送信できるようにすることで、顧客とのやりとりでブランドのアイデンティティを維持できます。DNS設定でSPFレコードを設定し、ドメインからのメール送信を許可してください。これにより、メールがスパムとしてマークされるのを防ぎ、メッセージ内に表示される “via” 表記も削除されます。

自分のメールアドレスを使ってサポートリクエストを受信したい場合、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はこのレコードの確認を試みます。

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を使用したメールのデジタル署名」を参照してください。

ドメインの確認

サポートアドレスを追加すると、Zendeskはこのレコードを自動で確認します。現在のところ、DNSレコードに対する確認機能はありませんが、将来的にはこの値をドメインのDNSレコードに追加する必要が生じる可能性があります。

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レコードが認証されないのでしょうか？」を参照してください。