Ein wirksames TrekMail-Support-Ticket schreiben

Ein gut geschriebenes Support-Ticket liefert dem Team die Details, die es für eine Untersuchung ohne Mutmaßungen benötigt. Es kann weder eine Antwortzeit noch ein Ergebnis versprechen, macht aber den nächsten Schritt klarer. Dieser Leitfaden erklärt, welche Angaben erforderlich sind, und enthält Vorlagen für häufige Ticket-Kategorien.

Wie Sie ein Ticket einreichen, wo Sie klicken und welche Felder Sie ausfüllen, erfahren Sie unter Das Support-Center verwenden. Dieser Artikel behandelt den Inhalt.

Die Grundstruktur eines guten Tickets

Jedes hilfreiche Ticket beantwortet vier Fragen:

1. Was ich tun wollte: Ihr Ziel, nicht nur das aufgetretene Problem.
2. Was tatsächlich passiert ist: der genaue Fehler, Status oder das beobachtete Verhalten.
3. Was ich bereits versucht habe: So muss eine grundlegende Prüfung nicht wiederholt werden.
4. Identifizierende Angaben: Domain, Postfach, Rechnungsnummer oder Zeitstempel, die den Fall bestimmen.

Je mehr Kontext Sie angeben, desto leichter lässt sich der richtige Produktbereich prüfen. Geben Sie niemals ein Passwort, einen 2FA-Code oder ein API-Token an.

Erforderliche Angaben nach Kategorie

Abrechnungstickets

• Rechnungsnummer oder Zahlungsreferenz, die unter Billing oder auf dem Zahlungsbeleg angezeigt wird.
• Die erwartete Belastung im Vergleich zur tatsächlichen Belastung, falls sie voneinander abweichen.
• Ob es um eine Verlängerung, die Aktivierung eines Add-ons, eine Erstattungsanfrage oder etwas anderes geht.
• Letzte 4 Ziffern der Karte bei kartenspezifischen Fragen, aber niemals die vollständige PAN oder CVV.
• Währung und Betrag der Beanstandung.

Beispiel:

Mir wurden gestern $52 berechnet, ich hatte jedoch $39 erwartet. Die Rechnungsnummer aus meiner Billing-Seite ist unten angegeben. Letzte 4 Ziffern der Karte: 4242. Bitte erklären Sie, ob die Differenz auf einen weiteren Posten oder auf Steuern zurückgeht. Ich habe einen Screenshot des Dashboards mit der Belastung angehängt.

Technische Tickets oder Versandtickets

• Adresse des sendenden Postfachs.
• Empfängeradresse oder Muster, zum Beispiel "alle Empfänger bei @gmail.com".
• Genaue Fehlermeldung, mit dem vollständigen Text und allen Fehlercodes wie 550 oder 421.
• Zeitpunkt des Beginns: Geben Sie nach Möglichkeit Datum, Uhrzeit und Zeitzone an.
• Ob dasselbe Postfach an andere Adressen senden kann: Dies zeigt, ob das Problem auf einen Empfänger oder Anbieter beschränkt ist.
• Ob Webmail dieselbe Nachricht senden kann: So lässt sich ein Einrichtungsproblem der E-Mail-App von einem Konto- oder Zustellproblem unterscheiden.

Beispiel:

Das Postfach alice@mycompany.com kann seit heute Morgen an keine Adresse bei gmail.com senden. Andere Empfänger (yahoo.com, outlook.com) funktionieren. Die Unzustellbarkeitsmeldung lautet "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." Webmail zeigt denselben Fehler. Begonnen hat das Problem am 2026-05-15 gegen ~09:00 UTC. Andere Postfächer derselben Domain können gmail.com ebenfalls nicht erreichen.

DNS-Tickets

• Domainname.
• Der von TrekMail für die Domain angezeigte Status und der genaue Eintrag, der nicht verifiziert wird.
• Das Ergebnis einer DNS-Abfrage, falls vorhanden. Zum Beispiel die dig-Ausgabe für einen MX- oder SPF-TXT-Eintrag.
• Ihr DNS-Anbieter, etwa Cloudflare oder GoDaddy.
• Der konkrete Eintrag, der nicht verifiziert wird.
• Ob Sie DNS kürzlich geändert haben, einschließlich der ungefähren Uhrzeit.

Beispiel:

Domain: mycompany.com. Der DKIM-Eintrag ist auf der Domains-Seite weiterhin rot. Ich habe ihn gestern bei Cloudflare hinzugefügt und auf DNS-only statt proxied gesetzt. dig +short TXT dkim._domainkey.mycompany.com gibt den erwarteten Wert v=DKIM1; k=rsa; p=... zurück. TrekMail kennzeichnet ihn weiterhin als fehlend. Ich habe die Verbreitung auch mit einem anderen DNS-Abfragedienst geprüft.

Zustellbarkeits- oder Spam-Tickets

• Sendende Domain und sendendes Postfach.
• Bounce-Rate aus dem Bereich Domain Email Stats.
• Beispielempfänger, bei denen Nachrichten zurückgewiesen oder in Spam eingeordnet werden, ohne die vollständige Liste weiterzugeben.
• Quelle Ihrer Liste: Opt-in-Formular, früherer Anbieter oder eine andere Quelle.
• Aktuelles Versandmuster: ob sich Volumen oder Zielgruppe in letzter Zeit geändert haben.

Beispiel:

Die Bounce-Rate der Domain mycompany.com ist in den letzten sieben Tagen von 0.5% auf 8% gestiegen. Ich habe einen Screenshot von Email Stats angehängt. Ich sende an eine Opt-in-Newsletterliste mit etwa 2,000 Abonnenten. Die Rückläufer enthalten "user unknown" und "mailbox over quota". Vor zwei Wochen habe ich etwa 200 inaktive Abonnenten entfernt. Das war die einzige aktuelle Änderung. Sollte ich die verbleibende Liste vor dem nächsten Versand verifizieren?

API-Tickets

• Name des API-Tokens, ohne das eigentliche Token einzufügen.
• Den aufgerufenen Endpunkt.
• Den Request-Body, in dem sensible Daten geschwärzt sind.
• Die Antwort mit Statuscode und Body.
• Erwartetes Verhalten im Vergleich zum beobachteten Verhalten.

Beispiel:

Ich rufe POST /api/v1/verify/bulk mit einem geschwärzten emails-Array und mode: quick auf. Ich erhalte HTTP 422. Der Response-Body ist unten ohne E-Mail-Adressen angehängt. Ich hatte erwartet, dass ein Verifizierungsauftrag erstellt wird. Token-Name: "production-verify-token". Das Problem begann heute gegen 13:00 UTC, und dieselbe Anfrage funktionierte gestern.

Konto- oder Anmeldetickets

• Die E-Mail-Adresse des Kontos, also Ihre Anmeldeadresse.
• Was passiert, zum Beispiel Anmeldung nicht möglich, E-Mail zum Zurücksetzen des Passworts kommt nicht an oder 2FA funktioniert nicht.
• Browser und Betriebssystem.
• Ob Sie sich über einen Social-Login-Anbieter wie Google, Microsoft oder einen ähnlichen Dienst anmelden.
• Ungefähres Datum der letzten erfolgreichen Anmeldung.

Beschreiben Sie bei einer Anfrage zur 2FA-Wiederherstellung das Zugriffsproblem und geben Sie nur die Kontodaten an, die im offiziellen Support-Ablauf verlangt werden. Senden Sie niemals ein aktuelles Passwort, einen 2FA-Code, einen Wiederherstellungscode oder ein Ausweisdokument in einer normalen Ticket-Nachricht, sofern ein verifizierter TrekMail-Prozess nicht ausdrücklich danach fragt.

Was Sie NICHT angeben sollten

Teilen Sie Folgendes nicht:

• Passwörter im Klartext. Niemals. Weder Ihr Dashboard-Passwort noch Postfachpasswörter oder Passwörter von Drittanbieterdiensten.
• Vollständige Kreditkartennummern, CVVs oder vollständige Bankverbindungsdaten. Die letzten 4 Ziffern reichen zur Identifizierung aus.
• API-Tokens im Klartext. Wir können sie anhand ihres Namens identifizieren.
• Adressen oder Daten anderer Kunden in Anhängen. Anonymisieren oder schwärzen Sie sie.
• Sensible personenbezogene Daten von Empfängern, sofern sie für die Untersuchung nicht unverzichtbar sind.

Falls Sie versehentlich ein Geheimnis weitergeben, widerrufen oder rotieren Sie es nach Möglichkeit und informieren Sie den Support umgehend, damit das Team Sie zum nächsten Schritt beraten kann.

Hinweise zu Anhängen

• Screenshots: nur Bildformate JPEG, PNG, GIF und WebP, maximal 5 MB. Zeigen Sie die relevante Seite und den Fehler, schneiden oder schwärzen Sie aber URLs mit einem Token, einer Postfachadresse oder anderen privaten Angaben.
• Ausgabe von DNS-Abfragen: als Text einfügen und zur besseren Lesbarkeit mit Backticks formatieren, nicht als Screenshot.
• Fehlerprotokolle: nur die relevanten Zeilen einfügen, nicht das gesamte Protokoll.
• Text einer Unzustellbarkeitsmeldung: den vollständigen Bericht einfügen, insbesondere die Zeile Diagnostic-Code:.
• Browser-Screenshots: Vermeiden Sie die Anzeige anderer Tabs, Benachrichtigungen, gespeicherter Passwörter oder irrelevanter Kundendaten.

Bildanhänge von Tickets werden planmäßig 30 Tage nach Schließung des Tickets entfernt. Bewahren Sie von allen wichtigen Inhalten eine lokale Kopie auf.

Ein Problem pro Ticket

Wenn Sie zwei getrennte Probleme haben, reichen Sie zwei getrennte Tickets ein. So bleibt jede Unterhaltung auf ein Thema konzentriert und der Verlauf ist leichter nachzuvollziehen.

Wenn zwei Probleme zusammenhängen, zum Beispiel "Abrechnung fehlgeschlagen UND Versand gestoppt", können sie in einem Ticket stehen, solange der Zusammenhang klar ist.

Ein Ticket aktualisieren

Falls sich das Problem vor der Antwort des Supports von selbst löst, etwa weil die DNS-Verbreitung abgeschlossen ist oder ein Drittanbieterdienst wieder funktioniert, fügen Sie eine kurze Aktualisierung hinzu: "Gelöst: Die DNS-Verbreitung ist abgeschlossen. Bitte schließen Sie dieses Ticket." Sie können ein aktives Ticket auch selbst auf seiner Seite schließen.

Wenn eine teilweise Umgehungslösung akzeptabel ist, aber nicht Ihrer gewünschten Lösung entspricht, sagen Sie das: "Ich konnte das Problem durch X umgehen, möchte aber weiterhin verstehen, warum der ursprüngliche Weg nicht funktioniert hat."

Vorlagen zum Kopieren

Für ein allgemeines Ticket zu einer Fehlfunktion:

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>

Für eine Funktionsanfrage:

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>

Für eine Abrechnungsbeanstandung:

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>