DNS, SSL, Redirect & URL — Manual

Zurück zur Übersicht: DNS, SSL, Redirect & URL · Tool live öffnen: www.jpkc.com/tools/dns-ssl-redirect-url/

Dieses Manual beschreibt alle fünf Tabs vollständig: was sie abfragen, wie du die Ergebnisse liest und welche technischen Grenzen gelten. Die Oberfläche des Tools ist auf Englisch — die Tab- und Button-Bezeichnungen stehen deshalb hier in ihrer englischen Original-Schreibweise (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Architektur und Grenzen vorab

Drei Tabs (DNS, SSL / Security, Redirect) holen Daten aus dem Netz und laufen daher über die JPKCom-Server. URL-Parser, Slug-Generator und der SPF-Generator rechnen im Browser; nur die beiden SPF-Funktionen Load und Count all lookups fragen den DNS-Endpunkt des Servers.

DNS-Abruf: Ein serverseitiger PHP-Endpunkt löst die Records mit dns_get_record() auf und gibt sie unverändert als JSON zurück. Erst die Anzeige im Browser maskiert Sonderzeichen — JSON-Ansicht, Zonendatei und Downloads enthalten also die Originalwerte, etwa ein & in einem TXT-Record.
SSL-Abruf: Der Proxy (p.php) baut zwei Verbindungen zum eingegebenen Host auf, jede an eine vorab geprüfte IP gebunden. Beide lösen den Namen getrennt auf — bei mehreren A-Records können das zwei verschiedene Adressen sein. Die erste ist ein normaler HTTPS-Request (GET, nur die Header werden gelesen) mit Zertifikatsprüfung gegen den CA-Store des Servers — sie liefert Status, Header, Timing und die Vertrauensentscheidung (12 s pro Request, 15 s insgesamt). Dieser Request folgt bis zu 5 Weiterleitungen; leitet die Adresse weiter, beziehen sich Status, Header, Timing und Trust auf die finale URL. Die zweite ist ein reiner TLS-Handshake ohne Prüfung (8 s Verbindungs-Timeout, mit SNI) zum eingegebenen Host, der die Zertifikatskette so mitschneidet, wie der Server sie sendet — Zertifikat, Kette, TLS-Version, Befunde und CAA gehören also immer zum eingegebenen Host. Dadurch zeigt das Tool auch abgelaufene, selbstsignierte oder anderweitig ungültige Zertifikate und akzeptiert dafür auch alte TLS-Versionen und schwache Schlüssel.
Redirect-Abruf: Jeder Hop ist ein eigener Request ohne automatisches Folgen: zuerst HEAD, bei Status 405 oder 501 ein GET, dessen Body nach den Headern verworfen wird. Pro Hop gelten höchstens 10 s, für die ganze Kette 24 s; Antwort-Header werden pro Hop auf 64 KB begrenzt.
Authentifizierung: Vor jedem Server-Request holt das JavaScript über p-api.php ein frisches, tageweise rotierendes Token (gültig in einem 5-Minuten-Fenster), das Referer-geprüft ist. Die Schlüssel dafür stehen in der geladenen Seite und wechseln täglich um Mitternacht (UTC); lag der Tab darüber hinaus offen, lehnt der Server mit „Forbidden" ab, und erst ein Reload holt neue. Diese Endpunkte sind kein öffentliches API — sie funktionieren nur aus dem Tool heraus.
SSRF-Schutz: Private, Loopback-, Link-local-, reservierte und CGNAT-Adressen (RFC 1918, 127/8, 169.254/16, 100.64/10, IPv6 fc00::/7, fe80::/10, ::1) werden blockiert — beim DNS-Reverse-Lookup, beim SSL-/Redirect-Abruf und bei Redirects auf jedem Hop erneut. Erlaubt sind nur http/https auf den Ports 80, 443, 3000, 5000, 8000, 8008, 8080 und 8443. Eine gesperrte Adresse meldet das Tool im Klartext („This address cannot be checked: …").
Limits: maximal 10 Redirect-Hops (Schleifen werden erkannt), maximale URL-Länge 3072 Zeichen, Domain-Länge 253 Zeichen.
Drossel und Rate-Limits: Eine clientseitige Drossel lässt nur etwa 1 Server-Anfrage pro Sekunde zu (Hinweis „Please wait a moment before making another request."). Serverseitig gilt pro IP-Adresse ein Limit von 120 Anfragen pro Minute für den Proxy und ebenso für den DNS-Endpunkt; Check All und die SPF-Funktionen teilen sich zusätzlich ein gemeinsames Limit von 20 pro Minute. Wird ein serverseitiges Limit überschritten, meldet der DNS-Tab (Lookup und Check All) „Rate limited. Please wait …ms."; SSL, Redirect und die SPF-Funktionen melden „Too many requests — please wait … s and try again."
Privatsphäre: Die geprüfte Domain sieht den JPKCom-Server, nicht deine IP.

Expert Mode (optional)

Das Tool unterstützt einen optionalen Expert Mode über einen selbst betriebenen lokalen Proxy (LocalProxy auf http://127.0.0.1:<port>, mindestens Version v1.1.0 — ältere Versionen meldet das Tool als veraltet, im Status mit „update required"). Ist er aktiv, holen SSL und Redirect ihre Daten über diesen lokalen Proxy statt über den JPKCom-Server, und die clientseitige Drossel entfällt für diese beiden Tabs. DNS und die SPF-Funktionen nutzen den lokalen Proxy nicht und bleiben gedrosselt. Auch der lokale Proxy blockiert private, Loopback- und Link-local-Ziele — Intranet-Hosts prüfst du damit ebenfalls nicht.

Der SSL-Tab zeigt im Expert Mode einen kleineren Umfang: Zertifikatsdaten, SANs, die Kette nur als Namensliste, zehn Security-Header (zusätzlich Cross-Origin-Embedder-Policy), die Server-Header Server, X-Powered-By und Via, die Raw Headers sowie das Timing. Dazu kommt eine Zeile HTTP/3, die anzeigt, ob das Ziel HTTP/3 per Alt-Svc anbietet („Advertised" oder „Not advertised"). Es fehlen TLS-Version, Seriennummer, Fingerprint, Hostname-Prüfung, Befunde, Signaturprüfung der Kette, die Buttons Chain (PEM) und PKI Viewer sowie die CAA-Karte. Zwei Unterschiede wiegen schwerer: Der lokale Proxy prüft das Zertifikat selbst, sodass abgelaufene, selbstsignierte oder anderweitig ungültige Zertifikate nur zur Meldung „Inspect failed: …" führen statt zu Karten — kaputte Zertifikate untersuchst du im Standard-Modus. Und die Trust-Zeile zeigt im Expert Mode immer „Trusted (verified against the CA store)"; dort hat sie keine Aussagekraft.

Der Redirect-Tab folgt im Expert Mode bis zu 11 Stationen, ohne das 24-s-Gesamtbudget, ohne GET-Fallback (kein Badge GET) und ohne die Hinweise „Stopped after 10 hops …" und „Blocked redirect target" — eine gesperrte Adresse oder ein anderer Fehler erscheint dort als „Inspect failed: …". Die Schleifenerkennung bleibt aktiv. Die Grenzen im Redirect-Abschnitt und in den Betriebsgrenzen gelten für den Standard-Modus. Die Einrichtung ist fortgeschritten und für den normalen Betrieb nicht nötig.

DNS — DNS-Records abfragen

Im DNS-Tab gibst du eine Domain (z. B. example.com) oder eine IP-Adresse ein und wählst rechts den Record-Typ. Mit Lookup (oder Enter) fragst du genau diesen Typ ab, mit Check All die wichtigsten Typen auf einmal. Protokoll, Pfad und Port in der Eingabe schneidet das Tool ab, sodass du auch eine komplette URL einfügen kannst.

Einzelabfrage (Lookup)

Im Dropdown stehen die Typen A, AAAA, MX, NS, TXT, CNAME, SOA, SRV, CAA, PTR, NAPTR. ANY bietet das Tool nicht mehr an: Die meisten Resolver verweigern solche Abfragen oder beantworten sie nur minimal (RFC 8482) — Check All ist der Ersatz. Das Ergebnis enthält die gefundenen Records mit allen Feldern (z. B. bei MX pri und target, bei SOA mname, rname, serial, refresh, retry, expire, minimum-ttl), die Anzahl der Treffer und einen Zeitstempel.

Leere Ergebnisse und NXDOMAIN

Findet die Abfrage nichts, unterscheidet das Tool zwei Fälle und blendet über dem Ergebnis einen Hinweis ein: „The name exists, but has no … records." (der Name existiert, hat aber keine Records dieses Typs) oder „The name does not exist (NXDOMAIN) — or the resolver did not answer." Dafür prüft es den Namen zusätzlich auf A-, AAAA-, CNAME-, MX-, TXT- und NS-Records. Liefert Check All gar keinen Abschnitt, erscheint ein eigener Hinweis — ohne diese zusätzliche Namensprüfung: „No records found — the name does not exist (NXDOMAIN) or the resolver did not answer."

Check All — Komplettabfrage

Check All fragt nacheinander A, AAAA, CNAME, MX, NS, TXT, SOA, SRV und CAA ab und ergänzt sieben Zusatz-Checks. Im Ergebnis erscheinen nur Abschnitte, die etwas gefunden haben:

www (A) — der A-Record der www.-Subdomain.
DMARC (TXT) — der TXT-Record unter _dmarc.<domain>.
DKIM (TXT) — Records unter <selector>._domainkey.<domain> für 21 gängige Selektoren: default, google, selector1, selector2, k1, k2, k3, s1, s2, dkim, mail, mandrill, smtp, zmail, protonmail, protonmail2, fm1, fm2, mailjet, brevo, key1. Gezählt werden nur TXT-Records, die mit v=DKIM beginnen oder einen Schlüssel (p=) enthalten; jeder Treffer trägt seinen Selektor im Feld selector. Die Liste der geprüften Selektoren steht im JSON unter dkimSelectorsChecked.
MTA-STS (TXT) — der Record unter _mta-sts.<domain>.
TLS-RPT (TXT) — der Record unter _smtp._tls.<domain>.
BIMI (TXT) — der Record unter default._bimi.<domain>.
Wildcard (A) — geprüft wird, ob eine zufällige Subdomain auflöst; falls ja, wird der Eintrag als *.<domain> dargestellt (Hinweis auf einen Wildcard-DNS-Eintrag).

Für IP-Adressen ist Check All deaktiviert (Record-Typen gelten nur für Domains).

Mail & domain security

Nach Check All fasst eine Karte „Mail & domain security" über dem JSON die mail- und zertifikatsrelevanten Einträge zusammen, jeweils mit Badge und Rohwert:

SPF — „present", „missing" oder „N records — invalid" (mehr als ein SPF-Record ist ein Fehler). Der Button Count lookups wechselt in den SPF-Tab, trägt die Domain ein und lädt dort den Record samt rekursiver Lookup-Zählung.
DMARC — grün bei p=reject oder p=quarantine, gelb bei p=none („monitoring only") oder fehlendem Record.
DKIM — „N found" mit den gefundenen Selektoren oder „not found" mit dem Hinweis, dass keiner der 21 geprüften Selektoren passt und ein eigener Selektor möglich ist.
MX — Anzahl der Mailserver mit Priorität, „none" oder „null MX" (ein einzelner MX-Eintrag .: die Domain empfängt keine Mail, RFC 7505).
MTA-STS, TLS-RPT, BIMI — „present" mit dem Record oder „not set" mit einer Kurzerklärung (TLS-Pflicht für eingehende Mail, Berichte über TLS-Zustellprobleme, Markenlogo im Mailprogramm).
CAA — die CAA-Records oder „not set" (dann darf jede CA Zertifikate ausstellen).

Reverse-Lookup (PTR) und IDN

Gibst du eine IP-Adresse ins Domain-Feld ein, schaltet das Tool den Record-Typ automatisch auf PTR um, deaktiviert Check All und baut die Reverse-Adresse (…in-addr.arpa für IPv4, …ip6.arpa für IPv6). Reverse-Lookups sind nur für öffentlich routbare IPs möglich — private, Loopback- und reservierte Bereiche werden abgewiesen. Internationalisierte Domains (Umlaute o. Ä.) werden vor der Abfrage nach Punycode umgewandelt; das Ergebnis weist die Unicode- und die Punycode-Form aus (idnDomain, punycode).

Ausgabe: JSON- oder Zone-Ansicht

Standardmäßig erscheint das Ergebnis als JSON in einem schreibgeschützten CodeMirror-Editor. Zone schaltet auf eine BIND-artige Zonendatei um: Kopfkommentare (Domain, ggf. IDN-Form, Abfragetyp, Zeitpunkt) und ausgerichtete Spalten Name, TTL, Class, Type, Data. TXT-Werte stehen dort als Folge gequoteter Strings mit höchstens 255 Zeichen je String, Anführungszeichen und Backslashes sind escaped; auch der CAA-Wert steht in Anführungszeichen. Die Zone-Ansicht ist editierbar, bevor du sie kopierst.

Die Buttons: Copy kopiert, was gerade sichtbar ist (JSON oder Zone), JSON speichert das Ergebnis als dns-<domain>.json, Zone wechselt die Ansicht. In der Zone-Ansicht kommen Copy Zone und Save Zone (<domain>.zone.txt) dazu.

SSL / Security — Zertifikat und Header

Im SSL / Security-Tab gibst du eine Domain (das https:// ist vorangestellt) ein und klickst Check SSL oder drückst Enter. Gibst du eine http://-Adresse ein, prüft der Server stattdessen die https://-Variante. Der Server ruft die Seite ab und liefert die Roh-Daten; das Tool baut daraus mehrere Karten. Dank des zusätzlichen TLS-Handshakes ohne Prüfung erscheinen Zertifikat und Kette auch dann, wenn die normale Verbindung am Zertifikat scheitert (im Standard-Modus, siehe Expert Mode).

Leitet die Adresse weiter (etwa example.com → www.example.com), mischt das Ergebnis zwei Hosts: HTTP-Status, IP-Adresse und Protokoll (Karte Connection), Security Headers, Server, Raw Headers, Timing und Trust stammen vom Ziel der Weiterleitung, Zertifikat, SANs, Kette, Befunde und CAA vom eingegebenen Host. Für die Header einer bestimmten Adresse gibst du deshalb die finale Adresse ein.

Fehlermeldungen

Scheitert der prüfende HTTPS-Request, steht oben ein Alert — SSL/TLS Error (rot) oder Connection Error (gelb) — mit einer Ursache, dem cURL-Fehlercode und der Original-Meldung. Die Ursache leitet das Tool aus cURLs Meldung ab: „Certificate expired", „Certificate not yet valid", „Untrusted root certificate in the chain", „Self-signed certificate", „Host name does not match the certificate", „Incomplete chain or unknown issuer", „Certificate revoked", „TLS protocol not supported" oder allgemein „TLS/SSL error". Die Karten darunter erscheinen trotzdem, soweit der zweite Handshake ein Zertifikat geliefert hat. Klappt auch dieser nicht, meldet das Tool „No TLS handshake possible: …".

Connection und Certificate

Connection — URL, ggf. finale URL nach Weiterleitung, IP-Adresse, HTTP-Statuscode, HTTP-Version (HTTP/1.0, /1.1, /2 oder /3) und TLS mit Protokoll-Version und Cipher. Die TLS-Version ist die im Handshake ausgehandelte, also die höchste, die beide Seiten beherrschen. TLS 1.0, TLS 1.1 und SSL markiert das Tool rot als „outdated" — dann bietet der Server nichts Neueres an. Ob ein Server neben TLS 1.2 oder 1.3 zusätzlich ältere Versionen erlaubt, zeigt diese Zeile nicht.
Certificate — Common Name, Organisation (falls vorhanden), Aussteller (Issuer, ggf. mit Organisation), Valid From und Valid Until mit verbleibenden Tagen (grün, ab ≤ 30 Tagen gelb, abgelaufen rot mit „expired … days ago"), Signature (Signatur-Algorithmus), Public Key (z. B. „RSA 2048 bit", „EC P-256 (256 bit)" oder „Ed25519"), Serial Number, SHA-256-Fingerprint, Host Name („covered by the certificate" oder „not covered", geprüft über SANs mit Wildcard nur im linken Label, sonst den CN) und Trust: „Trusted (verified against the CA store)", „Not trusted: …" mit Ursache oder „Unknown — the HTTP connection failed", wenn gar keine HTTP-Antwort kam. Das Symbol im Kartenkopf spiegelt diesen Vertrauensstatus. Den SHA-1-Fingerprint enthält nur der JSON-Export.
Befunde — unter der Tabelle listet das Tool konkrete Probleme als Fehler oder Warnung: abgelaufen (seit N Tagen), noch nicht gültig, Ablauf in höchstens 14 Tagen, Hostname nicht abgedeckt, selbstsigniert, schwacher Signatur-Algorithmus (MD5, SHA-1), RSA-Schlüssel unter 2048 Bit, fehlendes Intermediate-Zertifikat sowie eine gebrochene Kette oder falsche Reihenfolge.

Subject Alternative Names und Certificate Chain

Subject Alternative Names — alle im Zertifikat hinterlegten DNS-Namen und IP-SANs, die Anzahl steht im Kartenkopf.
Certificate Chain (as sent by the server) — die Kette genau so, wie der Server sie ausliefert. Je Zertifikat siehst du Subject, eine Rolle und ein Signatur-Badge, darunter Aussteller, Schlüssel, Signatur-Algorithmus, Ablaufdatum mit Resttagen und den SHA-256-Fingerprint. Die Rollen: Server certificate, Intermediate CA, Cross-signed root (acts as intermediate) (eine CA mit „Root" im Namen, die nicht selbstsigniert ist, sondern von einer älteren Root gegengezeichnet), Root CA (self-signed) (nur bei gültiger Selbstsignatur) und Certificate. Das Signatur-Badge prüft, ob jedes Zertifikat wirklich vom nächsten in der Kette signiert ist: „signature ok", „signature does not match" oder „issuer not sent" (der Aussteller fehlt in der gesendeten Kette — beim letzten Glied der Normalfall, denn Server senden die Root üblicherweise nicht mit).
Chain (PEM) speichert die komplette Kette als <host>-chain.pem; PKI Viewer öffnet den PKI Viewer in einem neuen Tab und lädt die Kette dort direkt in den Tab „PEM Decoder". Die Übergabe läuft über den lokalen Browser-Speicher und wird vom PKI Viewer sofort nach dem Einlesen gelöscht.

CAA

Die Karte CAA sucht die CAA-Records des Hosts — bzw. des nächsten übergeordneten Namens, der welche hat (RFC 8659) — und vergleicht sie mit dem Aussteller des Zertifikats. Bei einem Wildcard-Zertifikat zählt issuewild, ohne solchen Eintrag issue. Den Aussteller ordnet das Tool über die Namen bekannter CAs (z. B. Let's Encrypt, Google Trust Services, DigiCert, Sectigo, GlobalSign, Amazon) einem CAA-Bezeichner zu. Mögliche Badges: CA allowed, CA not listed (das Zertifikat stammt von einer CA, die der Record heute nicht erlaubt), not compared (CA nicht zuordenbar), no CAA (jede CA darf ausstellen) und not restricted (CAA-Records vorhanden, aber keiner für den passenden Tag). Darunter stehen die gefundenen Records mit dem Namen, an dem sie hängen. Für reine IP-Adressen entfällt die Karte.

Security Headers

Neun Header werden geprüft: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy. Ein Zähler-Badge zeigt „vorhanden/gesamt" (ab 6 grün, ab 3 gelb, sonst rot). Werte über 80 Zeichen werden gekürzt; den vollen Wert zeigt der Tooltip.

Vorhandene Header werden inhaltlich validiert und mit OK-, Warn-, Fehler- oder Info-Badge markiert:

HSTS: fehlendes max-age (Fehler), max-age unter 31536000 Sekunden (Warnung), fehlendes includeSubDomains bzw. preload (Info).
CSP: unsafe-inline und unsafe-eval je Direktive sowie das Fehlen von default-src und script-src (jeweils Warnung).
X-Frame-Options: andere Werte als DENY/SAMEORIGIN (Fehler), ALLOW-FROM als veraltet (Info).
X-Content-Type-Options: alles außer nosniff (Fehler).
Referrer-Policy: unbekannter Wert oder unsafe-url (Warnung).
Permissions-Policy: Wildcard * (Warnung).

X-XSS-Protection und die beiden Cross-Origin-Header prüft das Tool nur auf Anwesenheit. Fehlende Header bekommen einen kurzen Hinweis, wovor sie schützen würden. Kam keine HTTP-Antwort zustande, zeigt die Karte „not available" statt einer Null-Bilanz — die Header sind dann unbekannt, nicht fehlend.

Timing, Server und Export

Timing — DNS Lookup, TCP Connect, SSL Handshake (wenn messbar), Pretransfer, Start Transfer und Total.
Server — Server-, X-Powered-By-, Via-, X-Cache-, Cf-Ray-, X-Served-By- und Content-Type-Header, soweit vorhanden.
Raw Headers — die kompletten Roh-Antwort-Header, aufklappbar.

Mit Copy JSON / Save JSON (ssl-check-<host>.json) sicherst du das vollständige Ergebnis inklusive der PEM-Daten der Kette.

Redirect — Weiterleitungskette verfolgen

Im Redirect-Tab gibst du eine URL ein und klickst Trace Redirects (oder drückst Enter); fehlt das Schema, ergänzt das Tool https://. Der Server folgt der Kette Hop für Hop (ohne Location automatisch zu folgen, sondern jeden Schritt einzeln), bis zu 10 Hops. Er fragt zuerst per HEAD; lehnt der Server das mit 405 oder 501 ab, liest das Tool die Header per GET und markiert den Hop mit einem Badge GET. Pro Hop siehst du:

Hop-Nummer und die URL dieser Station,
den Statuscode (farbig nach 2xx/3xx/4xx/5xx),
ein HTTPS- oder HTTP-Badge,
die IP-Adresse der tatsächlich genutzten Verbindung, das Timing und den Server-Header,
bei HTTPS-Hops den Zertifikats-Namen mit Restlaufzeit in Tagen (über 30 grün, 1 bis 30 gelb, bei 0 und darunter rot — die Tage sind abgerundet, rot ist also auch ein Zertifikat, das noch weniger als 24 Stunden gilt),
die Roh-Header dieses Hops inklusive Statuszeile (aufklappbar),
bei einem Fehler die Meldung, bei Zertifikatsproblemen mit Ursache (z. B. „Certificate expired").

Relative Location-Weiterleitungen löst das Tool nach RFC 3986 zu absoluten URLs auf, auch Formen wie //host/pfad, ?query oder ../pfad. Wird eine bereits besuchte URL erneut angesteuert, bricht das Tool mit dem Hinweis „Redirect loop detected" ab. Ein Hop, der auf eine private/interne Adresse zeigt, wird als „Blocked redirect target" abgewiesen. Ist das Zeitbudget von 24 s verbraucht, endet die Kette mit „Stopped: time budget of 24 s for the whole chain used up". Leitet auch der zehnte Hop noch weiter, erscheint der Hinweis „Stopped after 10 hops — the chain continues". Der letzte Hop (kein 3xx mehr) wird als Endpunkt markiert. Copy JSON / Save JSON (redirect-trace.json) sichern die ganze Kette. Die genannten Grenzen gelten für den Standard-Modus; zum Expert Mode siehe Expert Mode (optional).

URL — Parser und Slug-Generator

Dieser Tab arbeitet vollständig im Browser, ohne Server-Abruf.

URL-Parser

Mit Parse URL (oder Enter) zerlegt das Tool eine Adresse über die JavaScript-URL-API in ihre Bestandteile: href, protocol, hostname (bei IDN zusätzlich hostname (Unicode), im Browser aus Punycode zurückgerechnet), port (oder „(default)"), pathname, search, hash, origin, host, username und password (maskiert als ***). Fehlt ein Protokoll, wird https:// ergänzt. Darunter listet eine Tabelle Search Parameters alle Query-Parameter als Schlüssel-Wert-Paare.

Die Karte Encoding zeigt die Adresse zweimal: Encoded (as sent) ist die normalisierte, prozentkodierte Form, wie sie über die Leitung geht; Decoded (readable) zeigt den Host in Unicode und dekodiert jede gültige Escape-Sequenz einzeln — ein loses % bleibt stehen, statt den Rest zu verderben. In beiden Zeilen ist ein Passwort maskiert. Alle Felder sind editierbar; Copy JSON kopiert die Struktur aus Komponenten und Parametern.

URL-Slug-Generator

Der URL Slug Generator wandelt beliebigen Text live (während du tippst) in einen URL-tauglichen Slug. Er behandelt deutsche Umlaute (ä→ae, ö→oe, ü→ue, ß→ss), zerlegt akzentuierte Zeichen per Unicode-Normalisierung (é→e, ñ→n …), ersetzt alle übrigen Sonderzeichen durch den Separator (- oder _), fasst Mehrfach-Separatoren zusammen und schneidet sie an den Rändern ab. Eine Zeichen-Zählung steht darunter; Copy kopiert den Slug.

SPF — SPF-TXT-Record bauen

Der SPF-Tab erzeugt live einen gültigen v=spf1-Record im Browser. Du konfigurierst links das Formular, rechts aktualisiert sich der Record sofort. Die Ausgabe-Box ist zusätzlich direkt editierbar, doch solche Änderungen übernimmt nur Copy: Lookup-Zähler, Length, Warnungen, der Wert in der DNS Entry-Karte und Count all lookups arbeiten weiter mit dem Record aus dem Formular, und jede Formularänderung überschreibt die Box.

Domain (optional) mit Button Load — lädt den veröffentlichten Record einer Domain, siehe SPF-Record laden und analysieren.
All Policy (Catch-all): -all (Fail, für Produktion empfohlen), ~all (SoftFail, Default, fürs Testen), ?all (Neutral), +all (Pass — ausdrücklich nicht empfohlen) oder „None" (weglassen). Unter dem Auswahlfeld erklärt ein Hinweistext die gewählte Policy.
Own Mail Servers — Checkboxen für a (der A-Record der Domain sendet Mail) und mx (die MX-Server senden Mail; standardmäßig aktiv).
Mail Providers — 16 Ein-Klick-Presets: Google, Microsoft 365, Amazon SES, SendGrid, Mailchimp, Postmark, Brevo, Mailgun, Zoho, HubSpot, Salesforce, Mailjet, SparkPost, Klaviyo, Fastmail und Proton Mail. Jedes Preset fügt seinen include:-Mechanismus hinzu; ein zweiter Klick nimmt ihn wieder heraus.
Add include: und IP Addresses — eigene include:-Zeilen sowie beliebig viele ip4:-/ip6:-Einträge, jeweils mit optionaler Präfixlänge. Ungültige Adressen markiert das Tool rot und lässt sie im Record weg; eine Warnung nennt sie.
Advanced — ein redirect= (verweist die Policy auf eine andere Domain; die All-Policy entfällt dann) und ein freies Feld Custom mechanisms für zusätzliche, space-getrennte Mechanismen.

Der Record entsteht in fester Reihenfolge: zuerst ip4:/ip6: (ohne DNS-Lookup), dann a, mx, die Provider-Presets, eigene include:-Zeilen, Custom mechanisms, redirect= und zuletzt die All-Policy.

Rechts zeigt eine Statistik-Zeile zwei Live-Werte: DNS lookups (this record) (x/10, ab 8 gelb, über 10 rot) und Length (Zeichen, über 300 gelb, über 450 rot). Der Zähler bewertet nur den Record selbst: include, a, mx, ptr, exists und redirect= kosten je einen Lookup, ip4:/ip6: keinen — was die eingebundenen Records ihrerseits verbrauchen, kommt erst mit Count all lookups hinzu. Der Generator warnt bei mehr als 10 DNS-Lookups, bei über 450 Zeichen, bei +all, bei ungültigen IP-Adressen und beim Konflikt redirect= plus All-Policy. Ist der Record länger als 255 Zeichen, zeigt die DNS Entry-Karte zusätzlich die Zeile Zone file / split mit dem Wert, aufgeteilt in mehrere gequotete Strings; die meisten DNS-Provider teilen automatisch.

Die DNS Entry-Karte fasst zusammen, wie der Record einzutragen ist (Typ TXT, Host @, der Wert, TTL 3600), darunter steht eine Kurzanleitung How to deploy. Copy kopiert den Record; Verify DNS springt in den DNS-Tab und stellt dort den Typ auf TXT, damit du deinen veröffentlichten Record direkt nachschlagen kannst — die Domain trägst du dort selbst ein.

SPF-Record laden und analysieren

Zwei Funktionen fragen den DNS-Endpunkt des Servers und unterliegen damit Drossel und Rate-Limit:

Load liest den unter Domain veröffentlichten SPF-Record (TXT-Record, der mit v=spf1 beginnt) und überträgt ihn ins Formular: ip4:/ip6: in IP-Zeilen, a und mx in die Checkboxen, bekannte Provider als aktive Presets, weitere include: als eigene Zeilen, redirect= und die All-Policy in ihre Felder; alles andere landet unter Custom mechanisms. Gleichzeitig startet die Analyse. Beim Neuaufbau gilt die feste Reihenfolge des Generators: Mechanismen mit Qualifier wie -ip4:…, ~a oder -include:… landen unter Custom mechanisms und stehen damit hinter a, mx, Presets und include: — weil bei SPF der erste Treffer zählt, kann das das Ergebnis ändern. Ungültige ip4:-/ip6:-Werte fallen mit Warnung aus dem Record. Vergleiche den neuen Record deshalb vor dem Veröffentlichen mit dem alten.
Count all lookups (incl. nested includes) analysiert den gerade generierten Record. Als Domain verwendet das Tool den Eintrag im Feld Domain, ohne Eintrag example.com.

Die Analyse folgt allen include:- und redirect=-Verweisen rekursiv und zeigt: die Gesamtzahl der DNS-Lookups (x/10, Badge grün, ab 8 gelb, über 10 rot), die void lookups (Verweise ohne Records, höchstens 2 erlaubt), Fehler und Warnungen sowie einen Baum aller eingebundenen Records mit den Lookups je Ebene. Als Fehler meldet sie mehr als einen SPF-Record, mehr als 10 Lookups, mehr als 2 Void-Lookups, ungültige ip4:-/ip6:-Werte, unbekannte Terme, Schleifen oder zu tiefe Verschachtelung und include:-Ziele ohne SPF-Record (Empfänger werten das als permerror). Als Warnung meldet sie ptr (veraltet und langsam) sowie +all/all. Ohne Fehler steht „Within the limits of RFC 7208.". Verweise mit Makros (%{…}) löst die Analyse nicht auf; redirect= wertet sie nur aus, wenn der Record kein all enthält.

Grenzen: höchstens 40 DNS-Abfragen je Analyse, 10 Ebenen Verschachtelung, ein übergebener Record darf maximal 2048 Zeichen lang sein, muss mit v=spf1 beginnen und nur druckbares ASCII enthalten.

History

Die Tabs DNS, SSL / Security, Redirect und URL speichern ihre letzten 20 Eingaben im lokalen Speicher deines Browsers; doppelte Einträge werden zusammengefasst. Ein Klick auf einen Eintrag setzt die Eingabe wieder ins Feld (im DNS-Tab auch den Record-Typ, nach Check All den Typ A) — die Abfrage selbst startest du danach mit dem Button. Clear leert die History des jeweiligen Tabs. Der SPF-Tab und der Slug-Generator führen keine History. Die URL-History speichert die Adresse so, wie du sie eingegeben hast — ein Passwort in user:pass@ steht dort im Klartext.

Betriebsgrenzen — kompakt

Privatsphäre: Abrufe laufen über den JPKCom-Server; die Zielseite sieht nicht deine IP.
SSRF-/Private-IP-Schutz: private, lokale, reservierte und CGNAT-Adressen werden geblockt (DNS-Reverse, SSL, jeder Redirect-Hop); nur http/https auf den Ports 80, 443, 3000, 5000, 8000, 8008, 8080 und 8443.
Limits (Standard-Modus): max. 10 Redirect-Hops, 10 s pro Hop und 24 s pro Kette, SSL-Abruf 15 s, URL ≤ 3072 Zeichen, Domain ≤ 253 Zeichen; SPF-Analyse max. 40 DNS-Abfragen und 10 Ebenen.
Drossel: clientseitig ~1 Server-Anfrage pro Sekunde (im Expert Mode nur für DNS und SPF).
Rate-Limits pro IP: 120 Anfragen pro Minute für Proxy bzw. DNS-Endpunkt, Check All und SPF-Funktionen zusätzlich gemeinsam 20 pro Minute.
Token: tageweise rotierend, 5-Minuten-Fenster, Referer-geprüft — kein öffentliches API.
Ohne Server nutzbar: URL-Parser, Slug-Generator und SPF-Generator rechnen komplett im Browser; nur Load und Count all lookups im SPF-Tab brauchen den Server.

Für das große Bild und die Zielgruppen siehe die Übersicht. Konkrete Abläufe stehen in den Beispielen, Kniffe in den Tipps & Tricks. Ausprobieren kannst du alles direkt im Tool.