SES nimmt meinen Versand an und meldet Erfolg, aber die E-Mail geht nie wirklich raus
Die SES-API meldet sauber Erfolg, die Nachricht kommt trotzdem nie an und taucht später als Permanent bounce mit dem Subtyp Suppressed auf. Die Adresse stand wegen eines früheren Hard Bounce (deines eigenen oder des Hard Bounce eines anderen SES-Kunden) auf einer Suppression List, SES verwirft sie also still, statt eine Zustellung zu versuchen, selbst bei einem gültigen, aktiven Postfach.
Die Lösung
Bestätige die Ursache: Ein Permanent bounce mit bounceSubType Suppressed nach einem sauberen Erfolg der API heißt, dass die Adresse unterdrückt wurde. Prüf deine Liste auf Kontoebene mit GetSuppressedDestination (oder ListSuppressedDestinations, oder auf der Seite Suppression list unter Configuration), und wenn dort eine bekanntermaßen gute Adresse steht, entferne sie mit DeleteSuppressedDestination. Vielleicht steht sie stattdessen auf der globalen Liste von SES, die du weder abfragen noch bearbeiten kannst; diese Einträge laufen innerhalb von bis zu 14 Tagen von selbst ab. Da deine Liste auf Kontoebene der globalen vorgeht, stell sicher, dass die Adresse nicht auf deiner Kontoliste steht, und sende erneut. Schalte die Suppression aber nicht pauschal ab und deaktiviere auch nicht die Suppression bei Beschwerden, denn wer sich beschwert hat und trotzdem wieder Post bekommt, schadet deiner Reputation schneller als Bounces.
Ein schlechter Marketing-Versand hat unser Konto pausiert, jetzt sind auch Passwort-Resets und Belege betroffen
SES verfolgt die Reputation aus Bounces und Beschwerden auf Ebene des gesamten Kontos. Eine einzige Marketing-Kampagne von schlechter Qualität, die die Beschwerden hochtreibt, kann das Konto also auf Under review oder Paused setzen. Damit steht auch transaktionale Post still, also Passwort-Resets, Belege und 2FA, die über dasselbe Konto laufen.
Die Lösung
Isoliere die Reputation, nicht nur die IP. Getrennte dedizierte IP-Pools innerhalb eines Kontos schützen dich nicht, denn Under review und Paused werden von den kontoweiten Bounce- und Beschwerderaten ausgelöst, ein Marketing-Ausschlag pausiert also weiterhin die transaktionale Post im selben Konto. Um den Auslöser wirklich zu isolieren, nutze Tenant Management (GA seit August 2025): Es verfolgt die Reputation pro Tenant und kann automatisch nur den auffälligen Tenant pausieren. Alternativ trennst du Marketing und Transaktional in zwei AWS-Konten. Gib jedem Stream ein eigenes Configuration Set mit Event Destinations für Bounces und Beschwerden, damit du siehst, welcher Stream abrutscht, bevor AWS überhaupt etwas pausiert.
Gmail zeigt neben unserem Namen weiterhin „via amazonses.com“, obwohl wir den eigenen MAIL FROM eingerichtet haben
Absender erwarten, dass eine eigene MAIL-FROM-Domain das Label „via amazonses.com“ bei Gmail verschwinden lässt, aber es bleibt. Gmail blendet diese Zeile aus, wenn die d=-Domain aus DKIM zur From-Domain passt, nicht anhand des Return-Path. Eine eigene MAIL-FROM-Domain allein entfernt das Label also nicht, und seit Februar 2024 signalisiert das sichtbare „via“ zusätzlich, dass deine From-Domain nicht DKIM-ausgerichtet ist.
Die Lösung
Aktiviere Easy DKIM auf der Domain-Identität und veröffentliche die 3 CNAME-Einträge, damit die Nachricht eine Signatur mit d=yourbrand.com trägt, die zum From-Header passt; dann lässt Gmail das Label „via amazonses.com“ fallen. Eine eigene MAIL-FROM-Domain repariert das SPF-Alignment und ändert die Zeile „mailed-by“, entfernt das „via“ aber nicht von sich aus. In der Detailansicht von Gmail spiegelt „mailed-by“ den Return-Path und zeigt amazonses.com, bis du zusätzlich einen eigenen MAIL FROM wie mail.yourbrand.com setzt, während „signed-by“ yourbrand.com zeigen sollte, sobald Easy DKIM ausgerichtet ist. Behandle die „via“-Zeile als Symptom für fehlendes DKIM-Alignment: Das Alignment zu reparieren schützt die Platzierung, und dass das Label verschwindet, bestätigt es.
Unsere Post kommt überall an, nur nicht bei Firmenempfängern hinter Proofpoint und Mimecast, die uns bouncen
Im Shared-IP-Pool von SES hängt deine Reputation an allen anderen Tenants auf derselben IP, und Enterprise-Gateways wie Proofpoint und Mimecast drosseln oder blockieren den ganzen Shared-Bereich von SES schnell, sobald ein Tenant auffällt oder der Bereich auf einer Blacklist landet. Bei Gmail und Yahoo läuft die Zustellung sauber, bei Firmendomains gibt es Bounces oder Post im Spam-Ordner, und AWS lässt Shared IPs nach eigenem Zeitplan wieder von den Listen nehmen.
Die Lösung
Bei B2B-Listen oder viel Firmenpost wechselst du besser auf dedizierte SES-IPs, damit deine Reputation dir allein gehört. Managed Dedicated IPs wärmen sich automatisch pro ISP auf, aber auch eine frische IP muss erst Reputation aufbauen: Gib ihr ein paar Wochen mit gleichmäßigem Versand an aktive Empfänger, bevor Firmen-Gateways ihr vertrauen. Arbeite parallel direkt mit den Gateways: Bei Proofpoint beantragst du für die konkrete IP (aus dem Bounce „554 Blocked“) eine Prüfung oder ein Delisting unter ipcheck.proofpoint.com; bei Mimecast bittest du den Empfänger oder seine Administration, die SES-IP-Bereiche deiner Region als Permitted Senders zu hinterlegen, denn nur sie können dich freischalten. Prüf vorher, dass SPF, DKIM und DMARC alle ausgerichtet sind, denn diese Gateways gewichten Authentifizierung stark und filtern einen nicht ausgerichteten Absender auf jeder IP weiter.
Die SES-Zustellbarkeit brach auf einer Shared IP neben Dating- und Erotikseiten ein, trotz makelloser Werte
Ein Absender mit 70.000 Newslettern pro Tag sah die Reputation seiner Shared IP in Google Postmaster Tools abstürzen, und das bei einer Beschwerderate von höchstens 0,05 %, Bounces unter 0,5 %, bestandenem SPF, DKIM und DMARC und aktivierter Ein-Klick-Abmeldung. Ein Blick auf die Nachbarn auf denselben SES-IPs zeigte überwiegend Dating- und Pornodomains, die die Reputation des Pools nach unten zogen.
Die Lösung
Wenn deine eigenen Versandwerte sauber sind, die Reputation der Shared IP aber fällt, liegt es an den Nachbarn und nicht an deiner Liste. Wechsle auf eine dedizierte IP, damit kein anderer Absender deine Reputation mit nach unten zieht, und nimm die Managed Dedicated IPs von SES, damit AWS das rund 45-tägige Warm-up übernimmt und das Volumen schrittweise auf die neue IP verschiebt, statt dass du von Hand hochfährst. Eine Managed Dedicated IP kostet typischerweise rund 50 % mehr als eine Shared IP und behebt den Einbruch bei Reputation und Zustellbarkeit. Reserviere Shared IPs für transaktionale Post mit geringem Volumen und lass das Massen-Marketing auf der dedizierten IP laufen.