# Transaktions-E-Mails: was sie sind und wie du sie versendest

Kanonische URL: https://brew.new/de/blog/transactional-emails
Autor: Thomas Park
Veröffentlicht: 2026-08-22
Aktualisiert: 2026-09-28

Transaktions-E-Mails informieren über eine Transaktion oder eine bestehende Kundenbeziehung: ein Beleg, ein angeforderter Passwort-Reset, eine Versandbenachrichtigung oder ein Sicherheitshinweis zum Konto. Ihr Zweck ist ein anderer als der einer Kampagne, die jemanden zum Kaufen oder Wiederkommen bewegen soll.

Die Unterscheidung hängt von der Nachricht ab. Wenn du eine E-Mail in einem Versandtool als „transaktional“ kennzeichnest, entscheidet das nicht über ihren rechtlichen Status.

## Wende den Hauptzweck-Test an

Der [CAN-SPAM-Leitfaden der FTC](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) beschreibt eng gefasste Kategorien von Transaktions- und Beziehungsnachrichten. Bei gemischten kommerziellen und transaktionalen Inhalten berücksichtigt er, was ein verständiger Empfänger der Betreffzeile entnehmen würde und wo die transaktionalen Informationen stehen.

Eine werbliche Betreffzeile kann eine gemischte Nachricht zur kommerziellen machen. Ein kurzer werblicher Footer tut das nicht automatisch: Die FTC nennt als Beispiel einen Kontoauszug, der überwiegend transaktional bleibt. Entscheidend sind die [Vorschrift](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316/section-316.3) und die konkrete Nachricht.

Stell die wesentlichen Informationen deutlich heraus. Wenn Werbung von einem Beleg oder einem Sicherheitshinweis ablenkt, ist eine separate Marketing-E-Mail redaktionell meist die klarere Wahl. Das sind Vorgaben aus den USA; prüfe die Anforderungen, die für deine Empfänger und dein Unternehmen gelten. Quellen geprüft am 28. September 2026.

## Einige typische Fälle

| Nachricht | Üblicher Zweck | Was du prüfen solltest |
| --- | --- | --- |
| Bestellbeleg oder Hinweis zur Rückerstattung | Transaktional | Korrekte Bestellangaben und der richtige Empfänger |
| Angeforderter Passwort-Reset | Kontosicherheit | Eine echte Anfrage, ein gültiger Link und kein ablenkendes Angebot |
| Versandbenachrichtigung | Transaktional | Informationen zur bestehenden Bestellung |
| Warenkorb-Erinnerung | Marketing | Einwilligung, aktueller Stand des Warenkorbs und Verhalten bei Abmeldung |
| Upgrade-Angebot zum Ende der Testphase | Marketing | Das tatsächliche Angebot und ob der Empfänger die Bedingungen noch erfüllt |

Ein Hinweis zum Kontostatus und ein Upgrade-Angebot können dieselbe Testphase betreffen und trotzdem unterschiedlichen Zwecken dienen. Prüfe, wozu die E-Mail den Leser auffordert.

## Die Regeln der Provider gelten trotzdem

[Die Richtlinien von Gmail](https://support.google.com/mail/answer/81126) unterscheiden bei den Anforderungen an die One-Click-Abmeldung zwischen Marketing- und abonnierten Nachrichten auf der einen und Transaktionsnachrichten auf der anderen Seite. Authentifizierung und Reputation zählen für beide.

[Yahoo](https://senders.yahooinc.com/best-practices/) empfiehlt, Massen-Marketing und Transaktions-Traffic nach IP und, wo sinnvoll, nach Domain zu trennen. Folge dem Setup deines Anbieters, statt anzunehmen, dass eine neue Subdomain allein schon eine unabhängige Reputation schafft.

Für Marketing-E-Mails definiert [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) den One-Click-Mechanismus über Header. Ein Abmeldelink im Footer und eine Abmeldung über Header erfüllen unterschiedliche Aufgaben. Teste das Verhalten an der empfangenen Nachricht.

## Ein Transaktions-Event über Brew versenden

Brew nutzt für diesen Workflow eine veröffentlichte Automatisierung und ihren Trigger. Richte eine verifizierte Versanddomain mit dem passenden Versandzweck ein, lege die Payload des Triggers fest und erstelle einen E-Mail-Schritt, der diese Domain nutzt. Die Domain-Einstellung steuert, wie Brew versendet; werbliche Inhalte macht sie rechtlich nicht zu transaktionalen.

Sobald du die Automatisierung getestet und veröffentlicht hast, löst dein Backend den Trigger aus. Dieses Beispiel geht davon aus, dass der Trigger `order_id` und `ship_date` deklariert:

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_ORDER_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1234-shipped" \
  -d '{"payload":{"email":"ada@example.com","order_id":"1234","ship_date":"Tuesday"}}'
```

Verwende die tatsächliche ID des Triggers und einen stabilen Idempotency-Key für das Event. Die E-Mail kann ein deklariertes Payload-Feld mit einer Syntax wie `{{ trigger.order_id }}` lesen. Sieh in der [Dokumentation zu Merge-Tags](https://docs.brew.new/create-emails/merge-tags) nach und teste fehlende Werte.

Prüfe die Ausführung und die empfangene E-Mail. Teste das Verhalten bei Wiederholungen und stell sicher, dass Abmeldungen vom Marketing entsprechend dem Versandzweck behandelt werden. Andere Schutzmechanismen, darunter Sperrlisten bei der Zustellung, gelten weiterhin; eine transaktionale Einstellung ist kein Versprechen, an jede Adresse zuzustellen.

Der [Leitfaden zur E-Mail-Automatisierung](/de/blog/email-marketing-automation-guide) behandelt das Veröffentlichen und die Statusprüfungen. Wenn ein Assistent die Vorlage verfasst, gilt dieselbe [Versandprüfung](/de/blog/agent-email-deliverability).