Email delivery problems inside a Java web app are usually caused by one of three areas: the application configuration, the mail server settings, or the hosting environment itself. On a managed hosting platform with Plesk and a Java service such as My App Server, the issue is often not the Java code alone, but how the app connects to SMTP, whether the right ports are open, and whether authentication is set correctly.
If your JSP, servlet, or WAR application can send mail locally but fails on the hosted account, the best approach is to check the full path end to end: Java mail library, SMTP host, port, encryption, credentials, and any restrictions enforced by the control panel or the hosting platform. In many cases, the fix is straightforward once the connection flow is understood.
Why email features fail in a Java web application
Java applications commonly use Jakarta Mail or older JavaMail APIs to send email through an SMTP server. The application does not usually send mail directly to recipients. Instead, it connects to an SMTP service, authenticates, and submits the message for delivery.
When email stops working, the failure is usually caused by one of the following:
- Wrong SMTP hostname or port
- Missing or incorrect authentication credentials
- SSL/TLS mismatch
- Outbound port blocked by the hosting environment
- Firewall, relay, or mail policy restrictions
- Incorrect JavaMail properties in the application
- Mail server requires a valid sender address that matches the account
- Application server or JVM is misconfigured
- Timeouts caused by DNS, network, or certificate issues
In a Java hosting setup with a private JVM or Tomcat instance, these issues are often easier to isolate because the app runs in its own service scope. That makes it possible to test mail sending from the same environment where the app runs, instead of guessing from the code alone.
How email sending works in a hosted Java app
A hosted Java app usually follows this flow:
- The application creates a mail session using SMTP settings.
- The Java runtime opens a network connection to the SMTP server.
- The SMTP server checks the username, password, and encryption settings.
- The server accepts or rejects the message.
- The application logs the result or throws an exception.
If any part of this chain fails, the user sees an error such as:
- Authentication failed
- Connection timed out
- Could not connect to SMTP host
- Handshake failure
- Relay denied
- Send failed
For Java hosting on a platform like My App Server, the runtime can be a private JVM or an Apache Tomcat instance managed through Plesk. That is useful because you can compare the same mail configuration across different Java versions or app server setups and identify whether the issue is application-specific or environment-specific.
Most common configuration mistakes
1. Wrong SMTP host name
One of the most frequent causes is a typo in the SMTP server name. The host must be exact. A small mistake in the domain, subdomain, or mail hostname will prevent the application from connecting.
Check whether your mail provider expects a host such as mail.example.com, a provider-specific SMTP endpoint, or another internal relay name. If the app uses the domain name without testing DNS resolution, the connection may fail silently until the first send attempt.
2. Incorrect port number
SMTP commonly uses port 25, 465, or 587, but the correct one depends on the mail provider and security mode.
- 25 is often used for server-to-server delivery and is sometimes restricted on shared hosting
- 465 is typically used for implicit SSL
- 587 is commonly used for submission with STARTTLS
If the port does not match the encryption mode expected by the server, the Java app may connect but fail during handshake or authentication.
3. TLS or SSL settings do not match the server
Modern SMTP servers usually require encryption. A common problem is enabling SSL in the application when the server expects STARTTLS, or the reverse.
For example:
- STARTTLS usually begins on port 587
- Implicit SSL is often used on port 465
If your JavaMail properties are not aligned with the SMTP service, the connection will fail before the message is sent.
4. Missing SMTP authentication
Many hosted environments require authenticated SMTP submission. That means the application must provide a valid username and password. If authentication is disabled in the code, the server may reject the send request.
Make sure your application uses:
- SMTP authentication enabled
- Correct username format, if the provider requires a full email address
- The current password, not an old one stored in configuration
5. Sender address not allowed
Some SMTP servers reject mail if the From address does not match the authenticated mailbox or allowed domain. This is a common issue in hosted applications when developers test with a personal address while the SMTP account belongs to another domain.
Always confirm whether the mail server allows:
- The same address as the authenticated mailbox
- A domain-aligned sender address
- Multiple sender identities
Hosting and control panel checks
On a managed hosting platform, the application may be technically correct but still fail because of server policy or service limits. If your Java app runs through Plesk and My App Server, check the hosting-side settings as well.
Outbound network access
The Java service must be able to reach the SMTP server over the required port. If the provider blocks outbound connections on certain ports, your app will not be able to connect. This is especially relevant on shared hosting environments where network policy is tighter than on a dedicated server.
Test connectivity from the application server environment if possible. If the mail server cannot be reached from the Java runtime, the problem is not in the mail library itself.
Firewall and relay restrictions
Some hosting platforms allow outbound SMTP only to approved destinations or require a local relay. If your app tries to use an external mail provider, the connection may fail due to policy restrictions.
Also check whether the mail server expects traffic from the hosting account or IP range to be allowed. A rejected relay can look like an authentication problem even when the username and password are correct.
Service and JVM status
In My App Server, the Java runtime and Tomcat service can be managed separately through the control panel. If the service is stopped, restarting, or running with a broken configuration, the app may not send mail or may fail intermittently.
Verify that:
- The Java service is running
- The selected Java version is compatible with your mail library
- The deployed WAR or application is loaded correctly
- There are no startup errors in the service logs
Application-level causes inside Tomcat or a private JVM
When hosting a Java app in Apache Tomcat or a private JVM, code-level issues can be easy to overlook. Even if the SMTP data is correct, the application may still fail because of the runtime or deployment setup.
Incorrect JavaMail dependency
Some applications rely on a specific mail library version. If the dependency is missing, outdated, or incompatible with the selected Java runtime, mail sending may fail at runtime.
Check your build configuration for:
- Jakarta Mail or JavaMail dependency presence
- Compatibility with the Java version installed in My App Server
- No duplicate JAR files causing class loading issues
Class loading and deployment conflicts
In Tomcat, libraries can be loaded from the application package or from the server environment. If the same mail classes are bundled in multiple places, the app may behave inconsistently.
This is especially relevant when deploying older applications to a newer Java hosting stack. A clean WAR build and a consistent dependency tree usually help.
Timeouts caused by slow DNS or blocked connection attempts
Sometimes the app does not fail immediately. Instead, it waits and eventually times out. This can happen if DNS lookup is slow, the remote SMTP host is unreachable, or the network route is blocked.
When testing, look for exceptions such as:
- Connection timed out
- Read timed out
- Unknown host
- Could not convert socket to TLS
Step-by-step troubleshooting process
If email features fail inside your Java web app, use the following process to narrow down the cause.
Step 1: Verify the SMTP details
Confirm the SMTP host, port, encryption mode, username, and password with the mail provider. Do not rely on old notes or copied configuration from another environment.
Make sure you know:
- SMTP server name
- Required port
- Whether STARTTLS or SSL is required
- Whether the username is a full email address
- Whether the sender address must match the mailbox
Step 2: Test the same credentials outside the app
Before debugging Java code, test the mailbox in a mail client or use a basic SMTP test. If the credentials fail there as well, the issue is with the account or mail server, not the application.
Step 3: Check application logs
Look at your Tomcat logs, JVM logs, and application logs in Plesk or the hosting control panel. The exact exception message usually points to the real problem.
Examples of useful log clues include:
- AuthenticationFailedException
- MessagingException
- SSLHandshakeException
- UnknownHostException
- ConnectException
Step 4: Confirm the hosting environment allows outbound SMTP
If the app runs on shared hosting or a managed Java platform, confirm that outbound connections to the SMTP server are permitted. If needed, try a different port supported by the provider, usually 587 with STARTTLS.
Step 5: Review the JavaMail properties
Double-check the SMTP settings inside your code or application configuration. A small property mismatch can break the connection.
Common properties to review include:
- mail.smtp.host
- mail.smtp.port
- mail.smtp.auth
- mail.smtp.starttls.enable
- mail.smtp.ssl.enable
- mail.smtp.timeout
- mail.smtp.connectiontimeout
Step 6: Restart the Java service after config changes
If you changed JVM settings, app server configuration, or deployment files, restart the service from the control panel. In My App Server, the service control tools are useful for applying changes cleanly and verifying whether the app comes back with the new settings.
Good practice for Java email on managed hosting
To keep mail features reliable in a Java hosting environment, follow a few practical rules:
- Use a dedicated SMTP account for the application
- Store credentials securely outside the code where possible
- Use port 587 with STARTTLS unless the mail provider requires another mode
- Keep sender addresses aligned with the authenticated domain
- Log mail exceptions clearly for support diagnosis
- Test after each Java version or configuration change
- Keep the JVM and Tomcat version compatible with your application
On a platform such as My App Server, this approach works well because the Java service is separate, the app can be deployed as a WAR or JSP-based application, and the runtime can be adjusted without moving to a much heavier enterprise stack.
When the issue is not mail at all
Sometimes a reported “email problem” is actually a background task problem. For example, the application may queue the message in a scheduled job or worker thread, but the job does not run because the JVM is stopped, the scheduler is misconfigured, or the thread dies after deployment.
This is especially relevant for applications that send:
- password reset emails
- order confirmations
- contact form replies
- scheduled notifications
- batch reports
If the app relies on a background process to trigger mail delivery, check whether the job is running at all. A healthy SMTP setup will not help if the task that initiates the send never executes.
Example of a practical diagnosis path
Suppose your hosted Java app on Tomcat suddenly stops sending mail after a deployment.
You can investigate in this order:
- Confirm the app is running in My App Server.
- Check whether the new deployment changed the Java version or dependencies.
- Review the mail exception in the logs.
- Verify SMTP host, port, and authentication.
- Confirm STARTTLS or SSL matches the server requirements.
- Test the same credentials from another client.
- Restart the service and retest after clearing old config values.
This order saves time because it starts with the most likely environment-related causes and moves toward application internals only when necessary.
Frequently asked questions
Why does email work in development but fail on hosted Java hosting?
Development environments often allow local testing with a relaxed network setup. Hosted environments may restrict outbound ports, require authenticated SMTP, or enforce stricter TLS settings. The same code can fail if the hosting platform or mail server rules differ.
Can Tomcat send email by itself?
Tomcat does not send email on its own. Your Java application uses a mail API to connect to an SMTP server. Tomcat only hosts the application and provides the runtime environment.
Is port 25 always the right choice?
No. Many providers prefer port 587 with STARTTLS for authenticated submission. Port 25 is often restricted on shared hosting and is more commonly used for server-to-server mail handling.
What should I check first if I see an authentication error?
Start with the username format, password, sender address, and whether the SMTP server requires full email-based login. Then check whether the server requires app-specific passwords or TLS before authentication.
Can the Java version affect email sending?
Yes. Older mail libraries or outdated TLS support can cause handshake problems on newer SMTP servers. If you changed the Java version in your hosting account, retest mail features carefully.
Should I put SMTP credentials directly in the code?
It is better to keep them in external configuration if possible. This makes updates easier and reduces the risk of exposing credentials in source control or deployment packages.
Summary
Email features in a Java web app usually fail because the SMTP connection is incomplete, blocked, or misconfigured. In a hosted Java environment with Plesk, Apache Tomcat, or a private JVM, the fix is often found by checking the mail server settings, outbound access, logs, and JavaMail properties together rather than looking at the code in isolation.
If your app runs on My App Server, use the control panel to verify the Java service, deployment status, and runtime version first, then confirm the SMTP details and TLS mode. That approach gives you the fastest path to a working mail setup for JSP, servlet, and WAR-based applications.