When email features inside a Tomcat web app stop working, the cause is usually not the application code alone. In a hosting environment, the issue is often related to SMTP access, server-side restrictions, DNS records, authentication, JavaMail configuration, or how the app is deployed inside the private JVM. In a managed hosting setup with Plesk and a Tomcat service, it is important to check both the application settings and the hosting account limits before assuming the Java code is at fault.
For UK-based hosting customers, the same troubleshooting logic applies whether the app sends password resets, contact form notifications, order confirmations, or scheduled task emails. If your Tomcat app can load pages but cannot send mail, the problem is usually in one of a few predictable places: the SMTP host, port, TLS settings, sender identity, firewall restrictions, or missing background service permissions.
Common reasons email fails in a Tomcat web app
Email in Java applications is commonly handled through JavaMail or a similar mail library. That means the application depends on an external mail server and valid network access. In hosted Tomcat environments, the most frequent reasons for failure are:
- Incorrect SMTP server name or port
- Missing username or password for authenticated sending
- TLS/SSL mismatch, such as using the wrong secure port
- Sender address not allowed by the mail server
- DNS or SPF/DKIM/DMARC issues affecting delivery
- Outbound SMTP blocked by the hosting environment or remote provider
- Timeouts caused by firewall rules, slow DNS resolution, or unreachable mail hosts
- Application-level misconfiguration in web.xml, properties files, or environment variables
- Jobs or background tasks running without the expected Java runtime permissions
If your app runs inside a private JVM managed through My App Server, you should also consider whether the Java version, Tomcat instance, or service state changed after deployment. A working app can break after a Java update, a new mail library, or a change in the hosting control panel.
Check whether the problem is sending, not receiving
Many developers say “email is failing” when the real issue is only one direction of mail flow. A Tomcat app usually sends email through SMTP; it does not host the mailbox itself. That means you should separate these cases:
- Sending failure: the app cannot connect to SMTP or the server rejects the message
- Delivery failure: the app sends successfully, but the recipient does not receive the message
- Mailbox access failure: the app cannot read from IMAP/POP3 or cannot verify incoming mail
In hosted Java applications, sending failure is the most common problem. Delivery failure can happen even when the app reports success, especially if the sender domain lacks proper SPF, DKIM, or DMARC records, or if the mail is marked as spam.
Verify the SMTP settings used by the app
The first technical check is always the SMTP configuration. In a Tomcat app this may be stored in a properties file, Spring configuration, environment variable, JNDI resource, or directly in code. Confirm all of the following:
- SMTP host is correct
- SMTP port matches the mail provider’s recommended port
- Authentication is enabled if required
- Username is the full mailbox address, if the provider expects it
- Password or app password is current
- STARTTLS or SSL is enabled only when needed
- From address is valid and permitted
Typical secure SMTP ports include 587 for STARTTLS and 465 for implicit SSL, but the right setting depends on your mail service. Do not assume that port 25 will work in a hosting environment. Many providers restrict it, and some remote servers reject unauthenticated traffic.
If you are using a mailbox from the same hosting account, check that the mail service itself is active and that the address exists. A typo in the username, domain, or SMTP host can produce errors that look like Java failures but are actually configuration errors.
Confirm that the Tomcat app can reach the mail server
A web app may have correct settings and still fail if the JVM cannot reach the SMTP server over the network. This is especially relevant in managed hosting, where outbound rules are stricter than on a local machine.
Look for symptoms such as:
- Connection timed out
- Could not connect to SMTP host
- Socket timeout during handshake
- SSL handshake failure
- Connection reset by peer
These errors usually mean the app cannot establish a clean network session. Possible reasons include wrong DNS resolution, an incorrect mail hostname, port blocking, or a certificate mismatch.
If you can test from the same account using another mail client or a simple SMTP test tool, compare the results. If the external client also fails, the issue is likely with the mail service itself. If only the Java app fails, focus on the Tomcat configuration, JavaMail properties, and TLS settings.
Check JavaMail and TLS settings inside the app
Java applications often need explicit mail properties. A common error is using one set of properties for a local test server and another for production, then forgetting to update them after deployment.
Important settings to review include:
mail.smtp.authmail.smtp.starttls.enablemail.smtp.ssl.enablemail.smtp.hostmail.smtp.portmail.smtp.connectiontimeoutmail.smtp.timeoutmail.smtp.writetimeout
When a provider requires STARTTLS, but the app tries plain SMTP, the server may refuse the connection or drop it after the greeting. When the app uses SSL on a port meant for STARTTLS, the connection will fail early in the handshake.
Also check the Java runtime version. Older Java versions may not support modern TLS defaults or ciphers expected by the mail provider. In a private JVM managed through My App Server, it is a good practice to confirm the selected Java version after every deployment or upgrade.
Review sender identity and domain authentication
Even if your app sends mail successfully, the recipient may never see it in the inbox. UK businesses commonly discover that transactional emails are delivered to spam or rejected because the sender domain is not authenticated properly.
For better delivery, make sure the sending domain has:
- SPF record allowing the mail provider
- DKIM signing enabled where supported
- DMARC policy configured sensibly
- A valid From address matching the domain or allowed alias
If the app uses a generic From address that does not belong to the authenticated mailbox, some providers will rewrite or reject the message. This is common with password reset, signup confirmation, and invoice notifications. A safer approach is to send from an address on the same domain and configure a proper reply-to header when needed.
Use the hosting control panel to isolate the issue
In a Plesk-based hosting account, the control panel can help you determine whether the problem is in the app or in the service configuration. Check:
- Whether the mailbox exists and can send mail from webmail
- Whether mail service is active for the domain
- Whether the domain has valid DNS records
- Whether there are limits on outgoing mail
- Whether logs show rejected messages or authentication failures
With My App Server, Tomcat runs as a separate service inside your hosting account. That is useful because it helps isolate the Java app from the rest of the site. If pages load but background email tasks fail, the issue may be in the app’s service configuration rather than the mail system itself.
Check the service status, restart the app if needed, and confirm that the correct Tomcat version and Java version are selected. A mismatch between application requirements and the active runtime often shows up first as mail failures, because mail code is sensitive to library and SSL differences.
Check logs first, not last
Logs are the fastest way to identify the exact failure point. In Tomcat-based hosting, review:
- Tomcat application logs
- Java stack traces
- Mail provider rejection messages
- System or service logs in the control panel
- Application-specific logs from the web app
Look for messages such as:
- Authentication failed
- Could not convert socket to TLS
- Unable to send mail
- Relay access denied
- Sender address rejected
- Unable to establish SSL connection
These errors tell you whether the issue is credentials, encryption, DNS, or access policy. If the log only says “send failed” without details, enable more detailed logging in the app temporarily. Many JavaMail issues become obvious once debug output is enabled.
Background jobs and scheduled tasks can fail differently from web requests
In hosted Java applications, mail is often sent from a background job rather than from the page request itself. For example, a scheduled task may process order reminders, cleanup notifications, or form submissions in the background. These jobs can fail even when the web interface works fine.
Common causes include:
- The scheduler is not running inside the Tomcat service
- The job starts before dependencies are ready
- Environment variables are missing for background execution
- Session-based settings are not available to the job
- The job hits a timeout or memory limit
If your app depends on scheduled mail sending, confirm that the task is actually triggered in the deployed environment. A JSP or servlet request may work, but the cron-like job may not start unless the service is up and the scheduling mechanism is configured correctly.
Practical troubleshooting steps
Use this sequence to diagnose the problem quickly:
- Test mail sending from the app with a known valid recipient.
- Confirm SMTP host, port, username, and password.
- Check whether the app uses SSL or STARTTLS correctly.
- Review Tomcat and application logs for the exact error message.
- Verify the mailbox can send mail outside the app, if available.
- Test whether the sender domain has correct SPF, DKIM, and DMARC records.
- Confirm the Java version used by the private JVM.
- Restart the Tomcat service after configuration changes.
- Retest using a minimal mail example to rule out application logic.
If possible, temporarily reduce the problem to a single message sent from a simple endpoint. That helps separate application flow issues from host, network, or mail provider issues.
Example configuration mistakes that cause mail failures
Wrong SMTP port
The application uses port 25 while the provider expects 587 with STARTTLS. The connection opens but the server rejects the protocol flow.
Missing authentication
The app connects to a mail server that requires login, but mail.smtp.auth is not enabled or the credentials are empty.
Bad From address
The sender address is noreply@yourdomain but the actual authenticated mailbox is elsewhere, so the server rejects the message.
TLS mismatch
The app enables SSL on a STARTTLS port or disables certificate verification in a way the server does not accept.
Deployment environment mismatch
The app works locally but fails after deployment because the hosted Tomcat instance uses a different Java version, library version, or system property set.
How My App Server helps with Tomcat email troubleshooting
In a hosted Java environment with My App Server, one advantage is that the Tomcat instance and JVM are under your control within the hosting account. That makes it easier to verify the runtime used by the application, adjust service settings, and test mail-related changes without touching unrelated sites.
This is especially useful when you need to:
- Choose a Java version compatible with your mail library
- Run a private Tomcat service for a JSP, servlet, or WAR application
- Restart the service after updating configuration
- Deploy a revised mail config without affecting other apps
- Switch between ready-made Java/Tomcat versions or custom app server builds
For small and medium web applications, this setup is often enough to resolve email issues without requiring a separate application server platform. The key is to keep the runtime simple, the SMTP configuration explicit, and the logs easy to access.
When to contact support
Contact hosting support if:
- The SMTP host is unreachable from your account
- The mail server rejects valid authenticated connections
- Outbound traffic to the required port is blocked
- The private JVM will not start after a change
- Tomcat logs show a platform-level error rather than an application error
- You suspect a control panel or service-level issue
When you contact support, include the exact error message, the SMTP host and port, the Java version, the Tomcat version, and the time of the failed attempt. That saves time and usually leads to a faster resolution.
FAQ
Why does email work in local development but fail on the hosted Tomcat app?
Local development often allows simpler SMTP settings or access to a different mail server. The hosted environment may require authentication, TLS, or a specific port. It may also use a different Java version or have stricter outbound rules.
Can a Tomcat app send email without a separate mail server?
No. The app needs an SMTP server to relay the message. Tomcat and the private JVM run your application code, but mail delivery still depends on an external or hosted SMTP service.
Why do I get a timeout when sending mail from Java?
This usually means the app cannot reach the SMTP server on the configured port. Check DNS, firewall access, the SMTP hostname, and whether the port is correct for the chosen security mode.
Why are emails sent but not received?
The mail may be accepted by the SMTP server but later filtered as spam or rejected due to missing SPF, DKIM, or DMARC records. It can also be blocked by the recipient’s mail system.
Do background jobs need different email settings from the web app?
Usually the SMTP settings are the same, but background jobs may need additional environment variables, service permissions, or scheduler configuration to run correctly inside Tomcat.
Can a Java version change break email sending?
Yes. Older Java runtimes may not support the TLS requirements of the mail server, or a library may behave differently after an upgrade. Always retest mail after changing the JVM version.
Conclusion
Email features in a Tomcat web app fail most often because of SMTP configuration, TLS mismatch, unreachable mail servers, or delivery authentication problems rather than the mail code itself. In a hosted environment with Plesk and My App Server, the fastest way to resolve the issue is to verify the SMTP details, check logs, confirm the Java and Tomcat versions, and test both the application and the mailbox service separately.
By treating sending, delivery, and background job execution as separate layers, you can identify the real failure point much faster and restore reliable email sending for your Java, JSP, or servlet application.