Amazon SES: SPF und DKIM für DMARC ausrichten

Von Thomas · virtueller CISO · 04. September 2026

Amazon SES (Simple Email Service) nimmt unter den Versandplattformen eine besondere Stellung ein: pro Nachricht abgerechnet, per API oder SMTP gesteuert, bedient es transaktionale Anwendungs-E-Mails ebenso wie Kampagnen mit hohem Volumen. Diese Flexibilität hat einen Preis bei der Authentifizierung: Anders als bei einer Office-Suite, in der DKIM mit zwei Klicks aktiv ist, bleibt die Verdrahtung der Ausrichtung dem Absender überlassen — und die Standardkonfiguration reicht nach der Verifizierung der Domain-Identität nicht aus, damit DMARC besteht.

Das häufigste Missverständnis liegt bei diesem Verifizierungsschritt. Eine Domain in SES hinzuzufügen und zu „verifizieren" belegt lediglich, dass die Konsole Zugriff auf die DNS-Zone hat; ausgerichtet wird damit weder SPF noch DKIM. Solange nichts weiter hinterlegt ist, verlässt der Umschlag der ausgehenden Nachrichten das System unter einer Subdomain von amazonses.com, und keine Signatur trägt die im From-Header angezeigte Domain. Ein Empfänger, der eine p=reject-Richtlinie durchsetzt, weist diesen an sich legitimen Verkehr dann ab.

Dieser Leitfaden behandelt die drei Bausteine, die SES DMARC-tauglich machen: Easy DKIM mit seinen drei CNAMEs, die eigene MAIL-FROM-Domain für die SPF-Ausrichtung und die BYODKIM-Alternative für Organisationen, die jede Delegation ablehnen. Anschließend die häufigsten Konfigurationsfehler und der abschließende Gegenbeweis — das Lesen der RUA-Berichte.

Easy DKIM: drei CNAMEs, eine ausgerichtete Signatur

Die empfohlene Option heißt Easy DKIM. Bei der Aktivierung auf einer Domain-Identität erzeugt SES ein Schlüsselpaar und veröffentlicht den öffentlichen Schlüssel auf seiner Seite; der Absender wiederum setzt drei CNAME-Einträge in die Zone der Domain — hier beispiel.de:

xxxx1._domainkey.beispiel.de.  CNAME  xxxx1.dkim.amazonses.com.
xxxx2._domainkey.beispiel.de.  CNAME  xxxx2.dkim.amazonses.com.
xxxx3._domainkey.beispiel.de.  CNAME  xxxx3.dkim.amazonses.com.

Die drei Präfixe (undurchsichtige, der Identität eigene Token) entsprechen drei DKIM-Selektoren. Die Logik ist die einer Delegation: Der Schlüssel wird nicht in die Zone der Domain kopiert, er liegt bei Amazon, und der CNAME schlägt die Brücke. Prüft ein empfangender Server eine Signatur d=beispiel.de; s=xxxx1, folgt die DNS-Auflösung dem CNAME und holt den Schlüssel bei SES — transparent. Drei Selektoren werden von Anfang an bereitgestellt, damit ein Schlüsselwechsel ohne manuellen Eingriff in die Zone möglich ist — kryptografische Hygiene, die an denjenigen delegiert wird, der sie industrialisiert.

Entscheidend für DMARC: Die erzeugte Signatur trägt d=beispiel.de, die Organisationsdomain selbst, und keine Amazon-Domain. Die DKIM-Ausrichtung ist damit gesichert, auch im strikten Modus. Allein über diesen Mechanismus besteht DMARC bereits — vorausgesetzt, die drei CNAMEs sind propagiert und der Schlüssel wird in der Konsole als aktiv erkannt.

Domain-Identität, Subdomains und das Verlassen der Sandbox

Noch vor der Authentifizierung erzwingt SES zwei strukturierende Entscheidungen, die auf DMARC wirken. Die erste betrifft den Umfang der verifizierten Identität: SES unterscheidet zwischen einer Domain-Identität und einer Adress-Identität. Die Verifizierung einer einzelnen Adresse (kontakt@beispiel.de) erlaubt den Versand aus diesem einen Postfach, aktiviert Easy DKIM aber nicht auf Domain-Ebene — die ausgerichtete Signatur folgt nicht. Für den ernsthaften Einsatz ist die Domain-Identität zu verifizieren: Sie deckt alle Adressen der Domain ab und trägt vor allem die DKIM-Konfiguration. Eine dem transaktionalen Versand gewidmete Subdomain (mailer.beispiel.de) kann überdies eine eigene Identität mit eigenen Schlüsseln bilden — eine nützliche Segmentierung, wenn ein Anwendungsstrom vom menschlichen Schriftverkehr getrennt bleiben soll.

Die zweite Entscheidung betrifft die Sandbox. Jedes neue SES-Konto startet im Sandbox-Modus: Der Versand ist nur an selbst verifizierte Adressen möglich, und das Volumen ist gedeckelt. Diese Einschränkung hat nichts mit der Authentifizierung zu tun, trübt aber häufig die Diagnose: Ein Test, der „nicht rausgeht", ist bisweilen eine Sandbox-Frage, kein DKIM-Fehler. Das Verlassen der Sandbox wird bei AWS beantragt und schaltet den Versand an beliebige Empfänger frei — ein Schritt, der vor jeder groß angelegten DMARC-Prüfkampagne zu erledigen ist.

Zur Kryptografie schließlich: Easy DKIM stellt standardmäßig RSA-Schlüssel mit 2048 Bit bereit, robust und überall akzeptiert. SES rotiert sie dank der drei Selektoren transparent, sodass es keinen Grund gibt, einen alten Schlüssel zu behalten. Die Länge von 1024 Bit, von manchen Alt-Werkzeugen noch geduldet, ist für jede neue Konfiguration zu vermeiden: Mehrere Mail-Betreiber stufen sie inzwischen als schwach ein.

Ein letzter Mechanismus verdient beim Monitoring Beachtung: die Configuration Sets. Sie hängen dem Versand einen Ereignisstrom an — Zustellungen, Beschwerden, Bounces —, der sich zu anderen AWS-Diensten exportieren lässt. Ohne unmittelbaren Bezug zur Ausrichtung ergänzen sie das Lesen der RUA-Berichte sinnvoll: Wo die aggregierten Berichte sagen, wie der Verkehr aus Sicht der Empfänger authentifiziert wird, sagen die SES-Ereignisse, was aus ihm nach der Zustellung wird. Das Zusammenführen beider Quellen beschleunigt die Diagnose, wenn eine legitime Quelle plötzlich zu scheitern beginnt.

Die eigene MAIL-FROM-Domain: die SPF-Ausrichtung anstreben

Standardmäßig ist die Umschlagadresse (der Return-Path, den SPF tatsächlich prüft) eine von Amazon verwaltete Subdomain der Form bounces+…@region.amazonses.com. SPF authentifiziert diese Domain zwar — Amazon veröffentlicht den passenden Eintrag —, aber sie richtet sich an amazonses.com aus, nicht an beispiel.de. Das Ergebnis: SPF besteht, ohne sich auszurichten, was aus Sicht von DMARC nicht zählt.

Die Antwort heißt „custom MAIL FROM domain". Sie besteht darin, eine Umschlag-Subdomain zu deklarieren, die zur Absenderdomain gehört — etwa mail.beispiel.de —, und dann zwei Einträge in die Zone zu setzen:

mail.beispiel.de.  MX   10 feedback-smtp.eu-central-1.amazonses.com.
mail.beispiel.de.  TXT  "v=spf1 include:amazonses.com ~all"

Der MX-Eintrag (dessen Host von der genutzten SES-Region abhängt — hier eu-central-1) ermöglicht die Bounce-Verarbeitung; der TXT-Eintrag autorisiert die Server von Amazon, für diese Subdomain zu senden. Der Umschlag wird damit zu …@mail.beispiel.de, einer Subdomain der Organisationsdomain: Im lockeren Modus — dem Standard von DMARC — richtet er sich an beispiel.de aus. Unter DMARCbis wird die Organisationsdomain über den DNS Tree Walk bestimmt statt über die alte Public Suffix List, das Ergebnis bleibt jedoch gleich.

Lohnt sich die SPF-Ausrichtung überhaupt, wenn Easy DKIM DMARC schon bestehen lässt? Die Redundanz hat einen realen betrieblichen Wert: Ändert eine Weiterleitung die versendende IP und bricht SPF, überlebt DKIM; schreibt ein Gateway den Nachrichtentext um und macht die DKIM-Signatur ungültig, hält SPF. Die kommentierten Beispiele, Tag für Tag zeigen, wie sich dieser Baustein in die Gesamtrichtlinie fügt: Die SES-Konfiguration bereitet die Ausrichtung vor, der _dmarc-Eintrag gibt die Anweisung.

BYODKIM: den Schlüssel im Haus behalten

Manche Organisationen, besonders in regulierten Branchen, untersagen die DNS-Delegation eines kryptografischen Schlüssels an einen Dritten. SES sieht diesen Fall mit BYODKIM vor — den eigenen DKIM-Schlüssel bereitstellen. Das Prinzip kehrt sich um: Das Schlüsselpaar wird intern erzeugt, der öffentliche Schlüssel wird als TXT-Eintrag unter einem selbst gewählten Selektor veröffentlicht, und der private Schlüssel wird SES bei der Konfiguration der Identität übergeben.

selector._domainkey.beispiel.de.  TXT  "v=DKIM1;k=rsa;p=MIIBIjANBgkq…"

Der Kompromiss ist eindeutig. BYODKIM behält die volle Kontrolle über den Schlüssel — seine Erzeugung, seine Länge, seine Ablage —, verlagert aber die Rotationslast auf das interne Team: Jede Erneuerung wird wieder zu einem manuellen, koordinierten Vorgang. Für die große Mehrheit der Fälle bleibt Easy DKIM vorzuziehen: weniger Kopierfehler, automatische Rotation und dasselbe Ausrichtungsergebnis. BYODKIM rechtfertigt sich, wenn eine Sicherheitsrichtlinie es ausdrücklich verlangt, nicht als Voreinstellung.

Die Fehler, die die Konfiguration scheitern lassen

Mehrere Fallen tauchen im Korpus der Berichte regelmäßig auf, die der kostenlose DMARC-Analyzer täglich verarbeitet.

Bei der Identitätsverifizierung stehenbleiben. Die Verifizierung der Domain in SES eröffnet nur das Senderecht; ohne aktiviertes und propagiertes Easy DKIM entsteht keine ausgerichtete Signatur. Das ist die häufigste Ursache für ein scheiterndes DMARC, obwohl „alles konfiguriert scheint".

Die eigene MAIL-FROM-Domain vergessen. Ohne sie richtet sich SPF nie aus. Das blockiert nicht, solange DKIM hält, entfernt aber die Redundanz: An dem Tag, an dem eine Signatur wegfällt, fängt nichts die Nachricht auf.

Die Region im MX-Eintrag verwechseln. Der Host feedback-smtp ist regionsspezifisch. Eine für us-east-1 konfigurierte Domain mit einem MX, der auf eu-central-1 zeigt, sieht die Bounce-Verarbeitung stillschweigend scheitern.

Ein zu striktes SPF zu früh veröffentlichen. Der direkte Sprung auf -all auf der MAIL-FROM-Subdomain, bevor bestätigt ist, dass der Verkehr wirklich über SES ausgeht, riskiert Abweisungen, falls noch eine andere Quelle sendet. Ein ~all (Softfail) bleibt während der Prüfung umsichtig.

Der Gegenbeweis: die RUA-Berichte

Der einzige Beleg dafür, dass eine Konfiguration hält, ist nicht die SES-Konsole, sondern das, was die Empfänger melden. Sobald ein _dmarc-Eintrag mit einer rua=-Adresse veröffentlicht ist, treffen die aggregierten Berichte binnen weniger Tage ein und schlüsseln Quelle für Quelle auf, was sich ausrichtet und was scheitert. Das Lesen der aggregierten DMARC-Berichte zeigt, ob der Amazon-SES-Verkehr der Domain korrekt zugeordnet wird: DKIM ausgerichtet, SPF ausgerichtet, sofern die MAIL-FROM-Domain gesetzt wurde, und vor allem keine SES-Quelle, die an beiden Mechanismen scheitert.

Eine praktische Kadenz hilft: eine erste Durchsicht wenige Tage nach der Veröffentlichung des _dmarc-Eintrags, sobald mehrere Empfänger gemeldet haben, danach ein wöchentlicher Blick, solange die Richtlinie bei p=none bleibt. Der Amazon-SES-Verkehr erscheint meist unter einer Handvoll stabiler IP-Bereiche, sodass eine ausgerichtete Grundlinie schnell zu erkennen ist — und jede neue, nicht ausgerichtete SES-Quelle fällt sofort auf, ob sie nun auf ein zweites Konto, eine vergessene Region oder eine nie propagierte Konfiguration hindeutet.

Diese Prüfung ist es, die die Verschärfung der Richtlinie erlaubt. Solange die Berichte legitimen, nicht ausgerichteten SES-Verkehr zeigen, würde der Wechsel zu p=reject einen Teil der eigenen Sendungen abschneiden. Sobald die Ausrichtung über mehrere Tage und über alle Ströme hinweg bestätigt ist — transaktional wie kampagnenbezogen —, erfolgt der Übergang zu einer strikten Richtlinie ohne Risiko. Der Online-Analyzer setzt diesen Zustand aus den veröffentlichten Einträgen und den empfangenen Berichten zusammen und verortet die Domain auf dem Weg, der von p=none zu p=reject führt.