So landen deine Amazon-SES-E-Mails nicht mehr im Spam

Bei Amazon SES liegt es fast immer an deiner Konfiguration und nicht an deinem Text, wenn E-Mails im Spam landen. SES ist eine reine Versand-API und bringt deshalb Voreinstellungen mit, die dir schaden: Es setzt zusätzlich eine zweite DKIM-Signatur mit amazonses.com, nutzt eine Subdomain von amazonses.com als MAIL-FROM-Domain (SPF besteht damit zwar, richtet sich für DMARC aber nie auf deine From-Domain aus) und überlässt dir Bounces und Beschwerden vollständig. Dieser Guide behandelt Easy DKIM gegenüber BYODKIM, die eigene MAIL-FROM-Domain, die Sandbox und den Produktionszugang, geteilte gegenüber dedizierten IPs, Configuration Sets und die Schwellenwerte für Bounces und Beschwerden, die dein ganzes Konto pausieren können. Trag danach die Test-Adresse von Unspam als Empfänger ein und schick eine echte SES-Nachricht: So siehst du deinen Score, SPF, DKIM, DMARC und das Inbox Placement je Anbieter.

Warum Amazon SES-E-Mails im Spam landen.

01

Dein MAIL FROM ist immer noch eine Subdomain von amazonses.com, deshalb richtet sich SPF nie aus

Solange du keine eigene MAIL-FROM-Domain konfigurierst, setzt SES den Return-Path (den Envelope-Absender) auf eine Subdomain von amazonses.com, die je nach Region variiert. SPF besteht, weil gegen amazonses.com geprüft wird, aber die Domain im From-Header stimmt nicht überein, also scheitert das SPF-Alignment für DMARC. Wenn du dich für DMARC auf SPF verlässt und nie ein DKIM-Alignment einrichtest, scheitert jede Nachricht an DMARC. Korrigiere das unter Configuration > Identities > deine Domain > Custom MAIL FROM domain, trag eine Subdomain wie mail.yourbrand.com ein und veröffentliche den einen MX-Eintrag und den einen SPF-TXT-Eintrag, die SES dir vorgibt.

02

DKIM signiert mit amazonses.com, weil Easy DKIM für die Domain nie aktiviert wurde

SES fügt für die Feedback Loops immer seine eigene DKIM-Signatur mit d=amazonses.com hinzu, und viele Absender halten das für echte Authentifizierung. Bis du Easy DKIM (oder BYODKIM) auf deiner Domain-Identität aktivierst, trägt keine Signatur deine eigene d=-Domain, DKIM kann sich also nicht auf deine From-Domain ausrichten. Aktiviere Easy DKIM unter Configuration > Identities > deine Domain > Authentication > DomainKeys Identified Mail (DKIM) > Edit, wähle RSA 2048-bit und veröffentliche die 3 CNAME-Einträge, die SES erzeugt (Name token._domainkey.yourbrand.com, Ziel token.dkim.amazonses.com). Die Signatur mit d=amazonses.com bleibt bestehen und darfst du ignorieren.

03

Du hast eine einzelne E-Mail-Adresse verifiziert, damit wird das DKIM der Domain umgangen

Wenn du Easy DKIM für die Domain example.com einrichtest, aber mary@example.com separat als eigene Identität verifizierst, geht Post von mary@example.com unsigniert raus, weil einzeln verifizierte Adressen ihre eigenen Einstellungen nutzen und nicht die der Domain. Das Ergebnis: Ein Absender authentifiziert sich, ein zweiter auf derselben Domain nicht. Lösch die eigenständige Adress-Identität unter Configuration > Identities, damit die gesamte Post das DKIM der Domain erbt, oder richte DKIM auch für diese Adresse ein.

04

Du steckst noch in der SES-Sandbox oder hast sie gerade mit Vollgas verlassen

Neue SES-Konten sind pro Region in der Sandbox: Du kannst nur an verifizierte Adressen oder an den Mailbox Simulator senden, begrenzt auf 200 Nachrichten pro 24 Stunden und 1 Nachricht pro Sekunde. Beantrage den Produktionszugang im Account dashboard über Get set up > Request production access (wähle Marketing oder Transactional). Nach der Freigabe solltest du mit einer brandneuen Domain und IP-Reputation nicht sofort auf volles Volumen gehen. Steigere über 2 bis 4 Wochen schrittweise und fang bei deinen aktivsten Empfängern an, damit die Mailbox-Provider Vertrauen zu deinem Versand aufbauen.

05

Wenig Volumen auf einer dedizierten Standard-IP, die du nie aufgewärmt hast

SES bietet Shared IPs (die Voreinstellung), dedizierte Standard-IPs, die du selbst aufwärmst und verwaltest, und Managed Dedicated IPs, die SES automatisch pro ISP aufwärmt und mit deinem Volumen skaliert. Eine dedizierte Standard-IP ohne Warm-up und mit niedrigem, unregelmäßigem Volumen schneidet schlechter ab als der gesunde Shared Pool, weil ISPs von ihr kaum genug Post sehen, um überhaupt eine Reputation aufzubauen. Wenn dein Versand gering oder sprunghaft ist, bleib bei den Shared IPs oder wähle Dedicated IPs (managed); eine dedizierte Standard-IP lohnt sich nur bei hohem, gleichmäßigem Volumen, das du auch von Hand aufwärmen willst.

06

Bounces oder Beschwerden haben die SES-Schwelle überschritten, dein Konto steht auf Under review oder Paused

SES setzt die Absender-Reputation auf Kontoebene durch. Eine Bounce-Rate ab 5 % (Hard Bounces an nicht verifizierte Domains) stellt dein Konto unter Review, ab 10 % kann der Versand pausiert werden; eine Beschwerderate ab 0,1 % löst die Review aus, ab 0,5 % kann sie den Versand stoppen. Gemessen wird über ein repräsentatives Volumen, nicht über ein festes Zeitfenster, und das Account dashboard zeigt Healthy, Under review oder Paused. Ohne ein Configuration Set, das Bounce- und Beschwerde-Events veröffentlicht, siehst du den Ärger nicht kommen. Nimm Hard Bounces und Beschwerdeführer sofort aus dem Versand und halte die Bounces unter 2 %.

So authentifiziert Amazon SES deine E-Mails.

SES ist eine reine Versandplattform, die Authentifizierung liegt also komplett bei dir, und zwei Voreinstellungen brechen DMARC im Stillen: die MAIL-FROM-Domain auf amazonses.com und die DKIM-Signatur mit d=amazonses.com. Die zwei Einstellungen, auf die es ankommt, sind Easy DKIM auf deiner Domain-Identität und eine eigene MAIL-FROM-Domain, beide unter Configuration > Identities.

Eintrag Standard das Problem die Lösung
DKIM SES fügt für die Feedback Loops immer eine Signatur mit d=amazonses.com hinzu, signiert aber erst dann mit deiner eigenen Domain, wenn du Easy DKIM oder BYODKIM auf der Domain-Identität aktivierst. Mit nur der amazonses.com-Signatur hat DKIM nichts, was auf deine From-Domain ausgerichtet ist. DMARC fehlt damit der ausgerichtete Identifier zum Bestehen, erst recht, sobald du dich auf DKIM statt auf SPF stützt. Configuration > Identities > deine Domain > Authentication > DKIM > Edit > Easy DKIM, wähle RSA 2048-bit, aktiviere es und veröffentliche die 3 CNAME-Einträge (token._domainkey.yourbrand.com, Ziel token.dkim.amazonses.com). Nimm stattdessen BYODKIM, wenn du den Schlüssel selbst kontrollieren musst: Dafür braucht es einen TXT-Eintrag mit deinem eigenen öffentlichen RSA-Schlüssel mit 1024 oder 2048 Bit.
SPF Der MAIL FROM (Return-Path) ist eine regionsspezifische Subdomain von amazonses.com. SPF besteht damit zwar, aber gegen amazonses.com und nicht gegen deine From-Domain. SPF besteht ohne Alignment, DMARC sieht also ein SPF-Pass, das nicht zählt. Genau deshalb zeigen Reports bei SES-Standardversand SPF pass, aber SPF alignment fail. Richte einen eigenen MAIL FROM ein unter Configuration > Identities > deine Domain > Custom MAIL FROM domain (zum Beispiel mail.yourbrand.com). Veröffentliche genau einen MX-Eintrag auf feedback-smtp.<region>.amazonses.com mit Priorität 10 und einen SPF-TXT-Eintrag v=spf1 include:amazonses.com ~all. Wähle bei MX-Fehler Reject message oder Use default, und rechne damit, dass SES bis zu 72 Stunden braucht, um den MX zu erkennen.
DMARC SES versendet auch völlig ohne DMARC-Eintrag auf deiner Domain, und viele SES-Absender veröffentlichen nie einen. Ohne ausgerichtetes DKIM oder einen ausgerichteten eigenen MAIL FROM ist kein Identifier ausgerichtet. Eine DMARC-Policy mit quarantine oder reject schickt deine eigene SES-Post damit in den Spam-Ordner, während Gmail und Yahoo bei Domains mit Massenversand inzwischen mindestens p=none erwarten. Veröffentliche v=DMARC1; p=none; rua=mailto:you@yourbrand.com auf _dmarc.yourbrand.com, prüfe in den Reports, dass Easy DKIM und der eigene MAIL FROM ausgerichtet sind, und zieh dann auf quarantine oder reject an. Der Advisor des SES Virtual Deliverability Manager markiert ein fehlendes oder falsch ausgerichtetes DMARC-Setup.
MAIL FROM (custom) Standard ist eine Subdomain von amazonses.com; der Status des eigenen MAIL FROM steht auf Pending, bis SES deinen MX erkennt, danach auf Success. Fehlt der MX, gibt es mehrere Einträge oder scheitert die Erkennung innerhalb von 72 Stunden, springt der Status auf Failed und SES fällt auf amazonses.com zurück (oder weist Post ab), das SPF-Alignment kippt also unbemerkt zurück. Veröffentliche genau einen MX-Eintrag (mehrere MX-Einträge lassen den eigenen MAIL FROM scheitern) und den SPF-TXT-Eintrag, und beobachte dann unter Configuration > Identities, bis der Status Success erreicht. Diese Subdomain verschafft dir das SPF-Alignment für DMARC.

Wenn du diese Einträge aktualisiert hast, prüfe mit den kostenlosen Tools von Unspam, ob alles passt: SPF-Check, DKIM-Check und DMARC-Check.

So testest du eine Amazon SES-Kampagne mit Unspam.

Unspam verbindet sich nicht mit der SES-API; das Testen ist bewusst manuell, und genau das passt zu SES, denn der einzige ehrliche Test ist ein echter Versand über dein tatsächliches Configuration Set, deine Identität, deinen MAIL FROM und deinen IP-Pool. Nutz die SES-API, das SMTP-Interface oder Send test email in der Konsole, aber schick eine echte Nachricht und keine Vorschau aus der Konsole.

  1. 01

    Hol dir deine Test-Adresse von Unspam

    Starte in Unspam einen Spam-Test oder einen Inbox-Placement-Test und kopiere die Test-Adresse, die dabei entsteht. Inbox-Placement-Tests enthalten Test-Adressen bei Gmail, Outlook, Yahoo, Zoho, ProtonMail und AOL, du siehst also die echte Platzierung je Anbieter.

  2. 02

    Mach die Test-Adresse zu einem zulässigen Empfänger

    Wenn dein Konto noch in der SES-Sandbox steckt, kannst du nur an verifizierte Empfänger senden. Verifiziere die Test-Adresse von Unspam also zuerst unter Configuration > Identities als Identität, oder beantrage den Produktionszugang im Account dashboard. In der Produktion kannst du direkt an sie senden.

  3. 03

    Schick eine echte Nachricht über deinen normalen SES-Weg

    Löse den Versand so aus, wie deine App es tut, über die SES v2 API oder den SMTP-Endpoint, mit derselben From-Identität, demselben Configuration Set und derselben eigenen MAIL-FROM-Domain wie in der Produktion. Wenn du IP Pools nutzt, sende aus demselben Pool. Meide die Adressen des Mailbox Simulator: Sie verlassen AWS nie und sagen nichts über die Platzierung aus.

  4. 04

    Prüf die Authentifizierung am echten Versand

    Schau dir in Unspam SPF, DKIM und DMARC der empfangenen Nachricht an. DKIM sollte d=yourbrand.com zeigen (die amazonses.com-Signatur ist als zweite Signatur zu erwarten), SPF sollte deine eigene MAIL-FROM-Subdomain authentifizieren, und DMARC sollte mit mindestens einem ausgerichteten Identifier bestehen.

  5. 05

    Lies Score, Platzierung und Heatmap in Unspam

    Sieh dir den Spam-Score an, die Platzierung je Anbieter in Posteingang, Werbung, Spam oder Fehlend, die Client-Vorschauen inklusive Dark Mode und die KI-Eyetracking-Heatmap. Der KI-Assistent markiert, was du ändern solltest, zum Beispiel eine fehlende eigene MAIL-FROM-Domain oder nicht ausgerichtetes DKIM, bevor du an deine echte Liste sendest.

Derselbe Test rendert deine Kampagne in über 50 echten E-Mail-Clients, darunter Gmail, Outlook, Apple Mail, iPhone und Android, jeweils im hellen und im dunklen Modus, über Client-Vorschauen, damit du Platzierung und Darstellung in einem Durchgang prüfst.

Amazon SES-Funktionen, die still und leise die Zustellung beeinflussen.

Jede SES-Nachricht trägt eine zweite DKIM-Signatur mit d=amazonses.com

SES signiert zusätzlich zu deinem eigenen DKIM immer mit amazonses.com, weil diese Signatur für die Feedback Loops zu Beschwerden nötig ist, und abschalten lässt sie sich nicht. Das ist normal und keine Fehlkonfiguration. Für dein DMARC-Alignment zählt die Signatur mit d=yourbrand.com. Achte beim Lesen eines Reports oder eines Tools also darauf, dass die Signatur deiner Domain vorhanden und ausgerichtet ist, statt dich um die von amazonses.com zu sorgen.

Sandbox-Status und Reputation gelten pro AWS-Region

Sandbox, Sendelimits, Identitäten, DKIM-Konfiguration und Absender-Reputation existieren in jeder AWS-Region unabhängig voneinander. Wenn du eine Domain in us-east-1 verifizierst und dort die Sandbox verlässt, musst du das komplette Setup in eu-west-1 trotzdem wiederholen, und eine Region ohne aufgewärmte Historie startet kalt. Wähle eine Region und bleib dabei, und wenn du aus mehreren sendest, richte DKIM in jeder ein und beantrage dort jeweils den Produktionszugang.

Mehrere MX-Einträge zerlegen das Setup des eigenen MAIL FROM

SES verlangt auf der eigenen MAIL-FROM-Subdomain genau einen MX-Eintrag (auf feedback-smtp.<region>.amazonses.com, Priorität 10). Hat die Subdomain bereits andere MX-Einträge, scheitert das Setup des eigenen MAIL FROM, der Status erreicht nie Success und SES fällt auf amazonses.com zurück, dein SPF-Alignment verschwindet also still und leise. Nimm eine eigene Subdomain, über die sonst keine Post ein- oder ausgeht.

Ohne Configuration Set bist du blind für Bounces und Beschwerden

SES zeigt dir Bounces und Beschwerden nur, wenn du Events veröffentlichst. Leg ein Configuration Set mit einer Event Destination an (Amazon SNS, CloudWatch, Amazon Data Firehose oder EventBridge) und setz es als Default configuration set der Identität, damit Zustellungen, Bounces, Beschwerden, Öffnungen und Klicks erfasst werden. Sonst ist das erste Anzeichen von Ärger ein Hinweis auf Under review oder Paused im Account dashboard, wenn der Schaden längst da ist.

Worauf Amazon SES-Absender in der Praxis stoßen.

Die häufigsten Probleme mit der Zustellbarkeit bei Amazon SES-Absendern, jeweils mit der passenden Lösung.

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.

Zustellbarkeit bei Amazon SES, kurz beantwortet.

Warum zeigt meine SES-Post eine DKIM-Signatur für amazonses.com statt für meine Domain?

SES fügt für die Feedback Loops immer seine eigene Signatur mit d=amazonses.com hinzu, und genau die siehst du, wenn du Easy DKIM oder BYODKIM auf deiner Domain-Identität nicht aktiviert hast. Aktiviere Easy DKIM unter Configuration > Identities > deine Domain > Authentication und veröffentliche die 3 CNAME-Einträge. Danach hast du zwei Signaturen: deine eigene (d=yourbrand.com, die für DMARC ausgerichtet ist) und die von amazonses.com, die du ignorieren kannst.

Mein SPF besteht, DMARC scheitert trotzdem. Woran liegt das?

Standardmäßig ist der MAIL FROM eine Subdomain von amazonses.com, SPF wird also gegen amazonses.com geprüft und besteht, richtet sich aber nicht auf deine From-Domain aus und zählt damit nicht für DMARC. Richte eine eigene MAIL-FROM-Domain ein (eine Subdomain wie mail.yourbrand.com) mit den MX- und SPF-Einträgen, die SES vorgibt, oder stütz dich stattdessen auf ausgerichtetes DKIM. Schon einer der beiden ausgerichteten Identifier reicht, damit DMARC besteht.

Brauche ich eine dedizierte IP, um bei SES nicht im Spam zu landen?

Meistens nicht. Shared IPs verwaltet AWS, und sie sind bei geringem oder unregelmäßigem Volumen die richtige Wahl. Eine dedizierte Standard-IP, die du nie aufwärmst, schneidet schlechter ab als der Shared Pool. Wenn du unbedingt eine dedizierte IP willst und dein Volumen nicht ganz gleichmäßig ist, sind Dedicated IPs (managed) die bessere Option, weil SES sie pro ISP aufwärmt und automatisch skaliert. Bring erst Authentifizierung, Listenhygiene und Beschwerderate in Ordnung, bevor du zur dedizierten IP greifst.

Mein SES-Konto steht auf Under review oder Paused. Was ist passiert?

SES setzt die Reputation auf Kontoebene durch. Eine Bounce-Rate ab 5 % (Hard Bounces an nicht verifizierte Domains) oder eine Beschwerderate ab 0,1 % bringt dich unter Review; 10 % Bounces oder 0,5 % Beschwerden können den Versand komplett pausieren. Nimm gebouncte und beschwerdeführende Adressen sofort aus dem Versand, behebe das Problem bei der Listengewinnung oder beim Inhalt und antworte dann auf den Support-Case, den SES für dich eröffnet hat. Halte Bounces unter 2 % und Beschwerden unter 0,1 %, damit dein Konto Healthy bleibt.

Kann sich Unspam mit meinem Amazon-SES-Konto verbinden und Versände automatisch testen?

Nein. Unspam bindet sich weder an die SES-API noch an die API eines anderen ESP an. Das Testen ist bewusst manuell: Du trägst die Test-Adresse von Unspam als Empfänger ein und schickst über deinen normalen SES-Weg (API, SMTP oder Konsole) eine echte Nachricht. Danach liest du SPF, DKIM, DMARC, den Spam-Score und die Platzierung je Anbieter in Unspam. Nur so testest du genau die Post, die deine Empfänger bekommen, über dein echtes Configuration Set und deine echte MAIL-FROM-Domain.

Soll ich Easy DKIM oder BYODKIM nutzen?

Nimm Easy DKIM, solange du keinen konkreten Grund dagegen hast. Es veröffentlicht 3 CNAME-Einträge, nutzt standardmäßig RSA mit 2048 Bit und rotiert die Schlüssel automatisch. Mit BYODKIM bringst du über einen einzigen TXT-Eintrag deinen eigenen RSA-Schlüssel mit 1024 oder 2048 Bit mit, was hilft, wenn du einen Schlüssel über mehrere Anbieter hinweg nutzt oder die Rotation selbst steuern musst. Wenn du von BYODKIM auf Easy DKIM wechselst, mach das in einer versandfreien Zeit oder über eine Zwischen-Subdomain, denn solange das neue Setup pending ist, kann Post unsigniert rausgehen.

Die Angaben zur Plattform Amazon SES wurden anhand öffentlich zugänglicher Dokumentation geprüft (Stand: June 2026) und können sich seitdem geändert haben. Amazon SES ist eine Marke des jeweiligen Inhabers. Unspam ist weder mit Amazon SES verbunden noch wird Unspam von Amazon SES unterstützt.

Teste deine nächste Amazon SES-Kampagne, bevor deine Abonnenten es tun.