E-Mail-Benachrichtigungen über SNS senden – Warum keine E-Mails ankommen

Du hast ein SNS-Topic erstellt, eine E-Mail-Subscription eingerichtet, eine Testnachricht gesendet – und nichts kommt an. Das ist eines der häufigsten Probleme beim ersten Einstieg in Amazon SNS: Die Subscription bleibt im Status PendingConfirmation, weil der Bestätigungslink in der Eingangs-E-Mail nie angeklickt wurde. Ohne diese Bestätigung liefert SNS keine einzige Nachricht aus.

TL;DR – Schnellübersicht

Problem	Ursache	Lösung
Keine E-Mail erhalten	Subscription nicht bestätigt	Bestätigungslink in der Opt-in-E-Mail anklicken
Bestätigungslink abgelaufen	Link ist nach 3 Tagen ungültig	Neue Subscription erstellen, neue E-Mail bestätigen
Subscription-Status unklar	Kein Monitoring eingerichtet	`aws sns list-subscriptions-by-topic` ausführen
E-Mail landet im Spam	Absender-Domain nicht vertraut	Spam-Ordner prüfen, Absender no-reply@sns.amazonaws.com freigeben
Falsches Topic verwendet	Mehrere Topics vorhanden	Topic-ARN in der Subscription verifizieren

Wie Amazon SNS E-Mail-Subscriptions funktionieren

Bevor wir zur Fehlersuche kommen, muss das Grundprinzip klar sein – denn genau hier liegt der häufigste Denkfehler.

Amazon SNS verwendet für E-Mail-Endpoints ein Double-Opt-in-Verfahren. Wenn du eine Subscription erstellst, sendet SNS sofort eine Bestätigungs-E-Mail an die angegebene Adresse. Diese E-Mail enthält einen signierten Bestätigungslink. Erst wenn dieser Link angeklickt wird, wechselt der Subscription-Status von PendingConfirmation auf Confirmed. Nur bestätigte Subscriptions empfangen Nachrichten.

sequenceDiagram participant Dev as Entwickler participant SNS as Amazon SNS participant Mail as E-Mail-Postfach Dev->>SNS: aws sns subscribe (protocol=email) SNS-->>Dev: SubscriptionArn: PendingConfirmation SNS->>Mail: Bestätigungs-E-Mail senden Note over Mail: Link gültig für 3 Tage Mail-->>Dev: E-Mail empfangen Dev->>SNS: Bestätigungslink anklicken SNS-->>Dev: Status: Confirmed Dev->>SNS: aws sns publish SNS->>Mail: Nachricht zugestellt

Subscribe: Du rufst aws sns subscribe auf – SNS legt die Subscription mit Status PendingConfirmation an.
Opt-in-E-Mail: SNS sendet automatisch eine Bestätigungs-E-Mail an den angegebenen Endpoint.
Bestätigung: Der Empfänger klickt den Link – Status wechselt auf Confirmed.
Nachrichtenauslieferung: Ab sofort werden alle Publish-Aufrufe an diesen Endpoint zugestellt.
Ablauf: Wird der Link nicht innerhalb von 3 Tagen angeklickt, verfällt die Subscription automatisch.

Das Double-Opt-in ist kein optionales Feature – es ist ein fest verdrahteter Bestandteil des SNS-E-Mail-Protokolls. SNS wird niemals eine unbestätigte E-Mail-Adresse mit Nachrichten beliefern, unabhängig davon, welche IAM-Berechtigungen oder Topic-Policies gesetzt sind.

Schritt-für-Schritt-Diagnose: Warum E-Mail-Alerts über SNS nicht ankommen

Schritt 1: Subscription-Status prüfen

Der erste Griff gilt immer dem tatsächlichen Status der Subscription. Console-Ansichten können veraltet sein – der CLI-Aufruf zeigt den aktuellen Zustand direkt aus der API. Ein Status von PendingConfirmation beendet die Fehlersuche sofort: Alle weiteren Schritte sind irrelevant, solange die Bestätigung aussteht.

aws sns list-subscriptions-by-topic \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MeinAlertTopic \
  --query 'Subscriptions[*].{Endpoint:Endpoint,Protocol:Protocol,Status:SubscriptionArn}' \
  --output table

Relevante Ausgabewerte:

PendingConfirmation – Bestätigungslink wurde noch nicht angeklickt.
Ein vollständiger ARN wie arn:aws:sns:us-east-1:123456789012:MeinAlertTopic:uuid – Subscription ist bestätigt.

Schritt 2: Spam-Ordner und E-Mail-Filter prüfen

Wenn der Status PendingConfirmation zeigt, ist die Bestätigungs-E-Mail entweder nicht angekommen oder wurde gefiltert. SNS sendet diese E-Mail vom Absender no-reply@sns.amazonaws.com. Viele Unternehmens-Mail-Gateways und persönliche Spam-Filter stufen diese Domain als unbekannt ein und verschieben die E-Mail automatisch in den Spam-Ordner. Das ist der häufigste Grund, warum der Link nie angeklickt wird – nicht weil er nicht gesendet wurde.

Prüfe explizit:

Spam- und Junk-Ordner des Postfachs
Unternehmens-Mail-Gateway-Quarantäne (falls vorhanden)
E-Mail-Weiterleitungsregeln, die Nachrichten von unbekannten Absendern löschen

Schritt 3: Topic-ARN in der Subscription verifizieren

In Umgebungen mit mehreren Topics – Staging, Production, verschiedene Services – passiert es schnell, dass die Subscription gegen das falsche Topic erstellt wurde. Eine bestätigte Subscription auf dem falschen Topic empfängt Nachrichten, aber nicht die, die du erwartest. Dieser Fehler ist besonders tückisch, weil der Status Confirmed zeigt und alles korrekt aussieht.

aws sns list-subscriptions \
  --query 'Subscriptions[?Protocol==`email`].{TopicArn:TopicArn,Endpoint:Endpoint,Status:SubscriptionArn}' \
  --output table

Vergleiche den TopicArn-Wert mit dem ARN, gegen den du tatsächlich publishst. Beide müssen identisch sein.

Schritt 4: Topic-Policy auf Publish-Berechtigung prüfen

Eine bestätigte Subscription allein reicht nicht aus, wenn der Publisher keine Berechtigung hat, Nachrichten an das Topic zu senden. Besonders bei Topics, die von CloudWatch Alarms, EventBridge oder anderen AWS-Services beschrieben werden, muss die Topic-Policy explizit den jeweiligen Service-Principal als Quelle erlauben. Fehlt diese Berechtigung, schlägt der Publish-Aufruf lautlos fehl – keine Fehlermeldung in der aufrufenden Ressource, keine Nachricht beim Subscriber.

aws sns get-topic-attributes \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MeinAlertTopic \
  --query 'Attributes.Policy' \
  --output text

Die Policy muss einen Statement-Block enthalten, der dem relevanten Principal die sns:Publish-Aktion erlaubt. Beispiel für CloudWatch Alarms:

🔽 Beispiel-Topic-Policy für CloudWatch Alarms anzeigen

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudwatch.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:123456789012:MeinAlertTopic",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:*"
        }
      }
    }
  ]
}

Schritt 5: Testnachricht direkt über CLI publishen

Wenn Subscription bestätigt und Policy korrekt ist, aber immer noch keine E-Mail ankommt, isoliere den Publish-Pfad. Ein direkter CLI-Aufruf umgeht alle vorgelagerten Services (CloudWatch, EventBridge) und testet ausschließlich den SNS-zu-E-Mail-Pfad. Kommt die E-Mail nach diesem Aufruf an, liegt das Problem im vorgelagerten Service, nicht in SNS selbst.

aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MeinAlertTopic \
  --subject "SNS Test-Nachricht" \
  --message "Dies ist eine direkte Testnachricht vom CLI."

Erwartete Ausgabe bei Erfolg:

{
    "MessageId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

Eine MessageId in der Antwort bedeutet, dass SNS die Nachricht angenommen hat. Sie garantiert nicht die Zustellung – aber wenn danach keine E-Mail ankommt, liegt das Problem auf der E-Mail-Empfängerseite (Spam-Filter, Postfach-Quota).

Abgelaufene Subscription: Was jetzt zu tun ist

Hier liegt ein häufiges Missverständnis: Man sieht eine Subscription im Status PendingConfirmation und versucht, sie zu löschen, um sauber neu anzufangen. Das funktioniert so nicht.

Eine ausstehende Subscription, deren Bestätigungslink abgelaufen ist, kann nicht manuell gelöscht werden. Sie verfällt nach 3 Tagen automatisch und wird vom System entfernt. Die einzige Lösung besteht darin, eine neue Subscription mit aws sns subscribe zu erstellen und die neue Bestätigungs-E-Mail zu verwenden.

graph TD A[Subscription PendingConfirmation] --> B{Bestätigungslink abgelaufen?} B -- Nein --> C[Spam-Ordner prüfen und Link anklicken] B -- Ja --> D[Subscription verfällt automatisch nach 3 Tagen] D --> E[aws sns subscribe erneut ausführen] E --> F[Neue Bestätigungs-E-Mail sofort prüfen] F --> G[Link anklicken] G --> H[Status: Confirmed Nachrichten werden zugestellt]

Neue Subscription erstellen: Führe aws sns subscribe erneut aus – SNS sendet sofort eine neue Bestätigungs-E-Mail.
E-Mail sofort prüfen: Öffne das Postfach unmittelbar nach dem Aufruf, inklusive Spam-Ordner.
Link anklicken: Der Bestätigungslink ist 3 Tage gültig – bestätige ihn so früh wie möglich.
Status verifizieren: Führe list-subscriptions-by-topic aus und prüfe, ob der ARN jetzt vollständig angezeigt wird.

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:MeinAlertTopic \
  --protocol email \
  --notification-endpoint deine-email@beispiel.de

Typisches Fehlermuster aus der Praxis

Das Szenario sieht immer gleich aus: Ein CloudWatch-Alarm wird erstellt, ein SNS-Topic als Ziel konfiguriert, die Subscription eingerichtet. Dann wartet man auf den ersten Alarm – und nichts passiert. Der erste Verdacht fällt auf den Alarm selbst: falsche Schwellenwerte, falscher Metrik-Namespace, fehlende Daten. Man verbringt eine Stunde damit, den Alarm zu debuggen.

Die eigentliche Ursache: Die Bestätigungs-E-Mail landete im Spam-Ordner. Der Alarm hat korrekt ausgelöst, SNS hat die Nachricht angenommen, aber die Subscription war nie im Status Confirmed. Der list-subscriptions-by-topic-Aufruf hätte das in zehn Sekunden gezeigt.

Subscription-Status ist immer der erste Check – nicht der letzte.

Minimale IAM-Berechtigungen für die Diagnose

Für die oben beschriebenen CLI-Befehle benötigt der ausführende IAM-Principal mindestens folgende Berechtigungen:

🔽 IAM-Policy für SNS-Diagnose anzeigen

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sns:ListSubscriptionsByTopic",
        "sns:ListSubscriptions",
        "sns:GetTopicAttributes",
        "sns:Subscribe",
        "sns:Publish"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:MeinAlertTopic"
    }
  ]
}

Hinweis: sns:ListSubscriptions ist eine List-Aktion, die in der AWS Service Authorization Reference als Aktion ohne Resource-Level-Support dokumentiert ist. In der Praxis wird dafür "Resource": "*" benötigt. Prüfe die aktuelle Service Authorization Reference, um die genauen Resource-Anforderungen zu verifizieren.

Nächste Schritte und weiterführende Ressourcen für SNS E-Mail-Alerts

Sobald die Subscription bestätigt ist und Testnachrichten ankommen, sind folgende Punkte sinnvoll:

CloudWatch-Alarm verknüpfen: Stelle sicher, dass der Alarm-ARN und der Topic-ARN in derselben Region liegen – regionsübergreifende SNS-Targets werden von CloudWatch Alarms nicht unterstützt.
Dead-Letter Queue (DLQ) einrichten: Für kritische Alerts empfiehlt sich eine SQS-DLQ als Fallback, um fehlgeschlagene Zustellversuche zu erfassen.
SNS-Metriken in CloudWatch beobachten: Die Metriken NumberOfNotificationsFailed und NumberOfNotificationsDelivered geben Auskunft über die tatsächliche Zustellrate.
Offizielle Dokumentation: Amazon SNS – E-Mail-Benachrichtigungen

Glossar

Begriff	Bedeutung
SNS Topic	Logischer Kanal, über den Nachrichten an alle Subscriber verteilt werden.
Subscription	Verbindung zwischen einem Topic und einem Endpoint (z.B. E-Mail-Adresse), die Nachrichten empfangen soll.
PendingConfirmation	Status einer Subscription, die noch nicht durch Anklicken des Bestätigungslinks aktiviert wurde.
Double Opt-in	Pflichtprozess bei E-Mail-Subscriptions: SNS sendet eine Bestätigungs-E-Mail, bevor Nachrichten zugestellt werden.
Topic Policy	Ressourcen-basierte IAM-Policy, die steuert, welche Principals Nachrichten an ein Topic publishen dürfen.

Dieses Blog durchsuchen

SW BBANG D