SES-Sandbox: die Falle, die niemand liest

Amazon SES ist der günstigste zuverlässige Weg, Transaktionsmails zu verschicken, und deshalb landet jeder Anmeldeprozess, den ich baue, am Ende dort. SES startet aber jeden neuen Account in einem Zustand namens Sandbox, und die Sandbox ist so gebaut, dass deine eigenen Tests durchgehen, während echte Mails lautlos scheitern. Ich habe daran zweimal einen Tag verloren. Beim zweiten Mal habe ich es aufgeschrieben.

Was die Sandbox macht

Im Sandbox-Modus stellt SES nur an Adressen und Domains zu, die du in der Konsole verifiziert hast. Deine eigene Adresse verifizierst du natürlich zuerst, denn so testest du. Also testest du, die Mail kommt an, alles sieht gut aus. Dann meldet sich eine echte Person an, der Sendeaufruf gibt einen Fehler mit dem Text Email address is not verified zurück, und dein Code loggt ihn irgendwohin, wo niemand hinschaut, oder schluckt ihn ganz. Von außen sieht das Formular gesund aus. Der Nutzer bekommt nur nie seine Bestätigung.

Die Sandbox deckelt dich außerdem auf 200 Nachrichten pro 24 Stunden und eine Nachricht pro Sekunde. Beide Grenzen sind niedrig genug, um einen kleinen Launch zu stolpern, und hoch genug, dass ein Test sie nie berührt.

Wie du es merkst, bevor es weh tut

Verlass dich nicht auf den ersten fehlgeschlagenen Versand. Prüf den Kontostatus direkt, und zwar in der Region, aus der du wirklich sendest, denn die Sandbox gilt pro Region.

aws sesv2 get-account --region eu-central-1 \
  --query '{production: ProductionAccessEnabled, quota: SendQuota}'

Kommt bei production ein false zurück, bist du in der Sandbox, egal was dein Testpostfach sagt. Diese Zeile steht bei mir in der Vorab-Checkliste von allem, was Mail verschickt, direkt neben den DKIM- und SPF-Prüfungen. Sie kostet nichts und hat das Problem schon einmal abgefangen.

Die Konsole sagt dasselbe auf dem SES-Account-Dashboard, mit einem gelben Banner, und das ist genau die Sorte Banner, an der du vorbeiscrollst, während du gerade eine Domain verifizierst.

Rauskommen

Produktionszugang ist ein Antrag, kein Schalter. In der SES-Konsole gibt es den Knopf "Request production access"; er öffnet ein kurzes Formular, das fragt, was du verschickst, ungefähr wie viel, wie die Empfänger zugestimmt haben und wie du mit Bounces und Beschwerden umgehst. Antworte schlicht. "Transaktionsmails für eine Anmeldebestätigung, etwa 300 pro Tag, Double-Opt-in, Bounces und Beschwerden gehen an ein SNS-Topic, das die Adresse sperrt" ist eine vollständige Antwort. AWS antwortet meist innerhalb eines Werktags, manchmal in Stunden. Kommt eine Rückfrage, beantworte sie am selben Tag, sonst schläft der Fall ein.

Hab die Bounce-Behandlung fertig, bevor du fragst. Die schauen nach, und der einfachste Weg zu einer langsamen Freigabe ist zu sagen, du richtest das später ein.

Die zwei Dinge, die ich jetzt standardmäßig mache

Erstens: Die Kontoprüfung oben kommt in die Launch-Checkliste, in jeder Region, die der Dienst nutzt. Zweitens: Die Sendefunktion behandelt MessageRejected als harten Fehler, der mich anpingt, nicht als weichen, der nur geloggt wird. Eine Bestätigungsmail, die nicht ankommt, ist eine verlorene Anmeldung, und eine verlorene Anmeldung sollte laut sein.

Wenn du gerade etwas auf einem frischen AWS-Account live stellst, beantrage den Produktionszugang am ersten Tag, bevor du ihn brauchst. Es ist das Billigste auf der Liste und das, was am meisten kostet, wenn du es vergisst.