If a JSP site stops working, loads intermittently, sends mail from the wrong address, or shows domain-related errors, the root cause is not always the JSP application itself. In many hosting environments, DNS and mail settings are part of the same service chain that your Java app depends on. A wrong DNS record, a missing MX entry, a stale A record, or a misconfigured SPF/DKIM setup can make a healthy Tomcat application look broken.
This guide explains how to identify hosting problems caused by DNS or mail configuration when you run JSP, Servlet, or Tomcat applications on a managed hosting platform such as Plesk with a private JVM or My App Server. It focuses on practical checks you can do from the control panel and from the browser, without needing deep server access.
What DNS and mail settings can affect in JSP hosting
In a typical JSP hosting setup, your application may depend on DNS for routing, hostname resolution, SSL validation, and links inside the app. Mail settings can affect contact forms, password resets, order notifications, and any feature that sends email from the application.
Common symptoms include:
- The domain opens the wrong website or an old version of the app.
- The JSP app works on a temporary URL but not on the live domain.
- SSL warnings appear after a domain change.
- Emails from the app are rejected or go to spam.
- Form submissions fail when the application tries to send mail.
- The site loads in one network but not in another.
- Tomcat or the app server starts correctly, but the app is unreachable by hostname.
Because JSP apps often sit behind Apache, Tomcat, and a hosting control panel, a DNS issue can present itself as a web server or application error even when the Java code is fine.
First check: determine whether the problem is DNS, mail, or the application
Before changing anything, isolate the layer that is failing.
Signs pointing to DNS
- The domain does not resolve to the correct IP address.
- The site works on one device or network but not another.
- Recent nameserver or DNS changes were made.
- Browser error pages mention server not found, DNS lookup failure, or domain resolution issues.
- The app responds on the server hostname or IP, but not on the public domain.
Signs pointing to mail configuration
- Contact form messages do not arrive.
- Password reset emails are missing.
- Mail sent from the app reaches spam or is rejected.
- SMTP authentication fails.
- Outgoing mail works from one address but not another.
Signs pointing to the JSP/Tomcat layer
- The site is resolved correctly, but you get HTTP 404, 500, or deployment errors.
- The app starts and stops from the control panel, but paths are wrong.
- Logs show Java exceptions, class loading issues, or context deployment problems.
- The issue remains even when DNS is confirmed correct.
If the application responds on the server IP but not through the domain name, DNS is a strong suspect. If pages load but mail features fail, the issue is likely in mail settings or sender authentication.
Check DNS records for the hosting account
For JSP hosting, the most important DNS records are usually A, AAAA, CNAME, MX, and TXT. In a control panel environment, these records are often managed in the DNS zone for the domain.
1. Confirm the domain points to the correct IP address
Check the A record for the main domain and, if used, the www subdomain. The domain should point to the IP address assigned to your hosting account.
- Example: example.com → A record to the hosting IP
- Example: www.example.com → CNAME to example.com or A record to the same IP
If the A record points somewhere else, visitors may reach another server, an old site, or a parked page. This is one of the most common reasons a JSP app appears offline after a migration.
2. Review AAAA records if you do not use IPv6
An incorrect AAAA record can cause some clients to prefer the wrong IPv6 destination. If your hosting account does not support IPv6 for the domain, remove the AAAA record or confirm that it points to the correct destination.
3. Check the www and non-www version
Sometimes the root domain works, but the www version fails, or the reverse. This usually means one record is missing or inconsistent. Make sure both hostnames resolve correctly and that your website or application redirects are configured consistently.
4. Verify nameserver delegation
If you changed DNS hosting recently, confirm that the domain uses the correct nameservers. A zone may look correct inside the control panel, but if the domain registrar still points elsewhere, the live internet will use a different DNS zone.
This is a frequent source of confusion after domain transfers, hosting migrations, or staged rollouts.
5. Allow time for propagation
After DNS changes, some networks may still cache the old answer. Depending on TTL values and resolver caches, updates can take time to become visible everywhere. If the site was just changed, check from multiple networks or use DNS lookup tools before assuming the new records are wrong.
How DNS issues affect JSP and Tomcat hosting
JSP applications often depend on the correct hostname for more than just page loading. DNS problems can affect:
- Virtual host routing in Apache or Tomcat
- SSL certificate validation and HTTPS redirection
- Session cookies tied to a domain
- Absolute URLs generated by the application
- Mail server lookups and sender reputation
For example, if a JSP app generates links using the wrong base URL, users may be sent to an old hostname or a temporary domain. If the SSL certificate was issued for the live domain but DNS still points elsewhere, the browser may warn users or refuse the connection.
In a managed hosting setup with My App Server, the application may run correctly in its private JVM, but the web front end still depends on the public DNS record and Apache routing. That means the app server can be healthy while the domain itself is misdirected.
Check mail settings that commonly break JSP applications
Many JSP sites send mail through an internal SMTP service, an external mail server, or the hosting platform’s outgoing mail configuration. If mail is not working, check these settings carefully.
1. Confirm the sender address exists and matches the domain
Some mail providers reject messages if the From address does not belong to the domain or if it is not allowed by authentication policies. Use a sender address that exists on the domain and is permitted by the mail setup.
2. Verify SMTP host, port, username, and password
If the application uses SMTP directly, confirm:
- SMTP host name
- Correct port number, usually 25, 465, or 587 depending on the provider
- Authentication username
- Password or app password
- Required encryption settings such as TLS or SSL
A single wrong character in the password or an outdated mail host can break form submissions and automated notifications.
3. Check SPF, DKIM, and DMARC
These DNS TXT records help receiving servers decide whether your mail is legitimate. If they are missing or incorrect, messages from your JSP application may be marked as spam or rejected.
- SPF tells receivers which servers may send mail for the domain.
- DKIM adds a cryptographic signature to prove the message was authorized.
- DMARC defines how receiving servers should handle failed authentication.
If mail delivery suddenly becomes unreliable, check whether the DNS zone still contains valid SPF/DKIM entries after a domain move or mail provider change.
4. Make sure reverse and forward alignment is sensible
Although not always visible in the hosting panel, poor alignment between the sending host, domain, and mail identity can trigger spam filtering. If possible, send from the same domain the app belongs to, and avoid using a third-party SMTP relay without correct authentication.
5. Test form mail separately from the application
If your JSP app has a contact form, create a small test action or use the application’s mail test feature, if available. This helps you decide whether the issue is with the form logic, SMTP configuration, or mail reputation.
Use the hosting control panel to narrow down the issue
When you host JSP applications in a managed panel such as Plesk, several useful checks are available without shell access.
DNS zone editor
Open the domain’s DNS zone and confirm the live records. Look for:
- A record for the domain
- CNAME or A record for www
- MX records for mail delivery
- TXT records for SPF, DKIM, and DMARC
- No conflicting or obsolete records
Mail settings
Check whether mail service is enabled for the domain and whether the mailbox exists. If the application uses a mailbox that was deleted or renamed, outgoing mail may fail even if the code is correct.
Web hosting and domain mapping
Make sure the domain is assigned to the correct hosting subscription and that the document root or application path matches the Tomcat deployment. A wrong mapping can look like a DNS problem from the browser because the domain resolves, but the wrong site opens.
Application server status
With My App Server or a private JVM setup, confirm that the service is running and that the application context is deployed. If the service is down, DNS checks will not solve the problem, but if the service is healthy and the domain still fails, DNS becomes more likely.
Practical troubleshooting steps
Use this sequence to reduce guesswork.
- Open the website using the main domain and the www version.
- Compare behavior on another network or device.
- Check the A and AAAA records for the domain.
- Confirm nameservers point to the active DNS zone.
- Verify MX records if mail delivery is failing.
- Check SPF, DKIM, and DMARC TXT records.
- Confirm the mail sender address belongs to the domain.
- Review the Tomcat or application logs for unrelated errors.
- Test the app directly on the server or temporary URL, if available.
If the application works by IP or internal hostname but not by domain name, you are likely dealing with DNS or virtual host configuration. If web access is fine but outgoing messages fail, focus on mail authentication and SMTP settings.
Examples of common scenarios
Scenario 1: The JSP site loads on the server but not on the domain
This usually means the app server is working, but the DNS A record is pointing to the wrong IP or the domain is delegated to the wrong nameservers. The fix is to correct the live DNS record and confirm that the hosting account is assigned to the domain.
Scenario 2: The site opens, but password reset emails never arrive
The application may be generating mail correctly, but the SMTP server is rejecting the message or the domain lacks proper SPF/DKIM records. Check the mail logs, sender address, and DNS TXT records.
Scenario 3: After a migration, the app still shows the old website
This often happens when the old A record is still cached or when the www subdomain points to the old host. Verify both hostnames and wait for DNS propagation if the change was recent.
Scenario 4: HTTPS works sometimes, then fails after DNS updates
SSL certificates are tied to hostnames. If DNS points to a different server than the one holding the certificate, browsers may warn users. Ensure the correct DNS record and certificate cover the live domain.
How My App Server and Tomcat context helps here
In a JSP hosting platform built around Plesk and My App Server, the application runs inside its own JVM and Tomcat environment, while the hosting layer still manages domain routing, DNS, and mail services. This separation is useful because it helps you isolate problems.
If the service control panel shows Tomcat running and the app deployed, but the site is still unavailable externally, the issue is more likely DNS, virtual host configuration, or mail service settings than the Java runtime itself.
That is why it helps to check the platform in layers:
- DNS resolves the domain
- Apache or the reverse proxy routes traffic
- Tomcat serves the JSP application
- Mail service handles outgoing messages
When one layer is misconfigured, the symptoms can appear in a different layer.
FAQ
Why does my JSP app work with the server IP but not with the domain?
This usually indicates a DNS or hostname mapping problem. Check the A record, www record, and nameserver delegation for the domain.
Can a bad MX record break my JSP website?
Usually no, not the website itself. However, it can break mail-based features such as contact forms, account activation, and password reset emails.
Do SPF and DKIM matter for a hosting account running Tomcat?
Yes. If your JSP application sends email, SPF and DKIM can strongly affect whether those messages are delivered or marked as spam.
What should I check first after moving a JSP site?
Start with DNS. Confirm the domain points to the correct hosting IP, the correct nameservers are active, and the SSL certificate matches the live hostname.
Can the control panel show a healthy app while DNS is wrong?
Yes. The application server can run normally inside the hosting account while the public domain still points elsewhere. That is why external DNS checks are important.
How do I know whether mail is blocked by the hosting provider or by the destination server?
Review mail logs and test with a valid SMTP configuration. If messages are accepted locally but rejected externally, the issue is often authentication, reputation, or DNS-based mail policy rather than the JSP application itself.
Conclusion
When a JSP site fails, do not assume the Java application is the first problem to solve. DNS and mail settings can create errors that look like Tomcat, SSL, or code issues. In a managed hosting environment with Plesk and My App Server, the fastest path is to check the domain records, verify mail authentication, and confirm that the app server is healthy before changing the application itself.
By checking A, AAAA, MX, SPF, DKIM, and domain mapping in a structured way, you can quickly separate network-level problems from real JSP deployment issues and restore the service with less trial and error.