このガイドを使用して、Zendeskとのシームレスなインテグレーションのためにメールシステムを最適化してください。この記事で説明するベストプラクティスに従うことで、メールサーバーの信頼性を高め、Zendeskを使用する際に発生する問題のリスクを最小限に抑えることができます。

この記事では、次の設定に関する推奨事項とベストプラクティスについて説明します。

推奨事項1：Zendeskにメールを送信するSMTPサーバーのPTRレコードを設定する

サポートへのメール送信に使用するすべてのIPアドレスに、Pointer(PTR)レコードがあることを確認してください。PTRレコードは、指定されたIPアドレスがドメインオーナーと関係があることを保証します。たとえば、domain.comからサポートにメールを送信する場合、IPアドレス1.2.3.4はmail.domain.comに解決されます。

理想的には、PTRレコードは、サポートにメールを送信するドメインと同じドメインに属している必要があります。IP アドレス番号や、IP アドレスが居住する ISP のものであることを示すキーワードを含めることはできません。

domain.comの正しいレコードの例：

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com

見つからないレコードの例：

  • host 1.2.3.4
  • Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)

メールの送信に使用しないレコードの例：

  • host 1.2.3.4
  • Host 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.com
  • HELO localhost
  • HELO 1.2.3.4
  • HELO invalid.tld
  • HELO not.existing.domain.com
    詳細については、Wikipediaの「List of SMTP server return codes」を参照してください。

推奨事項3：SPFレコード

サポートにメールを送信するドメインには、ドメインに代わってIPアドレスがメールを送信することを承認する有効なSPFレコードが必要です。

次の状況に適したSPFレコードの例を2つ見つけてください。

  • domain.com
  • SMTP servers with address 1.2.3.4
  • MX 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による送信者認証を有効にすることで、受信メールにセキュリティ層をさらに追加できます。詳しくは、「Authenticating incoming email (SPF, DKIM, DMARC, and ARC) (SPF, DKIM, DMARC, and 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@yoursubdomain.zendesk.com)に送信する場合は、一時的なネットワークエラーや4xx応答をフォームで処理して復元性を確保できる必要があります。
  • MXリレーを当社のMXレコードにハードコードしないでください。各リレーはMXルックアップを実行する必要があります
  • Webフォームからの送信にはスパムとして登録機能を使用しないでください。フォームの送信レピュテーションに悪影響を及ぼします
  • ZendeskカスタマーSupportでは、Webフォームの機能に関するSupportは提供していません。

信頼できるメールを送信するためのベストプラクティス

Zendeskは、次のことを信頼していません。

  • ドメインオーナーのDNSゾーンで認証SPFレコードを公開せずに、メールの送信者をなりすましているメール

  • 送信者アドレスが偽装されている、DKIM署名が無効または一致していない、SPFチェックに失敗したメール

    メモ：ドメインからZendesk Supportサブドメイン（例：support@yourdomain.com >> support@yoursubdomain.zendesk.com）にメールを転送している場合、Zendeskは転送メールの検出を試みます。メール転送が検出された場合、Zendeskは送信SMTPサーバを認証するための代替アプローチを実行します。ただし、DKIM署名を保持し、元のメール本文や機密ヘッダーが改ざんされないように転送サーバーを設定するようにしてください。また、可能な限りARCヘッダーを利用するようにしてください。
  • メールの送信元と受信者のヘッダーに無効なドメイン名、存在しないドメイン名、または解決できないドメイン名を使用しているメールは、一時停止または拒否される可能性があります。

サポートは、PTR レコードが見つからないか、無効な HELO メッセージを含む SMTP サーバ経由で送信されたメールに対して、低い信頼度を実行します。

翻訳に関する免責事項：この記事は、お客様の利便性のために自動翻訳ソフ トウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性につ いては保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事 を参照してください。

Powered by Zendesk