このガイドをお読みいただくと、お使いのメールシステムがZendeskとシームレスに統合できるように最適化されていることを確認できます。この記事で説明されているベストプラクティスに従うことで、メールサーバーの信頼レベルを高め、Zendeskと連携する際の問題発生のリスクを最小限に抑えることができます。
この記事では、以下の設定の推奨事項とベストプラクティスについて説明します。
- 推奨事項1：SMTPサーバーからZendeskにメールを送信するためのPTRレコードを設定する
- 推奨事項2：HELOとEHLOメッセージのホスト名を設定する
- 推奨事項3：SPFレコード
- 推奨事項4：DMARCおよびDKIM
- ベストプラクティス：スクリプトおよびWebフォームを使用したメール送信のベストプラクティス
- 信頼できるメールを送信するためのベストプラクティス
推奨事項1：SMTPサーバーからZendeskにメールを送信するためのPTRレコードを設定する
サポートへのメール送信に使用するすべてのIPアドレスにポインタ（PTR）レコードがあることを確認してください。PTRレコードにより、所定のIPアドレスがドメインオーナーに接続されているという信頼性が強化されます。たとえば、domain.comの人物がSupportにメールを送信した場合、IPアドレス1.2.3.4はmail.domain.comに解決されます。
理想的には、PTRレコードは、サポートにメールを送信するのと同じドメインに属している必要があります。IPアドレスが家庭用ISPのものであることを示すIPアドレス数字やキーワードを含めることはできません。
domain.comの正しいレコードの例：
host 1.2.3.4Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com
見つからないレコードの例：
host 1.2.3.4Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)
メールの送信に使用しないレコードの例：
host 1.2.3.4Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com
推奨事項2：HELOとEHLOメッセージのホスト名を設定する
HELO名は、SMTPサーバー間でメッセージを表示するために使用されます。RFC 5321 (zen2.3.5)に従って解決可能なHELOレコードは、メール送信者のドメインに属し、MXレコードと一致している必要があります。Supportでは、Supportにメールを送信するSMTPサーバーに解決可能なHELOホスト名が必要です。
domain.comの正しいレコードの例：
HELO mail.domain.com
信頼性が低いと見なされるHELOメッセージの例：
HELO mail.otherdomain.comHELO localhostHELO 1.2.3.4HELO invalid.tld-
HELO not.existing.domain.com
詳細については、Wikipediaの次の記事を参照してください：SMTPサーバーのリターンコードのリスト
推奨事項3：SPFレコード
サポートにメールを送信するドメインには、ドメインに代わってメールを送信するためのIPアドレスを許可する有効なSPFレコードが必要です。
以下の状況に応じた正しいSPFレコードの例を以下に2つ示します。
domain.comSMTP servers with address 1.2.3.4MX record mail.domain.com pointing on 1.2.3.4.
どちらの例でも、1.2.3.4がdomain.comの代わりにメールを送信することができます。
domain.com. 3600 IN TXT "v=spf1 mx:domain.com ~all”domain.com. 3600 IN TXT "v=spf1 ip4:1.2.3.4 ~all”
推奨事項4：DMARCおよびDKIM
なりすましメールやスパムの受信数を減らすには、SPF、DKIM、およびDMARCアライメントによる送信者認証を有効にして、受信メールにセキュリティ層をさらに追加します。詳細については、次の記事を参照してください：認証受信メール（SPF、DKIM、DMARC）
ベストプラクティス：スクリプトおよびWebフォームを使用したメール送信のベストプラクティス
Webフォームまたは自動スクリプトを使用してSupportにメールを送信する方法は推奨されず、現在サポートされていません。これらのタイプのメールを送信したい場合は、以下のルールに従う必要があります。
- 送信するWebフォームはすべて、認証を必要とするかCAPTCHAを使用するか、あるいはその両方を使用する必要があります。Zendeskでは、ユーザーが許可し、または誘導するスパム攻撃を阻止することはできません。
- Webフォーム、Webアプリケーション、または自動化スクリプトを使用してメールをSupportに送信する場合、メールは RFC 5322に従って正しい形式で作成する必要があります。
- メッセージには、適切な書式で「Subject：」、「From：」、「To：」、および 「Reply-To：」 ヘッダーが含まれている必要があります。
- 送信元IPアドレスにはPTRレコード（逆DNS解決）が必要です。
- サポートでは、有効なSPFレコードを追加し、送信ドメインのDNSゾーンで公開されたDKIMキーでこれらのメールに署名し、メールの扱い方を指定するDMARCポリシーを公開することをお勧めします。
- HELOメッセージには有効な解決可能なDNS名が必要です。
- データの冗長性を目的として、一時停止の可能性を減らすために、Webフォームで作成されたメールを外部のサポートアドレスに転送します。
- Zendeskのネイティブサポートアドレス（support@サブドメイン.zendesk.com）に送信する場合、フォームは一時的なネットワークエラーを処理できるか、
4xx回復力を強化するのに役立ちます。 - MXリレーを当社のMXレコードのいずれかにハードコードしないでください。各リレーはMXルックアップを実行する必要があります。
- Webフォームからの送信に「 スパム として登録」機能を使用しないでください。これはフォームの送信レピュテーションに悪影響を及ぼします。
- ZendeskカスタマーサポートはWebフォームの機能に関するサポートは行っておりません。
信頼できるメールを送信するためのベストプラクティス
Zendeskが信頼できない：
- ドメイン所有者のDNSゾーンに公開された認証用のSPFレコードを持たないメール送信者を、なりすまして送信するメール
- なりすまし送信者アドレス、無効なDKIM署名、またはSPFチェックに失敗したメール
メモ：自社のドメインからZendesk Supportのサブドメイン（例：support@yourdomain.com > support@subdomain.zendesk.com）にメールを転送している場合、Zendeskは転送メールの検出を試みます。メールの転送がZendeskに検出された場合、Zendeskは送信SMTPサーバーを認証するための代替アプローチを実行します。ただし、DKIM署名を保持し、元のメール本文と機密性の高いヘッダーが変更されないように、転送SMTPサーバーを設定してください。
- メールの送信者または受信者のヘッダーに、無効な、存在しない、または解決できないドメイン名が使用されているメール
PTRレコードが見つからない、または無効なHELOメッセージが含まれているSMTPサーバー経由で送信されたメールに対して、サポートが低い信頼性を提示している場合。
翻訳に関する免責事項：この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。
翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。