DNS, SSL, Redirect & URL — Tips & Tricks

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 whose Trust row says "Trusted" 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 some clients complain even though the certificate is valid, the intermediate certificate is usually missing. The Certificate Chain card shows the chain exactly as your server sends it: if there is only the server certificate, the tool reports "The server sends no intermediate certificate". A missing root, on the other hand, is normal — clients bring their own.
The findings list is your executive summary. Below the certificate card, the tool collects everything that stands out: expiry within 14 days, an uncovered host name, a self-signature, SHA-1 or MD5 signatures, RSA keys under 2048 bits, a broken chain. If the list is empty and the Trust row says "Trusted", the certificate is technically clean — the findings alone check neither trust in the issuing CA nor revocation.
"Cross-signed root" is not an error. A CA with "Root" in its name that is not self-signed has been cross-signed by an older root so that older devices trust it as well. In the chain it works as an intermediate — what counts is the green "signature ok".
CAA shows who may issue. If the CAA card says "CA not listed", the current certificate comes from a CA your CAA record does not permit today. The next renewal with that CA will fail — adjust the record or switch CAs. "not compared" only means the tool could not map the issuing CA to a CAA name.
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.
DKIM "not found" does not mean "no DKIM". Check All tries 21 common selectors. If your provider uses a name of its own, the tool will not find it — then query <selector>._domainkey.<domain> directly as TXT. The DKIM-Signature header of a real message gives the selector away; the Mail Header Analyzer shows it in its "DKIM signatures" card as s=.
DMARC p=none is observation only. The mail summary colors p=none yellow ("monitoring only"), because spoofed mail still gets delivered. It only turns green with p=quarantine or p=reject.
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 — but count recursively. SPF allows a hard maximum of 10 DNS lookups, counted across the whole record including every record it pulls in. ip4:/ip6: are free; every include:, a, mx, ptr, exists, and redirect= costs one lookup. The live counter DNS lookups (this record) only sees your own record; what an include: resolves in turn is only counted by Count all lookups (incl. nested includes). Keep that total at 10 or fewer, or receivers 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. The tree of the recursive analysis shows what each service costs — clear out what no longer sends.
Watch out for void lookups. If an include: points to a name without an SPF record, the analysis reports an error and counts a "void lookup"; more than two of those also invalidate the record. Typical case: a service you cancelled long ago.
Load instead of retyping. To rework an existing record, enter the domain and click Load. The tool spreads the record across the form; whatever it cannot map lands under Custom mechanisms. Not everything survives unchanged, though: the rebuilt record follows the generator's fixed order, so mechanisms with a qualifier such as -ip4:… slide behind a, mx, and the include: entries, and invalid IP values drop out. Compare the new record with the old one before you publish it.
~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 — not even in Expert Mode, because the local proxy blocks the same address ranges. Use a public staging domain. Ports other than 80, 443, 3000, 5000, 8000, 8008, 8080, and 8443 are blocked as well.
"Forbidden" or "Security token expired" means: reload the page. The tool fetches a fresh token on its own before every request. The keys behind it, however, are embedded in the loaded page and change daily at midnight (UTC). If the tab stayed open past that point, the next request fails with "Forbidden" (rarely with "Security token expired") — only a reload fetches new keys.
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. On top of that, there is a server-side limit per IP address — Check All and the SPF functions share a cap of 20 calls per minute. The message tells you how long to wait — in the DNS tab as "Rate limited. Please wait …ms.", for SSL, Redirect, and the SPF analysis as "Too many requests — please wait … s and try again."
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 — the history does not. If an address contains a user:pass@ part, the parser shows the password as ***, in the Encoding card too. The URL history, however, stores the input unchanged in your browser and lists it in plain text. After a test with credentials, click Clear 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 JSON buttons of the result tabs: Copy and JSON in the DNS tab, Copy JSON and Save JSON for SSL and Redirect, Copy JSON in the URL parser.

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? One click on PKI Viewer in the chain card opens the PKI Viewer with the complete chain — there you inspect every certificate with all its fields, the next step when the Trust row 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.