When email features stop working inside a Tomcat web app, the problem is usually not with Tomcat itself. In most hosted environments, the issue is caused by mail server settings, blocked outbound ports, incorrect authentication, missing JavaMail libraries, or application code that does not match the hosting platform’s SMTP requirements. If your app runs on a managed Java hosting service such as a Plesk-based Tomcat setup, the right approach is to check the mail configuration, the app server setup, and the hosting account limits in a logical order.
In a typical Java hosting environment with a private JVM or Apache Tomcat instance, email sending is handled by the application through SMTP. Tomcat does not provide mail delivery by itself. Your web app must connect to an external mail server or a mail service configured in the hosting control panel. If that connection fails, features such as contact forms, password resets, invoice notifications, and background email jobs will stop working even though the web app is otherwise online.
Why email features fail in a Tomcat web app
Email failures in Tomcat usually happen because one of the following layers is misconfigured:
- the application code or framework email settings
- the JavaMail library or application dependencies
- the SMTP host, port, username, or password
- SSL/TLS settings for the mail connection
- firewall or outbound network restrictions
- account limits or security rules in the hosting platform
- background jobs that are not running or are failing silently
In a hosted Tomcat environment, these issues are often seen after a deployment, after a Java version change, or after moving an app from local development to production. Local mail testing may work with a relaxed configuration, but the hosted server usually requires proper authentication and secure SMTP settings.
Common symptoms
You may be dealing with an email-related problem if you notice any of the following:
- forms submit successfully, but no email is sent
- password reset links are never delivered
- Tomcat logs show SMTP connection errors or authentication failures
- email works in development but fails on the hosted server
- background tasks run, but the mail queue stays empty
- messages are generated but never reach the recipient
- the application hangs while trying to send mail
If the app is using a background scheduler or worker thread, you may also see related issues where scheduled notifications do not fire, even though the mail code itself is correct.
How Tomcat handles email sending
Tomcat is a servlet container, not a mail server. That means your application must use JavaMail, Spring Mail, Jakarta Mail, or another library to connect to an SMTP server. In a My App Server setup, the app runs inside its own JVM and Tomcat instance, so it can send mail as long as the SMTP destination is reachable and correctly configured.
The usual flow is:
- The web app creates an email message.
- The app connects to an SMTP server over a network port.
- The SMTP server validates credentials and security settings.
- The message is accepted and delivered onward.
If any step fails, the user-facing feature may appear broken. That is why email problems should be diagnosed from the application logs, the Tomcat logs, and the hosting control panel settings together.
First checks in a managed hosting control panel
In a Plesk-based Java hosting account, start with the basic infrastructure checks before changing code.
Verify the SMTP server details
Confirm that the app is using the correct mail server hostname, port, username, and password. A common mistake is using a local host value such as localhost when the hosted app must use an external SMTP service or the hosting provider’s mail endpoint.
Check whether secure mail is required
Many hosting platforms require SMTP over TLS or SSL. If your app uses a plain connection on a secure-only port, the connection will fail. Likewise, using the wrong port for the selected security mode can cause timeouts or handshake errors.
Review account limits
Shared hosting plans and managed app server environments often include mail-related limits such as sending quotas, rate limits, or outbound connection rules. If the account has reached a limit, the platform may reject new messages even if the application code is working correctly. For service-specific limits, always check the account policy and the service usage notes in the control panel.
Confirm that the app server is running
In a Tomcat hosting setup, the application server must be active for both web requests and background jobs. If the service has stopped, your mail features will not run. Use the service control tools in the panel to verify that the Tomcat instance and the private JVM are up and healthy.
Application-level causes and fixes
Missing JavaMail dependency
If the application uses JavaMail or Jakarta Mail and the library is missing from the deployment, email sending can fail at runtime. This is common after a manual deploy or when a WAR file is rebuilt without the required dependency.
Check that the relevant mail library is included in the application package or referenced by the build tool. If the app works in one environment but not another, compare the deployed WAR contents and dependency versions.
Wrong SMTP authentication
Hosted environments usually require authenticated SMTP. If the application sends mail without credentials, or if the username and password are outdated, the server may reject the connection. Recheck:
- SMTP username format
- password or app password
- authentication enabled in the code
- stored secrets and environment variables
When credentials are stored in configuration files, confirm that the correct file is deployed and that the values are not being overridden by a production profile.
Incorrect port or TLS settings
SMTP commonly uses ports such as 25, 465, or 587, but the exact port depends on the provider and the security mode. A mismatch between port and encryption settings is one of the most frequent causes of failure.
Typical examples:
- port 465 usually expects SSL from the start
- port 587 often uses STARTTLS
- port 25 may be blocked or restricted by the hosting environment
If your app times out or shows handshake errors, compare the Java mail properties with the mail service documentation and the hosting platform rules.
Bad sender address or domain mismatch
Some SMTP servers reject messages if the sender address does not match an authorised domain or verified mailbox. For hosted apps, this often happens when the application uses a generic from-address such as no-reply@yourdomain without the necessary mailbox or DNS setup.
Make sure the sender address is valid, can receive mail if needed, and is allowed by the SMTP service.
Silent exception handling
Another common issue is poor error handling in the application. The email send may fail, but the app catches the exception and hides it. This makes the problem look like a delivery issue, when in fact the send call never completed.
Log the full exception, including the SMTP response code and stack trace. In Tomcat, useful clues are often found in the application log rather than the browser output.
Tomcat and JVM checks
Review the Tomcat logs
Start with the logs for the application server and the deployed app. Look for:
- connection refused messages
- authentication failures
- certificate or SSL errors
- DNS lookup errors
- socket timeout errors
- class not found errors for JavaMail classes
If the app runs in a hosted private JVM, a runtime or classpath issue may affect how mail libraries are loaded. This is especially relevant when using a custom Tomcat version or a manually uploaded app server configuration.
Check the Java version
Some email libraries behave differently across Java versions, especially when it comes to TLS support. If the hosting platform allows multiple Java versions, make sure the app is running on the version expected by the application framework and mail library.
After a Java update, test email features again. A version change can affect trust store handling, TLS protocols, or deprecated APIs used by older mail code.
Inspect the JVM security and trust store
If SMTP uses SSL/TLS, certificate validation can fail when the JVM does not trust the mail server certificate chain. This is more likely when the mail service uses a custom certificate or when the application connects to a third-party SMTP relay.
In that case, verify:
- the certificate chain is complete
- the hostname matches the certificate
- the JVM trust store includes the necessary CA certificates
Network and firewall restrictions
Even when the application is correct, the hosted environment may block outbound mail connections. This is particularly relevant in shared hosting or controlled app server environments where certain ports are restricted to protect the platform.
If mail sending fails only on the hosted server, test the same SMTP settings against an allowed port. If the host blocks port 25, switch to the recommended authenticated submission port, usually 587 or 465, depending on the mail provider.
DNS can also cause failures. If the SMTP hostname cannot be resolved from the app server, the connection will fail before authentication begins. In that case, check the hostname spelling and make sure the server can reach external DNS lookups.
Background jobs and scheduled email tasks
Many web apps do not send mail directly in the request thread. Instead, they queue messages or run background tasks such as:
- scheduled digests
- reminder emails
- password reset dispatch jobs
- order confirmation workers
- cleanup tasks that send alerts
In a Tomcat hosting environment, these jobs may rely on a scheduler inside the application or on a separate worker process. If the scheduler is not active, background email features may stop even while the website itself appears normal.
Check whether the app uses:
- Spring scheduled tasks
- Quartz jobs
- custom executor services
- JMS or queue-based workers
If the hosting account allows a private JVM and dedicated service control, confirm that the process handling the job is actually started and remains running. A web-only deployment can serve pages without running background tasks continuously.
Practical troubleshooting steps
Step 1: reproduce the failure with a simple test message
Send a plain test email from the application using the same SMTP configuration that production uses. Avoid templates, attachments, and background queues at first. This helps isolate whether the problem is in the mail transport or in the app logic around it.
Step 2: compare working and failing environments
If email works locally but not on the hosted Tomcat app, compare:
- SMTP host and port
- security mode
- Java version
- mail library versions
- environment variables
- server-side limits
Step 3: check server logs immediately after a send attempt
Logs are most useful right after a failure occurs. Search for the exact error line and the SMTP response. This will often point directly to authentication, TLS, or network issues.
Step 4: validate credentials outside the app
If allowed by your hosting policy, test the mailbox or SMTP relay credentials with a mail client or a simple SMTP test tool. If the credentials fail outside the app too, the issue is not in Tomcat.
Step 5: review the deployment package
Confirm that the WAR contains all required dependencies and configuration files. If your build separates email settings into environment-specific profiles, make sure the production profile was deployed.
Step 6: check whether the issue started after a platform change
Email failures often begin after:
- a Tomcat upgrade
- a Java version change
- a password rotation
- new firewall rules
- a deployment rebuild
- mail service policy changes
Identifying the change point helps narrow down the root cause much faster.
Recommended configuration pattern for hosted Tomcat apps
For a managed Java hosting setup, a stable pattern is to keep mail configuration outside the code where possible and store it in environment-specific settings. This makes it easier to update SMTP values without rebuilding the application every time.
A practical setup usually includes:
- a dedicated SMTP host or relay
- authenticated submission on the provider-recommended port
- TLS enabled where required
- valid sender addresses for the domain
- timeouts and retry handling in the application
- clear logging for all send failures
If you use a Plesk extension for Java hosting such as My App Server, keep the Tomcat service, Java version, and deployment settings aligned with the application’s mail requirements. That is especially important when running a private JVM or a custom Apache Tomcat instance inside a shared hosting account.
Examples of correct and incorrect setups
Example of a common incorrect setup
- SMTP host set to localhost
- port set to 25
- no authentication configured
- TLS disabled even though the server requires it
- no log output for send errors
This usually works only in a local developer machine and fails on the hosted server.
Example of a more reliable setup
- SMTP host set to the correct external mail service
- authenticated submission enabled
- port matches the security mode
- valid username and password stored securely
- mail exceptions written to the app log
- background jobs monitored through the Tomcat service
This approach is more suitable for a managed hosting environment because it reduces dependency on local server assumptions.
FAQ
Does Tomcat send emails by itself?
No. Tomcat runs the Java web application, but the app must connect to an SMTP server using a mail library such as JavaMail or Jakarta Mail.
Why does email work locally but fail on hosting?
Local environments often allow relaxed SMTP settings or test servers. Hosted servers usually require authenticated SMTP, secure connections, and valid outbound access.
Can the hosting control panel block email sending?
Yes. Some hosting platforms apply outbound mail restrictions, port rules, or account limits. Check the service usage and limits in the control panel.
What should I check first if password reset emails stop working?
Start with the SMTP credentials, the sender address, the Tomcat logs, and the background job status. Password reset mail often depends on both application code and a scheduler.
Do I need a separate mail server for a Tomcat app?
Not necessarily. You need a working SMTP service. That can be an external mail provider, a relay, or the hosting platform’s supported mail service, depending on your setup and policy.
Can Java version changes affect email delivery?
Yes. Java updates can affect TLS support, certificate validation, and mail library compatibility. Always retest email features after a Java change.
When to contact hosting support
Contact support if you have already checked the application settings and you still see network or service-level errors. Provide the following details to speed up troubleshooting:
- the exact error message from the log
- the SMTP host and port used by the app
- the Java version selected for the Tomcat instance
- the Tomcat service status
- whether the issue affects only background jobs or also direct sends
- the time of the failed test attempt
If the app is hosted in a My App Server environment, support can usually help confirm whether the issue is inside the application, inside Tomcat, or caused by platform-level mail restrictions.
Summary
Email features inside a Tomcat web app usually fail because the SMTP configuration, Java mail library, security settings, or hosting platform restrictions are not aligned. In a managed hosting setup, the quickest path to resolution is to check the logs, verify SMTP credentials and ports, confirm the Tomcat and JVM status, and review any outbound mail limits in the control panel. For apps running on a private JVM or Apache Tomcat instance, stable email delivery depends on correct application configuration and a mail service that the hosting environment can actually reach.
Once the mail transport is correct, background jobs and transactional email features such as contact forms, alerts, and reset messages should work reliably within the hosted Java application.