How to find Tomcat hosting problems caused by DNS or mail settings

If your Tomcat application starts, but login forms fail, password reset links point to the wrong address, outgoing mail does not arrive, or the app behaves differently after a domain change, the root cause is often not Tomcat itself. In many hosting environments, the problem comes from DNS records, mail routing, reverse lookups, or application settings that still point to an old host name.

This is especially common in Java hosting setups where Apache Tomcat runs inside a shared hosting account or private JVM managed from Plesk, such as with My App Server. Tomcat may be healthy, but the surrounding services your application depends on are not configured consistently.

Use the checks below to separate Tomcat issues from DNS and mail-related problems, then fix the right layer instead of restarting the server without results.

What usually causes DNS or mail-related Tomcat problems

Tomcat applications often depend on more than the application server itself. A typical web app may use:

the domain name for redirects, cookies, and callback URLs
DNS records to resolve the site, mail server, or API endpoints
mail settings for contact forms, password reset, invoices, and alerts
SMTP authentication to send email through the hosting platform
reverse DNS or hostname checks in mail delivery systems

When any of these are misconfigured, the app may still load, but specific functions fail. Common symptoms include:

password reset emails never arrive
contact forms submit but no email is sent
links in emails point to the wrong domain or old server
the app redirects to HTTP instead of HTTPS, or to a stale host name
SMTP login fails after moving the application
mail sent from the app lands in spam or is rejected
the application cannot resolve an external hostname used for API access

Check whether the issue is in Tomcat or outside it

Before changing application code, confirm that Tomcat itself is running normally. In a managed hosting setup with Plesk and My App Server, this helps you avoid replacing a working Java service configuration with a DNS or mail problem.

Quick signs that Tomcat is probably fine

The web application page opens in the browser.
Static content loads correctly.
JSP pages render.
Basic application functions work, but email or redirects do not.
The issue started after a domain or mail change, not after a Java deployment.

Quick signs that DNS or mail is the likely cause

The app works on the server URL but fails on the domain name.
Emails show an outdated sender domain.
The application uses a hardcoded URL that no longer matches the current domain.
The mail server hostname in the app does not match the current hosting settings.
DNS changes were made recently and propagation may still be in progress.

Verify the domain and DNS records first

If the application uses the domain name in redirects, callback URLs, or email templates, DNS must be correct before anything else can work reliably.

1. Confirm the domain resolves to the right hosting account

Check that the domain points to the correct IP address and the correct web hosting subscription. If the domain still resolves to an old server, Tomcat may be fine, but users will reach the wrong host.

Review these record types:

A record for the main domain
AAAA record if IPv6 is used
CNAME record for subdomains such as app.example.com
MX record for email delivery
TXT records for SPF, DKIM, and verification

If you use Plesk, compare the DNS zone entries with the live service settings. A common issue is that the web service is updated, but the DNS zone still points elsewhere.

2. Check propagation after DNS changes

After a domain move or DNS update, allow time for propagation. Different resolvers may keep old values temporarily. During this period, some users may reach the right site while others still hit the old address.

For troubleshooting, test with:

your local network
a public DNS resolver
the hosting control panel DNS zone
the actual hostname used by the application

3. Confirm the app uses the current canonical URL

Many Tomcat applications store the site URL in configuration files, environment settings, or database entries. If that value still contains an old host name, email links and redirects will be wrong even if DNS is correct.

Look for settings such as:

base URL
site URL
public hostname
application root URL
callback URL
reset password URL

Update these values to match the live domain, especially after domain migrations or when switching from a temporary server address to the final domain.

Check mail settings used by the Tomcat application

Mail problems are among the most common reasons a Tomcat app appears broken even though the server is working. In Java applications, outgoing mail is often handled through SMTP settings defined in the app, in a properties file, or in the hosting control panel.

1. Verify SMTP host, port, and authentication

Make sure the application is using the correct SMTP server name, port, username, and password. A mismatch often happens after domain changes, mailbox changes, or migration to a new hosting account.

Review the following fields:

SMTP host
SMTP port
encryption type: SSL, TLS, or STARTTLS
username and password
from address
reply-to address

If the app uses the domain mail server, confirm that the mailbox exists and is enabled. If it uses an external SMTP provider, verify that the hostname has not changed and that outbound connections are allowed from the hosting account.

2. Check the sender address and domain alignment

Many mail systems reject or filter email when the sender address does not match the domain configuration. For example, if the app sends mail from [email protected] while the site now runs on a different domain, delivery issues are likely.

Best practice is to use a sender address that matches the active domain and is configured in DNS with the proper SPF and DKIM records where supported.

3. Review SPF, DKIM, and DMARC

Incorrect DNS mail authentication records can cause sent messages to be rejected or marked as spam. Even if SMTP login works, recipients may never see the email.

Check the following:

SPF authorizes the correct mail server or provider
DKIM is enabled and matches the domain used by the app
DMARC policy is not too strict for the current setup

If you recently changed the mail server or moved the site to a new hosting environment, update these records as part of the migration.

Inspect Tomcat configuration for URL-dependent settings

Even when DNS and mail are the real problem, Tomcat configuration can still influence how the issue appears. Java apps often build absolute URLs from request data or from application properties.

1. Make sure the application sees the correct host name

If the app sits behind Apache or another web server proxy layer, it may need the forwarded host and protocol headers to generate correct links. Without them, the app can assume the wrong scheme or host name.

Common symptoms include:

links generated with http instead of https
redirect loops after login
callback URLs pointing to the internal server name
mail links using a local hostname instead of the public domain

In a Plesk-based hosting setup, make sure the Apache/Tomcat integration and any proxy forwarding settings are consistent with the site’s actual domain and SSL configuration.

2. Check environment variables and application properties

Some apps store mail and site settings in environment variables or property files. After deployment, these values may still reference the old domain or an obsolete SMTP server.

Search for:

SMTP host names
site base URL
email sender address
mail authentication credentials
API endpoints that depend on DNS

For hosted Tomcat applications, it is usually easier to update one central configuration file than to patch code in several places.

Use hosting control panel tools to isolate the problem

With managed hosting and My App Server, you can often narrow down the issue from the control panel without touching the Java code first.

Check service status

Confirm that the Tomcat service or private JVM is running. If the service is up and the app page loads, the problem is probably not the Java process itself.

Review web and mail logs

Logs help you tell the difference between an application error and a delivery or resolution problem.

Look for:

SMTP connection errors
authentication failures
DNS resolution errors
timeout messages
redirects to old domains
mail rejection responses from the remote server

If the application logs show a successful send attempt but the recipient never receives the message, the issue is likely outside Tomcat, often in DNS authentication or mail filtering.

Confirm SSL and domain binding

SSL issues sometimes look like DNS or mail problems because the app generates wrong URLs after a certificate or domain change. Check that the certificate matches the active domain and that the application is served on the expected host name.

If you changed the domain recently, ensure all related services were updated together:

web server host name
Tomcat virtual host or app configuration
SSL certificate
DNS records
mail sender domain

Practical troubleshooting workflow

Follow this order to find the root cause efficiently:

Open the application and note exactly what fails: page load, redirect, form submission, or email delivery.
Confirm Tomcat service status in the hosting panel.
Check whether the domain resolves to the correct hosting account.
Compare the live domain with the URL used inside the app.
Test outgoing mail settings: SMTP host, port, login, sender address, and encryption.
Review SPF, DKIM, and DMARC records for the sending domain.
Look at logs for DNS lookup failures or SMTP errors.
Correct configuration in the app, DNS zone, or mail settings as needed.
Retest from a private window and, if relevant, from a separate network.

Example: password reset email goes to the wrong domain

If users request a password reset and the email links contain an old domain, the problem is usually not SMTP delivery. The app is probably generating the link from an outdated base URL.

Fix checklist:

update the application base URL
verify the current domain in DNS
check the sender address
confirm the SSL certificate matches the active domain

Example: contact form sends nothing

If a form submits without visible error but no email arrives, check whether the app uses local mail, SMTP authentication, or an external provider.

Typical causes are:

wrong SMTP host
blocked port
invalid password
incorrect from address
missing SPF/DKIM records

How My App Server fits into this

In the ITA Java hosting environment, My App Server lets you run Apache Tomcat or a private JVM inside your hosting account and manage it from Plesk. That gives you practical control over Java version, service status, deployment, and app-level settings without needing a full enterprise Java platform.

For DNS and mail troubleshooting, this matters because you can usually verify the Java side separately from the surrounding hosting services:

Tomcat can be healthy while DNS is wrong
the app can deploy correctly while SMTP is misconfigured
the service can run while the domain still points elsewhere
a valid Java version can still produce wrong URLs if the application settings are outdated

If you manage a WAR, JSP, or servlet application in a shared hosting account, this separation makes troubleshooting much easier. You can check the Java service, the domain, and the mail settings in a structured way instead of treating every failure as a Tomcat crash.

Prevention tips for future deployments

To avoid repeating the same DNS or mail issues after a move, keep the following practices in place:

store the canonical site URL in one central config location
avoid hardcoding domains in Java code where possible
document SMTP settings and sender addresses
update SPF, DKIM, and DMARC whenever the mail path changes
test reset emails and contact forms after each deployment
recheck SSL, DNS, and mail together after a domain migration
keep a copy of the old and new settings during migration

These checks are especially useful for small and medium Java applications hosted on a managed platform, where one incorrect hostname can break authentication, notifications, or callback flows without affecting the main site.

FAQ

Why does my Tomcat app open, but email features do not work?

Because the application server is running, but the SMTP configuration, sender domain, or DNS mail authentication may be wrong. This is a common separation between Tomcat and the mail layer.

Can DNS issues affect login or password reset links?

Yes. If the app builds absolute URLs from the domain name and the DNS or base URL is outdated, users may receive links that point to the wrong host.

What should I check first after moving a Tomcat site to a new domain?

Check the DNS A and MX records, the application base URL, SSL certificate binding, and outgoing mail settings. These are the most common causes of broken redirects and email after a migration.

Why do emails from my app go to spam?

Usually because the sender address does not match the domain setup, or SPF, DKIM, and DMARC are missing or inconsistent. Mail reputation and content can also play a role.

Does Tomcat itself handle DNS or mail?

No. Tomcat runs the Java application, but DNS and mail are separate services. The app may use them, but the underlying configuration lives in the hosting environment, application settings, or external mail services.

What if the app works on the server IP but not on the domain name?

That usually points to DNS, virtual host, or SSL binding issues rather than a Tomcat runtime problem. Verify the domain resolves correctly and that the app is configured for the public host name.

Conclusion

When a Tomcat-hosted application fails in ways that involve redirects, email delivery, or domain-specific links, the cause is often DNS or mail configuration rather than Tomcat itself. In a managed hosting environment with Plesk and My App Server, the fastest fix is to check the domain records, the application’s base URL, SMTP settings, and mail authentication together.

By isolating the Java service from the surrounding services, you can solve the real problem faster and avoid unnecessary changes to the Tomcat setup. If the site loads but mail or domain-dependent features fail, start with DNS and SMTP before looking deeper into the application server.

How to find Tomcat hosting problems caused by DNS or mail settings