Fix unknown_ca Error in AWS Lambda

What causes the unknown_ca error in AWS Lambda when verifying emails?

You’re running a Lambda function to verify email addresses, and suddenly every connection fails with an unknown_ca error. The same email server works fine from your local machine. Why?

The issue isn’t with the email server—it’s with Lambda’s trust store. When your function tries to establish a secure TLS connection, Lambda can’t validate the server’s certificate because it doesn’t recognize the issuing Certificate Authority (CA). Even if the certificate is perfectly valid, the handshake fails if the CA isn’t in Lambda’s trusted root list.

This happens because Lambda executes in a minimal, frozen environment without access to the latest system-level trust stores. Updates to root CAs (like intermediate or new global CAs) don’t automatically propagate to Lambda’s runtime environment, making some valid certificates appear untrusted.

Key takeaways

The unknown_ca error occurs when AWS Lambda cannot verify an email server's TLS certificate due to missing or outdated root CAs in its trust store.
Lambda’s execution environment uses a static set of root certificates that do not update dynamically, meaning new or less common CAs may be rejected even if their certificates are valid.
Even if your email verification code is correct, TLS failures due to trust-store gaps can cause legitimate connections to fail—especially with newer or region-specific email providers.

Why does AWS Lambda struggle with TLS certificate validation for email verification?

You get an unknown_ca error in AWS Lambda when verifying emails because Lambda’s runtime environment uses a hardcoded, static set of trusted Certificate Authorities (CAs). This set doesn’t update automatically and may not include newer or less common CAs, even if the email server is otherwise reachable. When an email verification tool tries to connect via SMTP to a provider like Gmail or Outlook, the connection fails if the server's certificate chain relies on a CA not in Lambda’s trusted list.

How Lambda’s static CA trust store creates real-world failures

Lambda runs in an isolated, minimal environment optimized for function execution. It ships with a fixed list of trusted CAs, updated only when AWS pushes a new runtime version. This means new or niche CAs—common in cloud-based email services—can easily fall outside the trusted scope. Even if the TLS handshake completes, an untrusted CA results in an unknown_ca error, regardless of the underlying server’s validity.

For example, some email verification services perform direct SMTP connections to mailbox providers. These connections require full TLS validation, including CA trust. If the provider uses a certificate signed by a CA not in Lambda’s trust store—like a newer regional or internal CA—the validation fails. This isn’t a network or domain issue; it's a trust layer problem.

Why this breaks email verification workflows

If you're building email verification logic in Lambda, relying on direct SMTP checks can lead to false negatives. The error isn’t from your code or the email address; it’s from the trust store’s limitations. This is especially common with providers using modern or less common certificate authorities, or when running from regions with older runtime versions.

While AWS is responsible for maintaining the CA store, there’s no way for you to update it dynamically inside Lambda. This requires either switching to a runtime with a more current CA set (like custom Amazon Linux 2 with updated certificates), or using an external service to handle verification on your behalf.

That’s where tools like bulk email verification come in. They run on dedicated infrastructure with up-to-date CA trust stores, avoiding the AWS Lambda constraint entirely. You send your list, and the service completes the SMTP handshakes from a validated, trusted environment, returning accurate results without unknown_ca errors.

For a more scalable and reliable approach without managing CA issues, consider using an external verification API instead of implementing SMTP checks directly in Lambda.

For deeper insight into certificate validation standards, refer to RFC 5280, which details certificate validity and trust chains in TLS.

How does email verification work under the hood in a serverless environment?

When you verify an email in AWS Lambda, your function connects to the recipient domain’s SMTP server using TLS. The handshake starts with the server sending its certificate. Lambda checks that certificate against a trusted CA list. If any part of the trust chain—especially the root CA—is missing or unrecognized, the connection fails with an unknown_ca error. This happens even if the email is valid.

Why TLS trust fails in Lambda

By default, AWS Lambda runs in a minimal environment. It doesn’t carry a full system CA store. If the server’s certificate relies on a CA not in Lambda’s internal trust store—like a private or self-signed CA—you see unknown_ca. This isn’t about the email address; it’s about the certificate’s trust path.

Initiate TLS handshake through an SMTP connection to the recipient’s mail server. The client (Lambda) sends a ClientHello message to begin encryption.
Receive the server’s certificate. The mail server responds with its digital certificate, including its public key and issuer details.
Validate the certificate chain. Lambda checks if the server’s certificate is signed by a trusted CA. It verifies every link, from the end-entity cert to the root CA, including intermediate certificates.
Check the root CA trust store. Lambda uses a limited set of root CAs approved by AWS. If the issuing CA isn’t on that list, the handshake fails. This includes internal CAs, older CAs like GeoTrust old roots, or custom CA setups.
Fail with unknown_ca if chain is incomplete. Even a missing intermediate or an expired root CA can break the chain. The error appears even with valid emails—this is a connectivity trust issue, not a deliverability one.

Fixing the root cause

For many cases, the fix isn’t in your code—it’s in your environment. If you control the target domain, ensure your certificate chain uses public CAs in AWS’s trust store. You can validate this using tools like SSL Labs’ SSL Test, which shows the full chain and any gaps.

For verification services, a real-time API that handles TLS handshakes securely will account for these edge cases. It uses updated CA bundles and can retry with different configurations. For example, our email verification API handles edge cases like this without you managing the CA store.

When running in Lambda, you can also use layers to add a full CA bundle. But this increases cold-start times and complexity. For production systems where email quality matters, using a dedicated verification service is often more reliable than managing TLS trust chains in Lambda.

What does 'unknown_ca' mean in TLS terms?

The unknown_ca error in TLS means the client (like your AWS Lambda function) cannot verify the server’s certificate because the signing Certificate Authority (CA) isn’t in its trusted certificate store. It’s not about expired certificates or self-signed ones—it’s that the CA exists, but your system lacks the root certificate needed to validate the chain. This is a client-side trust issue, not a server problem.

Why 'unknown_ca' isn't a server flaw

Let’s be clear: this error doesn’t mean the email server is misconfigured or insecure. It means your verification environment (in this case, AWS Lambda) doesn’t recognize the CA that issued the server’s SSL certificate. The CA might be perfectly legitimate—like Sectigo or DigiCert—but unless it’s in your runtime’s trust store, the connection fails.

Unlike certificate expiry or self-signed issues, unknown_ca happens when the CA is unknown to the client. The validation process stops early because the root isn’t trusted. You can confirm this using tools like SSL Labs’ SSL Test—it shows the full chain and flags missing or untrusted roots.

Common causes in AWS Lambda

On AWS Lambda, this happens because Lambda runs on a minimal, sandboxed environment. It doesn’t include every CA certificate by default. Some CAs, especially newer ones or niche providers, aren’t present in the default trust store. Even well-known CAs can trigger the error if their root isn’t up to date in the runtime environment.

Some AWS Lambda runtimes (like Python 3.9+ or Node.js 18+) ship with updated trust stores, but updates aren’t guaranteed to be instant. If your verification tool relies on TLS 1.3+ and encounters a certificate from an older or less common CA, unknown_ca is the signal.

It’s worth noting that unknown_ca is defined in RFC 5246, Section 7.2.1 as a standard TLS alert code. It’s not specific to AWS—it’s part of how TLS ensures trust chains are verified across the internet.

If you're building a Lambda function for email verification, you're likely validating domains via SMTP with TLS. If you're getting unknown_ca across multiple domains, it’s not a data issue—it’s infrastructure. You may need to bundle the missing CA certificate in your deployment package or use a runtime with a newer trust store.

For teams handling large lists, using a third-party verification service can eliminate this complexity. Bulk email verification handles TLS chains and trust validation at scale, so you don’t have to manage the underlying infrastructure.

Can you resolve unknown_ca without modifying Lambda’s trust store?

You cannot resolve the unknown_ca error in AWS Lambda by adding root CAs at runtime without using a custom runtime or container image. Lambda’s trust store is static and sealed by AWS—there’s no way to extend it via code, environment variables, or configuration. Any TLS connection requiring certificate validation must rely only on the pre-approved CAs baked into the runtime environment.

Why Lambda’s trust store can’t be extended

Behind the scenes, Lambda uses a hardened, minimal Linux environment with a fixed set of trusted root certificates. This is a security-by-default design. When your code attempts to verify a TLS connection to an email server whose certificate is signed by a CA not in that store, you get the unknown_ca error—regardless of whether the certificate is technically valid.

Even if you try to bundle a custom CA bundle into your deployment package, Lambda won’t load it unless you’re using a custom runtime or container image. This is not a bug or a misconfiguration—it’s how AWS enforces isolation and trust boundaries.

What this means for email verification in Lambda

Any email verification tool running inside Lambda—like a script checking inbox placement or validating addresses via SMTP—must work within this constraint. You can't patch in new root authorities on the fly. The only reliable path is to use services that either:

Communicate with servers using certificates issued by widely recognized CAs (like Let’s Encrypt, DigiCert, or GlobalSign), which are included in Lambda’s default trust store.
Or avoid direct TLS negotiation entirely by offloading verification to a system with a customizable trust store.

If you're building an email validation pipeline on Lambda, the practical workaround is not to manage certificates but to integrate with a verification service that handles those concerns for you. For instance, you could call the EmailListChecker API from Lambda—it manages TLS, performs real-time checks, and returns results without requiring you to manage the underlying trust layer.

How do email verification services like Emaillistchecker.io handle unknown_ca in serverless environments?

When your AWS Lambda function hits an unknown_ca error during email verification, it’s usually because the runtime environment lacks a current certificate trust store. Emaillistchecker.io avoids this entirely by handling verification on its own dedicated servers—complete with up-to-date certificate authorities—so you never need to perform an SMTP handshake from Lambda. You send emails via our API, and we manage the connection, side-stepping TLS issues in restricted environments.

Why Lambda can't reliably verify emails on its own

Lambda runs on a minimal, isolated runtime that doesn’t include a full trust store. Even if you bundle certificates, they may be outdated or incomplete. This leads to unknown_ca errors when trying to validate emails over TLS—especially with modern services using strict certificate chains. It’s not a flaw in your code, it’s a limitation of the environment.

How Emaillistchecker.io solves it

Instead of forcing you to verify emails directly from Lambda, we run the actual SMTP verification process on servers we control. Our infrastructure maintains a real, actively updated trust store—based on Mozilla’s CA bundle, which is the industry standard for TLS validation (see crt.sh for public certificate transparency). No need to modify Lambda’s runtime or manage certificates.

Our real-time verification API works by receiving your email list remotely. We check each address against the recipient’s mail server over HTTPS or SMTP, using fully trusted connections. The result—valid, invalid, risky, catch-all—is returned to you in seconds. You don’t run the verification step in Lambda at all.

Let’s say you’re sending a campaign to a 10,000-person list. You could spend days trying to patch Lambda’s trust store, or you could send the list to our real-time verification API, process it in minutes, and send only verified emails—without ever touching the TLS handshake from within Lambda.

With our approach, you get a 98.9% accuracy rate across all verifications, not just the ones that happen to connect without certificate errors. This includes catching disposable domains, role accounts, and catch-all addresses—capabilities that don’t depend on live SMTP connections from your Lambda environment.

What are the practical steps to avoid unknown_ca when verifying emails in AWS Lambda?

Run email verification through a managed API service like Emaillistchecker.io instead of hitting SMTP endpoints directly. This avoids TLS handshake failures caused by Lambda’s outdated trust store. If you must use Lambda, isolate the verification in a container with a custom trust store, but be prepared for increased complexity and maintenance.

Why direct SMTP checks in Lambda fail

Lambda environments run on a hardened, minimal OS with an outdated root CA bundle. When your function tries to connect to a mail server via TLS, it can't validate the certificate if the CA isn’t in its trust store. This triggers the unknown_ca error — a direct consequence of missing or expired certificate authorities, not your code.

While RFC 5280 defines certificate validation, real-world systems like AWS Lambda don’t update their trust stores frequently. This means even valid certificates fail to verify when the CA isn’t recognized. You can check current trust store status on public tools like MxToolbox’s SSL Check, which shows how certificate chains fail across different systems.

How to fix it properly

Use a trusted email verification API such as Emaillistchecker.io's real-time API. It handles TLS negotiation, domain validation, and catch-all detection behind the scenes, so you don’t need to open raw connections in Lambda.
Avoid writing custom email validators that require open TLS connections to arbitrary domains. These systems are brittle and fail silently when the CA list lags behind real-world changes.
If you must keep the verification logic inside Lambda, deploy it in a container with an up-to-date trust store (e.g., Alpine with updated ca-certificates). But be aware this increases cold start time, security surface area, and long-term maintenance.
Don’t hardcode CA bundles. They expire, and updates require rebuilding and redeploying your function.
Monitor for errors via CloudWatch logs. unknown_ca is a clear signal that your Lambda environment can’t trust remote endpoints — not a failure in your email list or logic.

Let’s be clear: you’re not fighting a bug. You’re fighting a design constraint. The solution isn't more code — it's offloading the complexity.

Managed services like Emaillistchecker.io don’t just avoid unknown_ca — they eliminate the need to manage TLS trust stores altogether. They use dedicated, maintained infrastructure and provide structured results: valid, invalid, catch-all, risky. You get a 98.9% verified accuracy rate without touching raw SMTP sessions or trust store management.

How does Emaillistchecker.io ensure high accuracy without relying on Lambda's TLS stack?

You don’t need to fix Lambda’s TLS issues because Emaillistchecker.io never uses Lambda’s TLS stack for email verification. Instead, it runs verification through a globally distributed network of endpoints with fully trusted certificates and strict validation—so errors like unknown_ca never occur. This design maintains 98.9% accuracy, even when AWS Lambda’s environment fails to validate newer or less common certificate authorities.

Behind the scenes: Trusted infrastructure, not Lambda’s sandbox

Let’s be clear: Lambda’s execution environment is isolated. It runs in a container with a limited, sometimes outdated, set of root certificates. That’s why unknown_ca errors happen—they’re not about your email; they’re about missing trust anchors in the runtime. Emaillistchecker.io avoids this entirely by never spinning up verification tasks inside Lambda.

Instead, we run checks from our own infrastructure. Our endpoints are distributed across data centers with updated trust stores, regular certificate rotations, and compliance with RFC 6125, the standard for TLS certificate validation. These are not AWS-only systems. They’re maintained to industry standards, not constrained by function execution limits.

No SMTP handshakes from Lambda—just reliable, offloaded verification

We don’t perform SMTP handshakes from Lambda. That would expose us to the same TLS trust issues you’re seeing. Instead, we route all verification to our private network of verification nodes. These nodes initiate real SMTP sessions from trusted IPs, validate TLS handshakes properly, and handle all edge cases, including catch-all accounts, greylisting, and role-based email patterns.

Because our verification logic runs outside Lambda—fully isolated from its environment—your list accuracy isn’t at the mercy of a changing or incomplete root store. Whether you're using our bulk verification tool, real-time API, or testing inbox placement, the results come from a system designed to be resilient, not brittle.

That’s why, across thousands of verifications, our accuracy remains consistently high. It’s not a magic number—it’s infrastructure designed to avoid failure at the source.

When should you avoid direct email verification in serverless functions?

You should avoid direct email verification in AWS Lambda or similar serverless environments when the target email domain uses a newer or less common Certificate Authority (CA), or when the runtime environment has a static TLS trust store. This can lead to unknown_ca errors during SMTP handshake attempts, even if the email is valid. These functions often run with outdated or restricted CA bundles, and you can’t easily update them. When accuracy and reliability are essential—like in lead quality workflows or sending campaigns—the risk of false negatives outweighs the benefit of low-level control.

When newer or less common CAs are in play

Some domains now use newer CAs (e.g., Let’s Encrypt’s internal root updates) not present in older TLS trust stores.
Even if the certificate is valid, the handshake fails in serverless functions with outdated or incomplete CA bundles.
For example, a 2023 update to Let’s Encrypt’s trust chain caused issues in environments using OpenSSL 1.0.2—common in older Lambda runtimes.
Check your CA bundle version: AWS Lambda currently ships with a static, pre-bundled certificate list that doesn’t update in real time [AWS Lambda Documentation].

When static trust stores limit your control

Serverless runtimes like AWS Lambda don’t allow you to dynamically update the root CA store at runtime.
If you're relying on direct SMTP verification through libraries like Node.js’s smtp-connection or Python’s ssl module, you're constrained by the runtime’s fixed trust chain.
Even if you package custom CAs, AWS Lambda’s environment sandboxing often blocks file access or execution of custom CA updates.
This is especially risky for domains with less widespread or non-standard CAs—e.g., internal corporate domains, regional providers, or new entrants without broad CA inclusion.
When you need consistent accuracy across all domains, relying on direct verification in such environments becomes unreliable.

Let’s be clear: direct verification in Lambda works fine for common domains with widely accepted CAs. But when you’re dealing with edge cases—like a startup using a lesser-known CA or a large enterprise with internal PKI—you’re more likely to hit unknown_ca errors from outdated trust stores. In these cases, the cost of false declines is too high. A third-party email verification service reduces this risk by handling TLS and CA validation at the infrastructure level.

Instead of managing trust stores, you can use a verified, up-to-date service. Bulk verification with EmailListChecker.io skips this complexity entirely, validating millions of emails using real-world SMTP connections with modern CA bundles, while reporting accurate verdicts—even for domains that would otherwise fail in Lambda.

What is the most reliable way to verify bulk email lists in AWS Lambda?

You can reliably verify bulk email lists in AWS Lambda by calling the Emaillistchecker.io real-time verification API. It handles TLS handshake, certificate validation, and SMTP interactions outside of Lambda’s limited runtime environment, avoiding unknown_ca errors and other connectivity issues. Results return clear verdicts—valid, invalid, catch-all, or risky—without certificate-related failures.

How to avoid TLS and certificate errors in Lambda

Lambda’s execution environment restricts access to system-level certificates and can’t handle dynamic SSL/TLS handshakes reliably. This causes unknown_ca errors when trying to connect to SMTP servers directly.

Instead, offload the entire verification process to a trusted external service. Emaillistchecker.io manages TLS negotiation and certificate validation on servers with full root store access—no need to configure trust stores or patch certificates in your Lambda function.

Set up the Emaillistchecker.io API key in your Lambda environment variables for secure access, then call the API endpoint via HTTPS.
Send your email list as a payload in a structured format (e.g., JSON array), with each email as a string.
Process the response in real time—each email returns a verdict: valid, invalid, catch-all, or risky, with no error due to certificate chains.
Store or act on results immediately—skip invalid emails, flag risky ones, or enrich your list with verified addresses.
Scale safely—since the API handles SMTP sessions, you avoid rate limits and timeouts tied to Lambda’s execution time and concurrency.

The 5 steps described in “How to avoid TLS and certificate errors in Lambda”, in order.

Why external verification is more dependable

Even with custom certificates packaged into your Lambda deployment, certificate validation failures persist due to outdated or incomplete root stores. This is not a flaw in Lambda itself, but a design limitation of isolated runtimes. The RFC 5280 defines certificate validity, but it assumes full trust store access—something Lambda does not provide by default.

By using a dedicated API like Emaillistchecker.io, you ensure compatibility with RFC-compliant SMTP servers while bypassing Lambda’s constraints. This approach consistently avoids unknown_ca and other TLS-related errors seen in scripts trying to verify email addresses directly in serverless functions.

You get accuracy, speed, and reliability—all without managing certificates or retry logic. For full-scale list cleanup, explore bulk verification with direct uploads, or integrate via our real-time verification API.

Final takeaway: unknown_ca is not a problem with your email list — it’s a limitation of the infrastructure

The unknown_ca error in AWS Lambda indicates a failure in TLS certificate validation at the client layer, not an issue with the email address itself.

Even a perfectly clean list will fail to verify from Lambda if the underlying trust store lacks the required CA certificates, especially in older or minimal runtime environments.

Why direct verification from Lambda fails

Lambda’s default trust store may not include newer or less common Certificate Authorities.
This leads to TLS handshake failures, even when the target mail server is valid and reachable.
Such errors are consistent across verified addresses — meaning the problem is infrastructure, not data quality.

The reliable alternative

Using a third-party email verification service eliminates these runtime limitations by performing checks from trusted, widely maintained infrastructure.

These services handle TLS validation, deliverability scoring, and bounce patterns — all without requiring you to manage trust stores or network configurations.

Sources

DMARC adoption among the world's top 1.8 million domains jumped from 27.2% in 2023 to 47.7% in 2025 — a 75% surge driven by Google and Yahoo's sender rules. — EasyDMARC DMARC Adoption Report 2025 (2025)
By early 2026, 937,931 of 1.8 million analyzed domains had valid DMARC records — up 79% in three years — but about 56% of them still sit at monitoring-only p=none. — DMARC Report (EasyDMARC 2026 data) (2026)

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does unknown_ca mean when verifying emails in AWS Lambda?

It means the Lambda environment cannot trust the server’s TLS certificate because the issuing CA is not in its static list of trusted root CAs.

Can I update the root certificate store in AWS Lambda?

No. AWS Lambda uses a fixed, preloaded trust store that cannot be modified at runtime or during deployment.

Does unknown_ca indicate an invalid email address?

No. It indicates a TLS connection failure due to certificate trust, not the validity of the email itself.

How does Emaillistchecker.io avoid unknown_ca errors?

It performs verification on servers with updated trust stores, never from within Lambda, so certificate issues don't affect results.

Can I use a Lambda function to verify emails with high accuracy?

Direct SMTP-based verification in Lambda is unreliable due to TLS limitations. Use an API instead.

Why is Emaillistchecker.io more accurate than custom Lambda-based verification?

It avoids the TLS trust issue entirely by running verification outside of serverless environments with consistent, updated trust stores.

What happens if my Lambda function fails due to unknown_ca?

The verification fails, even if the email is valid — leading to false negatives and wasted processing.

Should I disable certificate validation to avoid unknown_ca?

No. Disabling TLS validation creates security risks and undermines deliverability safety.

What are valid alternatives to direct Lambda verification?

Use a third-party email verification API like Emaillistchecker.io, which handles all TLS and SMTP logic outside of Lambda.

How many free verifications does Emaillistchecker.io offer?

You get 100 free email verifications to start, with purchased credits that never expire.

Does Emaillistchecker.io support bulk verification in AWS?

Yes. You can verify large lists through its API and integrate it into Lambda workflows securely and reliably.

What types of emails does Emaillistchecker.io identify as risky?

It flags disposable, role-based, catch-all, or high-bounce-risk addresses based on real-time checks and deliverability signals.