効果的な TrekMail サポートチケットの書き方

分かりやすいサポートチケットには、推測せずに調査するための情報が含まれます。回答時期や結果を保証するものではありませんが、次の対応が明確になります。このガイドでは、必要な情報と一般的なカテゴリのテンプレートを紹介します。

チケットを送信する方法、クリックする場所、入力項目については、サポートセンターの使い方をご覧ください。この記事は内容について説明します。

良いチケットの基本構成

役立つチケットは四つの質問に答えます。

1. 何をしようとしていたか: 問題だけでなく目的も説明します。
2. 実際に何が起きたか: 表示された正確なエラー、状態、動作です。
3. すでに何を試したか: 基本確認の繰り返しを避けられます。
4. 識別情報: 対象を特定するドメイン、メールボックス、請求書番号、タイムスタンプです。

こうした情報が多いほど、製品の適切な箇所を確認しやすくなります。パスワード、2FA コード、API トークンは絶対に記載しないでください。

カテゴリ別に含める内容

請求チケット

• Billing または支払い領収書に表示された請求書番号または支払い参照番号。
• 異なる場合は予想した請求額と実際の請求額。
• 更新、add-on の有効化、返金依頼など、問題の種類。
• カード固有の問題ではカード末尾4桁。完全な PAN や CVV は記載しません。
• 争議対象の通貨と金額。

例:

昨日 $52 が請求されましたが、予想は $39 でした。Billing ページの請求書番号を以下に記載しました。カード末尾4桁: 4242。差額が別の商品か税金なのか説明してください。請求が表示されたダッシュボードのスクリーンショットを添付しました。

技術または送信チケット

• 送信メールボックスのアドレス。
• 受信者アドレスまたは「すべての @gmail.com 受信者」などのパターン。
• 550、421 などのコードを含む正確なエラーメッセージ全文。
• 開始時期: 可能なら日付、時刻、タイムゾーン。
• 同じメールボックスから別のアドレスへ送信できるか: 一つの受信者またはプロバイダーに限られるか判断できます。
• webmail で同じメールを送信できるか: メールアプリの設定と、アカウントまたは配信の問題を区別できます。

例:

Mailbox alice@mycompany.com から今朝以降 gmail.com のアドレスへ送信できません。ほかの受信者 (yahoo.com、outlook.com) には送れます。バウンスは "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." です。Webmail でも同じエラーです。2026-05-15 の09:00 UTC頃に始まりました。同じドメインのほかのメールボックスも gmail.com に送れません。

DNS チケット

• ドメイン名。
• TrekMail に表示される状態と未検証の正確なレコード。
• DNS 検索結果があれば、MX または SPF TXT レコードの dig 出力など。
• Cloudflare、GoDaddy などの DNS プロバイダー。
• 検証されない特定のレコード。
• 最近 DNS を変更したか、そのおおよその時刻。

例:

ドメイン: mycompany.com。Domains ページで DKIM レコードがまだ赤色です。昨日 Cloudflare にレコードを追加し、プロキシなしの DNS-only にしました。dig +short TXT dkim._domainkey.mycompany.com は期待する v=DKIM1; k=rsa; p=... を返しますが、TrekMail はまだ欠落と表示します。別の DNS 検索サービスでも伝播を確認しました。

到達性または迷惑メールのチケット

• 送信するドメインとメールボックス。
• Domain Email Stats パネルのバウンス率。
• バウンスまたは迷惑メール扱いとなる受信者の例。一覧全体は共有しません。
• リストの入手元: オプトインフォーム、以前のプロバイダー、その他。
• 最近の送信傾向: 量や対象を最近変更したか。

例:

ドメイン mycompany.com のバウンス率が過去七日間で 0.5% から 8% に上昇しました。Email Stats の画像を添付しました。約 2,000人のオプトインニュースレターリストへ送信しています。バウンスには "user unknown" と "mailbox over quota." があります。二週間前に約 200人の非アクティブ購読者を削除したことだけが最近の変更です。再送信前に残りのリストを検証すべきですか？

API チケット

• API トークン名。実際のトークンは貼り付けません。
• 呼び出している endpoint。
• 機密データを伏せたリクエスト本文。
• ステータスコードと本文を含むレスポンス。
• 期待した動作と実際の動作。

例:

伏せ字にした emails 配列と mode: quick を使い、POST /api/v1/verify/bulk を呼び出しています。HTTP 422 を受け取り、メールアドレスを除いたレスポンス本文を以下に添付しました。検証ジョブの作成を期待していました。トークン名: "production-verify-token"。本日13:00 UTC頃に始まり、昨日は同じリクエストが動作しました。

アカウントまたはログインのチケット

• ログインアドレスであるアカウントメール。
• ログイン不能、パスワードリセットが届かない、2FA が機能しないなどの状況。
• ブラウザと OS。
• Google、Microsoft などのソーシャルプロバイダーでログインするか。
• おおよその最後にログインできた日。

2FA の復旧依頼では、アクセス上の問題を説明し、正式なサポート手続きで要求されたアカウント情報だけを提出してください。検証済みの TrekMail 手続きが明示的に求めない限り、現在のパスワード、2FA コード、復旧コード、身分証明書を通常のチケット本文に送らないでください。

含めてはいけない情報

共有しないもの:

• 平文のパスワード。 ダッシュボード、メールボックス、第三者サービスのパスワードを一切含めません。
• カード番号全体、CVV、銀行口座の完全な詳細。 識別には末尾4桁で十分です。
• 平文の API トークン。名前で識別できます。
• 添付ファイル内の他の顧客のアドレスやデータ。匿名化または伏せ字にします。
• 調査に不可欠でない受信者の機密個人データ。

秘密情報を誤って共有した場合は、可能なら無効化またはローテーションし、すぐにサポートへ知らせて次の対応を確認してください。

添付ファイルのガイド

• スクリーンショット: JPEG、PNG、GIF、WebP の画像のみで、最大 5 MB。関連ページとエラーを表示し、トークンを含む URL、メールボックスアドレス、個人情報は切り取るか伏せます。
• DNS クエリ出力: スクリーンショットではなく、読みやすいようバッククォートで整形したテキストとして貼ります。
• エラーログ: ログ全体ではなく関連行だけを貼ります。
• メールのバウンス本文: 完全なバウンスレポート、特に Diagnostic-Code: 行を含めます。
• ブラウザの画像: ほかのタブ、通知、保存済みパスワード、無関係な顧客データを表示しません。

チケットの画像添付は、チケット終了から30日後に削除される予定です。重要なものはローカルコピーを保管してください。

一つのチケットにつき一つの問題

別々の問題が二つある場合は、二つのチケットを作成してください。会話が問題ごとに集中し、履歴を追いやすくなります。

二つの問題が関連する場合、たとえば「請求が失敗し、送信も停止した」場合は、関係を明確にすれば一つのチケットで構いません。

チケットを更新する

サポートからの返信前に DNS の伝播完了や第三者サービスの復旧で解決した場合は、短い更新を追加します。例: "Resolved: DNS finished propagating. Please close this ticket." 有効なチケットは、そのページから自分で閉じることもできます。

一時的な回避策は使えるものの希望した修正ではない場合は、次のように伝えます。"I worked around it by doing X, but I would still like to understand why the original way did not work."

コピーできるテンプレート

一般的な故障チケット:

Subject: <one-line summary of the issue>

What I was trying to do:
  <your goal>

What happened:
  <exact error or behaviour, including error messages>

Started:
  <timestamp or "always", "since yesterday", etc.>

What I tried:
  - <attempt 1>
  - <attempt 2>

Identifying info:
  - Domain: <domain.com>
  - Mailbox: <user@domain.com>
  - <Invoice number if billing, API token name if API, and similar identifiers>

機能リクエスト:

Subject: Feature request: <one-line description>

What I'd like to do:
  <user story: "as a <type of user>, I'd like to <action> so that <benefit>">

Current workaround:
  <if any>

Why this would help:
  <use case, frequency, scale>

Similar in other tools:
  <if any reference example>

請求に関する異議:

Subject: Billing dispute: <one-line summary>

Invoice number or payment reference: <from Billing or the payment receipt>
Charge amount: $X.XX
Expected amount: $Y.YY
Account email: alice@mycompany.com

What I was expecting:
  <explanation of what your subscription should have charged>

What was actually charged:
  <explanation of the actual invoice / charge>

Resolution requested:
  <refund / credit / explanation / something else>