# 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. Source: https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/tips/ Back to the overview: [DNS, SSL, Redirect & URL](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/) · Open the live tool: [www.jpkc.com/tools/dns-ssl-redirect-url/](https://www.jpkc.com/tools/dns-ssl-redirect-url/) The [manual](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/manual/) explains each tab, the [examples](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/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](https://www.jpkc.com/db/en/tools/seo/)** 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](https://www.jpkc.com/db/en/tools/pki/)** 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](https://www.jpkc.com/db/en/tools/ip/)** 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](https://www.jpkc.com/db/en/tools/mail-header/)** 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](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/) for the big picture, the [manual](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/manual/) for each tab, and the [examples](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/examples/) for the step-by-step workflows. You can try everything right in the [tool](https://www.jpkc.com/tools/dns-ssl-redirect-url/).