質問
メール システムが Zendesk で正常に動作することを確認するにはどうすればよいですか?
回答
Zendesk は受信トレイにスパムが入らないように努めていますが、顧客とのやり取りに使用するチャネルを保護するためにできる特定の対策があります。この記事では、メール サーバーの信頼レベルを上げる方法の概要を説明します。
この記事では、次のセクションについて説明します。
- Zendesk にメールを送信する SMTP サーバーの PTR レコード
- HELO および EHLO グリーティング ホスト名
- SPF レコード
- DMARC と DKIM
- スクリプトと Web フォームを使用してメールを送信する
- Zendesk が信頼しないメール
Zendesk にメールを送信する SMTP サーバーの PTR レコード
サポートに電子メールを送信するために使用するすべての IP アドレスに Pointer (PTR) レコードがあることを確認してください。PTR レコードは、指定された IP アドレスがドメイン所有者に接続されているというさらなる信頼を提供します。たとえば、domain.com の誰かがサポートに電子メールを送信した場合、IP アドレス 1.2.3.4 は mail.domain.com に解決されるはずです。
理想的には、PTR レコードは、サポートに電子メールを送信するのと同じドメインに属している必要があります。IP アドレスが家庭用 ISP に属していることを示す IP アドレス番号またはキーワードを含めないでください。
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
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
詳細については、ウィキペディアの次の記事を参照してください。SMTP サーバーの戻りコードのリスト。
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”
DMARC と DKIM
受信するなりすましメールやスパムの数を減らすには、SPF、DKIM、DMARC と連携した送信者認証を有効にして、受信メールにセキュリティ層を追加します。詳細については、次の記事を参照してください:受信メールの認証 (SPF、DKIM、DMARC) 。
スクリプトと Web フォームを使用してメールを送信する
Web フォームまたは自動化されたスクリプトを使用してサポートに電子メールを送信することは推奨されておらず、現在サポートされていません。これらの種類の電子メールを引き続き送信したいお客様は、以下に概説する規則に従う必要があります。
- すべての送信 Web フォームは、認証を要求するか、CAPTCHA を使用するか、またはその両方を行う必要があります。あなたが許可し、助長しているスパム攻撃を防ぐことはできません。
- Web フォーム、Web アプリケーション、または自動化スクリプトを使用してサポートに電子メールを送信する場合、電子メールはRFC 5322に従って正しくフォーマットする必要があります。
- メッセージには、適切な形式のSubject: 、 From: 、 To: 、 Reply-To:ヘッダーが含まれている必要があります。
- 送信 IP アドレスには PTR レコード (逆引き DNS 解決) が必要です。
- サポートでは、有効な SPF レコードを追加し、送信ドメインの DNS ゾーンで公開されている DKIM キーを使用してこれらの電子メールに署名し、電子メールの処理方法を指定する DMARC ポリシーを公開することをお勧めします。
- HELO グリーティングには、解決可能な有効な DNS 名が必要です。
- データの冗長性を確保し、停止の可能性を減らすために、Web フォームからの電子メールを外部のサポート アドレスに転送します。
- ネイティブの Zendesk サポート アドレス (support@ subdomain.zendesk.com) に送信する場合、フォームは一時的なネットワーク エラーを処理できる必要があります。
4xx
回復力への対応。 - MX リレーを MX レコードにハードコーディングしないでください。各リレーは MX ルックアップを実行する必要があります。
- 使用しないでくださいスパムとしてマーク Web フォームから送信するための機能。これは、フォームの送信レピュテーションに悪影響を及ぼします。
- Zendesk カスタマー サポートは、Web フォームの機能に対するサポートを提供していません。
Zendesk が信頼しないメール
Zendesk は以下を信頼しません。
- ドメイン所有者の DNS ゾーンで公開されている承認 SPF レコードを持たずに、電子メールの送信者になりすましている電子メール。
- 偽装された送信者アドレス、無効な DKIM 署名、または失敗した SPF チェックを含む電子メール。*
- 電子メールの送信者ヘッダーと受信者ヘッダーで、無効な、存在しない、または解決できないドメイン名を使用する電子メール。
サポートは、SMTP サーバー経由で送信された、PTR レコードが欠落している、または無効な HELO グリーティングを含む電子メールに対して、低レベルの信頼を行使します。
*Zendesk は、ドメインから Zendesk サポート サブドメイン (support@yourdomain.com >> support@subdomain.zendesk.com など) にメールを転送している場合、転送されたメールを検出しようとします。Zendesk がメール転送を検出した場合、Zendesk は送信側の SMTP サーバーを認証するための別のアプローチを採用します。ただし、転送 SMTP サーバーを構成して、DKIM 署名を保持し、元の電子メール本文と機密ヘッダーを改ざんしないようにします。
翻訳に関する免責事項:この記事は、お客様の利便性のために自動翻訳ソフトウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性については保証いたしません。
翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事を参照してください。
0 コメント
サインインしてコメントを残してください。