スパムや悪用から会社を守ることは、すべての企業が直面する課題です。すべてのスパムを阻止する特効薬はありませんが、広く採用されている対策が役に立つかもしれません。

アカウントをできるだけスパムから保護するには、アカウントに送信されるフォーム、メール、APIコールにアクティブな保護を適用する必要があります。この記事では、アカウントを保護するための有効な方法について説明します。

この記事では、次のトピックについて説明します。

  • フォームでのCAPTCHAの使用
  • SPF、DKIM、DMARCレコードによる、メールの不正使用からのドメインの保護
  • Zendesk Support固有の機能を利用したスパムと対策
  • その他の情報

フォームでのCAPTCHAの使用

CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart:コンピュータと人間を区別するための完全に自動化された公開チューリングテスト)は、システムへのスパムの侵入を防ぐための最良の方法の1つとして推奨されています。CAPTCHAは、チケットの送信者に課題を提示し、課題をクリアしたユーザーだけがチケットを送信できるしくみです。多くの場合、CAPTCHAにより、システムを悪用しようとする試みが完全に阻止されるでしょう。

Supportは、Cloudflareのボット検出・対策ソフトウェアを使用します。「アカウント登録」ページに含まれるCAPTCHAはデフォルトで有効になっており、無効にすることはできません。Cloudflareが疑わしいと判断したトラフィックにのみ、CAPTCHAの課題が提示されます。

SPF、DKIM、DMARCレコードによる、メールの不正使用からのドメインの保護

ほとんどの場合、不正なメールメッセージは、さまざまなプログラムやスクリプトで容易に生成可能な偽造アドレスや偽装アドレスから送られてきます。 SPF、DKIM、DMARCを連携させて使用することで、会社のドメインのレピュテーションを高め、会社のメールがカスタマーの迷惑メールフォルダに振り分けられるのを防ぐことができます。Zendeskはこれらの3種類のレコードすべてに対応しているため、お客様のアカウントで簡単に使用できます。各レコードに関して、以下に簡単に説明します。

SPFレコードは、DNSレコード内に設定されるポリシーで、サーバーがメッセージを送信することを許可されているかどうかをメール受信者のメールクライアントが検証できるようにします。平たく言えば、SPFはメールサーバーの許可リストのようなもので、会社のドメインに代わって、送信できるものとできないものを指定します。これにより、偽造メールを削減することができます。Zendeskのレコードの設定の詳細については、「自社のメールドメインの代わりにZendeskからメールを送信する方法」を参照してください。

DKIMレコードは、送信者のドメインのDNSレコードに配置された公開鍵に対してメッセージの暗号署名を検証するプロトコルです。これは、メールの経路に逸脱がなかったことを確認し、受信者がメッセージを取得する前にメッセージが何らかの形で変更されたかどうかを示します。このため、ドメインやメールが信頼性が高いとみなされる傾向が高く、スパムフォルダーに入る(または完全に拒否される)可能性は低くなります。Zendeskに必要なDKIMレコードの設定手順については、「DKIMまたはDMARCを使用したメールのデジタル署名」という記事を参照してください。

DMARC(Domain-based Message Authentication, Reporting and Conformance)は、SPFとDKIMを組み合わせて使用するポリシーで、SPFレコードやDKIMレコードがメール内に存在しない場合にメールを処理する方法をサーバーに指示します。また、ドメインがどのように使用され、メールを処理しているかを把握できるように、障害発生時にメールレポートを送信することもできます。DMARCの詳細と設定方法については、Dmarc.orgの「Overview」を参照してください。

Zendesk Support固有の機能を利用したスパムと対策

前述のアクションは、一般的にドメインに役立ちますが、Zendesk Supportには別の対策もいくつか用意されています。

初回返信トリガからの特定のプレースホルダの削除(オープンなZendesk Supportインスタンスにのみ適用)

登録不要で誰でもチケットを送信できる公開のZendesk Supportインスタンスを使用している場合、以下のプレースホルダを使用した初回返信トリガ(チケット作成時に起動するトリガ)が、リレースパムのターゲットになる可能性があります。

リレースパムとは、サードパーティ(この場合はZendesk)を経由して宛先にメールを送信することで、メールアドレスの送信元を隠してサードパーティになりすますことを指します。以下のプレースホルダは、誰でも任意のテキストやリンクを入力できる匿名エンドポイントを使用するため、リレースパムのターゲットになります。

  • {{ticket.title}}
  • {{ticket.requester.first_name}}
  • {{ticket.requester.last_name}}
  • {{ticket.requester.name}}

アカウントがリレースパムのターゲットになるリスクを回避するには、「エンドユーザーのアクセス設定」で説明したように、インスタンスを非公開にするか、制限するように設定することを検討してください。それ以外の場合は、Zendesk Supportの公開インスタンスでは、上記のプレースホルダを件名や本文に使用せず、静的テキストを使用してください。これにより、たとえばチケットが作成されたときに送信されるメール通知で、「山田 太郎様」という敬称が「www.spam.com 様」に置き換えられることはなくなります。 他のトリガ(最初の返信の後)でこれらのプレースホルダを使うことは、その時点で、そのやりとりが本物であることを証明したことになるので、許容されます。

送信者認証(インバウンドDMARC保護)

送信者認証は比較的新しい機能で、なりすましメールや不正なメールがアカウントに届かないように制御するのに役立ちます。 この機能は送信者のDMARCを認証し、失敗した場合は一時停止キューに送ります。この機能はメール管理ページの「管理」>「チャネル」>「メール」にあります。この機能の詳細については、サポート記事「DMARCを使用した受信メールの認証」をご覧ください。

メールとドメインのブロック

アカウントを予防的に保護する段階を過ぎていて、スパムメールがメール経由で届いている場合は、特定のアドレスやドメイン全体からの受信メールを完全にブロックすることができます。これはスパムを阻止する効率的な方法です。詳しくは「許可リストとブロックリストを使用したZendesk Supportへのアクセスの管理」を参照してください。

スパム送信者の手口はますます巧妙になっています。1つの解決策が完全に有効ということはないので、可能な限りのスパム対策ツールを活用することが重要です。ここに挙げた方法を組み合わせてビジネスに導入すれば、スパム送信者がビジネスを標的にする可能性は低くなるでしょう。

その他の情報

スパム対策のドキュメントをお探しの方は、以下をご覧ください。

  • ヘルプセンターのスパム防止について
  • Zendeskのスパムチケットを一括で削除するにはどうすればよいですか?
  • 一時停止中のチケットとスパムの管理について
Powered by Zendesk