Skip to main content

Common Issues

Symptoms: Emails are not being delivered through Amazon SESChecklist:
  • Verify your AWS credentials (Access Key ID and Secret Access Key) are valid
  • Check that the IAM user has AmazonSESFullAccess and AmazonSNSFullAccess permissions
  • Verify your AWS region matches your SES account region
  • Check that the TPSP is active in SendPost
  • Review the SendPost event logs for errors
  • Confirm your Amazon SES account is in good standing and not in sandbox mode (if applicable)
  • Verify your sending identities are verified in Amazon SES
Test Your AWS Credentials:
aws ses get-send-statistics --region us-east-1 \
  --aws-access-key-id YOUR_ACCESS_KEY_ID \
  --aws-secret-access-key YOUR_SECRET_ACCESS_KEY
If this returns authentication errors, your credentials are invalid.
Symptoms: Emails are sent but opens/clicks/bounces not showingChecklist:
  • Verify SNS topics and subscriptions are created in AWS Console
  • Check that the configuration set “sendpost-events” exists in Amazon SES
  • Ensure the configuration set is attached to your emails (automatically handled by SendPost)
  • Verify SNS subscriptions are active and pointing to SendPost endpoints
  • Wait a few minutes (events are processed asynchronously via SNS)
  • Check AWS CloudWatch logs for SNS delivery errors
Verify Configuration Set in Amazon SES:
  1. Go to AWS Console → Amazon SES → Configuration Sets
  2. Confirm “sendpost-events” configuration set exists
  3. Verify event destinations are configured for SNS
Symptoms: Bounced emails not reflected in analyticsCheck:
  • Review SMTP codes in event details
  • Hard bounces (ID: 29) = permanent failures
  • Soft bounces (ID: 30) = temporary failures
  • Ensure bounce events are enabled in the configuration set
  • Verify SNS topic is receiving bounce notifications
Symptoms: Cannot send emails, identities not verifiedChecklist:
  • Verify DNS records are correctly added to your domain’s DNS settings
  • Wait for DNS propagation (can take up to 48 hours)
  • Check identity verification status in Amazon SES console
  • For email addresses, verify the verification email was clicked
  • Ensure you’re not in SES sandbox mode (if applicable, request production access)
Verify Identity in Amazon SES:
  1. Go to AWS Console → Amazon SES → Verified Identities
  2. Check verification status of your domain/email
  3. Review DNS records if domain verification is pending
Error CodeMeaningSolution
401Invalid credentialsRegenerate Access Key ID and Secret Access Key in IAM
403Insufficient permissionsEnsure IAM user has AmazonSESFullAccess and AmazonSNSFullAccess
429Rate limit exceededWait and retry, or increase limits in SendPost and AWS
Symptoms: Events not being received via SNSChecklist:
  • Verify SNS topics are created in the correct AWS region
  • Check SNS subscription status (should be “Confirmed”)
  • Review SNS topic permissions (SendPost should have publish permissions)
  • Check AWS CloudWatch logs for SNS delivery failures
  • Verify the configuration set is publishing to the correct SNS topic
400 Bad Request with ValidationException:
{
  "__type": "ValidationException",
  "message": "Field 'RawMessage' is not supported. Please use Message with Subject and Body instead."
}
Solution: Remove the unsupported field from your request403 AccessDeniedException:
{
  "__type": "AccessDeniedException",
  "message": "Invalid or missing API key"
}
Solution: Verify your X-SubAccount-ApiKey header is correct413 MessageTooLarge:
{
  "__type": "MessageTooLarge",
  "message": "Payload exceeds 10MB limit"
}
Solution: Reduce request size below 10MB429 TooManyRequestsException:
{
  "__type": "TooManyRequestsException",
  "message": "Rate limit exceeded"
}
Solution: Wait and retry, or increase rate limits

Getting Help

If you’re still experiencing issues:
  1. Check Logs: Review detailed event logs in SendPost dashboard
  2. Check AWS CloudWatch: Review SNS and SES logs in AWS CloudWatch
  3. Contact Support: Reach out to SendPost support with:
    • Your account ID
    • TPSP ID
    • Message ID (if available)
    • Error messages
    • Timestamp of the issue
    • AWS region and SES account status

FAQs

Yes! Create a separate TPSP for each Amazon SES account. Each will have its own configuration set, SNS topics, and IP Pool.
Yes, all AWS credentials are encrypted at rest and never exposed in logs or API responses.
Yes, SendPost supports intelligent routing. You can configure rules to route specific traffic through Amazon SES using IP Pools.
Amazon SNS will retry message delivery. Events will be processed once connectivity is restored.
No! Unlike other providers, SendPost automatically creates an IP Pool for your Amazon SES integration. Just use the auto-created IP Pool name in your API calls.
SendPost automatically creates a configuration set named “sendpost-events” in your Amazon SES account. This configuration set is used for all event tracking.
Yes! You can run both systems in parallel during migration. Route a percentage of traffic to SendPost while keeping some on Amazon SES directly.
Events are typically processed within 1-5 seconds of being received from Amazon SNS.
SendPost doesn’t impose hard limits, but your Amazon SES account limits still apply. Configure throttling to match your SES limits.
If your Amazon SES account is in sandbox mode, you can only send to verified email addresses. Request production access in the AWS Console to send to any email address.
SendPost uses its own configuration set (“sendpost-events”) for event tracking. You can still use your existing configuration sets for other purposes, but SendPost emails will use the “sendpost-events” configuration set.
No, you need to set up an Amazon SES provider (TPSP) in SendPost first. The compatible API routes emails through your configured SES provider. However, you can use the compatible API format even when sending through SendPost’s native infrastructure by not specifying an IP Pool.
Yes! The Amazon SES Compatible API accepts the exact same request format as Amazon SES. You only need to change the endpoint URL and replace AWS Signature authentication with the X-SubAccount-ApiKey header.