If your JSP web app can load pages but email features fail, the problem is usually not the JSP code itself. In most cases, the application cannot reach the mail server, the SMTP settings are wrong, SSL/TLS is misconfigured, DNS records are incomplete, or the hosting platform blocks outbound mail connections. In a managed hosting environment with Plesk and a Java/Tomcat stack such as My App Server, you should check both the application settings and the surrounding mail infrastructure before assuming the app logic is broken.
Email in a JSP application typically depends on external services such as SMTP, DNS, and SSL certificates. That means the app may work correctly for database access, page rendering, and session handling, while mail sending still fails because one part of the connection chain is unavailable. The most common symptoms are authentication errors, connection timeouts, certificate validation errors, or messages that appear sent in the app but never arrive in the mailbox.
Common reasons email features stop working in JSP apps
When a Java web application sends email, it usually uses JavaMail or a similar library to connect to an SMTP server. If anything in that path is incorrect, mail will fail even if the rest of the application is healthy.
Incorrect SMTP host, port, or authentication
The most frequent cause is a wrong mail server configuration in the application. A JSP app may point to an outdated SMTP hostname, use the wrong port, or send credentials that no longer match the mailbox account. Common mistakes include:
- Using the wrong SMTP hostname, such as the web server name instead of the mail server name.
- Using port 25 when the mail service expects submission on 587 or secure SMTP on 465.
- Forgetting to enable SMTP authentication.
- Using a full email address as the username when the server expects a mailbox login, or the reverse.
- Hardcoding credentials that changed after a password reset.
SSL/TLS mismatch on the mail connection
If the mail server requires encryption, the application must use the correct SSL/TLS mode. A common issue is trying to connect without encryption to a server that requires STARTTLS, or enabling SSL on the wrong port. In Java, this often leads to handshake errors or certificate verification failures.
Typical causes include:
- Using SSL on port 587 instead of STARTTLS.
- Using STARTTLS with a server that only accepts implicit SSL on port 465.
- Missing or outdated CA trust in the JVM.
- Hostname mismatch between the SMTP server name and the certificate name.
DNS problems affecting mail delivery
Even if your app successfully connects to SMTP, messages may still fail delivery because DNS is incomplete or incorrect. Email systems rely heavily on DNS records. If the domain does not have valid MX records, or if SPF, DKIM, and DMARC are missing or inconsistent, mail may be rejected or filtered as spam.
This is especially important when the application sends messages using the customer domain, such as contact forms, password resets, invoices, and notifications.
Outbound mail blocked by hosting restrictions
Some hosting setups restrict outbound SMTP traffic from shared environments to reduce abuse. If port 25 is blocked, or if your platform only allows sending through a specific authenticated relay, the JSP application will not be able to connect to external mail servers directly.
In a managed hosting or control panel environment, this is often intentional and must be handled by using the provider’s mail submission service or by adjusting the application to use the correct relay host and port.
JVM or library compatibility issues
Java mail libraries are sensitive to runtime and dependency versions. On a private JVM or Tomcat instance managed through a Plesk extension such as My App Server, a JSP app may fail if it uses older JavaMail settings, outdated TLS defaults, or a library version that does not match the current Java runtime.
This can happen when the app was built for an older Java version and then deployed on a newer one, or when the application depends on a JAR that is missing from the WAR package.
How to check the mail setup in a JSP hosting environment
Before changing code, verify the basic mail service settings in the hosting control panel and in your application. A structured check usually finds the issue faster than random debugging.
1. Confirm the mailbox exists and can be logged into
Start by checking whether the mailbox account is active, the password is correct, and the mailbox can receive messages normally. If the mailbox itself is unavailable, the application cannot send through it.
In Plesk or a similar control panel, confirm the following:
- The mailbox address exists for the domain.
- The mailbox password matches the application configuration.
- The mailbox is not full.
- The domain’s mail service is enabled.
2. Verify the SMTP server name and port
Use the exact SMTP hostname recommended by your hosting provider or mail service. Avoid guessing the server name from the website domain unless that is explicitly documented. Check the port and encryption mode together, because they must match the server policy.
Common configurations are:
- Port 587 with STARTTLS
- Port 465 with SSL/TLS
- Port 25 for server-to-server delivery, where allowed
If your hosting company provides an authenticated relay or local mail service, use that instead of public SMTP settings.
3. Test DNS records for the domain
Check the domain’s MX records and make sure they point to the correct mail service. If your JSP app sends mail as the same domain it serves, SPF and DKIM should also be configured properly.
Look for these records:
- MX record for incoming mail routing.
- SPF record to authorize the sending server.
- DKIM record for message signing.
- DMARC record to define policy and reporting.
Missing or invalid records do not always stop SMTP submission, but they can cause delivery problems, spam filtering, or rejection by recipient servers.
4. Check whether the JVM trusts the mail server certificate
If the application uses SSL/TLS, the Java runtime must trust the certificate chain presented by the SMTP server. This is especially relevant when using a custom or third-party mail server, or when the certificate was recently renewed.
Symptoms include:
- javax.net.ssl.SSLHandshakeException
- Certificate path building errors
- Hostname verification errors
If you manage your own Java version through My App Server, make sure the JVM is current enough to support the mail provider’s TLS requirements.
What to check in your JSP code
If the hosting side looks correct, inspect the email code itself. A small configuration mistake in JavaMail can break the whole feature.
Verify the mail session properties
Check the SMTP properties passed to the JavaMail session. The exact keys depend on the library, but the most common settings include host, port, authentication, and TLS options.
Make sure the following logic is consistent:
- The SMTP host is correct and reachable.
- The port matches the encryption mode.
- Authentication is enabled if required.
- STARTTLS is enabled when the server expects it.
- SSL socket factory settings do not conflict with STARTTLS.
Check the From address and envelope sender
Some mail servers reject messages if the From address does not belong to the authenticated mailbox or the domain is not permitted to send on behalf of that account. In JSP applications, this often happens when developers hardcode a generic sender address such as [email protected] without configuring the mailbox or DNS records.
Use a sender address that matches your domain policy and the mail service rules. If the app sends support replies or notifications, consider a dedicated mailbox for those messages.
Inspect exception handling and logs
Mail failures are often hidden by broad exception handling in the JSP app. The user sees a generic “message sent” page, but the backend throws an error that is never written to the logs.
Check your Tomcat and application logs for:
- Authentication failures
- Connection timeouts
- Socket errors
- SSL handshake failures
- Messaging exceptions from JavaMail
In a hosting platform with a private JVM and Tomcat instance, these logs are usually the fastest way to identify whether the issue is code, networking, or certificate-related.
How My App Server and Tomcat affect email sending
In a JSP hosting setup with My App Server, the application runs inside its own Tomcat and private JVM environment. This gives you control, but it also means email behavior depends on the runtime configuration you selected when installing or updating the Java version.
Java version matters for TLS compatibility
Modern SMTP services often require newer TLS protocols. If the app is running on an older Java version, it may not support the required cipher suites or TLS defaults. Even if the same application works locally, it may fail on the hosting platform if the JVM is older than expected.
If you see secure connection failures, check whether the Java version in My App Server is compatible with the SMTP service you are using.
Tomcat deployment can hide missing dependencies
If your application uses JavaMail, mail API jars, or framework-specific mail components, ensure those libraries are included in the WAR file or available in the application classpath. A deployment may succeed while the email feature fails at runtime because one dependency is missing.
When you deploy or update the app in Tomcat, verify that:
- The WAR includes all required mail libraries.
- No conflicting mail JARs are loaded from a different location.
- The application is using the expected Java runtime.
Service control and restart after changes
After changing Java version, Tomcat configuration, or application libraries, restart the service if needed. Some mail-related changes do not take effect until the JVM and webapp are reloaded. In a control panel environment, this may be done through the service controls for the app server.
Practical troubleshooting steps
Use this order when email fails in a JSP web app:
- Confirm the mailbox account works in webmail or another mail client.
- Verify the SMTP host, port, and encryption settings.
- Check the password and authentication settings in the app.
- Review DNS records for MX, SPF, DKIM, and DMARC.
- Look for SSL/TLS errors in the Tomcat logs.
- Test with a simple SMTP example from the same JVM if possible.
- Confirm outbound SMTP traffic is allowed by the hosting environment.
- Check whether a recent Java update changed TLS behavior.
Test with a minimal mail script or sample class
If the full application is complex, isolate the problem by testing a minimal Java mail example from the same hosting account and JVM. This helps you determine whether the issue is in the application logic or in the environment.
If the sample code also fails, the issue is almost certainly with SMTP access, credentials, TLS, or network restrictions.
Use a controlled sender for debugging
When debugging, send mail to a mailbox you can check immediately. Avoid testing with multiple recipient systems at once. If the test message is accepted by the SMTP server but not delivered, the problem is likely DNS, SPF, DKIM, spam filtering, or sender reputation rather than the JSP app itself.
Common error messages and what they usually mean
Authentication failed
This usually means the username or password is incorrect, or SMTP AUTH is disabled on the server. It can also happen if the server requires a different login format.
Connection timed out
This often points to a blocked port, wrong host, or network restriction in the hosting environment. Check whether the server allows outbound SMTP connections to the selected port.
Could not convert socket to TLS
This suggests a mismatch between the configured encryption mode and the SMTP server requirements, or a Java TLS compatibility problem.
SSLHandshakeException
This usually means the certificate chain cannot be validated, the hostname does not match, or the JVM does not support the required TLS parameters.
Message accepted but never received
This typically indicates a delivery issue after submission. Review SPF, DKIM, DMARC, and spam filtering on the recipient side. Also check whether the From address is aligned with the sending domain.
Best practices for JSP email features on hosting platforms
To keep email features stable in a JSP hosting environment, follow a few practical rules:
- Use the provider-recommended SMTP relay or submission host.
- Prefer authenticated SMTP over unauthenticated direct delivery.
- Keep the Java runtime current enough for modern TLS requirements.
- Store mail credentials securely, not in publicly accessible files.
- Match the From address to the domain and mailbox policy.
- Set up SPF, DKIM, and DMARC for domains that send application mail.
- Check logs after every configuration change.
For hosted JSP applications, this approach is usually more reliable than trying to send mail directly from the application server without a validated mail service.
When the issue is not in the app
Sometimes the JSP code is working exactly as designed, but the broader mail ecosystem is the cause. This is common when:
- The domain is newly created and DNS has not fully propagated.
- The mailbox was changed or removed in the control panel.
- The host blocks unauthenticated outbound SMTP.
- The sender domain lacks SPF or DKIM.
- The recipient server rejects messages due to policy.
In those cases, fixing the application alone will not solve the problem. You must correct the mail service, DNS configuration, or hosting policy first.
FAQ
Why does my JSP app show success, but no email arrives?
The app may be catching SMTP errors too broadly or treating message submission as success before checking the server response. Review the Tomcat logs and confirm that the message is actually accepted by the SMTP server.
Do I need SPF, DKIM, and DMARC for a JSP app?
If the application sends mail from your domain, yes, they are strongly recommended. They improve deliverability and reduce the chance that messages are marked as spam or rejected.
Can I send mail directly from Tomcat without SMTP authentication?
In most hosting environments, that is not recommended and may be blocked. Authenticated SMTP through the correct relay is the safer and more reliable option.
Why does email work locally but not on hosted Tomcat?
Local environments often have different network access, Java versions, and certificate trust stores. The hosted JVM may also enforce stricter TLS rules or block certain ports.
Should I change the Java version if mail stops working?
Only if the current JVM is too old for the SMTP service’s TLS requirements. If the application was built for a specific Java version, test carefully before changing it.
Can My App Server help with mail issues?
My App Server helps by giving you control over the Java version, private JVM, Tomcat service, and deployment environment. That makes it easier to align the app with the mail server requirements, but you still need correct SMTP, DNS, and SSL settings.
Conclusion
Email features in a JSP web app usually fail because of SMTP configuration, SSL/TLS issues, DNS problems, or outbound mail restrictions rather than a general JSP error. In a managed hosting environment with Plesk and a private Tomcat or JVM, the best approach is to check the mailbox, SMTP host, port, encryption mode, logs, and DNS records in a fixed order. If the app runs on My App Server, also confirm that the selected Java version supports the mail server’s security requirements.
Once the mail path is configured correctly, JSP email features such as contact forms, password resets, and notification messages should work reliably without requiring changes to the core application logic.