When email features stop working inside a Java web app, the cause is often not the application code alone. In a hosted Java environment, the app may be blocked by local mail settings, an incorrect SMTP host, missing authentication, port restrictions, a Tomcat/JVM configuration issue, or a provider-side policy that affects how outbound mail is sent. In the UK hosting context, the most common pattern is that the application works locally, but sending mail fails once it is deployed to the hosting account.
With Java hosting on a managed platform such as My App Server in Plesk, it is usually possible to run a private Tomcat or JVM and control the deployment environment more closely. That makes troubleshooting easier, but it also means you need to check both the Java application and the hosting service settings. If your app sends password resets, order confirmations, contact form alerts, background job notifications, or scheduled reports, even one incorrect mail parameter can break the whole feature.
Common reasons Java email sending fails on hosted apps
Email delivery from a Java application typically depends on several layers working together:
- the app must build the message correctly;
- the SMTP server must be reachable from the hosting account;
- the SMTP credentials must be valid;
- the host name, port, TLS and authentication options must match the mail service;
- the Java runtime must trust the mail server certificate if encryption is used;
- the hosting platform must allow outbound mail on the selected port.
If any one of these fails, the feature may appear to be “broken” even though the issue is actually environmental.
Incorrect SMTP settings
This is the most frequent cause. Many Java apps are configured with a localhost mail host, a wrong port, or SMTP settings copied from another environment. Common mistakes include:
- using localhost when the mail server is external;
- using the wrong port for TLS or SSL;
- turning on authentication but leaving the username or password empty;
- using the mailbox address instead of the SMTP login;
- setting the wrong sender address, which the server rejects.
Outbound port restrictions
Some hosting environments restrict direct outbound SMTP traffic, especially on port 25. This is often done to reduce abuse and improve service reliability. In a hosted Java environment, you may need to use the provider’s recommended mail submission port, usually 587 with STARTTLS or 465 with SSL, rather than raw SMTP on port 25.
If your app connects successfully in development but times out in production, port filtering is a strong possibility.
Authentication or TLS mismatch
Modern SMTP servers usually require authentication and encryption. If the Java mail client is configured for plain text, or if it does not send the proper EHLO/TLS handshake, the server may reject the connection. Java apps can also fail if the mail server certificate is not trusted by the JVM trust store.
In a managed hosting setup, this becomes visible as a connection failure, handshake error, or authentication rejection in the application logs.
Sender policy problems
Many mail systems check whether the sender address is allowed for the selected mailbox or domain. If your app sends mail from an address that does not belong to the domain, or if the SMTP server enforces strict sender rules, delivery can fail. This is especially common with notification systems that use a generic “from” address but authenticate with a different account.
Tomcat or JVM configuration issues
In Java hosting, the app usually runs inside Tomcat or another private JVM provided by the hosting platform. If the application depends on environment variables, JNDI resources, custom mail properties, or a specific Java version, a mismatch in the runtime can prevent mail from being sent.
Examples include:
- the app expects Java 8 but the service is running on a different version;
- mail properties are defined in the wrong context file;
- a deployed WAR does not read the correct configuration file;
- the JVM has insufficient trust store settings for TLS mail connections;
- the app uses an outdated mail library with modern SMTP requirements.
How to troubleshoot email features in a Java web app
Use a structured approach. Start by checking the application logs, then verify the SMTP settings, and finally confirm that the hosting service allows the connection.
1. Check the application logs first
Most Java mail failures leave a clear error message. Look for:
- authentication failures;
- connection timeouts;
- certificate errors;
- “relay denied” messages;
- invalid recipient or sender errors;
- mail transport exceptions from JavaMail or Jakarta Mail.
In Plesk-based Java hosting, the Tomcat or application logs usually provide the fastest answer. If the log only says that mail sending failed, enable more detailed logging in the app temporarily so you can capture the SMTP response.
2. Verify the SMTP host and port
Confirm the exact details used by the hosting mail service or third-party email provider. Check:
- SMTP host name;
- submission port;
- whether TLS or SSL is required;
- whether authentication is mandatory;
- the correct mailbox or login name.
If the app uses a web form, password reset flow, or scheduled notification job, make sure the same SMTP settings are used everywhere. Partial configuration differences between dev, staging, and production often cause hidden failures.
3. Test authentication outside the app
Before assuming the Java code is wrong, test the mailbox credentials in a mail client or with a simple SMTP test tool. If the login fails there too, the issue is not in the app. Reset the password if needed, and make sure the provider has not blocked the account due to security rules.
4. Confirm TLS and certificate trust
If the SMTP server requires TLS, Java must trust the certificate chain. On hosted platforms, this may depend on the Java version and trust store used by the private JVM. Symptoms often include SSL handshake exceptions or server identity validation failures.
To check this, review the exact exception text. If the certificate is self-signed or the chain is incomplete, the app may need a proper trust configuration or a supported mail service endpoint.
5. Check sender address rules
Make sure the From address is valid for the domain and accepted by the SMTP service. Use a sender address that matches the authenticated mailbox or the configured domain policy. If the app sends mail on behalf of users, separate the visible sender name from the authenticated SMTP account.
6. Review hosting limits and mail policy
In shared hosting environments, there may be rate limits, message limits, or abuse protection rules. A scheduled Java job that sends a burst of notifications can hit these limits even if the first few emails work. If your background task sends many messages in a short period, check whether the platform throttles outbound mail.
What to check in My App Server and Plesk
When Java hosting is managed through My App Server, you can usually control the app runtime, Tomcat service, and Java version from the hosting panel. That helps when mail issues are caused by the environment rather than the code.
Java version and runtime alignment
Mail libraries can behave differently across Java versions. If the application was built for a specific runtime, install or select the matching version in the service settings. If you upload a custom app server, make sure the JVM and application dependencies are compatible with the mail library in use.
Tomcat service status
If the app sends mail from a background job, cron-like task, or scheduled servlet action, the service must be running normally. A stopped or restarting Tomcat instance can make the feature appear intermittent. Check service control in the panel and review whether the JVM has enough resources for the application.
Configuration files and environment variables
Many Java apps read SMTP settings from:
- properties files;
- environment variables;
- JNDI resources;
- Spring configuration;
- application-specific admin settings.
Verify that the deployed version is reading the intended values. If the app was moved from a local server to hosted Tomcat, the deployment path or config location may have changed.
Custom Tomcat or uploaded app server
If you use a custom Java/Tomcat setup, confirm that the mail libraries are present and loaded correctly. A custom app server gives flexibility, but it also means you are responsible for matching the runtime to the app’s requirements. Missing dependencies or an incorrect server layout can break mail features even when the source code is correct.
Best practices for Java email features in hosted environments
To reduce failures and support requests, configure your app with production-safe mail settings from the start.
- Use authenticated SMTP, not anonymous relay.
- Prefer the provider’s recommended submission port.
- Store credentials securely, not in public code.
- Separate development and production mail profiles.
- Log SMTP errors clearly but avoid exposing passwords or full recipient data.
- Use a verified sender address for the domain.
- Handle retry logic carefully for scheduled jobs.
- Keep the mail library updated for current SMTP and TLS support.
For scheduled jobs or background tasks, it is especially important to fail gracefully. If the mail server is unavailable, the job should log the error and retry in a controlled way rather than blocking the entire application.
Email jobs and background tasks in Java apps
Many hosted Java apps do not send mail only from user actions. They also send messages from background tasks such as:
- daily reports;
- queued notifications;
- order or ticket status updates;
- password reset reminders;
- cleanup jobs that notify administrators when something fails.
These tasks can fail for a different reason than interactive mail. A job may run under a different user, load a different configuration file, or start before the application is fully initialized. If email works in one part of the app but fails in another, compare the execution context carefully.
Also check whether the task depends on the system clock, locale, or timezone. In some applications, scheduled mail jobs fail because they trigger at unexpected times or read date-based configuration incorrectly.
Example checklist for diagnosing SMTP failure
Use this practical checklist when a Java web app in hosting cannot send email:
- Read the Tomcat or application error log.
- Confirm SMTP host, port, username, password, and encryption mode.
- Test the mailbox login separately.
- Check whether port 25 is blocked and use 587 or 465 if required.
- Verify sender address policy and domain alignment.
- Check TLS certificate trust in the JVM.
- Confirm the deployed environment uses the expected Java version.
- Review the app’s config file path and environment variables.
- Test mail from both the web request path and the background job path.
- Look for hosting limits or rate throttling if multiple messages fail together.
When the issue is in the application code
Sometimes the hosting environment is fine and the app itself is the problem. This is more likely if:
- the SMTP details are correct but the app still builds invalid headers;
- the message body contains unsupported characters or malformed MIME content;
- the code swallows exceptions and reports success even when mail failed;
- the app uses outdated Java mail APIs or incompatible library versions;
- the code sends mail before the configuration has loaded.
In these cases, review the mail-sending class, exception handling, and message construction. If possible, create a minimal test endpoint that sends a single message with fixed settings. This helps separate code issues from environment issues.
When to contact hosting support
Contact support if you have already checked the app logs and confirmed that the configuration is correct, but mail still fails due to connection or policy errors. Useful details include:
- the exact error message from the Java log;
- SMTP host and port used by the app;
- the Java version in the hosted environment;
- whether the issue affects all messages or only some;
- the time the failure occurred;
- whether the problem started after a deployment or password change.
For a managed hosting platform, clear logs and reproducible steps usually speed up resolution much more than a general report like “email is not working.”
FAQ
Why does email work locally but fail after deployment?
Local development often uses a different SMTP server, a permissive firewall, or a simpler Java runtime. After deployment, the hosting account may require authenticated SMTP, a different port, or TLS. The app code may be fine, but the production environment is stricter.
Can a Java app send mail without a local mail server?
Yes. Most hosted Java apps use an external SMTP service or the hosting provider’s mail service. The app connects to that SMTP server over an allowed port and authenticates with mailbox credentials.
Why do I get a timeout when sending email?
A timeout usually means the app cannot reach the SMTP host or the port is blocked. It can also happen if DNS resolution fails or if the remote service is not accepting connections from the hosting environment.
Why does my background job send mail only sometimes?
This often points to intermittent configuration loading, temporary mail server rejection, rate limits, or service restarts. Check whether the job runs while Tomcat is fully available and whether the mail server is throttling repeated messages.
Do I need a special Java version for email features?
Usually no, but the runtime must be compatible with your mail library and TLS requirements. In a private JVM setup, using the correct Java version can prevent certificate and API compatibility issues.
Conclusion
When email features fail inside a Java web app in the UK hosting context, the root cause is usually a mismatch between the application’s mail settings and the hosted runtime. Start with the logs, confirm SMTP host and port, check authentication and TLS, and then review Tomcat or JVM configuration in the control panel. In a My App Server environment, the advantage is that you can manage the Java version, service status, and deployment setup in one place, which makes it easier to isolate whether the problem is in the app, the mail service, or the hosting policy.
For Java hosting, Tomcat hosting, JSP applications, and scheduled mail jobs, the best results come from a simple, well-documented SMTP setup and clear separation between application code and server configuration.