If the main parts of your Tomcat application work, but email features do not, the problem is usually not Tomcat itself. In most UK hosting setups, email sending depends on SMTP access, DNS records, authentication, SSL/TLS settings, and sometimes firewall rules outside the Java application. A Tomcat web app can generate the mail request correctly and still fail because the surrounding mail service is misconfigured or blocked.
This article helps you check the most common causes in a managed hosting environment with Plesk and a Java hosting setup such as My App Server. It covers SMTP login errors, TLS certificate issues, DNS problems, local port restrictions, and application-level mistakes in JavaMail or other mail libraries.
Why email features fail in a Tomcat web app
Email sending from a Tomcat app normally follows this path:
- The application creates an email message.
- JavaMail or another mail library connects to an SMTP server.
- The SMTP server authenticates the account.
- The message is encrypted with SSL/TLS if required.
- DNS records and mailbox policy allow the message to be accepted and delivered.
If any part of that chain fails, the user sees a generic error such as:
- Authentication failed
- Connection timed out
- Could not convert socket to TLS
- Mail server connection refused
- Unable to send message
In a shared hosting account with a private JVM or Tomcat instance, the issue is often caused by one of the following:
- Incorrect SMTP host, port, username, or password
- Using the wrong security mode, such as SSL on a STARTTLS port
- Mail sent from localhost without a working local mail service
- DNS records missing or inconsistent, especially SPF, DKIM, or MX
- Provider firewall blocking outbound SMTP ports
- Certificate trust issues in the Java runtime
- Application code using an outdated mail configuration
Check the SMTP settings first
The most common cause is a simple SMTP configuration issue in the application. If the app is sending mail through your hosting mailbox or an external provider, confirm the exact server name and port.
Typical SMTP settings to verify
- SMTP host: the mail server hostname, not the website domain unless that is the correct mail host
- Port: often 587 for STARTTLS, 465 for SSL/TLS, or 25 in some environments
- Username: usually the full email address
- Password: mailbox password, app password, or provider token if required
- Encryption: SSL/TLS or STARTTLS, depending on the port
A frequent mistake is to mix port and encryption type. For example, port 465 normally expects SSL from the start, while port 587 usually uses plain connection first and then STARTTLS. If your Java app is configured for the wrong mode, the connection may fail even though the credentials are correct.
What to test in Plesk or your control panel
- Open the mailbox settings and confirm the outgoing server details.
- Check whether the mailbox can send manually from webmail.
- Confirm that the password has not expired or been changed.
- Verify whether the provider requires a specific outgoing server hostname.
If webmail works but the Tomcat app does not, the problem is usually in the Java settings, not the mailbox itself.
Make sure the Java app uses the correct mail host
In hosting environments, developers sometimes point JavaMail to localhost or 127.0.0.1 because that works in local development. On a managed hosting account, this often fails unless a local MTA such as Postfix is available and allowed for your service.
For most Tomcat hosting setups, it is better to use the authenticated SMTP service provided in the control panel or by your mail provider. That ensures proper authentication, logging, and delivery.
Example of a safer approach
- Use the full SMTP hostname provided by the hosting service.
- Use authenticated SMTP rather than unauthenticated local relay.
- Use the correct port for encrypted delivery.
- Set a realistic timeout so the app does not hang on connection attempts.
If you are deploying a WAR file through My App Server, the mail configuration is still part of the app itself. Tomcat manages the application runtime, but it does not automatically fix SMTP settings inside your code or properties file.
Check SSL/TLS certificate trust in Java
One of the most common causes of mail failure in Java hosting is certificate trust. Java is stricter than some other clients when connecting to SMTP servers over SSL/TLS. If the SMTP server presents a certificate chain that the Java runtime does not trust, the connection can fail.
Symptoms of certificate problems
- Handshake failure
- PKIX path building failed
- SSL peer unverified
- Unexpected close during TLS negotiation
This can happen if:
- The SMTP server uses a certificate chain not recognized by the JVM
- The server name in the app does not match the certificate name
- The Java runtime is old and does not trust a newer root certificate
- The application uses self-signed certificates without importing them into the trust store
What to check
- Use the exact SMTP hostname issued by the mail provider.
- Avoid connecting by IP address if the certificate is issued to a hostname.
- Confirm the JVM version used by your My App Server instance.
- If you manage your own trust store, make sure the chain is imported properly.
In many cases, simply upgrading to a supported Java version or correcting the SMTP hostname resolves the issue.
Review DNS records for the domain
DNS problems do not always stop your app from sending mail, but they can break delivery, spam reputation, or domain validation. This is especially relevant if your app sends mail as your domain name, such as invoices, contact forms, password resets, or order confirmations.
Important DNS records to inspect
- MX record: points to the correct inbound mail server
- SPF record: authorizes the sender service
- DKIM record: signs outgoing messages
- DMARC record: defines policy and reporting
- A/AAAA records: must be correct if the app references a hostname used for mail
Even if SMTP authentication succeeds, messages may still land in junk folders or be rejected if SPF and DKIM are missing or inconsistent. For business applications in the UK market, this is especially important for transactional emails such as payment notices and account activation emails.
Common DNS-related mistakes
- Sending mail from a domain without SPF
- Using a From address that does not match the authenticated account
- Changing mail providers without updating DNS
- Creating subdomain sender addresses without DNS authorization
If your Tomcat app sends from [email protected], make sure the domain is authorized to send through the chosen SMTP service.
Check outbound port access from the hosting environment
Some hosting platforms restrict direct outbound SMTP connections for security and abuse prevention. This means your Java app may not be allowed to connect to port 25, and sometimes even 465 or 587 may be filtered depending on the service policy.
If the app times out instead of returning an authentication error, a blocked port is a strong possibility.
How to recognise port blocking
- Connection timeout to the SMTP server
- No response from the mail host
- Works on your local machine but not on the hosting account
- Fails only when deployed through the server, not in development
Practical checks
- Confirm which SMTP ports are allowed by the hosting platform.
- Use the recommended secure submission port if available.
- Test connection from a simple mail client or diagnostic tool if your access allows it.
- Review any error logs produced by the application or service.
On shared hosting, using the supported mail submission route is usually the most reliable option. The application should not assume unrestricted network access.
Verify the Java mail library and application code
Sometimes the mail server is fine and the issue is inside the application. This is common in JSP, servlet, or WAR deployments where the mail settings are hardcoded, loaded from properties, or assembled dynamically from user input.
Areas to review in code
- SMTP host and port values
- Encryption flags for SSL and STARTTLS
- Authentication enabled or disabled
- From address and reply-to address
- Timeout and retry settings
- Character encoding for message content
If you use JavaMail, confirm that the properties match your SMTP provider. A small mismatch, such as enabling both SSL and STARTTLS at the same time, can cause the connection to fail.
Good practice for mail settings
- Store SMTP settings in external configuration where possible.
- Keep credentials separate from application source code.
- Use one known-good test account first.
- Log the exact exception in application logs without exposing passwords.
For My App Server deployments, this is especially useful because you can update the application and configuration without changing the Tomcat runtime itself.
Check mailbox limits and sending policy
Even when the technical setup is correct, the mailbox or provider may enforce limits that affect application mail. This can include sending quotas, rate limits, attachment size limits, or restrictions on automated mail.
Examples of policy-related issues
- Too many emails sent in a short time
- Messages rejected because the sender is unauthorised
- Attachments too large for the mailbox policy
- Account temporarily blocked after suspicious activity
If your app sends password resets, verification emails, or notification bursts, make sure the sending volume is within the allowed limits. A small Java web app may still trigger anti-abuse controls if it sends repeated test messages.
How to troubleshoot step by step
Use the following order to isolate the fault quickly.
1. Test the mailbox outside Tomcat
- Send a message from webmail or an email client.
- Confirm the mailbox can authenticate successfully.
- Check whether the message is delivered normally.
2. Review the SMTP details in the app
- Check host, port, username, and password.
- Confirm whether the app uses SSL or STARTTLS.
- Compare the settings with the mail provider’s recommended values.
3. Read the application and Tomcat logs
- Look for JavaMail exceptions.
- Check for handshake, timeout, or authentication failures.
- Note the exact error message and timestamp.
4. Verify DNS records
- Confirm SPF and DKIM are published correctly.
- Check the MX record if the domain also receives mail.
- Make sure the From domain matches the sender policy.
5. Test with a known-good SMTP account
- Try a mailbox with simple, verified credentials.
- Use the same app and only change the mail host settings.
- If the test works, the original account or policy is the issue.
6. Check Java version and certificate trust
- Confirm which JVM version your Tomcat instance uses.
- Update the runtime if the version is outdated.
- Import missing certificates only if you manage the trust store intentionally.
Example scenarios
Scenario 1: The app works locally but fails after deployment
This usually means the local machine has access to a mail service that your hosting account does not. The remote environment may block port 25, require authentication, or use a different certificate chain. Update the app to use the hosting-supported SMTP settings.
Scenario 2: Authentication works, but emails go to spam
The problem is likely DNS and sender reputation. Check SPF, DKIM, and the From address. Use a domain-addressed sender that matches the authenticated account. Avoid sending from a free mailbox or mismatched domain.
Scenario 3: The app throws TLS handshake errors
This usually points to a Java trust issue or a hostname mismatch. Confirm the SMTP hostname, use the correct port, and make sure the JVM trusts the certificate chain.
Scenario 4: The app times out with no clear error
This often means outbound SMTP is blocked or the host name cannot be resolved. Check DNS resolution, firewall rules, and allowed ports in the hosting platform.
How My App Server fits into this setup
With My App Server, you can run your own Tomcat or private JVM inside your hosting account and manage Java applications through Plesk. That gives you control over the runtime, Java version, service status, and application deployment, but email still depends on the mail service you configure in the application.
This is useful for JSP, servlet, WAR, and small to medium Java web apps that need a separate runtime and predictable deployment. However, mail delivery remains a separate layer. If the app cannot send email, the fix is usually in SMTP, DNS, SSL, or mailbox policy rather than in Tomcat service control itself.
FAQ
Why does my Tomcat app send emails locally but not on hosting?
Local development often uses a different SMTP server, no firewall restriction, or a local mail relay. In hosting, the app may need authenticated SMTP, a specific port, or a trusted certificate chain.
Can Tomcat send email by itself?
Tomcat provides the application runtime, not the mail service. The application must connect to an SMTP server using Java code or a mail library.
Do I need DNS records for application emails?
Yes, if you send from your own domain. SPF and DKIM are especially important for delivery and spam prevention.
Why do I get a PKIX or SSL error when sending mail?
The Java runtime does not trust the SMTP certificate chain, or the hostname used in the app does not match the certificate.
Is localhost a good SMTP setting on managed hosting?
Usually not, unless your hosting plan explicitly provides a local mail relay for that purpose. In most cases, use the authenticated SMTP server provided by the mail service.
What should I check first if email suddenly stops working?
Start with the SMTP credentials, password changes, and logs. Then verify DNS and certificate trust, and finally check port access and mailbox policy.
Conclusion
When email features fail in a Tomcat web app, the root cause is usually outside the application code itself. In a managed hosting environment, the most common problems are incorrect SMTP settings, TLS certificate trust issues, blocked outbound ports, or DNS records that do not match the sending domain. If your Java app runs through My App Server, Tomcat can serve the application correctly while mail still fails because the SMTP layer is misconfigured.
The fastest way to fix the issue is to test the mailbox separately, confirm the exact SMTP settings, review logs for authentication or SSL errors, and verify SPF, DKIM, and firewall access. Once these layers are aligned, email functionality in the Tomcat app usually starts working reliably.