Writing an Effective TrekMail Support Ticket

A well-written support ticket gives the team the details needed to investigate without guessing. It cannot promise a response time or outcome, but it makes the next step clearer. This guide shows what to include, plus templates for common ticket categories.

For how to file a ticket (where to click, the fields), see Using the Support Center. This article is about the content.

The core structure of a good ticket

Every useful ticket answers four questions:

1. What I was trying to do: your goal, not just what went wrong.
2. What actually happened: the exact error, status, or behaviour you saw.
3. What I already tried: this avoids repeating a basic check.
4. Identifying information: the domain, mailbox, invoice number, or timestamps that identify the case.

The more of this context you can give, the easier it is to check the right area of the product. Never include a password, 2FA code, or API token.

What to include by category

Billing tickets

• Invoice number or payment reference shown in Billing or on the payment receipt.
• The expected charge vs actual charge if they differ.
• Whether the issue is about a renewal, an add-on activation, a refund request, etc.
• Card last 4 if asking about card-specific issues (but never the full PAN or CVV).
• Currency and amount in the dispute.

Example:

I was charged $52 yesterday, but expected $39. The invoice number from my Billing page is included below. Card last 4: 4242. Please explain whether the difference is another item or tax. I attached a screenshot of the dashboard that shows the charge.

Technical / sending tickets

• Sending mailbox address.
• Recipient address (or pattern, e.g. "all @gmail.com recipients").
• Exact error message (copy the full text including any error codes like 550, 421).
• When it started: include a date, time, and timezone when possible.
• Whether the same mailbox can send to other addresses: this shows whether the issue is limited to one recipient or provider.
• Whether webmail can send the same email: this helps distinguish a mail app setup issue from an account or delivery issue.

Example:

Mailbox alice@mycompany.com can't send to any address on gmail.com since this morning. Other recipients (yahoo.com, outlook.com) work fine. The bounce message is "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." Webmail shows the same error. Started ~09:00 UTC on 2026-05-15. Other mailboxes on the same domain also can't reach gmail.com.

DNS tickets

• Domain name.
• The status TrekMail shows for the domain and the exact record that is not verified.
• The result of a DNS lookup, if you have one. For example, the dig output for an MX record or SPF TXT record.
• Your DNS provider (Cloudflare, GoDaddy, etc.).
• The specific record that won't verify.
• Whether you changed DNS recently, including the approximate time.

Example:

Domain: mycompany.com. The DKIM record is still red on the Domains page. I added the record at Cloudflare yesterday and set it to DNS-only, not proxied. dig +short TXT dkim._domainkey.mycompany.com returns the expected v=DKIM1; k=rsa; p=... value. TrekMail still marks it as missing. I also checked propagation from another DNS lookup service.

Deliverability / spam tickets

• Domain and mailbox sending.
• Bounce rate from your Domain Email Stats panel.
• Sample recipients that are bouncing or spam-folding (without sharing the entire list).
• Your list source: opt-in form, an older provider, or another source.
• Recent sending pattern: whether volume or audience changed lately.

Example:

Domain mycompany.com bounce rate rose from 0.5% to 8% over the last seven days. I attached an Email Stats screenshot. I send to an opt-in newsletter list of about 2,000 subscribers. The bounces include "user unknown" and "mailbox over quota." I removed about 200 inactive subscribers two weeks ago, which is the only recent change. Should I verify the remaining list before sending again?

API tickets

• API token name (don't paste the actual token).
• The endpoint you're calling.
• The request body (redact any sensitive data).
• The response (status code + body).
• Expected behaviour vs observed behaviour.

Example:

Calling POST /api/v1/verify/bulk with a redacted emails array and mode: quick. I receive HTTP 422; the response body is attached below with email addresses removed. I expected a verification job to be created. Token name: "production-verify-token". This started around 13:00 UTC today, and the same request worked yesterday.

Account / login tickets

• The account email (your sign-in address).
• What's happening (can't log in, password reset not arriving, 2FA not working, etc.).
• Browser and OS.
• Whether you sign in with a social provider (Google, Microsoft, and similar services).
• Approximate last successful login date.

For a 2FA recovery request, describe the access problem and provide only the account details requested through the official support flow. Never send a current password, 2FA code, recovery code, or identity document in an ordinary ticket message unless a verified TrekMail process explicitly asks for it.

What NOT to include

Don't share:

• Plaintext passwords. Ever. Not your dashboard password, not mailbox passwords, not third-party service passwords.
• Full credit card numbers, CVVs, or full bank account details. Last 4 digits are fine for identification.
• API tokens in plain text (we can identify them by name).
• Other customers' addresses or data in attachments. Anonymize or redact.
• Sensitive personal data of recipients unless it is essential to the investigation.

If you accidentally share a secret, revoke or rotate it where possible, then tell support promptly so the team can advise on the next step.

Attachment guidance

• Screenshots: image format only (JPEG, PNG, GIF, WebP), maximum 5 MB. Show the relevant page and error, but crop or redact URLs that contain a token, mailbox address, or other private information.
• DNS query output: paste as text (formatted with backticks for readability), not screenshot.
• Error logs: paste the relevant lines, not the entire log.
• Email-bounce text: include the full bounce report (the Diagnostic-Code: line especially).
• Browser screenshots: avoid showing other tabs, notifications, saved passwords, or unrelated customer data.

Ticket image attachments are scheduled for removal 30 days after the ticket closes. Keep a local copy of anything important.

One issue per ticket

If you have two separate problems, file two separate tickets. This keeps each conversation focused and makes the history easier to follow.

If two problems are linked (e.g. "billing failed AND sending stopped"), it's fine in one ticket as long as the connection is clear.

Updating a ticket

If the issue resolves itself before support replies, for example DNS finishes propagating or a third-party service returns, add a short update such as: "Resolved: DNS finished propagating. Please close this ticket." You can also close an active ticket yourself from its page.

If a partial workaround is acceptable but not the fix you wanted, say so: "I worked around it by doing X, but I would still like to understand why the original way did not work."

Templates you can copy

For a generic "something is broken" ticket:

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>

For a feature request:

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>

For a billing dispute:

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>