Tomcat applications can send email from shared hosting when the server is configured with an SMTP service that your Java app can reach, and when the application is allowed to use the right network settings, credentials, and sender address. In a managed hosting environment with Plesk and My App Server, this is usually straightforward for standard application mail such as password resets, contact forms, order notifications, and job alerts.
For most hosted Tomcat, JSP, and servlet applications, the safest and most reliable approach is to send mail through a normal SMTP server rather than trying to deliver directly from the application server itself. This helps avoid blocked outbound ports, poor deliverability, and rejected messages caused by missing DNS records or shared-IP reputation issues.
How email sending works in Tomcat on shared hosting
Tomcat does not send mail by itself. Your application uses a mail library, usually the JavaMail API or Jakarta Mail, and connects to an SMTP server. The SMTP server may be provided by your hosting account, by your organization, or by a third-party mail service.
In a shared hosting setup, the Tomcat instance runs inside your hosting account, often as a private JVM managed through Plesk and the My App Server extension. That means your app can send email only if the following are available:
- An SMTP server address and port
- Valid authentication credentials, if required
- Allowed outbound network access from the JVM
- A sender address that matches the mail system rules
- Correct TLS/SSL settings when the SMTP server requires encryption
For hosted Java applications, this pattern is ideal because the mail flow remains separate from the application runtime. The Tomcat app generates the message, the SMTP server handles delivery, and the hosting platform only needs to permit the connection.
Recommended mail setup for Tomcat applications
For most small and medium Java applications, the best practice is to configure your app to send mail through an authenticated SMTP account. This can be the mailbox associated with your domain or a dedicated transactional mail service.
Use SMTP instead of direct server-to-server delivery
Direct delivery from Tomcat to recipient mail servers is usually not recommended on shared hosting. It can fail because many providers block outbound SMTP on port 25, and recipient servers may reject messages that come from dynamic or shared infrastructure without proper reputation, SPF, DKIM, and PTR alignment.
Using SMTP submission on port 587 or secure SMTPS on port 465 is usually the most practical option. These ports are designed for authenticated mail sending and work better in managed hosting environments.
Choose the right sender address
Use a real mailbox or a valid no-reply address on your domain, such as [email protected] or [email protected]. Avoid random free-mail sender addresses in production, because they often cause rejection or spam filtering.
Also make sure the From address, Reply-To address, and SMTP login are consistent with your domain policy. Some SMTP servers will refuse to send if the envelope sender does not match the authenticated account.
Prefer TLS or SSL
Email credentials should never be sent in plain text. Use TLS on port 587 or SSL on port 465 if your mail provider supports it. In Java mail configuration this usually means enabling authentication and encryption explicitly.
Typical Tomcat mail configuration
Most Java web applications use JavaMail or Jakarta Mail to connect to an SMTP server. The exact implementation depends on your code or framework, but the core settings are usually the same.
Common SMTP settings
- Host: smtp.example.com
- Port: 587 for STARTTLS, or 465 for SSL
- Authentication: enabled
- Username: full mailbox address or mail account login
- Password: mailbox or application-specific password
- Encryption: TLS or SSL depending on the provider
What your application usually needs
- Mail library dependency in the project
- SMTP configuration in application properties or environment variables
- Correct server time and timezone for message timestamps and scheduled jobs
- Exception handling and logging for failed deliveries
In hosted Tomcat environments, it is often better to store these values outside the application code, for example in configuration files or Plesk-managed environment settings, so they can be updated without a full redeploy.
Setting up email in My App Server and Plesk
On managed Java hosting with My App Server, Tomcat runs as a service under your hosting account. This makes it easier to control versions, restart the service, and keep settings isolated from other websites or apps on the same platform.
Check whether outbound SMTP is allowed
Before testing mail from your application, confirm that your hosting plan allows outbound connections to the SMTP port you plan to use. In many environments, port 587 is allowed, while port 25 may be restricted.
If your application cannot connect, the issue may not be in the code. It may be a network limitation, firewall rule, or SMTP provider policy.
Verify Java version compatibility
Different Tomcat and Java versions may use different mail libraries or module behavior. If your app is running on a selected Java version through My App Server, ensure that your mail library supports that runtime. This is especially important for older applications migrated to newer Java releases.
Use service control for restart after changes
After adjusting mail properties, application config files, or library dependencies, restart the Tomcat service through the control panel. This ensures that configuration changes are loaded and old connections are closed cleanly.
If the application reads email settings at startup, a service restart is often required before new SMTP values take effect.
Practical steps to send email from a Tomcat app
The exact steps vary by framework, but the following workflow applies to most hosted servlet and JSP applications.
- Choose the SMTP server you want to use.
- Create or confirm the sender mailbox and password.
- Check whether port 587 or 465 is supported by the hosting platform and mail provider.
- Add the mail dependency to your application if it is not already included.
- Set SMTP host, port, username, password, and encryption options.
- Deploy or update the WAR file.
- Restart the Tomcat service if needed.
- Run a test email from the application and inspect logs if it fails.
Example use cases
- Password reset emails for a customer portal
- Contact form notifications from a JSP site
- Order or booking confirmations
- Scheduled reminder emails from a background job
- System alerts for app errors or failed tasks
How to avoid common email delivery problems
Email sending from shared hosting usually fails for one of a few predictable reasons. Knowing these in advance can save time during deployment and support checks.
Authentication failures
If the SMTP server returns a login error, confirm the username and password, and check whether the mailbox requires an app password or special authentication method. Some providers also require the full email address as the username.
Connection refused or timeout
This usually means either the SMTP host is wrong, the port is blocked, or the network route is not available from the hosting account. Try a different port such as 587, and verify the provider’s SMTP documentation.
Mail sent but not received
If the application reports success but messages do not appear in the inbox, review spam folders, sender reputation, SPF/DKIM settings, and the exact From address. It is also worth checking whether the message body or subject contains patterns that trigger spam filters.
TLS handshake errors
These errors usually mean the Java runtime cannot negotiate the encryption settings expected by the SMTP server. This can happen with older Java versions, outdated certificates, or a mismatch between STARTTLS and SSL configuration.
Incorrect sender policy
Some SMTP servers will reject messages if the sender address does not belong to the authenticated account or verified domain. Always align the sending account with the domain used by the application.
Best practices for hosted Tomcat mail sending
Following a few simple practices will make mail handling much more reliable on shared hosting.
- Use authenticated SMTP rather than direct delivery.
- Store credentials outside the application source code where possible.
- Use a domain-based sender address.
- Enable TLS or SSL.
- Log mail failures clearly, including SMTP response codes.
- Test after every deployment or Java version change.
- Keep mail logic separate from user-facing request processing when possible.
If your app sends a high volume of messages, consider moving bulk or transactional mail to a dedicated mail service. Shared hosting can handle standard application notifications, but large campaigns or heavy email queues are not a good fit for a Tomcat app running in a shared account.
Sending email from background jobs and scheduled tasks
Many Tomcat applications send mail from background processes rather than from a user request. This is common for queued notifications, cron-like jobs, or scheduled reminders.
On managed hosting, background tasks should be designed carefully so they do not overload the JVM or conflict with app restarts. When sending mail from jobs, make sure the task:
- Uses the same tested SMTP settings as the main application
- Handles retries gracefully
- Writes useful logs when delivery fails
- Does not block the application thread pool for too long
If the job framework depends on a persistent scheduler, make sure it is compatible with the hosting model and service control features available in My App Server.
Troubleshooting checklist
If your Tomcat application cannot send email, use this checklist to narrow down the issue quickly:
- Confirm the SMTP server name and port.
- Check whether the account can connect to that port from shared hosting.
- Verify the mailbox username and password.
- Ensure TLS or SSL is configured correctly.
- Test with a simple message first, not a large template.
- Review Tomcat logs and application logs for SMTP error details.
- Restart the service after changing runtime settings.
- Check recipient spam and quarantine folders.
- Validate the sender domain authentication if you control DNS.
Useful log clues
SMTP errors often include messages such as authentication denied, connection timed out, relay denied, or certificate validation failure. These phrases usually point directly to the layer that needs attention: credentials, network access, server policy, or encryption.
FAQ
Can a Tomcat app send email without a mail server?
No. The application needs an SMTP server or an email service to relay messages. Tomcat itself is only the runtime for your Java web app.
Is port 25 recommended for sending mail from shared hosting?
Usually no. Port 25 is often restricted and is not the best choice for application mail. Port 587 with STARTTLS is generally the preferred option.
Can I use my website mailbox as the SMTP account?
Yes, in most cases that is a practical option. Just make sure the mailbox is active, the password is correct, and the provider allows authenticated sending from external apps.
Do I need JavaMail in every Tomcat application?
Only if the app sends email directly. Some frameworks include mail support already, while others require you to add the library and configure it manually.
Why does mail work locally but fail on hosted Tomcat?
Local environments often allow unrestricted network access and different SMTP settings. Hosted environments may block some ports, require TLS, or enforce authentication rules that your local setup does not use.
Can I send mail from scheduled tasks in My App Server?
Yes, as long as the task uses supported Java runtime settings and the SMTP configuration is valid. For reliable delivery, keep the job lightweight and make sure errors are logged.
Conclusion
Tomcat applications on shared hosting can send email reliably when they use authenticated SMTP, the correct Java mail configuration, and a hosting setup that allows outbound connections to the required port. In a managed environment with Plesk and My App Server, this usually means configuring your private JVM, deploying the application, and testing delivery through a standard mail account or transactional provider.
For most Java hosting use cases, the simplest and most stable approach is to keep email delivery separate from the application server itself: let Tomcat create the message, let SMTP deliver it, and use the control panel to manage service settings and restarts when needed. This gives you a clean setup for contact forms, notifications, scheduled jobs, and other email-driven application tasks.