質問
Zendeskでメールシステムを確実に動作させるにはどうすればよいですか？
回答
Zendeskでは、受信トレイにスパムが入らないように努めていますが、顧客とのやりとりに使用するチャネルをセキュリティで保護するために、いくつかの方法があります。この記事では、メールサーバーの信頼レベルを上げる方法の概要を説明します。
この記事では、次のトピックについて説明します。
- Zendeskにメールを送信するSMTPサーバーのPTRレコード
- HELOおよびEHLOメッセージのホスト名
- SPFレコード
- DMARCとDKIM
- スクリプトとWebフォームを使用してメールを送信する
- Zendeskが信頼しないメール
Zendeskにメールを送信するSMTPサーバーのPTRレコード
Supportへのメールの送信に使用するすべてのIPアドレスにポインタ（PTR）レコードがあることを確認してください。PTRレコードは、指定されたIPアドレスがドメインオーナーに接続されているという信頼性を提供します。たとえば、domain.comの誰かがSupportにメールを送信した場合、IPアドレス1.2.3.4はmail.domain.comに解決されます。
理想的には、PTRレコードはSupportにメールを送信するのと同じドメインに属している必要があります。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
HELOおよびEHLOメッセージのホスト名
HELO名は、SMTPサーバー間で挨拶するために使用されます。RFC 5321（§2.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サーバーの戻りコードのリスト。
SPFレコード
Supportにメールを送信するドメインには、ドメインに代わってメールを送信することを許可する有効なSPFレコードが必要です。
以下の2つの正しいSPFレコードの例を見つけてください。
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”
DMARCとDKIM
なりすましメールや迷惑メールの受信件数を減らすには、SPF、DKIM、DMARCアラインメントによる送信者認証を有効にして、受信メールのセキュリティを強化します。詳細については、次の記事を参照してください：受信メールの認証（SPF、DKIM、DMARC）
スクリプトとWebフォームを使用してメールを送信する
Webフォームや自動スクリプトを使用してSupportにメールを送信することはお勧めできません。これらのタイプのメールを引き続き送信する場合は、以下のルールに従う必要があります。
- すべての送信Webフォームは、認証を要求するか、CAPTCHAを使用するか、またはその両方を行う必要があります。お客様が許可および奨励しているスパム攻撃を防ぐことはできません。
- 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が信頼しないメール
Zendeskは以下を信頼していません。
- ドメインオーナーのDNSゾーンに認証SPFレコードを公開せずに、メールの送信者を偽装しているメール。
- なりすましの送信者アドレス、無効なDKIM署名、またはSPFチェックに失敗したメール*。
- メールの送信者と受信者のヘッダーに無効なドメイン名、存在しないドメイン名、解決できないドメイン名を使用しているメール。
サポートは、PTRレコードが欠落している、または無効なHELOメッセージが含まれているSMTPサーバー経由で送信されたメールに対しては、信頼度が低くなっています。
*ドメインからZendeskサポートサブドメイン（support@yourdomain.com >> support@subdomain.zendesk.comなど）にメールを転送している場合、転送されたメールを検出しようとします。Zendeskがメールの転送を検出した場合、Zendeskは送信SMTPサーバーを認証する別の方法をとります。ただし、DKIM署名を保持し、元のメール本文と機密ヘッダーを改ざんしないように、転送SMTPサーバーを設定します。
翻訳に関する免責事項：この記事は、お客様の利便性のために自動翻訳ソフトウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性については保証いたしません。
翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事を参照してください。
0 コメント
サインインしてコメントを残してください。