When email features fail inside a JSP web app, the problem is usually not the JSP itself. In most hosting environments, the failure happens because the application cannot reach a mail server, the JavaMail settings are incomplete, the SMTP host is blocked, or the app server does not have the required permissions and configuration. In a managed hosting setup with Plesk and a private Tomcat or JVM, these issues are often related to account limits, service configuration, or incorrect values in the application’s web.xml, property files, or environment variables.
If your JSP application can load pages normally but fails when sending email, you should check the mail transport layer first. That means SMTP host, port, authentication, TLS/SSL settings, sender address, DNS records, and server-side restrictions. In many cases, the application code is correct, but the hosting platform is not allowing outbound mail on the expected port, or the mail library is trying to use a local mail relay that is not available in the current environment.
Most common reasons email stops working in a JSP application
Email sending inside JSP and servlet applications usually depends on JavaMail or a similar library. The application builds a message, connects to an SMTP server, and then transmits the mail. If any part of that chain fails, the user sees a generic error such as “could not connect to SMTP host”, “authentication failed”, or “sending failed”.
1. Incorrect SMTP settings
The most frequent cause is a wrong SMTP configuration. Typical mistakes include:
- Using the wrong hostname for the mail server
- Using port 25 when the provider expects 587 or 465
- Enabling SSL and TLS at the same time when the server supports only one mode
- Leaving authentication disabled when the SMTP server requires login
- Setting the sender address to a domain that does not match the authenticated account
In hosted environments, the SMTP server should usually be the provider’s designated mail host, not localhost, unless local mail submission is explicitly available in your plan.
2. Outbound mail ports are blocked
Some hosting platforms restrict direct outbound connections on certain ports to reduce abuse and spam. If your JSP app attempts to connect directly to an external SMTP server, the connection may fail even though the code is correct. This is especially common when an application uses hardcoded SMTP settings from development or another server.
Check whether your hosting provider allows outbound connections to the SMTP port you are using. In managed hosting, port 587 is often the safest choice for authenticated submission. Port 25 may be restricted or filtered.
3. Missing JavaMail dependency
Modern JSP and servlet projects usually need a mail library on the classpath. If the JavaMail API or Jakarta Mail dependency is missing, the app may compile locally but fail on the server with class loading errors.
Typical signs include:
ClassNotFoundExceptionNoClassDefFoundError- Failure only after deployment to Tomcat
Make sure the required JAR files are included in the application package or provided by the hosting environment. If you deploy a WAR file, confirm that the dependencies are bundled correctly and not dependent on local IDE settings.
4. Wrong Java version or library compatibility
Email code can also fail because of version mismatch. For example, an app built for an older Java runtime may rely on legacy mail libraries, while the server is using a newer Java version. The opposite can also happen if the app expects Jakarta namespaces and the deployed libraries still use older Java EE packages.
In a Java hosting environment with selectable Java/Tomcat versions, always confirm that your application was built for the runtime currently assigned to the private JVM or Tomcat instance. A small mismatch can cause mail features to break even if the web interface still works.
5. Authentication or TLS issues
SMTP servers commonly require authenticated login and encrypted transport. If credentials are correct but the server still rejects the connection, the problem may be in encryption settings or certificate validation.
Examples include:
- Using STARTTLS on a port that expects implicit SSL
- Using SSL on a STARTTLS-only server
- Server certificate not trusted by the JVM
- Old Java runtime lacking modern TLS support
When a JVM is managed through a hosting control panel, you may need to verify the Java version and the trust store configuration if your mail server uses strict TLS settings.
6. Sender domain and DNS problems
Email delivery is not only about connecting to SMTP. The sender domain must also be properly configured. If the application sends from a domain that does not have valid MX, SPF, DKIM, or DMARC records, the message may be rejected or marked as suspicious.
For application-generated mail such as password resets, order notifications, or contact forms, make sure the sending address matches a domain that is properly set up in DNS and accepted by the mail server.
7. Local file or permission problems
Some JSP apps do not send mail directly from the request thread. Instead, they create log files, temporary files, or queued message files before dispatching mail through a background task. If the application lacks write permissions to its working directory, the email process can fail indirectly.
This is common in hosted Java environments where the app runs under a limited user account and can only write to specific application folders. Check whether the process can write to temp directories, log paths, and mail queue locations.
How email sending usually works in a JSP hosting environment
In a typical JSP hosting setup, the web application runs inside Tomcat or another Java servlet container. When a user performs an action, the app creates a message and sends it using SMTP. The mail flow normally looks like this:
- The JSP or servlet calls a service layer method.
- The application prepares the message content and recipient list.
- JavaMail opens a connection to the SMTP server.
- The server authenticates the sender and negotiates TLS if needed.
- The mail is accepted by the SMTP server and handed over for delivery.
If your application is deployed on a private JVM or custom Tomcat instance managed through a Plesk extension such as My App Server, the app server itself is usually not responsible for sending email. It only provides the runtime. Mail delivery still depends on correct application-level SMTP settings and network access.
What is important in hosted Java environments
In hosted JSP and Tomcat environments, the app server is isolated from the rest of the system for safety and stability. That means the application may not have access to:
- System-wide mail relay configuration
- Unlimited outbound network access
- Direct access to OS-level mail agents
- Root-level certificate stores or service configuration
Because of that, it is better to configure email delivery explicitly in the application instead of relying on server defaults that may exist on a local development machine.
Step-by-step checks to fix email features in a JSP app
If email sending fails, use a structured troubleshooting approach. The goal is to isolate whether the issue is in the code, the runtime, or the hosting platform.
Step 1: Verify the application logs
Start with the Tomcat or application logs. Look for stack traces related to mail sending, including connection refusal, authentication errors, timeout messages, and class loading problems. A log entry is often more useful than the browser error because it shows the real SMTP exception.
Common log messages include:
- Connection timed out
- Authentication failed
- Unable to open socket
- Class not found
- Handshake failure
Step 2: Confirm the SMTP host and port
Double-check the mail server name, port, and protocol used by the application. If you are not sure which values to use, check the hosting control panel or your mail service documentation. In many cases, authenticated SMTP submission uses:
- Port 587 with STARTTLS
- Port 465 with SSL
Avoid guessing or reusing values from a different environment. A setting that works on a local laptop may fail on hosted infrastructure.
Step 3: Test connectivity from the server environment
If your hosting plan allows it, test whether the server can reach the SMTP host and port. A network timeout usually means the app cannot connect, while an immediate rejection often points to authentication or policy problems.
If direct command-line testing is not available, use the application logs to see whether the connection is being opened at all. In hosted JSP environments, connectivity issues are often outside the Java code itself.
Step 4: Check JavaMail properties
Review the configuration used by your mail code. Typical properties include server name, port, authentication, and TLS flags. Make sure they match the SMTP server’s requirements exactly. If your app uses a property file or environment variables, confirm that the deployed values are the same as the local ones.
Pay attention to these common mistakes:
- Incorrect property key names
- Whitespace in usernames or passwords
- Using the wrong default port
- Forcing SSL when STARTTLS is needed
Step 5: Confirm dependency packaging
If the error indicates a missing class or method, verify that the mail library is inside the WAR or available to the Tomcat runtime. When you use a hosting platform with a private JVM, the safest approach is to package the required libraries with the application unless the runtime explicitly provides them.
Step 6: Validate the sender identity
Make sure the From address belongs to a domain you control and that the SMTP account is allowed to send as that identity. Some SMTP servers reject messages if the sender does not match the authenticated mailbox or if the envelope sender is not accepted by policy.
This matters especially for application alerts, form submissions, and automated messages generated by background jobs.
Step 7: Check timeouts and message size
Email can fail if the message is too large or the SMTP server is slow to respond. Attachments, inline images, and verbose HTML templates may increase the size of the message enough to trigger a timeout or rejection.
For JSP applications, keep notification emails short and efficient. If the app sends reports or exports, consider generating them asynchronously and letting the user download them instead of attaching large files to email.
Email sending in background jobs and scheduled tasks
Many JSP applications do not send all mail directly from the user request. They use background jobs, scheduled tasks, or worker threads to send notifications later. This is common for account verification, queue processing, and periodic summaries.
In a hosted Tomcat environment, background mail tasks can fail for reasons that are different from page-based requests:
- The scheduler is not running after a deploy or restart
- The JVM has been restarted and in-memory queues were lost
- Thread pool limits were reached
- The app has no permission to create background threads
- The mail task is blocked by a timeout or connection issue
If your hosting platform provides service control in Plesk or a similar panel, verify that the Java service is actually running and that the application server instance is healthy. A stopped or misconfigured service can cause mail jobs to disappear silently.
Tips for scheduled email tasks
- Use persistent storage for queued mail if delivery matters
- Log each send attempt with status and timestamp
- Keep retry logic simple and controlled
- Avoid starting unmanaged threads inside JSP pages
- Restart the service after changing runtime settings
Special considerations for My App Server, Tomcat, and private JVM hosting
With Java hosting based on a dedicated Tomcat or private JVM inside a shared hosting account, email features usually depend on three layers: application code, runtime configuration, and external SMTP service.
The key advantage of this setup is that you can manage the Java version, service state, and deployment process through the hosting panel without needing a full enterprise Java stack. This works well for small and medium JSP applications that need reliable mail sending, servlet processing, and simple background jobs.
What to review in the control panel
- Which Java version is selected for the app
- Whether the Tomcat or JVM service is running
- Whether the application was redeployed after config changes
- Whether custom app server settings were applied correctly
- Whether the app uses the correct context path and runtime profile
If your setup allows switching between preinstalled Java/Tomcat versions or uploading custom app server files, make sure the version in use is compatible with your mail library and TLS requirements. Email failures often appear after a Java upgrade because the JVM becomes stricter about certificates or deprecated protocols.
Practical configuration example
A common and stable setup for a JSP application is to store SMTP settings outside the source code and read them during startup. That way, the same WAR can be deployed in development, staging, and production with different mail credentials.
Recommended values to keep under control:
- SMTP host
- SMTP port
- Username
- Password
- Transport security mode
- From address
- Reply-to address, if used
Using environment-specific values reduces errors and makes it easier to adjust mail settings when the hosting provider changes policy or when you move the app to a different runtime.
Security and deliverability best practices
Email features in JSP applications should be configured with both security and deliverability in mind. A working SMTP connection is not enough if the messages are filtered or if credentials are exposed in the codebase.
- Do not hardcode passwords in JSP files
- Prefer configuration files or protected environment values
- Use authenticated SMTP submission instead of open relay assumptions
- Enable TLS where supported by the SMTP server
- Use a real sender domain with proper DNS records
- Log failures without exposing secrets
If the app sends transactional email, keep templates concise and consistent. Clear subject lines, valid sender details, and a stable mail domain improve inbox placement and reduce support tickets.
FAQ
Why does email work on my local machine but fail on the hosted JSP app?
Local development environments often allow unrestricted mail configuration, different Java versions, or a local SMTP service. In hosting, outbound ports, runtime versions, and permissions are more controlled. The app may need a different SMTP host, port, or TLS setting on the server.
Can a JSP page send email directly?
Yes, but it is better to send mail from a servlet, service class, or background task rather than directly from presentation code. JSP should mainly render the view. Business logic and SMTP handling are easier to maintain outside the page layer.
Do I need Tomcat to send email from a JSP app?
Tomcat does not send email by itself. It runs the application, which then connects to an SMTP server. The mail feature depends on your code, dependencies, and external mail service, not only on the servlet container.
What if I get a TLS handshake error?
Check the SMTP port, encryption mode, Java version, and certificate trust chain. Handshake failures often happen when the server expects STARTTLS but the app uses SSL, or when the JVM does not trust the mail server certificate.
Why do scheduled email jobs stop after a restart?
If your job scheduler stores tasks only in memory, they may not survive a service restart. Use persistent job storage or reinitialize the scheduler when the app starts. Also confirm that the Java service starts correctly in the hosting panel.
Should I use localhost as the SMTP host?
Only if your hosting provider explicitly supports a local mail relay in that environment. In many managed hosting setups, localhost will not work for application-level SMTP delivery, even if it works on a development server.
Summary
Email features failing inside a JSP web app usually point to SMTP configuration, network access, dependency packaging, Java version compatibility, or hosting restrictions rather than a problem with JSP itself. In a managed Java hosting environment with Tomcat or a private JVM, the most effective approach is to verify the mail server settings, review application logs, confirm the JavaMail dependency, and make sure the service and runtime are configured correctly in the control panel.
For hosted JSP applications, the most reliable solution is a clean separation between application code, runtime settings, and external mail delivery. Once the SMTP host, port, authentication, and TLS values match the environment, mail features usually start working without further code changes.