Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add dnsdoctor/claude-plugin --skill dns-doctorgit clone --depth 1 https://github.com/dnsdoctor/claude-pluginWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/dnsdoctor/claude-plugin/dns-doctor)<a href="https://agentmods.dev/skills/dnsdoctor/claude-plugin/dns-doctor"><img src="https://agentmods.dev/badge/skills/dnsdoctor/claude-plugin/dns-doctor/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/dnsdoctor/claude-plugin/dns-doctor"><img src="https://agentmods.dev/badge/skills/dnsdoctor/claude-plugin/dns-doctor.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00177 | $0.08069 |
| Opus 5 | $0.00088 | $0.04034 |
| Sonnet 5 | $0.00035 | $0.01614 |
| Haiku 4.5 | $0.00018 | $0.00807 |
Grade A, and why
dns-doctor scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 428 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DNS Doctor — the DNS, DMARC, SPF and DKIM skill
DNS Doctor scans, fixes and verifies a domain's DNS — email authentication (SPF, DMARC, DKIM) first, plus multi-region propagation, SPF include supply-chain audits, MX, DNS health, blacklists and domain/SSL expiry — and returns deterministic verdicts plus copy-paste fix records generated by a validating engine. The record you get back is verified against RFC grammar and the SPF 10-lookup limit — it is never an LLM guess. Your job is to run the scan, explain the findings, hand the human the exact record, and confirm the fix — not to author DNS records yourself.
What this skill sends, and where
Every tool call goes to one host, https://dnsdoctor.dev (or the local @dnsdoctor/mcp
client, which calls the same public API). What leaves the machine is exactly what the user
asked to check: a domain name, and for the focused tools a record name, an IP address, a DKIM
selector, a pasted DMARC record, or an uploaded DMARC report. Nothing else is read or sent — no
files, no environment beyond an optional DNSDOCTOR_API_TOKEN, no message contents.
Two things the user should know before you scan a domain for them:
- A scan result is a public report page at
https://dnsdoctor.dev/scan/<domain>(the free scanner is a public service, like a DNS lookup site). Do not scan a domain the user wants kept private, and say so if they ask. - The optional API token (
DNSDOCTOR_API_TOKEN) goes to dnsdoctor.dev only, as anAuthorizationheader, and only if the user put it in your environment; the local@dnsdoctor/mcpclient attaches it to its requests, and the server uses it for the two monitoring reads (get_alerts,get_readiness) and thednsdoctor://domainsresource. Never send any other credential, and never ask for one.
DNS Doctor never changes DNS: it returns records for a human to publish.
When to use this skill
Reach for it whenever a user describes any of:
- "our email is going to spam" / "customers aren't getting our mail"
- "SPF PermError" or "too many DNS lookups" (the SPF 10-lookup limit)
- "DMARC is stuck at p=none" / "how do I get to p=reject safely"
- a bounce code like
550 5.7.515,550 5.7.1, ordmarc=fail - "is my domain blacklisted?" / "am I on a blocklist?"
- "when does my domain / TLS certificate expire?"
- "who can send as us?" / auditing SPF includes before or after an email provider migration
- locking down parked, redirect or brand-defensive domains that send no mail
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today Changed · +21 lines 6969051dd7b2
- 3d ago Changed · -8 lines · +27 tokens per session 9e1094876235
- 6d ago Changed · +35 lines · +34 tokens per session 7e61cf2d99c4
- 10d ago First seen · 380 lines · 116 tokens per session scan A 1a57d4f67de4
dns-doctor is a skill published in the GitHub repository dnsdoctor/claude-plugin (2 stars, last pushed yesterday), licensed Apache-2.0. It adds 177 tokens to every session and 8,069 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
analyzing-email-headers-for-phishing-investigation
Parse and analyze email headers to trace the origin of phishing emails, verify sender authenticity, and identify spoofing through SPF, DKIM, and DMARC validation.
analyzing-email-headers-for-phishing-investigation
Parse and analyze email headers (Received chain, Return-Path, Message-ID) to trace the true origin of a phishing email and validate SPF, DKIM, and DMARC results to confirm or rule out sender spoofing. Use when triaging a suspicious or reported email, investigating a phishing incident, or verifying whether a message's…
analyzing-email-headers-for-phishing-investigation
Parse and analyze email headers to trace the origin of phishing emails, verify sender authenticity, and identify spoofing through SPF, DKIM, and DMARC validation.
email-security
DMARC/SPF/DKIM check, email spoofing, SMTP test, and security header analysis.
email-deliverability
Use when mail already sent lands in spam, is rejected, or fails the Gmail/Yahoo bulk-sender checks and the fix is authentication and reputation, not the sending code: SPF/DKIM/DMARC alignment, domain warmup, spam-complaint rate, one-click unsubscribe, BIMI. NOT putting mail on the wire through a provider API (that is…
analyzing-email-headers-for-phishing-investigation
Use when parse and analyze email headers to trace the origin of phishing emails, verify sender authenticity, and identify spoofing through SPF, DKIM, and DMARC validation. Use when working with analyzing email headers for phishing investigation.