# DNS, SSL, Redirect & URL — Examples

> Hands-on walkthroughs: check DNS, inspect a certificate, read a redirect chain, parse a URL, and build an SPF record.

Source: https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/examples/

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/) describes each tab in detail. This page adds **concrete workflows**: typical tasks, played through step by step. The interface is in English, so tab and button names are quoted as-is. 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](https://www.jpkc.com/tools/dns-ssl-redirect-url/), 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 — `www (A)`, `DMARC (TXT)`, `DKIM (TXT)`, and `Wildcard (A)`.
3. **Read the mail-related sections first.** Is there a sensible mail server under `MX`? Does `DMARC (TXT)` appear? If the DMARC section is missing entirely, the domain has no DMARC record — a common gap.
4. **Watch for `Wildcard (A)`.** If this section appears, *any* arbitrary subdomain resolves — sometimes intended, often a misconfiguration.
5. 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.
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 **Verification** line: `OK` means a clean chain. Red text like "Self-signed certificate", "Unable to get local issuer certificate", or "Hostname mismatch" names the specific problem.
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 whether the server, intermediate, and root certificates are all delivered. An incomplete chain is a common, easily missed source of error.

## 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).
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.

## 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.

## 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.
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, the **All Policy** is at the top. 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** (`x/10`) and **Length**. Stay under 10 lookups and under 450 characters and everything is green. When the lookup counter turns yellow (from 8) or red (above 10), you have too many `include:`/`a`/`mx` mechanisms — consolidate them.
5. Copy the record with **Copy**, then publish it as a TXT record (`@`, TTL `3600`) at your DNS provider per the **DNS Entry** card.
6. 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.

---

Go deeper: 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 all limits, the [tips & tricks](https://www.jpkc.com/db/en/tools/dns-ssl-redirect-url/tips/) for interpretation and combination. You can try everything right in the [tool](https://www.jpkc.com/tools/dns-ssl-redirect-url/).