SuperAPI AI Directory

claude-plugin

🎖️ 🐍 ☁️ - Scan and fix a domain's email authentication (SPF, DMARC, DKIM, MX), blacklist status and domain/SSL expiry, with deterministic, validated fix records.

Open website

About this tool

DNS Doctor MCP server and Claude Code plugin are used to scan, fix, and verify a domain's DNS configuration from any AI agent, with a focus on email authentication (SPF, DMARC, DKIM), and extending to multi-region propagation, SPF include supply chain auditing, MX, DNS health, blacklists, and domain/SSL expiration checks.

Main capabilities

  • Scan and diagnose: perform a scan on a specified domain, checking DMARC policy, SPF record validity and lookup count, DKIM selectors, blacklist status, domain expiration time, and more.
  • Remediation suggestions: generate and verify remediation records. All remediation records are generated and verified by a deterministic engine (RFC syntax plus the SPF 10-lookup counter), rather than LLM guesses, ensuring that the returned records parse correctly and avoiding plausible-looking but actually invalid strings.
  • Monitoring reads: provide three monitoring read tools, get_alerts, get_readiness, and get_lookalikes, as well as the dnsdoctor://domains resource (continuously monitored domains and their latest per-item check status).
  • Two transport methods: hosted Streamable HTTP (https://dnsdoctor.dev/mcp,无需安装、无需密钥)与本地 stdio (npx -y @dnsdoctor/mcp@1.10.3, runs locally and calls the public REST API, does not hold diagnostic logic, and forwards record strings verbatim). Both transport methods provide the same 22 tools.

How to use

  • Claude Code plugin: add the marketplace/repository and enable the plugin. Once enabled, the skill loads automatically, and the dns-doctor MCP server connects to https://dnsdoctor.dev/mcp。开发期间也可将 Claude Code points to the local checkout of this directory.
  • claude.ai (MCP connector): add a custom connector with the URL https://dnsdoctor.dev/mcp,传输方式为 Streamable HTTP, with authentication as none (anonymous) or a Bearer token.
  • Any MCP client: use the standard configuration.
  • Optional API token: anonymous access covers scanning and remediation; an account API token unlocks the account's own monitoring data (the get_alerts, get_readiness, and get_lookalikes tools and the dnsdoctor://domains resource). At https://dnsdoctor.dev after logging in, go to Settings → API tokens to create a token; the plaintext (dnsd_…) is shown only once. In .mcp.json, add an Authorization header for the server: { "mcpServers": { "dns-doctor": { "type": "http", "url": "https://dnsdoctor.dev/mcp", "headers": { "Authorization": "Bearer ${DNSDOCTOR_API_TOKEN}" } } }, then export DNSDOCTOR_API_TOKEN=dnsd_YOUR_TOKEN in the environment. Never commit the token.
  • Environment variables: DNSDOCTOR_API_TOKEN is optional (anonymous access covers scanning and fixes; the three monitoring reads require it). DNSDOCTOR_API_BASE can override the origin, and must provide an origin for /api/… paths, i.e. the public site rather than a bare backend port.
  • Building the stdio server from source: tools.json and instructions.txt are generated by the hosted server and pinned by backend tests; never edit them manually, and do not add tool descriptions to src/. These two files are published with the npm package; if they are missing, the client will have no tools and no security guidance.

When to use

  • Troubleshoot DMARC, SPF, and DKIM configuration issues when email goes to spam.
  • Need to generate publish-ready, syntactically correct DNS fix records.
  • Perform one-off diagnostics or continuous monitoring for a domain (API token required).
  • Audit the SPF include supply chain, check multi-region propagation, MX, blocklists, and domain/SSL expiration.

Limitations

  • Anonymous access covers only all 15 diagnostic tools, which is enough for one-off diagnostics; monitoring read tools and the dnsdoctor://domains resource require a valid token, otherwise the call is rejected and points to the page where the account owner can generate a token.
  • The local stdio server only registers tools and does not provide resources.
  • The local stdio server itself does not hold diagnostic logic; it only forwards the record strings returned by the public REST API.
  • Fix records must be applied by the user in their DNS host, and after confirming approval, rescanned for verification.
  • The project uses the Apache-2.0 license.

Methodology (how determinations are calculated):https://dnsdoctor.dev/methodology REST API / OpenAPI schema:https://dnsdoctor.dev/api/v1/openapi.json