Ein Broadcast ist eine einzelne E-Mail an die Abonnenten Ihrer Mailinglisten: ein Newsletter, ein Produkt-Update, eine Ankündigung. Er nutzt ein E-Mail-Design, geht über einen E-Mail-Kanal Ihres Posteingangs hinaus, und eine Antwort darauf wird eine Unterhaltung in diesem Posteingang. Danach zeigt Yuva, was geschehen ist: wer die Mail bekam, wer gebounct ist, sich abgemeldet oder geantwortet hat.
Der Ablauf ist Listen, dann ein Design, dann ein Broadcast. Broadcasts versenden Owner und Admins; Agents lesen die Broadcasts ihrer Posteingänge, damit sie eine Antwort verstehen.
1. Vor dem ersten Broadcast
- Legen Sie eine Liste an und bringen Sie Abonnenten darauf. Ein
Broadcast geht nur an Personen, die auf einer Liste
subscribedsind. - Tragen Sie die Absenderangaben des Posteingangs ein. Jeder Broadcast endet damit, und die Prüfung blockiert den Versand ohne rechtlichen Namen und Postanschrift.
- Bauen Sie ein Design oder starten Sie mit einer Vorlage.
- Der Posteingang braucht einen E-Mail-Kanal mit SMTP-Konto und einer Absenderadresse. Ein Catch-all-Kanal braucht eine From-Adresse. Richten Sie SPF, DKIM und DMARC für die Domain dieser Adresse ein (Zustellbarkeit).
- Optional, aber ratsam: ein eigenes Konto des Kanals für Broadcasts (unten).
Auf einem Server, den jemand anderes betreibt, muss ein neuer Workspace vor dem Versand eventuell auch freigegeben werden.
2. Den Broadcast schreiben
Im Panel: Broadcasts, dann New broadcast. Geben Sie einen Namen, den nur Ihr Team sieht, und wählen Sie den Posteingang. Er bleibt ein Entwurf, und jede Änderung wird beim Machen gespeichert, bis Sie ihn senden oder planen.
Der Absender
Wählen Sie den E-Mail-Kanal, der ihn versendet. Der Composer sagt, ob der Kanal bereit ist, welches Konto er nutzt und wie schnell er sendet.
Broadcast-Mails laufen nie über den eigenen Mailer des Servers. Es wird das separate Broadcast-Konto des Kanals genutzt, falls vorhanden, sonst sein Support-Konto. Ein eigenes Konto hält Beschwerden über Werbemails von dem Konto fern, das Ihre Support-Antworten trägt, und ein langsamer Versand verzögert nie eine Support-Antwort.
So richten Sie eines ein: Settings → den Posteingang → Channels → E-mail, dort der Abschnitt Broadcast sending. Schalten Sie „Use a separate account for broadcasts“ ein und tragen Sie Host, Port, Verschlüsselung, Benutzername und Passwort ein. Speichern mit ausgeschaltetem Schalter entfernt es. Das Tempo ist die Zahl der Mails pro Sekunde, die der Kanal sendet, von 1 bis 100 (5 bei einem neuen Kanal); bleiben Sie unter dem, was Ihr Anbieter erlaubt.
Die Zielgruppe
Wählen Sie bis zu 10 Listen des Posteingangs. Wer auf mehreren steht, bekommt eine Mail, und zwar unter der ersten seiner Listen in der von Ihnen gewählten Reihenfolge.
Auf Wunsch schränken Sie ein:
- Bedingungen (bis zu 10; alle müssen passen) vergleichen ein Kontaktattribut: ist, ist nicht, enthält (ohne Beachtung der Groß-/Kleinschreibung), ist größer als, ist kleiner als, ist eines von, ist gesetzt, ist nicht gesetzt. Ein Kontakt ohne das Attribut passt nur zu „ist nicht“ und „ist nicht gesetzt“.
- Sprachen (bis zu 20) behalten nur Kontakte, deren Sprache eine davon ist;
trbehält auchtr-TR. Leer behält alle.
Der Composer zeigt die Empfängerzahl, während Sie die Zielgruppe ändern, und unter „Left out“, warum die anderen nichts bekommen:
| Grund | Wer |
|---|---|
| Unsubscribed | Von den Listen abgemeldet. |
| Not confirmed yet | Auf den Listen nur pending (Double-Opt-in nicht abgeschlossen). |
| Bounced or reported as spam | Die Adresse ist gesperrt. |
| Objected to all mail | Die Person hat allen Mails Ihres Workspaces widersprochen. |
| Blocked contacts | Sie haben den Kontakt blockiert. |
| Left out by a condition or language | Eine Bedingung oder Sprache passt nicht. |
| On several lists, one mail each | Die überzähligen Abonnements. |
Der Inhalt
Wählen Sie das Design. Schreiben Sie den Betreff (bis zu 300 Zeichen; Posteingänge zeigen etwa die ersten
80) und, wenn Sie möchten, den Vorschautext, der in den meisten Posteingängen auf den Betreff folgt. Leer
nimmt den des Designs. Merge-Felder wie {{ contact.first_name | "there" }} funktionieren auch im
Betreff; die Prüfung hält Sie auf, wenn ein Feld ohne Fallback bei jemandem leer wäre.
Optionen
„Count clicks“ ist aus. Siehe Klick-Tracking.
Testversand
Senden Sie vor jedem Versand einen Test an sich selbst oder an bis zu fünf Mitglieder. Er sieht genau
aus wie die echte Mail, mit [Test] vor dem Betreff. Tests gehen nur an Mitglieder des Workspaces, nie
an eine andere Adresse, und ihr Abmeldelink sagt, dass es ein Test war. Die Merge-Felder füllen Sie mit
Beispielwerten oder mit den Werten eines Kontakts (der Test geht trotzdem nur an die gewählten
Mitglieder). Höchstens 20 Tests pro Stunde und Workspace.
3. Prüfen und senden
„Review and send“ zeigt die Checkliste, die der Server beim Planen ausführt. Blockierende Punkte stoppen den Versand; Warnungen nicht.
| Punkt | Blockiert, wenn |
|---|---|
| Sender details for the footer | Der Posteingang hat keinen rechtlichen Namen oder keine Postanschrift. |
| Sending channel | Kein Kanal gewählt, oder er hat kein SMTP-Konto oder keine From-Adresse. |
| Permission to send | Broadcasts sind auf dem Server aus, der Workspace wartet auf Freigabe oder ist gesperrt. |
| Design | Keines gewählt, oder es ergibt mehr als 500 KB HTML. |
| Recipients | Keine Liste gewählt, oder niemand bekäme die Mail. |
| Merge fields | Ein Feld ohne Fallback wäre bei jemandem leer. |
| Mail size | Über 102 KB HTML, wo Gmail die Mail abschneidet (samt Fußzeile und Abmeldelink). Ab 90 KB eine Warnung. |
| Image descriptions | Warnung: einem Bild fehlt der Alternativtext. |
| Links | Warnung: ein Link nutzt http:. |
| Subject | Leer oder länger als 300 Zeichen. Ab 80 eine Warnung. |
| Daily limit | Warnung: das Tageslimit macht den Versand länger als einen Tag. |
| Test mail | Warnung: seit der letzten Änderung ging kein Test hinaus. |
| Click tracking | Warnung, wenn an: Links zeigen auf die Link-Domain des Servers. |
Wählen Sie dann Send now oder Schedule mit einer Zeit in Ihrer Zeitzone, höchstens 90 Tage im Voraus. Das Panel bittet Sie, die Empfängerzahl zu bestätigen. Hat sich die Zielgruppe geändert, während Sie hinschauten, bittet es um eine neue Prüfung.
Was beim Planen passiert:
- Das Design wird in seiner aktuellen Version eingefroren. Spätere Änderungen am Design ändern diesen Broadcast nicht.
- Beim Start wird die Zielgruppe einmal festgelegt. Wer sich später anmeldet, ist nicht dabei. Wer sich abmeldet, bounct oder sich beschwert, bevor seine Mail hinausgeht, wird übersprungen, und jede Adresse wird direkt vor ihrer Mail noch einmal geprüft.
- Bis zum Start holt „Back to draft“ einen geplanten Broadcast zur Änderung zurück.
4. Während des Versands
Die Broadcast-Seite zeigt den Fortschritt live: festgelegte Empfänger, gesendet, fehlgeschlagen, gebounct und wann er ungefähr fertig ist.
| Status | Bedeutung |
|---|---|
| Draft | Wird geschrieben. |
| Scheduled | Wartet auf seine Zeit. |
| Preparing | Die Zielgruppe wird festgelegt. |
| Sending | Mails gehen hinaus. |
| Paused | Gestoppt, bis jemand fortsetzt. |
| Sent | Fertig. |
| Cancelled | Endgültig gestoppt. |
| Failed | Er kann nicht weiter, zum Beispiel weil sein Kanal entfernt wurde. |
Pause stoppt den Versand innerhalb des laufenden Stapels (höchstens 50 Mails). Resume macht dort weiter, wo er aufgehört hat. Cancel beendet ihn endgültig; noch nicht gesendete Mails werden übersprungen. Ein Entwurf oder ein beendeter Broadcast lässt sich samt Empfängerliste löschen; Unterhaltungen, die Antworten geöffnet haben, bleiben.
Vorübergehende SMTP-Fehler werden nach 5 Minuten, 30 Minuten, 2 Stunden und 6 Stunden wiederholt, dann gilt die Mail als fehlgeschlagen. Eine SMTP-Ablehnung der Adresse selbst (5.1.x und 5.2.1) ist ein Bounce.
Das Tageslimit
Ein Workspace kann ein Limit für Empfänger pro Tag (UTC) haben, für alle seine Broadcasts zusammen. Es
kommt aus YUVA_BROADCAST_DAILY_RECIPIENTS des Servers, dem Limit des
Operators für den Workspace und auf einem gehosteten Server aus dem Warm-up
(unten); das kleinste gilt. Erreicht ein Versand es, wartet der
Broadcast, und das Panel zeigt, wann er um 00:00 UTC weitergeht. Ein Broadcast an 250 Empfänger bei einem
Limit von 100 am Tag dauert drei Tage. Die Prüfung warnt vor dem Start; Settings → Workspace →
Broadcasts zeigt die heutige Zahl neben dem Limit.
Pausen, die Yuva selbst macht
Ein Broadcast pausiert von selbst, mit dem Grund auf der Seite, wenn:
| Grund | Auslöser |
|---|---|
| Bounce-Rate | 5 % oder mehr der seit dem Start oder der letzten Fortsetzung gesendeten Mails sind gebounct (nach mindestens 200 Mails). |
| Beschwerderate | 0,3 % oder mehr wurden als Spam gemeldet (nach mindestens 1.000 Mails). |
| Absenderfehler | Der SMTP-Server lehnt das Konto oder sein TLS ab, lehnt 20 Mails hintereinander ab oder ist 30 Minuten nicht erreichbar. Seine Antwort wird angezeigt. |
| Workspace gesperrt | Siehe unten. |
| Mitglied, Operator | Jemand hat pausiert. |
Beheben Sie die Ursache und setzen Sie dann fort. Nach dem Fortsetzen zählen die Raten ab diesem Moment.
Ein Workspace wird vom Versand gesperrt, wenn in den letzten 30 Tagen mindestens 0,3 % von mindestens 1.000 Broadcast-Mails als Spam gemeldet wurden oder mindestens 8 % von mindestens 2.000 gebounct sind. Seine laufenden Broadcasts pausieren, und Planen und Fortsetzen werden abgelehnt. Nur der Operator des Servers hebt eine Sperre auf: Ein Owner sieht den Grund unter Settings → Workspace → Broadcasts.
Bounces und Beschwerden
Yuva liest Bounces von Amazon SES (über SNS, siehe Bounces), aus Zustellberichten an den Kanal, aus SMTP-Ablehnungen beim Versand und Missbrauchsberichte (ARF) an den Kanal; Letztere zählen nur von einem Absender, dessen DMARC-Ergebnis der empfangende Server bestätigt.
- Ein harter Bounce sperrt die Adresse für alle Mails des Workspaces.
- Eine Spam-Beschwerde über einen Broadcast beendet Broadcasts an diese Adresse, meldet sie von jeder Liste des Workspaces ab und merkt sich den Widerspruch. Support-Antworten können sie weiter erreichen.
5. Antworten
Eine Antwort auf einen Broadcast eröffnet mit diesem Kontakt eine Unterhaltung im Posteingang des Broadcasts, markiert als „Reply to {Broadcast}“ und mit ihm verknüpft. Weitere Antworten setzen die Unterhaltung fort. Im Posteingang zeigt der Filter nach Typ mit „Replies to a broadcast“ sie an, und der Bericht des Broadcasts listet die ersten 50.
Automatische Antworten (Abwesenheit) werden nicht als Unterhaltungen gespeichert: Sie werden nur als
auto_replied gezählt, damit ein Versand den Posteingang nicht füllt. Mail von jemand anderem als dem
Empfänger, etwa eine Weiterleitung, eröffnet eine eigene Unterhaltung.
Mitglieder bekommen pro Broadcast eine Push-Benachrichtigung über seine neuen Antworten, alle 10 Minuten gebündelt, und keine E-Mail dazu.
6. Berichte
Die Broadcast-Seite zeigt ihren Bericht, sobald der Versand beginnt.
| Zahl | Bedeutung |
|---|---|
| Recipients | Die beim Start des Versands festgelegte Zielgruppe. |
| Sent | Mails, die der SMTP-Server angenommen hat. |
| Failed | Mails, die dauerhaft abgelehnt wurden, ohne eine schlechte Adresse zu nennen. |
| Bounced | Empfänger, deren Mail gebounct ist. |
| Reported as spam | Empfänger, die sich beschwert haben. |
| Unsubscribed | Empfänger, die sich über die Links dieses Broadcasts von einer Liste abgemeldet haben. |
| Replied | Empfänger, die geantwortet haben; jeder ist eine Unterhaltung. |
| Automatic replies | Abwesenheitsantworten, nur gezählt. |
| Clicked | Empfänger, die einen Link geöffnet haben; nur mit Klick-Tracking. |
| Skipped | Ausgelassen, weil gesperrt, widersprochen, vor ihrer Mail abgemeldet oder der Broadcast abgebrochen wurde. |
Raten sind Anteile der gesendeten Mails. Die Zeitleiste ist stündlich für die ersten 72 Stunden nach dem Start, danach täglich. Die Empfängerliste zeigt den Status jeder Person und bei Fehlern die SMTP-Antwort; filtern Sie nach Status, suchen Sie nach Adresse oder Name oder zeigen Sie nur die, die geantwortet haben. Die Empfängerliste wird 400 Tage nach dem Ende des Broadcasts gelöscht; die Zahlen bleiben.
Klick-Tracking
Standardmäßig aus. Eingeschaltet laufen die Links der Mail über /c/… auf der Link-Domain des Servers,
und der Bericht zeigt eindeutige Klicks pro Link. Nur Web-Links, die für alle Empfänger gleich sind (ohne
Merge-Feld), werden verfolgt; sie werden beim Planen gefunden. Klicks sind ungefähr: Eine HEAD-Anfrage
und drei Links einer Mail, die innerhalb von zwei Sekunden geöffnet werden, wie es Sicherheitsscanner
tun, werden nicht gezählt.
Es gibt kein Öffnungs-Tracking und kein Tracking-Pixel. Öffnungsraten sind unzuverlässig, weil Mail-Apps Bilder vorab laden, und ein Pixel wäre das Einzige in der Mail, das an Dritte meldet.
7. Keys und Assistenten
Versenden ist das Einzige, das API-Keys und OAuth-Tokens standardmäßig nicht bekommen:
- Der Scope
broadcasts:sendist nie impliziert; nennen Sie ihn beim Anlegen eines Keys ausdrücklich. - Auch dann kann ein Key oder Token Broadcasts nur planen und fortsetzen, solange ein Owner oder Admin
unter Settings → Workspace → Broadcasts „Keys and assistants may send broadcasts“ eingeschaltet hat.
Der Schalter ist standardmäßig aus, und das Umschalten erfordert eine Mitgliedssitzung. Sonst
antwortet das Planen mit
403 broadcasts_by_keys_disabled. - Entwürfe anlegen, ändern und testen braucht
broadcasts:write, Lesenbroadcasts:read. Pausieren und Abbrechen brauchenbroadcasts:sendund werden vom Schalter nicht zurückgehalten.
Freigabe auf gehosteten Servern
Ein Server, der die Anmeldung für alle öffnet (YUVA_SIGNUP=open), betreibt Broadcasts standardmäßig im
Modus approval, damit ein nachlässiger Workspace den Versandruf des ganzen Servers nicht beschädigen
kann. Wenn Sie Ihren eigenen Server nur mit Einladungen betreiben, gilt das nicht für Sie.
Im Modus approval kann ein über die Anmeldung angelegter Workspace erst Broadcasts planen, wenn der
Operator ihn freigibt. Entwürfe schreiben und Tests senden können Sie in der Zwischenzeit.
- Öffnen Sie Settings → Workspace → Broadcasts. Ein Owner sieht den Status: allowed, needs the operator’s approval, waiting for the operator oder suspended.
- Wählen Sie Ask for approval und tragen Sie Ihre Website ein, wer sendet und worum es in den Mails geht, und wie Ihre Abonnenten zugestimmt haben. Genau das liest der Operator.
- Der Status wechselt auf „Waiting for the operator“. Der Operator gibt frei oder lehnt mit einer Begründung ab, die Sie sehen; nach einer Ablehnung können Sie erneut anfragen. Bis dahin zeigt die Prüfung „Permission to send“ als blockierend.
Freigegebene Workspaces und jeder Workspace auf einem approval-Server wärmen sich auf: Sie dürfen am
ersten Tag an 500 Empfänger senden, und das Limit verdoppelt sich nach jedem sauberen Tag (mindestens 100
Mails gesendet, Bounces unter 3 %, Beschwerden unter 0,1 %). Ein schlechter Tag nimmt eine Verdopplung
zurück. Ein Workspace hat auf einem solchen Server höchstens 1.000 Broadcasts; löschen Sie alte.
Auf einem Server, auf dem Broadcasts off sind, funktionieren Listen und Formulare weiter, aber
Broadcasts anlegen, ändern und senden antwortet mit 403 broadcasts_disabled.
Zustellbarkeit
Mail eines neuen Absenders landet im Spam, wenn die Grundlagen nicht stimmen.
- SPF, DKIM und DMARC für die Domain der From-Adresse des Kanals, bestanden und ausgerichtet. Siehe
die DNS-Checkliste. Senden Sie einen Test an ein Postfach, das Sie
kontrollieren, und suchen Sie
spf=pass,dkim=passunddmarc=pass. - Gmail und Yahoo erwarten von Absendern großer Mengen Mail, dass sie sich mit SPF, DKIM und DMARC authentifizieren, Abmeldung mit einem Klick anbieten, die innerhalb von zwei Tagen umgesetzt wird, und Spam-Beschwerden unter 0,3 % halten (Ziel: unter 0,1 %). Yuva fügt jedem Broadcast die Abmelde-Header und den Fußzeilen-Link hinzu und pausiert bei 0,3 %. Die Regeln stehen in Googles Absenderrichtlinien und Yahoos Best Practices für Absender.
- Fangen Sie klein an. Senden Sie zuerst an ein paar hundert interessierte Abonnenten und steigern Sie sich.
- Schreiben Sie nur Personen an, die zugestimmt haben. Eine Liste aus Einwilligungsnachweisen ist Ihr bester Schutz.
- Nutzen Sie ein eigenes Konto für Broadcasts, wenn Sie möchten von einer Subdomain wie
news.example.com.
Yuva setzt auf jede Broadcast-Mail List-Unsubscribe mit One-Click (RFC 8058), List-Id, Feedback-ID
und X-Auto-Response-Suppress, damit Mail-Programme ihren eigenen Abmelde-Button zeigen.
Die API
Das Panel nutzt dieselbe API wie alles andere. Ein Broadcast aus einem Skript:
curl -X POST https://support.example.com/v1/broadcasts \
-H "Authorization: Bearer $YUVA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"inbox_id": "INBOX-ID",
"channel_id": "CHANNEL-ID",
"name": "October newsletter",
"subject": "What is new in October",
"design_id": "DESIGN-ID",
"audience": { "list_ids": ["LIST-ID"] }
}'
Danach GET /v1/broadcasts/{broadcastId}/review für die Checkliste, POST .../audience für die
Empfängerzahl und POST .../test für eine Testmail an ein Mitglied (ein API-Key nennt sie in
member_ids). Keys brauchen die Scopes unten. Planen Sie mit confirm_recipients auf der
Zahl, die Sie gesehen haben:
curl -X POST https://support.example.com/v1/broadcasts/BROADCAST-ID/schedule \
-H "Authorization: Bearer $YUVA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"send_at": "2026-10-20T08:00:00Z", "confirm_recipients": 1280}'
Referenz
Endpunkte
| Endpunkt | Zweck |
|---|---|
GET, POST /v1/broadcasts |
Entwürfe auflisten (inbox_id, state) und anlegen. |
GET, PATCH, DELETE /v1/broadcasts/{broadcastId} |
Lesen, einen Entwurf ändern, einen Entwurf oder beendeten Broadcast löschen. |
POST /v1/broadcasts/{broadcastId}/audience |
Die Zielgruppe zählen: Empfänger, wer warum ausgelassen wird, Merge-Felder, die leer wären. |
GET /v1/broadcasts/{broadcastId}/review |
Die Checkliste. |
POST /v1/broadcasts/{broadcastId}/test |
Einen Test an Mitglieder senden (member_ids, contact_id). |
POST /v1/broadcasts/{broadcastId}/schedule |
Planen oder sofort senden (send_at, confirm_recipients). |
POST /v1/broadcasts/{broadcastId}/unschedule |
Zurück zum Entwurf, vor dem Start. |
POST /v1/broadcasts/{broadcastId}/pause, resume, cancel |
Einen laufenden Broadcast steuern. |
GET /v1/broadcasts/{broadcastId}/deliveries |
Die Empfänger (state, q, replied). |
GET /v1/broadcasts/{broadcastId}/report |
Zahlen, Raten, Zeitleiste, Links und Antworten. |
GET /v1/conversations?broadcast_id= |
Unterhaltungen, die Antworten auf einen Broadcast geöffnet haben. |
PATCH /v1/workspace |
broadcasts_by_keys, der Schalter für Keys und Assistenten. |
POST /v1/workspace/broadcast-approval |
Den Operator um Freigabe bitten (Owner, Mitgliedssitzung). |
GET /v1/workspace liefert ein Objekt broadcasts mit dem mode des Servers sowie status,
daily_limit, sent_today und by_keys des Workspaces. email.broadcast_smtp und
email.broadcast_rate eines Kanals setzen Sie mit PATCH /v1/channels/{channelId}
(broadcast_smtp_remove: true entfernt das Konto). Die vollständigen Formen stehen im
API-Vertrag. Fehler, die Sie behandeln sollten: 409 review_failed (mit
den blockierenden items), 409 audience_changed, 409 not_draft, 409 invalid_state,
403 broadcasts_approval_required, 403 broadcasts_suspended, 403 broadcasts_by_keys_disabled,
403 broadcasts_disabled und 429 test_limit.
Scopes
| Scope | Bedeutung |
|---|---|
broadcasts:read |
Broadcasts, Zielgruppenzahlen, Prüfungen und Berichte lesen; die Empfängerliste braucht zusätzlich contacts:read. |
broadcasts:write |
Entwürfe anlegen, ändern und löschen; Tests senden. |
broadcasts:send |
Planen, Planung zurücknehmen, pausieren, fortsetzen und abbrechen. Nie impliziert. |
Keys, die vor diesen Scopes angelegt wurden, bekommen sie nicht.
Ereignisse
| Name | Bedeutung |
|---|---|
broadcast.updated |
Webhook- und Event-Feed-Ereignis: Der Broadcast hat den Status gewechselt. data.broadcast ist der Broadcast, data.previous_state der alte Status. |
broadcast.progress |
Nur Realtime (/v1/realtime): die Zahlen eines vorbereitenden oder sendenden Broadcasts, höchstens alle 5 Sekunden. Nicht gespeichert und nicht wiedergegeben; lesen Sie den Broadcast nach einem Neuaufbau der Verbindung erneut. |
Beide erreichen Aufrufer mit broadcasts:read, die den Posteingang des Broadcasts sehen können.
Antworten fügen der Zeitleiste der Unterhaltung einen Eintrag broadcast_reply hinzu.
Grenzen
| Grenze | Wert |
|---|---|
| Listen pro Broadcast | 10 |
| Bedingungen, Sprachen | 10, 20 |
| Name, Betreff, Vorschautext | 200, 300, 300 Zeichen |
| Vorausplanen | 90 Tage |
| Testversand | 20 pro Stunde und Workspace; je 1 bis 5 Mitglieder |
| Pause und Abbruch wirken innerhalb von | einem Stapel, höchstens 50 Mails |
| Tempo | 1 bis 100 Mails pro Sekunde und Kanal; standardmäßig 5 |
| Wiederholungen bei vorübergehendem Fehler | nach 5 Minuten, 30 Minuten, 2 Stunden, 6 Stunden |
| HTML | 90 KB Warnung, 102 KB blockiert, 500 KB abgelehnt |
| Broadcasts pro Workspace | 1.000 auf einem approval-Server |
| Empfängerliste aufbewahrt | 400 Tage nach dem Ende des Broadcasts |