What happens if TlsPolicy is REQUIRE and the recipient's mail server doesn't support TLS?

The message delivery fails outright, SES does not fall back to sending unencrypted when TlsPolicy is REQUIRE, this is a deliberate security posture: some organizations need the guarantee that their email either goes out encrypted or doesn't go out at all, rather than silently degrading to plaintext for a subset of recipients whose mail servers lack TLS support. Understand this tradeoff before setting REQUIRE on a high-volume transactional configuration set where deliverability to every recipient matters.

Why route BOUNCE/COMPLAINT events to a separate SNS destination instead of relying on the same CloudWatch metrics destination?

CloudWatch metrics are good for dashboards and trend visibility (aggregate bounce rate over time), but they're not designed for triggering an immediate, per-event automated response. Routing BOUNCE/COMPLAINT specifically to SNS lets you attach a Lambda function that reacts to each individual event, for example, immediately adding the address to a suppression list, rather than only noticing an elevated bounce rate after the fact in a metrics dashboard.

Does enabling ReputationMetricsEnabled affect deliverability itself?

No, it only enables visibility into your sending reputation metrics (bounce rate, complaint rate) via CloudWatch, it doesn't change how SES actually sends mail. The value is early warning, catching a rising bounce or complaint rate before it's severe enough to trigger SES's own automatic sending pause protections, which do affect deliverability once triggered.

AWS SES Configuration Set Builder

ServerlessAWS

Build SES configuration set configs with event destinations, reputation tracking, VDM, and delivery options.

Amazon SES Configuration

Build SES configuration set configs with event destinations, reputation tracking, VDM, and delivery options.

Required Fields

ConfigurationSetNameEventDestinations

{
  "ConfigurationSetName": "transactional-email-config",
  "SendingOptions": {
    "SendingEnabled": true
  },
  "TrackingOptions": {
    "CustomRedirectDomain": "email.example.com"
  },
  "ReputationOptions": {
    "ReputationMetricsEnabled": true,
    "LastFreshStart": "2024-01-01T00:00:00Z"
  },
  "DeliveryOptions": {
    "TlsPolicy": "REQUIRE",
    "SendingPoolName": "transactional-pool"
  },
  "SuppressionOptions": {
    "SuppressedReasons": ["BOUNCE", "COMPLAINT"]
  },
  "VdmOptions": {
    "DashboardOptions": {
      "EngagementMetrics": "ENABLED"
    },
    "GuardianOptions": {
      "OptimizedSharedDelivery": "ENABLED"
    }
  },
  "EventDestinations": [
    {
      "Name": "cloudwatch-metrics",
      "Enabled": true,
      "MatchingEventTypes": ["SEND", "DELIVERY", "BOUNCE", "COMPLAINT", "REJECT", "OPEN", "CLICK"],
      "CloudWatchDestination": {
        "DimensionConfigurations": [
          {
            "DimensionName": "EmailType",
            "DimensionValueSource": "MESSAGE_TAG",
            "DefaultDimensionValue": "transactional"
          }
        ]
      }
    },
    {
      "Name": "sns-bounce-notifications",
      "Enabled": true,
      "MatchingEventTypes": ["BOUNCE", "COMPLAINT"],
      "SnsDestination": {
        "TopicArn": "arn:aws:sns:us-east-1:123456789012:ses-bounce-notifications"
      }
    }
  ],
  "Tags": [
    {
      "Key": "Service",
      "Value": "email"
    }
  ]
}

Generated Output

Output will appear here...

What This Tool Does

Build an SES configuration set combining reputation tracking, TLS delivery policy, VDM (Virtual Deliverability Manager) dashboard options, and multiple EventDestinations routing different email lifecycle events (SEND, DELIVERY, BOUNCE, COMPLAINT, OPEN, CLICK) to different targets, like CloudWatch metrics for dashboards and SNS specifically for bounce/complaint alerting. DeliveryOptions.TlsPolicy set to REQUIRE enforces that SES only delivers via a TLS-encrypted connection to the receiving mail server, refusing delivery entirely (rather than falling back to plaintext) if the recipient's mail server doesn't support TLS, a meaningful security-versus-deliverability tradeoff since a small fraction of mail servers still don't support inbound TLS.

Technical Details

The builder validates that ConfigurationSetName and EventDestinations resolve before accepting the JSON as a valid combined configuration set creation request, the fields SES needs to name the set and route its lifecycle events; it can't verify the referenced SNS topic ARN or CloudWatch dimension configuration actually work end-to-end, that's only confirmed once real email events start flowing through the configuration set.

Common Use Cases

1Setting DeliveryOptions.TlsPolicy to REQUIRE for a configuration set handling sensitive transactional email (password resets, financial notifications), accepting that delivery to any non-TLS-capable recipient mail server will fail outright rather than degrade to unencrypted delivery.
2Routing BOUNCE and COMPLAINT events specifically to an SNS topic (separate from the broader CloudWatch metrics destination covering all event types), so a bounce/complaint-processing Lambda can react immediately to suppress future sends to that address, which matters directly for maintaining sender reputation.
3Enabling ReputationMetricsEnabled so bounce and complaint rates are tracked and visible before they get bad enough to trigger SES account-level sending restrictions, giving early warning rather than finding out only after a reputation-based throttle kicks in.
4Using SuppressionOptions.SuppressedReasons to automatically suppress future sends to addresses that have bounced or complained, rather than relying on manual list hygiene that inevitably lags behind real bounce/complaint events.

Common Questions

What happens if TlsPolicy is REQUIRE and the recipient's mail server doesn't support TLS?: The message delivery fails outright, SES does not fall back to sending unencrypted when TlsPolicy is REQUIRE, this is a deliberate security posture: some organizations need the guarantee that their email either goes out encrypted or doesn't go out at all, rather than silently degrading to plaintext for a subset of recipients whose mail servers lack TLS support. Understand this tradeoff before setting REQUIRE on a high-volume transactional configuration set where deliverability to every recipient matters.
Why route BOUNCE/COMPLAINT events to a separate SNS destination instead of relying on the same CloudWatch metrics destination?: CloudWatch metrics are good for dashboards and trend visibility (aggregate bounce rate over time), but they're not designed for triggering an immediate, per-event automated response. Routing BOUNCE/COMPLAINT specifically to SNS lets you attach a Lambda function that reacts to each individual event, for example, immediately adding the address to a suppression list, rather than only noticing an elevated bounce rate after the fact in a metrics dashboard.
Does enabling ReputationMetricsEnabled affect deliverability itself?: No, it only enables visibility into your sending reputation metrics (bounce rate, complaint rate) via CloudWatch, it doesn't change how SES actually sends mail. The value is early warning, catching a rising bounce or complaint rate before it's severe enough to trigger SES's own automatic sending pause protections, which do affect deliverability once triggered.

Expert Tips

TIP

TlsPolicy REQUIRE is the right choice for sensitive transactional content but carries a real deliverability risk for a small percentage of legacy recipient mail servers, weigh this deliberately rather than defaulting to REQUIRE everywhere without considering your actual recipient mail server diversity.

TIP

Always route BOUNCE and COMPLAINT events to an actionable destination (SNS feeding an automated suppression handler), not just CloudWatch metrics, reputation damage from repeatedly emailing bounced/complained addresses accumulates faster than a metrics dashboard alone will get someone to notice and intervene.

TIP

VDM's engagement metrics and Guardian's optimized shared delivery are genuinely useful for understanding real inbox placement and deliverability issues beyond simple bounce/complaint tracking, enable them for any meaningful-volume sending program, not just the base reputation metrics.

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.

AWS SES Configuration Set Builder

ServerlessAWS

Build SES configuration set configs with event destinations, reputation tracking, VDM, and delivery options.

Amazon SES Configuration

Build SES configuration set configs with event destinations, reputation tracking, VDM, and delivery options.

Required Fields

ConfigurationSetNameEventDestinations

Generated Output

Output will appear here...

What This Tool Does

Technical Details

Common Use Cases

1Setting DeliveryOptions.TlsPolicy to REQUIRE for a configuration set handling sensitive transactional email (password resets, financial notifications), accepting that delivery to any non-TLS-capable recipient mail server will fail outright rather than degrade to unencrypted delivery.
2Routing BOUNCE and COMPLAINT events specifically to an SNS topic (separate from the broader CloudWatch metrics destination covering all event types), so a bounce/complaint-processing Lambda can react immediately to suppress future sends to that address, which matters directly for maintaining sender reputation.
3Enabling ReputationMetricsEnabled so bounce and complaint rates are tracked and visible before they get bad enough to trigger SES account-level sending restrictions, giving early warning rather than finding out only after a reputation-based throttle kicks in.
4Using SuppressionOptions.SuppressedReasons to automatically suppress future sends to addresses that have bounced or complained, rather than relying on manual list hygiene that inevitably lags behind real bounce/complaint events.

Common Questions

What happens if TlsPolicy is REQUIRE and the recipient's mail server doesn't support TLS?: The message delivery fails outright, SES does not fall back to sending unencrypted when TlsPolicy is REQUIRE, this is a deliberate security posture: some organizations need the guarantee that their email either goes out encrypted or doesn't go out at all, rather than silently degrading to plaintext for a subset of recipients whose mail servers lack TLS support. Understand this tradeoff before setting REQUIRE on a high-volume transactional configuration set where deliverability to every recipient matters.
Why route BOUNCE/COMPLAINT events to a separate SNS destination instead of relying on the same CloudWatch metrics destination?: CloudWatch metrics are good for dashboards and trend visibility (aggregate bounce rate over time), but they're not designed for triggering an immediate, per-event automated response. Routing BOUNCE/COMPLAINT specifically to SNS lets you attach a Lambda function that reacts to each individual event, for example, immediately adding the address to a suppression list, rather than only noticing an elevated bounce rate after the fact in a metrics dashboard.
Does enabling ReputationMetricsEnabled affect deliverability itself?: No, it only enables visibility into your sending reputation metrics (bounce rate, complaint rate) via CloudWatch, it doesn't change how SES actually sends mail. The value is early warning, catching a rising bounce or complaint rate before it's severe enough to trigger SES's own automatic sending pause protections, which do affect deliverability once triggered.

Expert Tips

TIP

Related Learning Guides

Lambda Performance Tuning26 min read
SQS vs SNS vs EventBridge25 min read

Was this tool helpful?