If email-related features in a JSP web app stop working, the cause is usually not the JSP code itself, but the way the application server, mail settings, and hosting controls are configured. In a managed hosting environment, especially when using a private JVM or Tomcat instance through Plesk, email sending can fail because of incorrect SMTP details, blocked ports, authentication errors, missing DNS records, or a background job that never starts.
This applies whether your app sends account notifications, password resets, order confirmations, or scheduled email tasks. The quickest way to resolve the issue is to separate the problem into two parts: mail sending from the web app and background execution of jobs. Once you know which part fails, the fix is usually straightforward.
Common reasons email features fail in a JSP application
In JSP hosting and Tomcat hosting environments, email problems typically fall into one of these categories:
- Wrong SMTP host, port, username, or password
- Authentication disabled or unsupported by the mail provider
- Firewall or outbound network restrictions
- Application tries to send mail from a background task that is not running
- Tomcat/JVM restart cleared an in-memory queue or scheduler
- DNS, SPF, DKIM, or sender address issues
- Expired certificates or TLS/SSL mismatch
- Mail library misconfiguration in web.xml, properties files, or environment variables
For hosted JSP applications, the most common mistake is assuming that email sending is automatic once the app is deployed. In reality, the app must connect to an SMTP service that accepts outbound messages, and any scheduled or queued mail processing must be supported by the runtime.
Check whether the problem is sending mail or running a job
Many web applications use two separate mechanisms:
1. Direct mail sending from a request
This happens when a user triggers an action, such as signing up or resetting a password, and the JSP application immediately sends an email through SMTP.
2. Background jobs or scheduled tasks
This is used for nightly reports, reminders, queue processing, or bulk notifications. If the job engine is not active, the email is never sent even if the SMTP settings are correct.
On a hosted Tomcat instance, both parts must be configured correctly. If your app uses a private JVM or a dedicated Tomcat service managed through Plesk, make sure the background process starts automatically and stays within the service limits of your hosting plan.
Verify the SMTP settings inside the JSP app
Start by checking the application’s mail configuration. In many Java web apps, SMTP settings are stored in a properties file, XML config, environment variables, or application-specific admin panel.
Confirm these values
- SMTP host - for example, smtp.example.com
- SMTP port - commonly 25, 465, or 587
- Username
- Password or app-specific password
- From address
- Security mode - SSL, STARTTLS, or none
Make sure the application is using the correct port for the chosen security mode. A very common issue is trying to use SSL on a STARTTLS port, or the reverse.
Typical port usage
- 25 - often used for server-to-server delivery, but may be restricted
- 465 - implicit SSL/TLS
- 587 - submission port, usually with STARTTLS
If your mail provider requires authentication, the app must log in with valid credentials. Some providers also require an app password rather than the main mailbox password.
Test the SMTP connection from the hosting environment
If the app cannot send mail, verify whether the hosting environment can reach the SMTP server. In managed hosting, outbound connection rules and network policy can affect this.
What to test
- Can the server resolve the SMTP hostname?
- Can it connect to the SMTP port?
- Does authentication succeed?
- Does TLS negotiation complete without errors?
If you use a custom Tomcat instance through My App Server, check logs from the Java application and from the Tomcat service. A failed connection usually produces a clear error such as connection timeout, authentication rejected, handshake failure, or refused connection.
For example, if the log shows a timeout, the SMTP host may be unreachable. If it shows authentication failure, the credentials or authentication method are likely incorrect. If it shows a TLS handshake problem, the certificate, protocol, or port combination is probably wrong.
Review Tomcat and My App Server configuration
In a JSP hosting setup using My App Server, email problems can be linked to how the Java service is installed and managed in Plesk. Since the platform can run a private JVM and a separate Apache Tomcat instance, the application may behave differently than on a shared system-wide Java installation.
Check the following
- Correct Java version for the application
- Tomcat service status
- Deployment location of the WAR or exploded app
- Application restart after configuration changes
- Environment variables loaded into the JVM
If the application depends on a JavaMail library, make sure the library is included in the deployment. Missing mail jars can lead to class loading errors or silent failures depending on how the app handles exceptions.
When using a custom app server setup, confirm that the service is started through the control panel and that the expected JVM is assigned to the site. If the wrong runtime is selected, the app may start but email code may fail because of unsupported library versions or incompatible TLS support.
Look for errors in application and Tomcat logs
Logs are usually the fastest way to identify the root cause. In JSP and servlet hosting, the relevant logs may include:
- Tomcat Catalina logs
- Application logs
- Java stack traces
- Mail provider error responses
Common log messages and what they usually mean
- Authentication failed - username, password, or app password is wrong
- Connection timed out - network access to the SMTP server is blocked or unavailable
- Could not convert socket to TLS - SSL/TLS mismatch or certificate issue
- Address rejected - sender address is not allowed or not verified
- ClassNotFoundException for mail classes - missing JavaMail dependency
- Scheduler thread not running - background task did not start after deploy or restart
If your application only fails when sending email from a scheduled task, the issue may be in the job runner rather than SMTP itself. For example, a job can stop working after a JVM restart if it was stored only in memory and was not configured to start again automatically.
Check whether background jobs are actually supported by your app design
Some JSP applications rely on in-process schedulers such as Quartz, Spring scheduling, or custom timer threads. These can work well for small and medium applications, but they must be designed with hosting limits in mind.
What can go wrong
- The job starts only during the first request and never again
- The scheduler depends on a process that stops on restart
- The app uses a memory queue with no persistence
- The thread pool is too small or exhausted
- The task is disabled in a config file
In a managed hosting environment, if the app is redeployed or the Tomcat service is restarted, scheduled mail jobs should come back cleanly. If they do not, the application may need a persistent job store or a startup hook that initializes the scheduler properly.
For periodic email delivery, also check whether the job’s time zone matches the expected schedule. A cron expression set for a different zone can look like a failure when it is actually running at the wrong time.
Validate sender identity and DNS requirements
Email delivery is not only about sending. Many providers reject or flag mail if the sender domain is not configured correctly. This can affect password reset messages, contact forms, and transactional notifications.
Check these DNS and sender items
- SPF record authorizes the sending service
- DKIM signature is enabled if the provider supports it
- DMARC policy does not block legitimate mail
- From address matches the verified domain or allowed mailbox
- Reply-to is set correctly if different from From
Even if the message is successfully submitted by the JSP app, poor authentication at the domain level can reduce deliverability or cause the mail to be rejected by some providers. This is especially important for UK-facing sites that send account emails to public providers such as Gmail, Outlook, and business mail systems.
Confirm TLS and certificate compatibility
Modern SMTP services usually require encrypted connections. If your Java app uses an outdated Java version or old mail library, TLS negotiation may fail.
Things to check
- Java version supports the required TLS protocol
- The SMTP server certificate is valid and not expired
- The hostname in the SMTP setting matches the certificate
- The app uses the right protocol for the selected port
If your hosting account uses a private JVM through My App Server, choosing a modern Java version can help avoid TLS issues. This is one reason why control over the Java version is useful in JSP hosting.
Check limits and resource usage
Email functions can also fail when the application hits resource limits. In shared hosting or managed Java hosting, heavy sending bursts, stuck threads, or repeated retry loops may hit service limits or exhaust memory.
Watch for these signs
- High memory usage during mail generation
- Slow queue processing
- Repeated retry loops after SMTP failure
- Thread exhaustion in Tomcat
- Service restart caused by out-of-memory conditions
If a large batch of emails is being generated, consider sending them in smaller groups and confirming that the JVM has enough memory assigned for the workload. For hosted JSP applications, it is better to keep mail tasks efficient and predictable rather than relying on long-running in-process jobs.
Practical troubleshooting steps
Use the following checklist to isolate the issue quickly:
- Send a single test email from the application.
- Check the app log for the exact SMTP or scheduler error.
- Confirm SMTP host, port, username, password, and security mode.
- Verify that the mail server is reachable from the hosting environment.
- Check whether the app uses JavaMail and that required libraries are deployed.
- Review Tomcat status and make sure the service is running normally.
- Restart the application after any configuration change.
- Test with a different sender and recipient address.
- Review SPF, DKIM, and DMARC if messages are sent but not delivered.
- Confirm that scheduled jobs are enabled and not failing silently.
If possible, compare a failing environment with a known-good staging copy of the same JSP app. Differences in Java version, SMTP credentials, or config values often reveal the problem immediately.
How this relates to JSP hosting on My App Server
When hosting JSP, servlet, or WAR-based applications through My App Server, email functionality depends on three layers working together:
- The web application must build and send the message correctly
- The Java runtime and Tomcat service must stay active and load the app properly
- The SMTP service must accept and relay the message
Because My App Server allows you to manage a private JVM and Tomcat instance from Plesk, you have more control than in a fixed runtime setup. That makes it easier to match the Java version to your app, install the needed Tomcat version, and adjust the service when mail-related features fail. It also means that a mail issue can be solved at the application, service, or configuration level without changing the whole hosting account.
For many small and medium JSP applications, this is enough to keep transactional email and supporting tasks reliable without moving to a much heavier application platform.
FAQ
Why does my JSP app send email locally but not on the hosted server?
Local environments often allow unrestricted SMTP access or use different credentials. On hosted servers, outbound ports, TLS settings, or authentication rules may differ. Always test against the production SMTP configuration.
Why do background email jobs stop after a restart?
If the scheduler is in memory only, it may not restart automatically with the Tomcat service. Use a persistent scheduler or ensure the application initializes the job on startup.
Can I use any SMTP provider with a JSP app on Tomcat?
Usually yes, as long as the provider allows authenticated SMTP access and the hosting environment can connect to the required port. Some providers require app passwords or specific TLS settings.
What log file should I check first?
Start with the Tomcat application log and the application-specific log file if one exists. The exact error message usually points to credentials, connectivity, TLS, or scheduler problems.
Why are emails being generated but not received?
This often means the app successfully submitted the message, but the message was rejected, filtered, or delayed downstream. Check sender authentication, domain DNS records, and recipient spam filtering.
Do I need a separate mail server on my hosting account?
Not necessarily. Many JSP applications send through an external SMTP provider. The important part is that the app is configured to use a working SMTP endpoint and that the hosting environment can reach it.
Summary
When email features fail inside a JSP web app, the issue is usually caused by incorrect SMTP configuration, blocked connectivity, missing JavaMail support, or a background job that is not running. In a Tomcat hosting setup managed through Plesk and My App Server, the best approach is to verify the mail settings, check logs, confirm the Java runtime and Tomcat service, and test whether scheduled tasks are actually active.
By separating direct email sending from job execution, you can narrow the fault quickly and restore transactional mail, notifications, and supporting tasks with minimal disruption.