Why are email features not working in a Java web app in the UK

When email features in a Java web app stop working, the cause is often not the Java code itself but the surrounding mail, DNS, or SSL configuration. In a hosting environment, a Tomcat or JVM-based application may be able to run normally while SMTP connections fail, DNS lookups return the wrong host, or secure mail delivery is blocked by certificate or port restrictions.

This is especially common for applications deployed on shared hosting with a private JVM or Tomcat instance through Plesk and a Java hosting extension such as My App Server. The application may work for pages, forms, and database access, but features like password reset, order notifications, contact forms, and automated alerts do not send email.

Below you will find the most common reasons email-related features fail in a Java web app, how to check each one, and what to change in your hosting and application settings.

Why Java email features fail even when the app is running

A Java application usually sends mail in one of two ways:

By connecting directly to an SMTP server such as your mailbox provider or a transactional mail service.
By handing the message to a local or remote mail relay configured in the app, Tomcat, or the hosting control panel.

If one of the supporting layers is misconfigured, the mail function fails even if the application server is healthy. Common points of failure include:

Wrong SMTP host, port, username, or password.
SSL/TLS mismatch between the app and the mail server.
DNS resolution problems for the mail hostname.
Outbound port restrictions on the hosting account or network.
Invalid sender address or domain authentication issues such as SPF, DKIM, or DMARC.
Java truststore problems when the mail server uses a certificate the JVM does not trust.
Application code using outdated JavaMail settings or incompatible TLS versions.

Check the SMTP settings in the Java app first

The first step is to confirm that the application is configured with the correct mail server values. Many mail problems are caused by a simple typo in the Java properties file, environment variables, or framework configuration.

Verify these values

SMTP host: the mail server hostname, for example smtp.example.co.uk.
Port: commonly 25, 465, or 587 depending on the provider.
Username: usually the full mailbox address.
Password: make sure the mailbox password is current.
Encryption: SSL on port 465, STARTTLS on port 587, or no encryption only if explicitly required.
From address: should match the domain policy of the mail server.

For JavaMail and Spring-based apps, check whether the app is set to use authentication and whether STARTTLS or SSL is enabled in the correct combination. A frequent issue is trying to use SSL on a port that expects STARTTLS, or the other way around.

Typical JavaMail examples of what can go wrong

Using port 465 with STARTTLS instead of implicit SSL.
Using port 587 but forgetting to enable TLS.
Using a hostname that resolves only in your local office network but not on the hosting server.
Using a mailbox account that can receive mail but is not allowed to send through SMTP authentication.

Confirm the mail server hostname resolves correctly

Mail delivery depends on DNS. If your Java app cannot resolve the SMTP host, it cannot connect to the server. This can happen even when the website itself loads correctly.

What to check

Make sure the SMTP hostname exists in public DNS.
Check for spelling errors in the hostname.
Confirm that the app server can reach the hostname from the hosting environment.
If the hostname was recently changed, allow time for DNS propagation.

If your app uses a custom mail server name, test whether the domain has valid A or CNAME records. If the mail server is meant to be part of the same domain, verify that the DNS zone contains the right records and that they point to the current service.

In a Plesk-based hosting environment, DNS settings can be managed in the panel or delegated to external DNS. A mismatch between the active DNS zone and the actual mail server location is a common reason for failed SMTP connections.

SSL and TLS issues with SMTP connections

Modern mail services usually require encryption. If the Java runtime cannot negotiate the expected SSL/TLS version, the connection fails with handshake errors, certificate validation errors, or timeouts.

Common SSL-related symptoms

javax.net.ssl.SSLHandshakeException
PKIX path building failed
Connection timeout during TLS negotiation
Authentication works, but sending fails when encryption is enabled

What this usually means

The mail server certificate is not trusted by the JVM.
The Java version is too old for the mail server’s required TLS version.
The application is using the wrong SMTP security mode for the chosen port.
A proxy, firewall, or intermediate service is interrupting the handshake.

How to fix it

Check the SMTP provider’s documentation for the required port and encryption mode.
Confirm the Java version in your My App Server setup supports the required TLS version.
Update the app to use STARTTLS on 587 or SSL on 465, depending on the provider.
If the server uses a private or custom certificate, import the CA chain into the JVM truststore if needed.
Restart the Java service after changing SSL-related settings.

In hosted Tomcat environments, it is important to remember that the JVM has its own certificate store. A certificate that your browser trusts is not always automatically trusted by the Java runtime.

Check outbound port access from the hosting account

Some hosting platforms limit outbound SMTP connections for security and abuse prevention. This can affect direct mail delivery from a Java application even when the app itself is healthy.

Ports commonly used for outgoing mail

25: traditional SMTP, often restricted on shared hosting.
465: SMTP over SSL.
587: SMTP submission with STARTTLS, commonly recommended.

If your hosting account cannot connect to the chosen port, the app may show connection timeout, refused connection, or authentication errors caused by an incomplete handshake.

Recommended approach

Prefer the provider’s authenticated SMTP submission service.
Use the port and encryption method documented by the mail provider.
Avoid relying on unauthenticated direct delivery from the application server unless it is clearly supported.

For managed hosting and shared Java hosting, authenticated SMTP is usually the most reliable option for application mail features such as registration emails, invoice notifications, and contact forms.

Validate the sender domain and email authentication

Even if the Java app successfully connects to SMTP, messages may still be rejected or filtered if the sender domain is not properly authenticated.

Things to verify in DNS

SPF: allows the mail server to send on behalf of your domain.
DKIM: signs outgoing messages so they can be verified by the recipient.
DMARC: defines how receivers should handle unauthenticated messages.

If your app sends mail using an address like [email protected], make sure the domain is configured to allow sending from the SMTP service you are using. If SPF is missing or incorrect, some providers may accept the message but place it in spam or reject it entirely.

Best practice for Java apps

Use a real mailbox or a properly configured no-reply address.
Keep the sender domain aligned with the SMTP server.
Use a consistent From name and address across the application.
Test delivery to multiple mailbox providers, not only one inbox.

Review application logs and Tomcat logs

In My App Server and Apache Tomcat environments, logs are one of the fastest ways to identify the real cause. A failed mail action usually leaves a clear Java exception or SMTP response code.

Look for these entries

Authentication failures, such as invalid username or password.
Connection refused or timeout errors.
SSL handshake exceptions.
Relay denied responses from the mail server.
Invalid address formatting or header errors.

If your application uses Spring Boot, Hibernate, or another framework, review both the framework logs and the Tomcat stdout or catalina logs. A problem may be reported by the mail library before the application-level error page shows anything useful.

Useful log clues

535 Authentication failed usually means the login details are wrong or SMTP access is blocked for that mailbox.
550 relay not permitted usually means the server will not send mail for the chosen sender without proper authentication.
Could not connect to SMTP host usually indicates DNS, port, or firewall issues.
PKIX path building failed usually indicates a certificate trust issue inside Java.

Check the Java version and mail library compatibility

Some email failures happen after a Java upgrade or when an older application is deployed into a newer runtime. Mail servers and TLS requirements evolve, and older Java versions may not support current security defaults.

Things to confirm

The Java version selected in My App Server matches the application requirements.
The mail library version is compatible with that Java runtime.
The app does not force old TLS protocols such as SSLv3 or TLS 1.0.
The application is not using obsolete JavaMail configuration flags.

If you manage a WAR or JSP application on a private JVM, it is a good idea to test mail sending after each Java version change. A setup that works on one Java release may fail on another if the mail provider has tightened security rules.

Test mail sending outside the application

Before changing code, it helps to separate network problems from application problems. If possible, test the same SMTP details with a simple mail client or command-line test from a controlled environment.

What this tells you

If mail works outside the app, the problem is likely in the Java configuration or code.
If mail fails everywhere, the issue is likely DNS, credentials, SSL, or the SMTP service itself.
If mail works from one network but not from the hosting environment, outbound access may be restricted.

When using a managed hosting platform, you may not have shell access for full diagnostics. In that case, the fastest route is usually to compare the SMTP settings against the provider’s documentation and review the Tomcat logs for the exact failure message.

Special notes for Plesk and My App Server setups

In a Plesk-based Java hosting environment with My App Server, the application may run in its own JVM and Tomcat service, separate from website and mail services. That separation is useful for control and stability, but it also means mail problems can come from several different layers.

What to check in the hosting panel

Verify the selected Java version for the application.
Check whether the Tomcat or application service is running normally.
Review any custom application server settings that affect environment variables or JVM options.
Confirm that the domain’s DNS and mail settings are consistent with the SMTP host.
Restart the service after making configuration changes.

If your app uses a custom Tomcat installation or manually uploaded Java version, ensure that the mail library and truststore are included correctly. A missing library or an incomplete Java setup can break mail functionality even when the web app starts without visible errors.

Practical troubleshooting checklist

Use this checklist when email features stop working in a Java app:

Confirm the SMTP hostname, port, username, and password.
Check whether the app should use SSL or STARTTLS.
Verify that the SMTP host resolves in DNS.
Test whether outbound access to the SMTP port is allowed.
Review Java and Tomcat logs for the exact exception.
Check the JVM version and TLS support.
Make sure the sender domain has valid SPF, DKIM, and DMARC records.
Restart the application server after changes.
Send a test message to more than one mailbox provider.

Examples of common scenarios

Password reset emails do not arrive

This usually means the app can generate the email but delivery fails after submission. Check the sender domain, SPF/DKIM, and spam filtering. Also confirm that the SMTP server accepted the message rather than rejecting it.

Contact form submits successfully, but no email is sent

This often points to an SMTP authentication problem, a wrong From address, or a connection issue from the hosting account to the mail server.

Mail works on the developer machine but not in hosting

This is usually a network or SSL issue. The hosting environment may have different outbound restrictions, DNS resolvers, or JVM certificate trust settings than your local machine.

Only secure SMTP fails

This is often caused by a TLS mismatch or a certificate trust problem. Review the Java runtime version and make sure the correct port and encryption mode are configured.

When to contact hosting support

Contact support if you have already checked the application settings and logs, but the issue remains unclear. Provide the exact SMTP host and port, the Java version, the error message, and a short description of what the app is trying to do.

This helps identify whether the problem is in the app, the JVM, the Tomcat service, DNS, or network access from the hosting account.

FAQ

Why does my Java app work except for email?

Because email depends on separate services such as SMTP, DNS, SSL, and outbound connectivity. The web application may run correctly while the mail path fails.

Is this usually a Tomcat problem?

Not usually. Tomcat is often only the runtime where the problem appears. The root cause is more often SMTP configuration, DNS, TLS, or mailbox authentication.

Can I send mail directly from a Java app on shared hosting?

Usually yes, if the hosting platform and mail provider allow authenticated SMTP access. In many cases, authenticated submission through port 587 is the most reliable option.

Why do I get SSL handshake errors when sending mail?

This usually means the Java runtime does not trust the mail server certificate, the TLS version is too old, or the app is using the wrong security mode for the port.

Do I need SPF and DKIM for application emails?

Yes, if you want better delivery and fewer rejections or spam issues. They are especially important when the application sends password resets, invoices, alerts, or other automated messages.

What is the best port for SMTP in a hosted Java app?

Most providers recommend port 587 with STARTTLS. However, you should always follow the mail service’s own documentation and match the encryption settings exactly.

Summary

Email features in a Java web app often fail because of SMTP, DNS, SSL, or mailbox authentication issues rather than the application itself. In a hosting environment with My App Server, Tomcat, and Plesk, the best approach is to verify the SMTP configuration, check DNS and TLS settings, review logs, and confirm that outbound access is allowed from the account. Once the mail service, DNS records, and Java runtime are aligned, most sending problems can be resolved without changing the core application logic.

Why are email features not working in a Java web app in the UK?