AWS SES Sandbox-Modus: Warum du nur an dich selbst senden kannst und wie du den Produktionszugang beantragst

Du hast SES eingerichtet, deine Absenderadresse verifiziert, einen Test-E-Mail an dich selbst gesendet — alles funktioniert. Dann versuchst du, eine echte Willkommens-E-Mail an einen neuen Kunden zu senden, und bekommst entweder einen Bounce oder eine Fehlermeldung. Das liegt nicht an deiner Konfiguration. Jedes neue AWS-Konto startet im SES Sandbox-Modus, einem absichtlich eingeschränkten Betriebszustand, aus dem man aktiv herausmuss.

TL;DR — SES Sandbox auf einen Blick

AspektSandbox-ModusProduktionsmodus
EmpfängerNur verifizierte E-Mail-Adressen/DomainsBeliebige Empfänger
Sendelimit200 E-Mails pro 24 Stunden, 1 E-Mail/SekundePer Support-Case erhöhbar
AktivierungAutomatisch bei KontoerstellungManueller Antrag über AWS Support
Bounce/Complaint-MonitoringEingeschränkt relevantKritisch — hohe Raten führen zu Sperrung

Pricing und aktuelle Limits immer in der offiziellen AWS-Dokumentation prüfen — diese Werte können sich ändern.

Wie der SES Sandbox-Modus funktioniert

AWS schützt die Reputation seiner E-Mail-Infrastruktur, indem neue Konten standardmäßig in einer isolierten Umgebung starten. Der Sandbox-Modus ist kein Bug und kein Versehen — er ist eine bewusste Schutzmaßnahme gegen Spam-Missbrauch über neu erstellte Konten.

Im Sandbox-Modus prüft SES bei jeder ausgehenden E-Mail, ob die Empfängeradresse in deinem Konto als verifizierte Identität hinterlegt ist. Ist sie das nicht, wird die Nachricht abgelehnt. Das erklärt, warum der Test an deine eigene, verifizierte Adresse funktioniert — aber nicht an Kundenadressen.

graph TD A["E-Mail senden"] --> B{"Absender-Identitaet verifiziert?"} B -- Nein --> C["Ablehnung: Unverified sender"] B -- Ja --> D{"Sandbox-Modus aktiv?"} D -- Nein --> G["E-Mail wird zugestellt"] D -- Ja --> E{"Empfaenger-Identitaet verifiziert?"} E -- Nein --> F["Ablehnung: Unverified recipient"] E -- Ja --> G
  1. Absender-Identität: SES prüft, ob die From-Adresse oder Domain verifiziert ist — das gilt in beiden Modi.
  2. Empfänger-Prüfung (Sandbox): Im Sandbox-Modus wird zusätzlich geprüft, ob die Zieladresse ebenfalls verifiziert ist. Ist sie es nicht, wird die E-Mail abgelehnt.
  3. Empfänger-Prüfung (Produktion): Im Produktionsmodus entfällt diese Einschränkung. SES sendet an beliebige Empfänger.
  4. Bounce/Complaint-Feedback: In beiden Modi werden Bounces und Beschwerden über SNS oder SES-Ereignisse zurückgemeldet. Im Produktionsmodus ist das Monitoring dieser Metriken operativ kritisch.
Der Sandbox-Modus verhält sich wie eine Staging-Umgebung, die AWS für dich betreibt — du kannst alles testen, aber der Traffic bleibt intern. Erst nach dem Produktions-Upgrade öffnet sich das Tor nach außen.

Schritt 1: Aktuellen SES-Status prüfen

Bevor du einen Support-Case öffnest, solltest du deinen aktuellen Sendestatus und die konfigurierten Identitäten kennen. Der Sandbox-Status ist region-spezifisch — ein Konto kann in us-east-1 bereits im Produktionsmodus sein, aber in eu-west-1 noch im Sandbox.

# Aktuellen Account-Sendestatus abrufen
aws sesv2 get-account \
  --region eu-west-1

Im JSON-Output ist das relevante Feld ProductionAccessEnabled. Steht es auf false, bist du im Sandbox-Modus.

# Alle verifizierten Identitäten in der Region auflisten
aws sesv2 list-email-identities \
  --region eu-west-1

Dieser Befehl zeigt dir, welche Adressen und Domains verifiziert sind. Im Sandbox-Modus sind das die einzigen gültigen Empfänger.

Schritt 2: Fehlende Empfänger-Identitäten für Tests verifizieren

Wenn du den Produktionszugang noch nicht beantragt hast, aber dringende Tests mit weiteren Adressen durchführen musst, kannst du diese temporär als verifizierte Identitäten hinzufügen. Das ist kein Workaround für den Produktionsbetrieb — aber es überbrückt die Zeit bis zur Freigabe.

# Eine Test-Empfängeradresse verifizieren (Sandbox-Workaround)
aws sesv2 create-email-identity \
  --email-identity testempfaenger@beispiel.de \
  --region eu-west-1

AWS sendet eine Bestätigungs-E-Mail an diese Adresse. Erst nach dem Klick auf den Bestätigungslink ist die Adresse als Empfänger nutzbar.

Schritt 2: Produktionszugang beantragen — der richtige Weg

Der Antrag läuft über AWS Support, nicht über die SES-Konsole direkt. Du öffnest einen Service-Limit-Increase-Case und wählst SES als Service. AWS bewertet den Antrag manuell — typischerweise innerhalb von 24 Stunden, aber ohne garantierte SLA.

Was AWS in diesem Case sehen will:

  • Wie baust du deine Empfängerliste auf? (Opt-in-Verfahren)
  • Wie gehst du mit Bounces und Beschwerden um?
  • Welches Sendevolumen erwartest du?
  • Welchen Use-Case hast du? (Transaktions-E-Mails, Newsletter, etc.)

Vage Antworten wie 'Ich sende Marketing-E-Mails' führen häufig zu Nachfragen oder Ablehnung. Konkrete Angaben zu Opt-in-Prozess und Bounce-Handling beschleunigen die Freigabe erheblich.

# Support-Case über die CLI erstellen
aws support create-case \
  --subject 'SES Production Access Request - eu-west-1' \
  --service-code 'ses' \
  --severity-code 'normal' \
  --category-code 'general-guidance' \
  --communication-body 'Wir beantragen den Produktionszugang fuer SES in eu-west-1. Use-Case: Transaktions-E-Mails (Bestellbestaetigung, Passwort-Reset) fuer registrierte Nutzer. Opt-in: Double-Opt-In bei Registrierung. Bounce-Handling: SNS-Topic mit Lambda-Verarbeitung, automatische Listenpflege. Erwartetes Volumen: ca. 5.000 E-Mails/Tag.' \
  --language 'de' \
  --region us-east-1

Hinweis: Die AWS Support API ist global und wird immer gegen us-east-1 aufgerufen, unabhängig davon, für welche SES-Region du den Antrag stellst. Gib die Zielregion explizit im Nachrichtentext an.

Schritt 3: Bounce- und Complaint-Handling einrichten — vor der Freigabe, nicht danach

Das ist der Punkt, an dem viele Entwickler einen Fehler machen. Sie beantragen den Produktionszugang, bekommen ihn, fangen an zu senden — und richten das Bounce-Monitoring erst ein, wenn AWS ihnen eine Warnung schickt. Zu diesem Zeitpunkt ist die Reputation des Sending-Domains bereits beschädigt.

AWS überwacht Bounce- und Complaint-Raten kontinuierlich. Überschreiten sie dokumentierte Schwellenwerte, kann AWS das Sendekonto pausieren. Die genauen Schwellenwerte sind in der offiziellen SES-Dokumentation unter 'Email sending best practices' beschrieben.

graph LR A["SES sendet E-Mail"] --> B["Empfaenger-Mailserver"] B --> C{"Zustellung erfolgreich?"} C -- Hard Bounce --> D["Bounce-Feedback an SES"] C -- Spam-Markierung --> E["Complaint-Feedback an SES"] C -- Erfolg --> F["Zugestellt"] D --> G["SNS Topic: ses-bounce"] E --> H["SNS Topic: ses-complaint"] G --> I["Lambda: Adresse aus Liste entfernen"] H --> I D --> J["AWS Bounce-Rate Monitor"] E --> K["AWS Complaint-Rate Monitor"] J --> L{"Schwellenwert ueberschritten?"} K --> L L -- Ja --> M["Warnung oder Kontosperrung"]
  1. SES sendet E-Mail: Die Nachricht verlässt SES in Richtung Empfänger-Mailserver.
  2. Bounce oder Complaint: Der Empfänger-Mailserver meldet einen Hard Bounce (Adresse existiert nicht) oder der Empfänger markiert die E-Mail als Spam.
  3. Feedback an SES: SES empfängt das Feedback und leitet es an ein konfiguriertes SNS-Topic weiter.
  4. Verarbeitung: Eine Lambda-Funktion oder ein anderer Subscriber verarbeitet das Ereignis und entfernt die Adresse aus der Senderliste.
  5. AWS-Monitoring: AWS berechnet kontinuierlich die Bounce- und Complaint-Rate. Bei Überschreitung der Schwellenwerte erfolgt eine Warnung oder Kontosperrung.
# SNS-Topic fuer Bounce-Benachrichtigungen erstellen
aws sns create-topic \
  --name ses-bounce-notifications \
  --region eu-west-1
# Bounce-Benachrichtigungen fuer eine verifizierte Identitaet konfigurieren
aws sesv2 put-email-identity-feedback-attributes \
  --email-identity deine-domain.de \
  --email-forwarding-enabled false \
  --region eu-west-1
# SNS-Benachrichtigungstyp fuer eine Identitaet setzen
# Hinweis: Dieser Befehl nutzt die SES v1 API (ses, nicht sesv2)
aws ses set-identity-notification-topic \
  --identity deine-domain.de \
  --notification-type Bounce \
  --sns-topic arn:aws:sns:eu-west-1:123456789012:ses-bounce-notifications \
  --region eu-west-1

Wiederhole den letzten Befehl mit --notification-type Complaint für Spam-Beschwerden.

Diagnose: Warum der Produktionszugang abgelehnt wurde

Symptom: Du erhältst eine E-Mail von AWS Support mit dem Hinweis, dass dein Antrag nicht genehmigt wurde, ohne klare Begründung.

Erste Annahme: Das Konto ist zu neu oder das Volumen zu gering. Tatsächliche Ursache in den meisten Fällen: Der Antrag enthält keine konkreten Angaben zum Opt-in-Verfahren oder zum Bounce-Handling. AWS-Reviewer sehen täglich Anträge — generische Beschreibungen signalisieren, dass der Antragsteller die Anforderungen nicht verinnerlicht hat.

Korrektur: Antrag zurückziehen und neu stellen mit expliziten Angaben:

  • Wie genau wird die Einwilligung der Empfänger eingeholt? (z.B. 'Double-Opt-In über Bestätigungs-E-Mail beim Registrierungsprozess')
  • Welche technischen Maßnahmen verhindern, dass Bounced-Adressen erneut kontaktiert werden?
  • Gibt es eine Abmelde-Möglichkeit in jeder E-Mail?

Ein Antrag, der diese drei Punkte konkret beantwortet, wird in der Praxis deutlich schneller genehmigt.

IAM-Berechtigungen für SES-Operationen

Wenn du SES programmatisch nutzt — über die CLI oder aus einer Anwendung heraus — benötigst du eine IAM-Policy mit den entsprechenden Berechtigungen. Least Privilege bedeutet hier: nur die tatsächlich benötigten Aktionen, nur für die relevanten Identitäten.

🔽 IAM-Policy für SES-Sendebetrieb (klicken zum Aufklappen) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SESSendEmail",
      "Effect": "Allow",
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource": "arn:aws:ses:eu-west-1:123456789012:identity/deine-domain.de"
    },
    {
      "Sid": "SESReadAccount",
      "Effect": "Allow",
      "Action": [
        "sesv2:GetAccount",
        "sesv2:ListEmailIdentities"
      ],
      "Resource": "*"
    }
  ]
}

Hinweis: sesv2:GetAccount und sesv2:ListEmailIdentities erfordern Resource: "*", da sie keine ressourcenspezifische ARN-Einschränkung unterstützen. Verifiziere dies im AWS Service Authorization Reference, bevor du die Policy in Produktion einsetzt.

Wrap-up: SES Sandbox verlassen und stabil betreiben

Der SES Sandbox-Modus ist kein technisches Problem — er ist ein Prozess. Den Produktionszugang beantragen, Bounce-Handling einrichten und Sending-Identitäten korrekt konfigurieren sind drei voneinander unabhängige Schritte, die alle vor dem ersten produktiven Versand abgeschlossen sein sollten.

Nächste Schritte:

  • Sandbox-Status prüfen: aws sesv2 get-account --region <deine-region>
  • Support-Case mit konkreten Angaben zu Opt-in und Bounce-Handling stellen
  • SNS-Topics für Bounce und Complaint konfigurieren — vor der Freigabe
  • Offizielle Dokumentation: SES Production Access beantragen

Glossar

BegriffBedeutung
Sandbox-ModusStandardzustand neuer SES-Konten. Sendungen nur an verifizierte Empfänger, begrenzte Senderate.
Verifizierte IdentitätEine E-Mail-Adresse oder Domain, deren Eigentümerschaft gegenüber AWS bestätigt wurde.
Hard BouncePermanente Zustellfehler, z.B. weil die Empfängeradresse nicht existiert.
Complaint RateAnteil der Empfänger, die eine E-Mail als Spam markieren. Hohe Raten gefährden den Sendestatus.
Double-Opt-InZweistufiges Einwilligungsverfahren: Anmeldung + Bestätigung per E-Mail. Von AWS als Best Practice empfohlen.

Related Posts

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

LSI vs. GSI in DynamoDB: Den richtigen Sekundärindex wählen

Man hat eine DynamoDB-Tabelle aufgebaut, die Abfragen über den Primärschlüssel laufen schnell — und dann kommt die Anforderung, dieselben Daten nach einem anderen Attribut zu filtern. Genau hier beginnt die Entscheidung zwischen einem Local Secondary Index (LSI) und einem Global Secondary Index (GSI) , und wer sie falsch trifft, zahlt entweder mit Flexibilitätsverlust oder mit unerwartetem Durchsatz-Overhead. TL;DR: LSI vs. GSI auf einen Blick Merkmal LSI GSI Erstellungszeitpunkt Nur bei Tabellenerstellung Jederzeit Partition Key Identisch mit Basistabelle Beliebiges Attribut Sort Key Anderes Attribut als Basistabelle Beliebiges Attribut (optional) Konsistenzmodell Strongly consistent möglich Nur eventually consistent Kapazität Teilt RCU/WCU mit Basistabelle Eigene RCU/WCU (Provisioned) oder On-Demand Datenmenge pro Partition Key Max. 10 GB Unbegrenzt Max. Anzahl pro Tabelle 5 20 (Standard...
Mehr anzeigen

ElastiCache Redis einsetzen: Wann ein Caching-Layer deine RDS-Datenbank entlastet

Du hast die Abfragen optimiert, Indizes gesetzt, Read Replicas hinzugefügt — und der RDS-Endpunkt ist immer noch der Engpass. Das passiert fast immer dann, wenn dieselben Zeilen hunderte Male pro Sekunde gelesen werden und jede Anfrage trotzdem den vollen Datenbankpfad durchläuft. Ein ElastiCache Redis-Layer löst genau dieses Problem, indem er häufig gelesene Ergebnisse im Arbeitsspeicher hält und RDS damit aus der kritischen Anfragekette herausnimmt. TL;DR: ElastiCache Redis als Caching-Layer vor RDS Aspekt Ohne Cache Mit ElastiCache Redis Lesepfad App → RDS (Disk/Buffer Pool) App → Redis (RAM) → RDS nur bei Cache Miss Latenz (typisch) Einige Millisekunden bis Dutzende ms Unter 1 ms bei Cache Hit RDS-Last bei hohem Traffic Linear steigend Deutlich reduziert bei hoher Hit-Rate Datenkonsistenz Immer aktuell Abhängig von TTL und Invalidierungsstrategie Operativer Aufwand Gering Mittel (Cache-Strategie,...
Mehr anzeigen

EBS vs. EFS für mehrere EC2-Instanzen: Gemeinsame Ordner richtig teilen

Du hast fünf EC2-Instanzen und willst, dass alle auf denselben Ordner zugreifen — ein klassisches Setup, das auf den ersten Blick trivial wirkt, aber schnell zur Falle wird, wenn man EBS und EFS verwechselt. EBS verhält sich wie eine externe Festplatte: einmal angesteckt, einmal gemountet. EFS dagegen ist ein Netzwerk-Dateisystem, das genau für diesen Anwendungsfall gebaut wurde. TL;DR: EBS vs. EFS auf einen Blick Kriterium EBS EFS Gleichzeitiger Zugriff mehrerer Instanzen Nur mit EBS Multi-Attach (eingeschränkt) Ja, nativ unterstützt Dateisystem-Typ Block Storage (ext4, xfs, etc.) NFS v4.1 / v4.2 Regionsübergreifend Nein (AZ-gebunden) Ja (regionaler Dienst) Typischer Anwendungsfall Einzelne Instanz, Datenbanken Shared Workloads, CMS, ML-Training Kapazitätsplanung ...
Mehr anzeigen