Skip to content

Puzzling AWS SES / Lambda Issue: Console Works, Lambda Fails?

0

I'm facing a critical and perplexing issue with Amazon SES in us-east-2 (Ohio) that's preventing my Lambda function from sending emails, despite successful console tests. I'm developing a contact form using AWS Lambda (Node.js 18.x) and SES. My Lambda function calls ses.send(new SendEmailCommand(params)) to send emails.

The Core Problem: My Lambda function consistently receives a SESServiceException [ValidationError]: Value at 'source' failed to satisfy constraint: Member must not be null. This causes my Lambda to return a 500 Internal Server Error to the frontend, and emails are NOT sent when triggered by Lambda.

Observation: When I send a test email directly from the SES console the email is successfully delivered (it arrived in spam, but delivery was confirmed). This indicates the email is functional and verified.

What I've already tried (and confirmed): FROM_EMAIL and TO_EMAIL environment variables are correctly read within Lambda logs. The FromEmailAddress parameter in the SendEmailCommand is indeed the same email(confirmed via console.log of the params object just before the send call).

Deleted and re-verifiedmy email in SES identities (us-east-2). Checked SES suppression list (email is not listed). Confirmed Lambda's IAM role (LambdaSesRole) has AmazonSESFullAccess, and specifically the SES action Resource is "*" (meaning it should allow sending from ANY verified identity). There are no explicit Deny statements. Given that direct console sends work, but Lambda-initiated sends fail with this specific validation error, it strongly suggests a nuanced issue related to the SES sandbox's interaction with IAM roles for sending identities.

My Questions: Could you please investigate why this ValidationError is occurring specifically when Lambda attempts the send, despite the console test working and comprehensive IAM permissions? Should I proceed with requesting production access, and is this a known sandbox behavior?

Thank you for your time and assistance.

Best regards

3 Answers
0

Root Cause The error: SESServiceException [ValidationError]: Value at 'source' failed to satisfy constraint: Member must not be null means the Source (i.e., the FromEmailAddress) is undefined or null when passed to SES, despite your Lambda logging the correct value. This is not an IAM issue or a sandbox limit (yet).

Most Likely: The FROM_EMAIL environment variable might be missing, misnamed, or have an invisible character (like a space or newline). console.log() might show a value, but that doesn’t mean it’s valid when passed into the actual SDK call. SES needs an explicit, non-empty string for the Source field; even one small issue can break it.

Cross Check: Your Lambda is running in the same region as SES (us-east-2 in your case) The FROM_EMAIL is verified in SES You’re using the correct name in your Lambda env vars; even a typo or case difference can silently fail

answered a year ago

EXPERT

reviewed a year ago

  • Based on the CloudWatch logs I've reviewed, I can confidently rule out the FROM_EMAIL environment variable being undefined, null, misnamed, or containing invisible characters at the point of the SES SDK call.

    Here's why:

    1. Lambda Init Logs: Early in the Lambda's execution, the logs clearly showed: INFO Lambda Init - FROM_EMAIL: my-correct email This confirms the process.env.FROM_EMAIL variable was correctly read by my Lambda runtime.
    2. More critically, the console.log statement I added directly before await ses.send(new SendEmailCommand(params)); showed the exact params object being passed to the AWS SDK.

    This situation strongly suggests that the issue is external to Lambda's code:

    It points back to a behavior within the AWS SES service itself, specifically when operating in the sandbox mode. The fact that sending from the SES console works, but sending from your Lambda (with correct IAM permissions and correct parameters + clearly verified email on the console) does not, highlights a distinction in how SES processes requests originating from different sources in the sandbox. I was thinking that the ValidationError message might be misleading in this context, as the value for source is clearly not null.

0

Based on the information provided, it appears you're encountering a validation error in your Lambda function when trying to send emails via Amazon SES, despite successful tests from the SES console.

The error message "Value at 'source' failed to satisfy constraint: Member must not be null" specifically indicates that the 'source' parameter (which is the sender's email address) is either missing or null when your Lambda function attempts to send the email.

Here are some potential causes and solutions:

  1. Environment Variable Issues: While you mentioned that your environment variables are correctly read in Lambda logs, there might be an issue with how they're being accessed or processed in your code. Double-check that the FROM_EMAIL value is properly assigned to the 'source' field in your SendEmailCommand parameters.

  2. Code Execution Flow: There might be a conditional statement or asynchronous operation in your code that's causing the source parameter to be undefined when the SendEmailCommand is executed. Ensure that your environment variables are fully loaded before attempting to send the email.

  3. Parameter Structure: Verify that your params object is correctly structured according to the SES API requirements. The 'source' field needs to be properly defined in the SendEmailCommand parameters.

  4. Lambda Execution Context: Lambda functions can sometimes behave differently than local environments due to the execution context. Make sure your code handles any potential race conditions or timing issues.

  5. SES Sandbox Restrictions: While in the SES sandbox, you can only send emails to verified addresses. Ensure that both your sender and recipient addresses are verified in SES. This is different from the console test, which might have different verification requirements.

To troubleshoot further:

  • Add more detailed logging right before the SendEmailCommand call to verify the exact structure of your params object
  • Try hardcoding the source email address directly in your code (temporarily) to see if that resolves the issue
  • Check if there are any transformations or manipulations of the environment variables that might be causing the source to become null
  • Ensure your Lambda function has enough execution time and memory allocated

If these steps don't resolve the issue, requesting production access might help, but it's important to fix the underlying validation error first, as it suggests a code or configuration issue rather than a sandbox limitation.
Sources
sending email from lambda function within private subnet in vpc | AWS re:Post
Getting "Unverified" when sending emails with AWS SES using a verified email with my company domain | AWS re:Post
Send Mail on AWS Lambda NodeJS with Nodemailer | AWS re:Post

answered a year ago

EXPERT

reviewed a year ago

0

I agree, the logs show that FROM_EMAIL is being read and passed correctly. But from past experience, SES’s "ValidationError: source must not be null" error can still happen in cases where the value looks right but fails internal validation especially if:

The email isn’t verified in the same region (us-east-2)

The SDK request silently fails due to encoding issues or invisible characters

The SES sandbox enforces more strict validation via the SDK/API than what the Console UI does

Even if the email is technically present, SES may be rejecting it before it hits the sending phase.

To move forward, I’d suggest testing:

Wrapping process.env.FROM_EMAIL in .trim() (just in case)

Confirming the email is verified in us-east-2

Trying sendRawEmail() instead of sendEmail() , that sometimes helps isolate whether the issue is with request structure vs. SES identity checks.

Totally understand where you're coming from, and agree the error message is misleading.

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.