JPKCom DB

DNS, SSL, Redirect & URL — Examples

Hands-on walkthroughs: check a domain and its mail security, inspect broken certificates, read redirect chains, parse URLs, build and count SPF records.

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

The manual describes each tab in detail. This page adds concrete workflows: typical tasks, played through step by step. Tab and button names are quoted exactly as they appear in the interface. All domains and values here are examples, not fixed tool constants.

Example 1: Survey a domain completely (Check All)

You have inherited a domain and want to see its DNS at a glance.

  1. Open the DNS tab, type example.com in the domain field, and click Check All.
  2. The result appears as JSON, grouped into sections: A, AAAA, MX, NS, TXT, SOA, plus — if present — CAA, www (A), DMARC (TXT), DKIM (TXT), MTA-STS (TXT), TLS-RPT (TXT), BIMI (TXT), and Wildcard (A).
  3. Read the "Mail & domain security" card first, above the JSON. It rates the mail entries at a glance: is SPF "present" — and present only once? Does DMARC show a green p=reject or p=quarantine, or just a yellow "monitoring only"? Did DKIM find a key under one of the 21 selectors checked? Are there MX servers, MTA-STS, TLS-RPT, and CAA? A yellow "missing" next to DMARC is a common gap.
  4. If DKIM says "not found", that only means none of the common selectors matched. If you know your mail provider's selector, query <selector>._domainkey.example.com directly as TXT.
  5. Watch for Wildcard (A). If this section appears, any arbitrary subdomain resolves — sometimes intended, often a misconfiguration.
  6. Click Zone to see the same result as a BIND-style zone file, and save it with Save Zone as a reference snapshot.

Example 2: Look up a single mail detail (TXT/MX)

You only want to know whether a particular TXT record (e.g. SPF) is set.

  1. In the DNS tab enter example.com, pick TXT in the dropdown, and click Lookup.
  2. In the result, find the line starting with v=spf1 — that is the SPF record. If it is missing, the domain has no SPF entry. If no TXT record comes back at all, a note above the JSON tells you whether the name exists but simply has no TXT records, or does not exist at all (NXDOMAIN).
  3. For the mail servers themselves, switch the type to MX and look at pri (priority) and target (target server).
  4. Need a reverse check? Enter the IP address instead of the domain: the tool switches to PTR automatically and shows the hostname behind the IP.

Example 3: Check a certificate — valid or expiring soon?

The classic before a go-live or when a certificate warning appears.

  1. Switch to the SSL / Security tab, enter example.com (the https:// is already prefixed), and click Check SSL.
  2. Look at Valid Until in the Certificate card: the days remaining are in parentheses. Green means plenty of time, yellow at 30 days or fewer (plan the renewal), red means expired.
  3. Check the Trust and Host Name rows: "Trusted (verified against the CA store)" and "covered by the certificate" mean chain and host name are in order. Red text such as "Not trusted: Incomplete chain or unknown issuer" or "Host name does not match the certificate" names the specific problem; the findings below the table also list everything else that stands out — an expiry within 14 days, say, or an RSA key that is too short.
  4. In the Subject Alternative Names card, confirm that all needed hostnames (e.g. example.com and www.example.com) are in the certificate — if one is missing, that host triggers a browser warning.
  5. The Certificate Chain shows the chain as your server sends it: the server certificate followed by at least one Intermediate CA with a green "signature ok". The root is normally absent — clients bring their own. If the server sends only its own certificate, the tool reports "The server sends no intermediate certificate" — a common, easily missed source of error.
  6. Under Connection you also see the TLS version and cipher. A red "outdated" next to TLS 1.0 or 1.1 means the server offers nothing newer. The row only shows the negotiated version — whether a server allows older versions in addition to TLS 1.2 or 1.3 is not something it reveals.

Example 4: Rate a page's security headers

You want to check a page's HTTP protection mechanisms.

  1. In the SSL / Security tab, after the run, scroll to the Security Headers card. The badge shows e.g. "4/9" — four of nine checked headers are set (green from 6, yellow from 3, otherwise red). If the address redirects, the headers come from the redirect target — so for a specific address, enter the final one right away.
  2. Checked headers are HSTS, CSP, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, and Cross-Origin-Resource-Policy.
  3. Read the validation badges, not just the check mark: a present HSTS header with too short a max-age gets a yellow warning badge ("max-age … < 31536000"), and a CSP with unsafe-inline does too. Present alone does not mean correct.
  4. Missing headers show a short note on what they would protect against ("Prevents clickjacking" and so on) — your to-do list for the server config.
  5. If the card header says "not available" instead of a number, no HTTP response came back. The headers are unknown then, not missing — check the error alert at the top first.

Example 5: Trace a redirect chain (www → non-www, HTTP → HTTPS)

After a migration you want to see whether redirects run cleanly.

  1. In the Redirect tab enter http://example.com (deliberately with http://, to see the HTTPS redirect) and click Trace Redirects.
  2. You get the chain hop by hop, for example:
    • Hop 1 http://example.com → status 301, HTTP badge.
    • Hop 2 https://example.com → status 301, HTTPS badge.
    • Hop 3 https://www.example.com → status 200, marked as the endpoint.
  3. Judge the chain length. Each extra hop costs load time and is ugly for SEO. The ideal is one jump to the target; three like above (HTTPS first, then www) can often be collapsed into one.
  4. Watch for mixed protocols. If the chain bounces between http and https, the server rule is messy. The per-hop HTTP/HTTPS badge makes that instantly visible.
  5. If the chain ends with "Redirect loop detected", two URLs point at each other — a classic misconfiguration you spot at once. If it says "Stopped after 10 hops — the chain continues" instead, the chain is longer than ten jumps; that needs trimming too.
  6. If a hop carries the grey GET badge, the server refused the HEAD request with 405 or 501. The tool then read the headers via GET — the result still holds, but the server does not handle HEAD properly.

Example 6: Parse a URL and generate a slug

You are working on tracking links or clean paths.

  1. In the URL tab paste an address with parameters, e.g. https://example.com/products?ref=newsletter&utm_source=mail#top, and click Parse URL.
  2. The URL Components table shows each part separately: protocol (https:), hostname, pathname (/products), search, hash (#top), origin, and more. The Search Parameters table lists ref = newsletter and utm_source = mail separately — handy for auditing tracking parameters.
  3. Enter an internationalized domain (e.g. https://müller.de) and hostname (Unicode) appears next to the Punycode form — so you see both spellings. The Encoding card shows the address under Encoded (as sent) the way it actually travels (Punycode, percent-encoding), and under Decoded (readable) in legible form with umlauts.
  4. Scroll down to the URL Slug Generator and type a title like Über die Größe & Schönheit moderner Webtechnologien. The slug ueber-die-groesse-schoenheit-moderner-webtechnologien is built live (umlauts resolved, special characters removed). Use Separator to switch to _; Copy takes the result.

Example 7: Build an SPF record for Google Workspace

Your domain sends mail through Google and a newsletter service.

  1. In the SPF tab you find the All Policy select. Leave it at ~all (SoftFail) for now — switch to -all for the strict version later.
  2. Under Own Mail Servers, mx is already active. Leave it on if your MX servers send mail themselves.
  3. Click Google under Mail Providers — the record on the right immediately adds include:_spf.google.com. For the newsletter, also click e.g. Brevo or create a custom line via Add include:.
  4. Keep an eye on the stats. The row shows DNS lookups (this record) (x/10) and Length. If the lookup counter turns yellow (from 8) or red (above 10), your own record already has too many include:/a/mx mechanisms — consolidate them. But the counter only sees your record, not the lookups that _spf.google.com and the newsletter service trigger in turn.
  5. So click Count all lookups (incl. nested includes). The tool resolves every include: recursively and shows the real total, plus a tree of how many lookups each service consumes. If it says "Within the limits of RFC 7208.", the record is fine.
  6. Copy the record with Copy, then publish it as a TXT record (@, TTL 3600) at your DNS provider per the DNS Entry card.
  7. After propagation, click Verify DNS: the tool jumps to the DNS tab with type TXT, you enter your domain, and you see the published record to confirm.

Example 8: Load an existing SPF record and check it recursively

You take over a domain whose SPF record has grown over the years, and mail sporadically lands in spam.

  1. In the SPF tab, enter example.com under Domain at the top and click Load.
  2. The tool loads the published record and spreads it across the form: IP addresses into the IP lines, known providers as active presets, other include: as your own lines, anything unknown under Custom mechanisms.
  3. The analysis appears below. The badge shows the total of all DNS lookups across every nested include: — say "12/10 DNS lookups" in red. The error list names the reason: too many lookups, an include: without an SPF record, or more than one SPF record. Receivers treat all of that as permerror and ignore the record.
  4. The tree below shows which included service consumes how many lookups. Remove from the form whatever no longer sends, or replace fixed servers with ip4: entries, which cost no lookup.
  5. Click Count all lookups (incl. nested includes) to count the cleaned-up version again, and copy it into your DNS with Copy.

You can take the same route from the DNS tab: after Check All, the mail summary has a Count lookups button next to the SPF record that starts exactly this analysis in the SPF tab.

Example 9: Inspect a broken certificate and open it in the PKI Viewer

A site shows a certificate error in the browser, and you want to know exactly what is wrong.

  1. In the SSL / Security tab, enter the domain and click Check SSL.
  2. A red SSL/TLS Error alert appears at the top with the cause, such as "Certificate expired" or "Self-signed certificate", plus the cURL error code.
  3. The cards below are filled anyway: the tool read the certificate through a second handshake without verification. In the Certificate card, Trust says "Not trusted: …", and the findings state the problem in plain words — for example "The certificate expired 3 days ago."
  4. In the Certificate Chain, check each link: a red "signature does not match" points to a wrongly assembled chain, and the role "Root CA (self-signed)" directly behind the server certificate suggests a private, in-house CA.
  5. For the detailed analysis, click PKI Viewer in the chain card header: the PKI Viewer opens in a new tab and shows every certificate of the chain with all its fields. Alternatively, save it with Chain (PEM) as a file for the support ticket.

Go deeper: the overview for the big picture, the manual for each tab and all limits, the tips & tricks for interpretation and combination. You can try everything right in the tool.