TrekMail-Sendelimits nach Tarif im Überblick

TrekMail schützt die Zustellqualität durch Tarifgrenzen und Sicherheitsprüfungen. Jeder Empfänger zählt zum Versandkontingent. Eine Nachricht an drei Personen verbraucht deshalb drei Empfängersendungen. Im Dashboard und auf der Registerkarte SMTP jeder Domain werden die heute geltenden Grenzen angezeigt, einschließlich der Testphasen-Grenzen, des ersten Tages nach der ersten Zahlung und des Warm-ups einer neuen Domain.

Grundlimits der Tarife

Nano enthält kein Managed TrekMail SMTP. Eine Nano-Domain benötigt zum Senden ein funktionierendes eigenes SMTP-Profil. Der externe Anbieter kann zusätzlich zu den hier beschriebenen TrekMail-Schutzmechanismen eigene Grenzen festlegen.

Sicherheitsgrenzen vor der ersten bezahlten Abbuchung

Konten, für die noch keine Zahlung eines Mailtarifs abgeschlossen wurde, können niedrigere Sicherheitsgrenzen erhalten. Diese Werte schützen ein neues Konto während der Einrichtung.

Die erste erfolgreiche Abbuchung erhöht diese Grenzen sofort, und zwar auf die unten beschriebenen Grenzen für den ersten Tag. In der Testphase müssen Sie nicht bis zu ihrem Ende warten: Abrechnung → Testphase beenden und Abonnement jetzt starten beendet die Testphase, rechnet den gewählten Tarif ab und erhöht die Testphasen-Grenzen sofort. Ein größerer Tarif während der Testphase hebt sie nicht auf, denn die Sicherheitsgrenzen sind in jedem Tarif gleich. Eine neue Domain kann sich dennoch in ihrem eigenen Warm-up befinden. Gehen Sie daher nicht davon aus, dass eine Zahlung sofort zum Grundmaximum berechtigt. Lesen Sie die Regeln für das Domain-Warm-up.

Die ersten 24 Stunden nach der ersten Zahlung

In den ersten 24 Stunden nach der ersten erfolgreichen Zahlung eines Kontos liegen seine Grenzen über denen einer Testphase, aber unter den eigenen Werten des Tarifs:

Diese Werte sind eine Obergrenze. Erlaubt der Tarif oder das Warm-up einer neuen Domain weniger, gilt der niedrigere Wert. Nach 24 Stunden gelten die vollen Grenzen des Tarifs von selbst: Sie müssen nichts tun. Das Dashboard, die Registerkarte SMTP jeder Domain und die E-Mail zur Zahlungsbestätigung zeigen den genauen Zeitpunkt.

Das gilt einmalig für die erste Zahlung, unabhängig von der Zahlungsart. Verlängerungen, Upgrades und spätere Zahlungen lösen es nicht erneut aus. Es schützt neue Konten und die Versandreputation, die sich alle Kunden teilen. Wenn Sie ein etabliertes Unternehmen zu TrekMail umziehen und die vollen Grenzen früher benötigen, wenden Sie sich an den Support.

Warm-up einer neuen Domain

In den ersten sieben Tagen nach dem Erstellen einer Domain reduziert TrekMail die ratenbezogenen Limits dieser Domain:

Das Warm-up senkt nur die Grenzen der neuen Domain und ihrer Postfächer. Ihre anderen Domains behalten ihr volles Kontingent, und die tägliche Gesamtsumme des Kontos wird durch eine neue Domain nicht verringert. Die zulässige Empfängerzahl einer Nachricht ändert sich durch das Warm-up nicht. Jede Stufe beginnt um 00:00 UTC an Tag 4 und an Tag 8. Beginnen Sie mit Empfängern, die Ihre Nachrichten erwarten, und erhöhen Sie das Volumen schrittweise.

Beispiel: ein Konto in der Testphase mit einer neuen Domain

Ein Starter-Konto in der Testphase fügt am Montag eine Domain hinzu und sendet am Dienstag, dem zweiten Tag der Domain, von ihr aus:

• Ein Postfach kann heute an 12 Empfänger senden: die Testphasen-Grenze von 30, zu 40 % für eine neue Domain. Sechs Nachrichten an je zwei Personen schöpfen sie aus.
• Die ganze Domain kann heute an 20 Empfänger senden, das ganze Konto an 50.
• Ab Donnerstag (Tag 4) kann das Postfach an 21 Empfänger pro Tag senden, ab dem folgenden Montag (Tag 8) an die volle Testphasen-Grenze von 30.
• Startet das Abonnement früher, steigt die Testphasen-Grenze sofort: In den ersten 24 Stunden kann dasselbe Postfach an 150 Empfänger pro Tag senden, danach während des Warm-ups an 400 pro Tag und nach dem Warm-up an 1.000 pro Tag.

Was auf das Kontingent angerechnet wird

Die maßgebliche Grenze hängt vom Versandweg und der Empfängerzahl ab.

• Eine Nachricht mit mehreren Empfängern in To, Cc oder Bcc zählt einmal pro Empfänger.
• Webmail und die API prüfen das Postfach, seine Domain und das ganze Konto sowie die Empfängerzahl jeder Nachricht.
• Mail-Apps, die per SMTP senden (Outlook, Apple Mail, Telefone), werden gegen das tägliche und stündliche Kontingent des Kontos geprüft und eine neue Domain gegen ihr eigenes Warm-up-Kontingent. Webmail, die API und Mail-Apps teilen sich dieselben Tagessummen.
• Weitergeleitete Nachrichten, die TrekMail verlassen, verbrauchen das Versandbudget des Kontos. Eine Spitze bei Weiterleitungen kann die Weiterleitung bis zum Ende des geltenden Zeitfensters pausieren.
• Ein eigenes SMTP-Profil ergänzt die Regeln des externen Anbieters. Es entfernt nicht die Absender-, Konto-, Sicherheits- oder Ratenprüfungen von TrekMail.
• API- und MCP-Sendungen müssen neben dem gewählten Versandweg und diesen geltenden Grenzen auch ihre eigenen Anfrageschutzmechanismen einhalten.

Bei API- und MCP-Automatisierung erlaubt ein Nachrichtentoken 60 Sendeanfragen pro Minute und bis zu 500 Sendungen pro Tag, während ein Postfach standardmäßig 100 API-Sendungen pro Tag erlaubt. Normalerweise greift zuerst die niedrigere Postfachgrenze. Diese Schutzmechanismen gelten zusätzlich zu den Grenzen von Tarif, Domain, Konto und externem Anbieter. Sie ersetzen sie nicht.

Wenn Sie Weiterleitung für E-Mails mit hohem Volumen verwenden, lesen Sie den Leitfaden Weiterleitungsadressen und testen Sie zuerst mit einer kleinen Gruppe.

Wann sich die Grenzen erneuern

• Tagesgrenzen (Postfach, Domain, Konto) erneuern sich um 00:00 UTC. Webmail zeigt die Uhrzeit in Ihrer Zeitzone an.
• Die stündliche SMTP-Grenze erneuert sich zu Beginn jeder Stunde (UTC).
• Die Empfängergrenze pro Nachricht erneuert sich nicht: Teilen Sie eine große Nachricht in kleinere auf.
• Die API-Grenze pro Postfach zählt über gleitende 24 Stunden ab dem ersten Versand; der Fehler nennt, wann sie wieder frei wird.
• Warm-up-Stufen beginnen um 00:00 UTC an Tag 4 und an Tag 8 einer neuen Domain.

Verhalten beim Erreichen eines Limits

Nichts, was Sie geschrieben haben, geht verloren, und jede Oberfläche sagt, welche Grenze erreicht ist und was Sie tun können:

• Webmail warnt Sie schon vor dem Senden. Wenn die Nachricht mehr Empfänger hat, als heute noch möglich sind, oder das heutige Kontingent bereits aufgebraucht ist, weist eine Zeile unter den Empfängern darauf hin, und ihre Schaltfläche Was kann ich tun? öffnet die vollständige Erklärung. Senden Sie trotzdem, bleibt die Nachricht geöffnet und dieselbe Erklärung erscheint: wie viel der Grenze verbraucht ist, warum sie gerade niedriger ist (eine Testphase, der erste Tag nach der ersten Zahlung oder eine neue Domain), wann sie sich in Ihrer Zeitzone erneuert und welche Möglichkeiten Sie haben. Wer die Abrechnung verwalten darf, sieht die Möglichkeit, das Abonnement jetzt zu starten; alle anderen werden gebeten, sich an die Administration ihres Kontos zu wenden. Sind Sie im selben Browser auch im Dashboard des Kontos angemeldet, und zwar mit einer Rolle, die Support-Tickets eröffnen darf, enthält die Erklärung zusätzlich die Schaltfläche Support kontaktieren.
• Geplante Nachrichten, die zu ihrem Zeitpunkt an eine Grenze stoßen, bleiben mit ihren Anhängen unter Geplant erhalten und sind als Nicht gesendet markiert. Senden Sie sie nach der Erneuerung, wählen Sie eine andere Zeit oder löschen Sie sie. Sie bleiben 7 Tage erhalten.
• Mail-Apps zeigen eine vorübergehende 4.7.1-Antwort, die die Grenze, die Zahlen, den Grund und die Erneuerungszeit nennt. Die Nachricht bleibt meist im Postausgang der App; senden Sie sie nach dieser Zeit erneut.
• Die API antwortet mit 429 und sending_limit_exceeded, das die Grenze (dimension), die Zahlen und die Erneuerungszeit (resets_at) nennt. Eine Nachricht, die die API mit 202 angenommen hat, kann beim Verlassen der Warteschlange noch abgelehnt werden: Prüfen Sie sie mit GET /api/v1/messages/deliveries/{request_id}.

Scheitert der Versand auch nach der Erneuerung, kann ein anderes Problem vorliegen, etwa eine inaktive Domain, eine nicht bestätigte Konto-E-Mail, eine fehlende SMTP-Route, ein Abrechnungsproblem oder eine Sicherheitssperre für ein einzelnes Postfach. Folgen Sie Häufige E-Mail-Sendefehler beheben.

IMAP-Verbindungsgrenzen

Dies sind Verbindungsgrenzen, keine Sendelimits. Sie steuern gleichzeitige IMAP-Verbindungen eines Postfachs.

Wenn eine Mail-App wiederholt zu viele Verbindungen öffnet, verringern Sie die Synchronisierungshäufigkeit oder entfernen Sie ein nicht genutztes Gerät, bevor Sie weitere Verbindungen hinzufügen.

Versand sicher planen

1. Prüfen Sie die heutigen Grenzen im Dashboard oder auf der Registerkarte SMTP der Domain.
2. Zählen Sie Empfänger, nicht nur Nachrichten. Planen Sie am ersten Tag nach der ersten Zahlung mit den Grenzen für den ersten Tag.
3. Verwenden Sie bei einer neuen Domain den Warm-up-Prozentsatz statt des allgemeinen Tariflimits.
4. Beginnen Sie mit einer kleinen Zielgruppe, die Ihre Nachrichten erwartet, und prüfen Sie die Zustellergebnisse.
5. Verwenden Sie für Kampagnen, die über normale Geschäftskorrespondenz hinausgehen, einen speziellen, einwilligungsbasierten Marketingdienst.

E-Mail-Hinweise für den Kontoinhaber

TrekMail schickt dem Kontoinhaber eine E-Mail in dessen Sprache, wenn eine Tagesgrenze fast oder ganz aufgebraucht ist:

• Fast aufgebraucht: Das Konto hat 80 % seines Tageskontingents verbraucht.
• Aufgebraucht: Ein Postfach, eine Domain in ihrer ersten Warm-up-Woche oder das ganze Konto hat das jeweilige Tageskontingent vollständig verbraucht.

Jeder Hinweis kommt höchstens einmal am Tag für dasselbe Konto, dieselbe Domain oder dasselbe Postfach, und Sendungen aus Webmail, über die API und aus Mail-Apps können diese Hinweise gleichermaßen auslösen. Außerdem gibt es weiterhin die bisherige Warnung, wenn Mail-Apps 80 % der stündlichen SMTP-Grenze erreichen; sie kommt höchstens einmal pro Stunde. Wenn Sie diese E-Mails nicht mehr erhalten möchten, schalten Sie Warnungen zur Domain-Zustellbarkeit unter Konto-Einstellungen → E-Mail-Benachrichtigungen aus. Derselbe Schalter deaktiviert auch andere Domain-Warnungen, etwa zur Bounce-Rate oder zu DNS-Problemen.