What to Include in a Support Ticket

A well-written support ticket gets resolved in one round-trip. A poorly written one bounces back and forth for days. This guide shows what to include to make your ticket fast and accurate, plus templates for the 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 good ticket has four parts:

1. What I was trying to do — your goal (not just what went wrong).
2. What actually happened — the exact error, status, behaviour you saw.
3. What I already tried — to skip past obvious "did you try X" replies.
4. Identifying info — domain, mailbox, invoice ID, timestamps so we can look you up in logs.

Without any one of these, support has to guess and ask. With all four, we usually know exactly what to check.

What to include — by category

Billing tickets

• Invoice ID (the IN-YYYY-NNNN or Stripe in_xxx from your Billing page).
• 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:

Stripe charged my card $39 yesterday but my invoice shows $52. Invoice ID: IN-2026-0521. Card last 4: 4242. Expected charge was $39 (White Label Lite). Was the extra $13 a different item I missed? Screenshot of the dashboard attached showing the discrepancy.

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 — timestamp.
• Whether the same mailbox can send to other addresses — narrows down whether it's a sender-side or recipient-side issue.
• Whether webmail can send the same email — narrows down client-side vs server-side.

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 this domain.
• Output of dig for the relevant record (MX, TXT for SPF, etc.).
• Your DNS provider (Cloudflare, GoDaddy, etc.).
• The specific record that won't verify.
• Whether you've changed DNS recently.

Example:

Domain mycompany.com — DKIM record shows red on the Domains page. I added the record at Cloudflare yesterday (orange-cloud off, grey-cloud DNS-only). dig +short TXT dkim._domainkey.mycompany.com from my laptop returns the expected v=DKIM1; k=rsa; p=... value. TrekMail's verify still flags it as missing. dnschecker.org shows propagation worldwide.

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? Bought? Imported from a previous provider?
• Recent sending pattern — has volume changed lately?

Example:

Domain mycompany.com bounce rate jumped from 0.5% to 8% over the last 7 days (Email stats screenshot attached). I send mostly to my opt-in newsletter list (2,000 subscribers). The bounce errors include a mix of "user unknown" and "mailbox over quota". I removed about 200 inactive subscribers two weeks ago — that's the only recent change. Should I run the list through the Verifier before continuing?

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/job with {"emails": [...100 emails...]}. Getting 422 response: {"errors": {"emails": ["The emails field is required."]}}. The request includes the emails — confirmed via curl --trace. Token name: "production-verify-token". Started failing around 13:00 UTC today. Same call 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 signed up with a social provider (Google, Microsoft, etc.) — this changes the recovery path.
• Approximate last successful login date.

For 2FA-recovery tickets, expect identity-verification questions: documenting purchases, address history, etc. These take longer because we're verifying it's actually you.

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 absolutely necessary for the ticket.

If you accidentally share something sensitive, mention it in a follow-up reply and we can scrub the message internally.

Attachment guidance

• Screenshots: image format only (JPEG, PNG, GIF, WebP). Maximum 5 MB. Include the URL bar so we can verify which page you're on.
• 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).
• Don't share screenshots that include other tabs in your browser — they may leak info.

Attachments are retained for 30 days after ticket closure. Download anything important locally.

One issue per ticket

If you have two separate problems, file two separate tickets. This keeps each conversation focused and lets the right team handle each.

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 (DNS finally propagated, a third-party service came back online, etc.), reply with: "Resolved — DNS finished propagating. Ticket can be closed." It saves a round-trip and helps support close it cleanly.

If a partial workaround was acceptable but not the real fix you wanted, mention it: "I worked around it by doing X, but I'd still like to understand why the original way doesn't 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 / 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 ID if billing, API token name if API, etc.>

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 ID: IN-YYYY-NNNN
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>