このガイドを使用して、Zendeskとのシームレスなインテグレーションのためにメールシステムを最適化してください。この記事で説明するベストプラクティスに従うことで、メールサーバーの信頼性を高め、Zendeskを使用する際に発生する問題のリスクを最小限に抑えることができます。
この記事では、次の設定に関する推奨事項とベストプラクティスについて説明します。
- 推奨事項1：Zendeskにメールを送信するSMTPサーバーのPTRレコードを設定する
- 推奨事項2：HELOおよびEHLOメッセージのホスト名を設定
- 推奨事項3：SPFレコード
- 推奨事項4：DMARCおよびDKIM
- スクリプトとWebフォームを使用したメール送信のベストプラクティス
- 信頼できるメールを送信するためのベストプラクティス
推奨事項1：Zendeskにメールを送信するSMTPサーバーのPTRレコードを設定する
サポートへのメール送信に使用するすべてのIPアドレスに、ポインタ（PTR）レコードがあることを確認します。PTRレコードは、所定のIPアドレスがドメインオーナーと関係があるという確信をさらに高めます。たとえば、domain.comの誰かがサポートにメールを送信した場合、IPアドレス1.2.3.4はmail.domain.comに解決されます。
PTRレコードは、サポートにメールを送信するドメインと同じであることが望ましいです。IP アドレス番号や、IP アドレスが居住する ISP のものであることを示すキーワードを含めることはできません。
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（§2.3.5）に従って解決可能なHELOレコードは、メールの送信者のドメインに属し、MXレコードと一致する必要があります。サポートは、サポートにメールを送信する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：SPF、DKIM、DMARC、ARC
なりすましメールやスパムの受信数を減らすために、SPF、DKIM、DMARC、およびARCによる送信者認証を有効にすることで、受信メールにセキュリティ層をさらに追加できます。詳細については、次の記事を参照してください：受信メールを認証しています。
推奨事項5：ARCヘッダーを追加する
Zendeskにトラフィックを転送するアカウントでは、転送サーバーに到着したときのトラフィックの認証評価を組み込むために、ARCヘッダーを追加することをお勧めします。
スクリプトとWebフォームを使用したメール送信のベストプラクティス
Webフォームまたは自動スクリプトを使用してサポートにメールを送信することは推奨されておらず、現在サポートされていません。これらのタイプのメールを送信したいお客様は、以下のルールに従う必要があります。
- すべての送信Webフォームは、認証を要求するか、CAPTCHAを使用するか、またはその両方を使用する必要があります。Zendeskは、スパム攻撃を許可し、奨励しているだけでは防ぐことはできません。
- Webフォーム、Webアプリケーション、または自動化スクリプトを使用してサポートにメールを送信する場合は、RFC 5322に従ってメールが正しくフォーマットされている必要があります。
- メッセージには、Subject:、From:、To:、および Reply-To: の各ヘッダーが正しくフォーマットされている必要があります。
- 送信IPアドレスにはPTRレコード（DNSの逆解決）が必要です。
- サポートでは、有効なSPFレコードを追加し、送信ドメインのDNSゾーンで発行されたDKIMキーでこれらのメールに署名し、メールの処理方法を指定するDMARCポリシーを公開することを推奨しています。
- HELOメッセージには、解決可能な有効なDNS名が必要です。
- Webフォームからのメールを外部サポートアドレス経由で転送します。これは、データの冗長性を確保し、トラフィックの一時停止やドロップの可能性を軽減するためです。
- ネイティブのZendesk Supportアドレス（support@subdomain.zendesk.com）に送信する場合は、一時的なネットワークエラーや、耐障害性のための
4xx応答をフォームで処理できる必要があります。 - MXリレーを当社のMXレコードにハードコードしないでください。各リレーはMXルックアップを実行する必要があります。
- Webフォームからの送信に「スパムとして登録」機能を使用しないでください。これは、フォームの送信レピュテーションに悪影響を及ぼします。
- ZendeskカスタマーSupportでは、Webフォームの機能をSupportしていません。
信頼できるメールを送信するためのベストプラクティス
Zendeskは、次のものを信頼していません。
- ドメインオーナーのDNSゾーンに公開済みの承認SPFレコードを持たない、メールの送信者を偽装したメール。
- 送信者アドレスが偽装されている、DKIM署名が無効または一致しない、SPFチェックに失敗したメール
メモ：自分のドメインからZendesk Supportのサブドメイン（support@yourdomain.com >> support@subdomain.zendesk.comなど）にメールを転送すると、Zendeskは転送メールの検出を試みます。メール転送が検出された場合、Zendeskは送信SMTPサーバを認証するための代替手段を実行します。ただし、DKIM署名を保持し、元のメール本文や機密ヘッダーが改ざんされないように転送サーバーを設定するようにしてください。改ざんされると、エラーが発生する可能性があります。また、可能な限りARCヘッダーを利用するようにしてください。
- メールの送信元と受信者のヘッダーに無効なドメイン名、存在しないドメイン名、または解決できないドメイン名が使用されているメールは、一時停止または拒否される可能性があります。
サポートは、PTRレコードが見つからないか、無効なHELOメッセージを含むSMTPサーバー経由で送信されたメールに対して、低いレベルの信頼を実行します。
翻訳に関する免責事項：この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。
翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。