If your Java application is not starting correctly, returns unexpected errors, or only fails for some users, the cause is not always the application code itself. In a hosting environment, DNS and mail configuration can affect how your app behaves, especially when it depends on domain resolution, SSL certificates, callback URLs, SMTP delivery, or external services. On a shared hosting account with Java support, these issues often appear as Tomcat startup warnings, 502/503 errors, failed login redirects, or messages about unreachable hosts.
This article explains how to identify whether the problem is caused by DNS or mail settings, and how to check the most common configuration points in a Plesk-based hosting panel with My App Server for Java hosting, Tomcat hosting, JSP hosting, servlet hosting, and private JVM use.
Symptoms that often point to DNS or mail-related issues
Java hosting problems caused by DNS or mail settings usually affect external connectivity rather than the Java runtime itself. Typical signs include:
- The application starts, but certain features do not work.
- Login redirects go to the wrong domain or an old address.
- Webhooks, payment callbacks, or API requests fail with host lookup errors.
- Email notifications are not sent, or they are delayed.
- Tomcat logs show UnknownHostException, timeout, or connection refused messages.
- SSL warnings appear because the hostname does not match the certificate or DNS points elsewhere.
- The site works on one network but not on another, which can indicate DNS propagation or caching issues.
In a managed hosting environment, these issues can look like application errors even when the underlying cause is a domain, mail exchanger, or name resolution problem.
Check whether DNS is resolving the correct destination
DNS controls where your domain points. If the A record, AAAA record, or CNAME is incorrect, your Java app may be reached through the wrong host or may not resolve at all. This can cause broken redirects, failed callbacks, and certificate mismatches.
What to verify in the DNS zone
- A record for the main domain points to the correct IP address.
- AAAA record is present only if you intentionally use IPv6.
- www and other subdomains point to the expected host.
- CNAME records do not create loops or point to outdated targets.
- MX records are correct if the same domain is used for mail.
- TXT records for SPF, DKIM, and verification are valid if your app sends email.
If you use Plesk, open the domain’s DNS settings and compare the active records with the values required by your application or by your current hosting setup. A small typo in one record can be enough to break mail delivery or URL generation.
How DNS problems affect Java applications
Java apps often use domain names in several places:
- Application URLs configured in properties files or environment variables.
- SMTP server hostnames used by mail libraries.
- External API endpoints for payment, CRM, or identity services.
- Callback and redirect URLs used by authentication systems.
If a hostname cannot be resolved, Java may throw UnknownHostException. If it resolves to an old or incorrect IP, your app may connect to the wrong service or fail SSL validation.
Simple DNS checks you can perform
Use these checks to confirm whether the domain resolves correctly:
- Open the domain in a browser and verify that it loads the expected site.
- Check the current DNS records in your control panel.
- Test the domain from another network or device to rule out local caching.
- Confirm that any subdomain used by the Java app exists and points to the correct host.
- If you recently changed DNS, wait for propagation and then retest.
When investigating a hosting issue, also compare the hostname used inside your Java configuration with the public domain name. For example, an internal hostname such as app.internal.local will not work for public redirects or external SMTP servers.
Identify problems caused by mail settings
Mail settings matter when your Java application sends password resets, order confirmations, alerts, or contact form messages. In hosting environments, the app usually depends on a valid SMTP host, port, username, password, and encryption mode. A misconfigured mail setup can create errors that look like application failures.
Common mail-related causes
- The SMTP hostname does not resolve in DNS.
- The mail server hostname does not match the SSL certificate.
- Port 25, 465, or 587 is blocked or not allowed by the app configuration.
- Authentication details are wrong.
- SPF or DKIM is missing, so messages are rejected or marked as spam.
- The application uses the wrong From address for the domain.
If outbound mail works for one domain but not another, the issue is often in domain-level DNS or mail authentication records rather than in Tomcat or the JVM.
How to test whether SMTP settings are the problem
Use the following approach:
- Confirm the SMTP host name and port in your application configuration.
- Check that the host name resolves correctly from the server or hosting account.
- Verify whether the application uses SSL/TLS and whether the certificate is valid.
- Send a test message from the application and review the log output.
- Compare the From address with the domain’s SPF and DKIM setup.
If the logs show authentication errors, connection timeouts, or certificate exceptions, the issue is usually with mail configuration or DNS rather than Java code.
Review the Java application logs first
Before changing settings, check the Tomcat and application logs. In My App Server, logs are a key part of troubleshooting because they show whether the error comes from the app, the JVM, DNS resolution, or mail connectivity.
Log messages that suggest DNS or mail trouble
- UnknownHostException - the hostname cannot be resolved.
- Connect timed out - the destination server is unreachable or filtered.
- Connection refused - the port is closed or the service is not listening.
- SSLHandshakeException - certificate trust or hostname mismatch issue.
- MailSendException or similar SMTP-related errors.
- SocketTimeoutException during API calls or SMTP delivery.
If the log shows that Tomcat starts normally and the application deploys correctly, but one feature fails when it tries to reach another service, DNS or mail settings are a strong candidate.
What to compare in the logs
- The exact hostname or mail server mentioned in the error.
- The time of the error and whether it matches a recent DNS change.
- The port number and protocol being used.
- Whether the issue appears consistently or only after cache expiration.
For applications hosted in a private JVM or managed Tomcat instance, this comparison is often the fastest way to isolate the problem.
Check SSL certificate and hostname matching
Although this article focuses on DNS and mail, SSL often overlaps with both. If the domain points to the correct host but the certificate does not match the hostname, browser errors and backend connection failures may appear. Java is especially strict when calling HTTPS endpoints or validating mail servers with encryption enabled.
Typical SSL-related symptoms
- Browser shows a certificate name mismatch.
- Java app cannot connect to an HTTPS API endpoint.
- SMTP over SSL/TLS fails with handshake errors.
- Redirects between http and https loop endlessly.
In Plesk, make sure the certificate is installed for the exact domain or subdomain used by the application. If your Java app uses a separate hostname such as app.example.com, that hostname must be present in DNS and covered by the certificate.
How SSL and DNS work together
DNS ensures the browser or client reaches the correct server. SSL confirms it is talking to the expected hostname. If either side is wrong, Java applications may fail during startup checks, external API access, or mail sending.
Verify the application base URL and redirect settings
Many Java applications generate absolute URLs for login, password reset, payment confirmation, or callback handling. If the base URL in the application configuration does not match the real domain, users may be redirected to a wrong or non-working address.
Things to check
- Application base URL or server URL setting.
- Proxy or reverse proxy headers, if used.
- Hardcoded links in configuration files.
- Callback URLs registered with third-party services.
- Any old domain names left in properties, XML files, or environment variables.
This is especially important after domain changes, SSL renewal, or migration to a new hosting account. The app may still run, but old URLs can make it look broken.
Use Plesk and My App Server to isolate the issue
My App Server in Plesk gives you a practical way to separate Java runtime problems from external dependency problems. Because it allows you to install and control your own Tomcat or private JVM inside a shared hosting account, you can check whether the application itself is healthy while DNS or mail is still failing.
Helpful checks in the hosting panel
- Confirm the Java service is running.
- Check the selected Java version and Tomcat version.
- Review service logs for startup and runtime errors.
- Verify domain binding and document root configuration.
- Check whether the application uses the correct subdomain or context path.
If the service starts correctly and the web app responds, then a later failure is more likely due to domain resolution, SSL, or mail delivery rather than the Java installation itself.
When to suspect the hosting service and not the code
- The app works on localhost but not on the hosted domain.
- Only external calls fail, not the local application logic.
- Mail sending fails even though the app compiles and deploys normally.
- The same WAR file works after changing only the DNS or SMTP details.
Step-by-step troubleshooting process
Use this practical workflow to narrow down the source of the issue.
- Check the logs. Look for hostname, SMTP, SSL, or timeout errors.
- Verify DNS records. Confirm A, AAAA, CNAME, MX, and TXT values.
- Test the domain externally. Open the site from another network and compare results.
- Review the application configuration. Check base URL, SMTP host, callback URLs, and environment variables.
- Validate SSL. Make sure the certificate matches the exact hostname.
- Confirm mail authentication. Review SPF, DKIM, and the From address.
- Retest after DNS propagation. Some changes take time to reach all resolvers.
This sequence usually reveals whether the problem is in the Java application, the hosting configuration, or a surrounding service such as DNS or mail.
Examples of common scenarios
Example 1: Password reset emails are not sent
Your JSP application can open in the browser, and Tomcat is running, but password reset messages never arrive. The logs show SMTP connection errors. In this case, check the mail server hostname, port, authentication, and SPF/DKIM records. If the SMTP host does not resolve, fix DNS first.
Example 2: Login redirects go to the wrong domain
The application moved to a new domain, but the login callback still points to the old one. Users see redirect errors or certificate warnings. Update the application base URL, verify DNS for the new domain, and install the certificate for the active hostname.
Example 3: An external API call fails with UnknownHostException
The app connects to a payment service or internal API, but one request fails during processing. The exception shows the remote host name. This usually means the hostname is invalid, DNS is unreachable from the hosting account, or the configured name is outdated.
Best practices to prevent repeat issues
- Keep DNS records documented and review them after any domain change.
- Use consistent hostnames in the application, certificate, and mail settings.
- Avoid hardcoded old URLs in Java configuration files.
- Test SMTP delivery after deployment, not only after development.
- Check logs regularly when you update Tomcat, Java, or mail credentials.
- Use the same hostname in public URLs and SSL certificates.
For Java hosting in a managed environment, stable domain and mail settings are often as important as the application itself. A well-configured Tomcat instance with the right DNS and SMTP data usually reduces support incidents significantly.
When to contact support
Contact hosting support if you have already verified the application configuration and the problem still points to DNS, SSL, or mail delivery. Provide the following details to speed up troubleshooting:
- The domain or subdomain affected.
- The exact error message from the Java or Tomcat log.
- The time the issue started.
- Recent DNS, SSL, or mail changes.
- The SMTP host and port, if the problem involves email.
- Whether the issue happens in all browsers, all networks, or only some users.
With this information, support can quickly determine whether the issue is caused by a DNS record, a mail configuration problem, an SSL mismatch, or a hosting-side service setting.
FAQ
Why does my Java app throw UnknownHostException even though the site opens?
The website domain may be working correctly, but the app could be trying to resolve a different hostname, such as an SMTP server or external API. Check the exact host mentioned in the error.
Can DNS issues affect Tomcat startup?
Yes, if the application performs startup checks, connects to external services, or loads remote resources during initialization. Tomcat itself may start, but the app can fail later because a required hostname does not resolve.
Why do email notifications work in one environment but not in hosting?
Hosting environments often require correct SMTP authentication, valid DNS records, and proper SSL settings. A local setup may use a different relay or allow unauthenticated sending, which does not match the hosted environment.
Do I need to change DNS if I switch Java versions in My App Server?
No, changing Java or Tomcat versions does not usually require DNS changes. However, if you also move the application to a new hostname or subdomain, update DNS and SSL accordingly.
What is the most common mistake with mail settings?
The most common mistake is using the wrong SMTP host name or leaving an old From address in the application configuration. Both can cause authentication failures or delivery problems.
How do I know if the issue is DNS propagation?
If some users can access the correct host while others cannot, and the DNS records were changed recently, propagation or caching is likely. Retest from different networks and wait for the new records to settle.
Conclusion
When a Java application hosted in Plesk with My App Server has problems that look like application faults, DNS and mail settings are often the real cause. Start by checking the logs, then verify the active DNS records, SMTP configuration, SSL certificate hostname, and application base URL. In many cases, a small configuration mismatch is enough to break redirects, mail sending, or external API access.
A structured check of DNS, mail, and SSL usually helps you separate hosting configuration issues from actual Java runtime problems and get the application working again with less downtime.