When a Tomcat application starts to behave unpredictably, DNS and mail settings are often checked too late. In many cases the Tomcat service itself is working correctly, but the app cannot reach the right host name, cannot resolve an API endpoint, or fails because mail delivery is misconfigured. On a managed hosting account with Plesk and My App Server, these issues usually sit outside the Tomcat process, which makes them easier to isolate once you know where to look.
This guide shows how to identify hosting problems caused by DNS or mail settings in a UK-focused Tomcat hosting environment. It is useful for Java hosting, JSP hosting, servlet hosting, and private JVM setups where your application runs inside its own Tomcat instance but still depends on external DNS records, SMTP servers, and mail authentication.
What DNS and mail issues can look like in Tomcat
Tomcat errors are not always caused by the application server. A web app may fail because a domain does not resolve correctly, a service endpoint points to the wrong IP, or outgoing mail is rejected. Common symptoms include:
- Pages that load intermittently or redirect to the wrong host name.
- Login, callback, or API requests failing when the application calls another service by domain name.
- SMTP connection errors such as timeouts, authentication failures, or relay denied messages.
- Contact forms that submit successfully but no email is received.
- Notification emails going to spam or being rejected by the receiving server.
- SSL warnings when the application connects to a remote service using HTTPS.
- Tomcat startup logs that show connection failures even though the app itself deploys correctly.
If you host a Java app through My App Server, these problems may appear as application errors, but the root cause can be in DNS, mail routing, or external service settings rather than in Tomcat configuration.
Check whether the problem is inside Tomcat or outside it
Before changing DNS or mail settings, confirm whether Tomcat itself is healthy. In Plesk and My App Server, check the service status, application logs, and recent deployment changes.
Quick isolation checklist
- Confirm that the Tomcat service is running.
- Check whether the issue affects only one application or all apps in the same account.
- Verify if the issue happens only when the app calls another domain or sends email.
- Test the same URL or SMTP details from another tool, if available.
- Review recent changes to DNS, mail settings, SSL certificates, or application properties.
If the application serves local pages but fails only when it reaches another host name or sends email, the cause is likely outside the servlet container.
Find DNS-related Tomcat hosting problems
Many Java applications depend on DNS to reach APIs, database gateways, payment providers, SSO endpoints, or mail servers. If the host name cannot be resolved, the application may throw timeout errors or fail during startup.
1. Verify the domain name the application is using
Check the exact host name configured in the app. A typo, missing subdomain, or wrong environment value is a common source of problems. Make sure the application is not using an old staging record or an internal hostname that is no longer valid.
Look for:
- Hard-coded host names in configuration files.
- Environment variables used by the Java app.
- Properties set in the Tomcat application context.
- Old DNS names left over after a migration.
2. Confirm the DNS record exists and points to the expected target
In your DNS zone, verify that the relevant A, AAAA, CNAME, or MX record is present and correct. A missing or outdated record can break outbound integrations or inbound access to your site.
Typical checks include:
- A record for the main domain and required subdomains.
- CNAME records for application hostnames if used by the app.
- MX records if the domain receives email.
- TXT records for SPF, DKIM, or verification services when mail is involved.
If a service expects a specific subdomain such as api.example.co.uk or mail.example.co.uk, make sure that name resolves exactly as intended.
3. Check propagation and caching
DNS changes do not always take effect everywhere at once. Cached records may cause one tester to see the new address while another still reaches the old one. This can look like an intermittent Tomcat issue.
Watch for:
- Different results from different networks.
- Old IP addresses still appearing in some lookups.
- Service errors shortly after a DNS update.
If the problem started after a record change, consider DNS caching as a likely cause. Allow time for propagation and retest before changing the application.
4. Make sure both IPv4 and IPv6 settings are consistent
Some applications or external services behave differently depending on whether they connect via IPv4 or IPv6. If the app resolves a host name to an AAAA record but the destination is not reachable on IPv6, you may see timeouts even though the domain looks valid.
Check that:
- The destination supports the IP family returned by DNS.
- There is no broken AAAA record causing failed lookups.
- Your application or library handles IPv6 properly.
5. Review DNS lookups from the application side
If you have access to logs or a shell environment in your hosting account, test name resolution from the same environment where Tomcat runs. A name that resolves on your local machine may fail on the server if the application is using a different resolver path.
Useful signs in logs include:
- Unknown host.
- DNS resolution timeout.
- Connection refused after a successful lookup.
- Handshake failure caused by connecting to the wrong endpoint.
In many managed hosting setups, the application can resolve public DNS names normally, but custom or internal zones may need special attention.
Find mail-related Tomcat hosting problems
Tomcat applications commonly send mail for password resets, order confirmations, contact forms, and system alerts. If outgoing mail is misconfigured, the app may still run correctly but fail at the last step.
1. Identify how the application sends mail
Check whether the app uses:
- SMTP through a local or remote mail server.
- Mailing through a third-party provider.
- A framework such as JavaMail or a higher-level library.
Knowing the mail path helps you determine whether the problem is in the app, the SMTP server, or the DNS record for the mail host.
2. Verify SMTP host, port, username, and password
Incorrect mail credentials are one of the most common causes of failed outbound email. Double-check the configured SMTP server name, port number, and authentication details.
Common mistakes include:
- Using the wrong server name after a domain change.
- Trying port 25 when the provider expects 587 or 465.
- Missing SMTP authentication.
- Using a mailbox password instead of an app-specific password when required.
If the SMTP server name is a domain, confirm that DNS resolves it correctly. A mail failure may begin as a DNS issue and only later appear as an authentication error.
3. Check whether the mail domain has valid DNS records
Outbound mail deliverability depends heavily on DNS. If your domain sends mail but lacks proper SPF, DKIM, or DMARC records, recipients may reject or quarantine messages.
Review the following:
- SPF to authorize the sending service.
- DKIM to sign mail correctly.
- DMARC to define the policy and reporting.
- MX records if the domain also receives email.
Even if Tomcat can submit the email successfully, weak mail DNS can still cause delivery failures or spam placement.
4. Check the From address and domain alignment
Mail servers often reject or downgrade messages when the From address does not match the sending domain or when SPF/DKIM alignment is broken. This is especially common when a Java app uses a generic sender address but the SMTP server belongs to a different domain.
Make sure:
- The sender address is valid for the domain.
- The mail server is allowed to send on behalf of that domain.
- The visible From address and technical envelope settings are consistent where possible.
5. Review TLS and SSL settings for SMTP
Many mail providers require encrypted connections. If your Java app uses the wrong TLS mode, outdated certificates, or an incompatible port, the connection can fail even though the server name and credentials are correct.
Check:
- Whether the provider expects STARTTLS or implicit SSL.
- Whether the port matches the encryption mode.
- Whether the certificate chain is trusted by the JVM used in My App Server.
When the JVM is older or custom-built, certificate trust issues can show up as mail failures or SSL handshake errors in the logs.
Use Plesk and My App Server to narrow down the cause
In a managed Tomcat hosting environment, control panel tools can help you separate application problems from service problems. My App Server lets you manage your Tomcat instance and JVM from the hosting account, while Plesk gives you visibility into related site and mail settings.
What to check in the control panel
- Application status and service control in My App Server.
- Deployment files and application configuration.
- Domain and subdomain setup.
- DNS zone entries for the affected hostname.
- Mail account settings and outbound mail configuration.
- SSL certificates used by the site or by mail endpoints.
If the app runs in its own private JVM, one advantage is that you can test changes without affecting other sites in the same account. That makes it easier to determine whether DNS or mail settings are the real source of the fault.
How to compare expected and actual behavior
A practical troubleshooting method is to write down three things:
- What the application expects to reach.
- What the DNS record or SMTP setting currently resolves to.
- What the logs show when the request fails.
When these three do not match, the cause is often obvious. For example, the app may still point to an old mail host, or the DNS record may reference a service that has already moved.
Typical log messages and what they mean
Tomcat and Java libraries usually produce enough detail to identify DNS or mail problems if you know what to look for.
Common DNS-related messages
- UnknownHostException — the hostname could not be resolved.
- Connection timed out — the host may resolve, but the destination is unreachable or blocked.
- No route to host — network path issue or incorrect target.
- Connection refused — the host is reachable, but the service is not accepting connections on that port.
Common mail-related messages
- Authentication failed — SMTP username or password is wrong, or the provider requires a different auth method.
- Relay denied — the server does not allow sending for that domain or recipient.
- Could not connect to SMTP host — DNS or network issue, or the port is blocked.
- SSLHandshakeException — certificate trust or TLS version mismatch.
If the same error appears every time, focus on the network or mail configuration rather than Tomcat deployment.
Practical troubleshooting steps
Use the following order to avoid unnecessary changes:
- Confirm the app works locally inside Tomcat without external integrations.
- Check whether the failing feature depends on DNS or email.
- Verify the hostname, MX record, or SMTP server in the configuration.
- Review DNS records for the affected domain and subdomain.
- Confirm SPF, DKIM, and DMARC if mail delivery is affected.
- Test the same SMTP host and port from another tool or environment.
- Read the Tomcat and application logs for the exact exception.
- Adjust one setting at a time and retest.
This method helps you avoid solving the wrong problem. In hosting support, DNS and mail faults often look like application bugs until the dependency is checked carefully.
Examples of real-world scenarios
Scenario 1: A payment callback fails after a domain move
A Java app in Tomcat calls a payment endpoint by host name. After the domain is updated, the app still uses the old DNS record from cached settings. The result is a timeout or redirect failure. In this case, the Tomcat instance is healthy, but the integration must be updated to use the new hostname.
Scenario 2: Password reset emails are not delivered
The application successfully submits email through SMTP, but messages never arrive. The issue may be that SPF is missing, the From address is misaligned, or the message is being rejected by the recipient because the domain records are incomplete. Tomcat is not the problem; the domain mail setup is.
Scenario 3: SMTP login fails after switching mail provider
The app still points to the previous mail host. DNS may resolve the old server, but credentials are now invalid because the provider changed. Updating the SMTP server name and checking the mail DNS records resolves the issue.
Best practices for Tomcat applications that depend on DNS and mail
- Store host names and SMTP details in a central configuration file or environment setting.
- Document every external service used by the app.
- Use stable subdomains for APIs and mail endpoints.
- Keep SPF, DKIM, and DMARC aligned with the sending domain.
- Review DNS records after migrations or provider changes.
- Check the JVM trust store when connecting to encrypted mail or HTTPS services.
- Monitor application logs for repeated UnknownHostException or SMTP errors.
These habits reduce downtime and make support requests much faster to resolve.
When to contact hosting support
Contact support if you have already checked the app configuration, DNS records, and mail settings but the problem continues. Provide as much detail as possible, including:
- The domain or subdomain involved.
- The exact error message from the Tomcat or application log.
- The time the issue started.
- Any recent DNS, SSL, or mail changes.
- Whether the issue affects inbound access, outbound mail, or both.
- Which Tomcat or Java version is running in My App Server.
Clear log excerpts are especially useful because they show whether the failure is a DNS lookup, mail authentication issue, TLS problem, or something else outside the servlet container.
FAQ
Can DNS problems make Tomcat look broken?
Yes. If your application depends on a host name that does not resolve correctly, Tomcat may appear to be failing even though the server is running normally.
Why does my Java app send emails locally but not on hosting?
The hosting environment may use different SMTP settings, stricter mail authentication, or different DNS resolution. Check the SMTP host, port, credentials, and SPF/DKIM records.
Does a Tomcat restart fix DNS or mail issues?
Usually not. Restarting Tomcat may clear temporary state, but if the hostname, SMTP server, or DNS record is wrong, the issue will return.
What is the most common mail-related cause in Tomcat apps?
Wrong SMTP settings are very common, followed by missing SPF/DKIM records and TLS mismatches between the Java runtime and the mail server.
Can My App Server help isolate these problems?
Yes. Because you can manage the Tomcat service and JVM separately in the control panel, it is easier to see whether the issue is with the application, the server process, or the external DNS/mail dependency.
Conclusion
When a Tomcat application shows errors related to DNS or mail, the fastest path to a fix is to treat the problem as a dependency check rather than a Tomcat-only issue. Verify the hostname, confirm DNS records, inspect SMTP settings, and read the application logs for exact exceptions. In a managed hosting environment with My App Server and Plesk, this approach helps you quickly separate Java application faults from DNS and mail configuration problems.
Once the external settings are correct, most Tomcat apps return to normal without changes to the servlet container itself.