JPKCom DB

DNS, SSL, Redirect & URL — Tips & Tricks

Tricks for DNS, SSL, Redirect & URL: reading results correctly, common pitfalls, the privacy implication, and combining it with other JPKCom tools.

Back to the overview: DNS, SSL, Redirect & URL · Open the live tool: www.jpkc.com/tools/dns-ssl-redirect-url/

The manual explains each tab, the examples show the workflows. This page is about what both assume: how to read the results well, where the traps are, and how to combine the tool with others.

Reading results correctly

  • Days remaining beat validity. A certificate with Verification: OK is valid today — but the Valid Until line with its day count tells you how much longer. From yellow (≤ 30 days), schedule the renewal; red means visitors already see a warning.
  • An incomplete chain is the most common "weird" SSL message. When browsers complain even though the certificate is valid, the intermediate certificate is usually missing. The Certificate Chain card shows this at once: if it does not end at a real root CA or the intermediate is missing, your server delivers the chain incompletely.
  • Present security headers are not automatically good headers. The counter badge ("x/9") only counts presence. What matters are the validation badges behind them: HSTS with too short a max-age, a CSP with unsafe-inline/unsafe-eval, or an X-Content-Type-Options without nosniff get flagged yellow or red. Read the badges, not just the check mark.
  • Every redirect hop costs. Three hops to get from http:// without www to the final https://www… address are common but suboptimal. The goal is one jump. And: if the chain bounces between http and https, the server rule is messy — the per-hop HTTP/HTTPS badge makes it visible.
  • Wildcard (A) in Check All is a signal, not an error. If the section appears, every subdomain resolves. Sometimes deliberate (catch-all), often a forgotten wildcard entry that invites subdomain takeover or unintended hits.

Using the SPF generator well

  • The lookup counter is the most important number. SPF allows a hard maximum of 10 DNS-resolving mechanisms. ip4:/ip6: are free; every include:, a, mx, redirect= costs one lookup. The live counter turns yellow from 8, red above 10 — stay under it, or recipients treat the record as a permerror.
  • Consolidate providers instead of stacking them. Each provider preset brings its include:, and some trigger further lookups internally. Adding Google, Microsoft 365, and three newsletter services at once quickly exceeds the limit. Clear out what no longer sends.
  • ~all for testing, -all for production. The default ~all (SoftFail) only marks unauthorized mail. Only once you are sure all legitimate senders are in the record should you go strict with -all (Fail). +all is never a good idea — the tool warns for good reason.
  • redirect= and the all-policy are mutually exclusive. If you set redirect=, the generator automatically omits the all-policy and flags it with a note. Use redirect= only when another domain owns the SPF authority.
  • Verify DNS closes the loop. After publishing, use Verify DNS to jump straight to the DNS tab (type TXT) and check the live record — remember propagation can take up to 48 hours.

Pitfalls from practice

  • The tool sees what the JPKCom server sees — not your browser. DNS, SSL, and Redirect run server-side. Geo-specific DNS (GeoDNS), login-protected pages, or content that only appears client-side may look different to the server than to you. For reproducible checks that is an advantage; for "it looks different here" cases it is the explanation.
  • localhost and intranet do not work. SSRF protection blocks private, loopback, reserved, and CGNAT addresses — for the DNS reverse lookup, the SSL/redirect fetch, and on every redirect hop again. You cannot check a local dev instance; use a public staging domain or expert mode with a local proxy.
  • "Security token expired" means: reload the page. The token is only valid within a 5-minute window. If the tab sat open for a while, the next reload fetches a fresh token.
  • Clicked too fast? Wait a moment. A client-side throttle allows about one server request per second; fire faster and you get the "Please wait a moment" hint. Just wait briefly instead of re-clicking.
  • Reverse lookup only for public IPs. PTR on a private IP (e.g. 192.168.…) is rejected. That is not a bug, it is the same SSRF protection.
  • The URL parser masks passwords. If an address contains a user:pass@ part, the parser shows the password as *** — good for screenshots, but remember the value was there.

Keep privacy in mind

The server-side fetch has a deliberate privacy property: the checked domain logs a request from the JPKCom server, not your IP address. That is handy when checking third-party sites without "showing yourself". Conversely, it means the server endpoints are not an open API — they are protected by token, time window, and referer check, and only usable from within the tool. If you want to process the raw data further, use the Copy/Save JSON buttons in each tab.

Combining with other JPKCom tools

  • Check a page holistically instead of piecemeal? The SEO & GEO Analyzer rates a page's HTTPS, redirects, security headers, and performance together and assigns scores — the ideal complement when the SSL tab only shows you the technical slice.
  • Found a certificate problem? With the PKI tools you create and inspect certificates, CSRs, and keys — the next step when the Verification line was red.
  • Following up on IPs from DNS or redirects? The IP tools analyze addresses and subnets, e.g. when a redirect IP or an A record looks suspicious.
  • Verify SPF in real mail? The mail header analyzer reads received headers and shows whether SPF/DKIM/DMARC actually apply on delivery — the real-world test for the record built here.

The pattern is always the same: diagnose here, repair or dig deeper with the right tool, then re-check.

More context: the overview for the big picture, the manual for each tab, and the examples for the step-by-step workflows. You can try everything right in the tool.