I built an MCP server for DNS + email security — 37 tools...

The first time intodns-mcp saved me real time was on day one. Claude scanned a client's domain, listed seven concrete issues with citations to the live records, and proposed exact zone-file edits — in under three seconds. Before MCP, that conversation was three browser tabs, two dig sessions, and a lot of squinting at numeric DKIM key tags.

The reason it worked: Claude wasn't guessing.

Email-auth and DNS are exactly the kind of domain where LLMs hallucinate the worst — small surface area, sharp answers, no room for "approximately correct". Ask any frontier model to check whether example.com has DNSSEC and a fair share of the time it cheerfully invents a key tag. Ask it whether your SPF blows the 10-lookup limit and it'll quote the rule from memory but skip counting your actual includes.

There is no fix-by-prompt for this. The model has to look. So I built intodns-mcp — a Model Context Protocol server that exposes 37 deterministic tools backed by IntoDNS.ai's free public API. The model doesn't remember. It calls check_dmarc, gets the live record, gets the policy interpretation, gets the citation URL, and writes an answer grounded in what your DNS actually says today.

Install

npx -y intodns-mcp

For Claude Code, add to ~/.claude.json:

{
  "mcpServers": {
    "intodns": {
      "command": "npx",
      "args": ["-y", "intodns-mcp"]
    }
  }
}

Same shape works for Cursor, Windsurf, Zed, Continue, OpenClaw — anything that speaks MCP stdio. No API key. Live in ten seconds.

What's in the box

37 tools across four buckets:

DNS layer — lookup_dns, validate_dnssec, check_dns_propagation, check_tlsa_dane, check_http3

Email authentication — check_spf, discover_dkim, check_dmarc, check_bimi, check_mta_sts, check_smtp_tls, check_fcrdns, check_blacklist, check_sender_requirements

Holistic scan + reports — scan_domain, get_everything_report, create_report_snapshot, run_public_scan, start_deep_scan

Compliance — nis2_quickscan, which is the one I'm most pleased with: it maps every observable DNS/mail-auth/TLS signal onto NIS2 Article 21.2's ten cyber-hygiene measures (a–j) and returns a weighted 0–100 score with per-measure evidence and concrete fix suggestions. For EU teams staring down the NIS2 enforcement deadline, this turns "are we compliant?" into a checkable artifact instead of a panel discussion.

The full tool list is in the README.

A real session

Asking Claude to audit example.com:

> /mcp__intodns__scan_domain example.com

Grade: D
Score: 42/100

Issues:
- spf_missing
- dmarc_missing
- no_dnssec
- no_caa

Recommendations:
- Publish SPF record (start with: v=spf1 -all)
- Add DMARC policy (start at p=none, sp=none, ruf=…)
- Enable DNSSEC at registrar
- Publish CAA records to restrict CA issuance

Citations:
- https://intodns.ai/scan/example.com
- https://intodns.ai/learn/spf
- …

The model now reasons over a real result instead of fictional RFCs. Combine scan_domain with generate_dns_fix and you can ask "what's broken and how do I fix it?" and get an answer that references actual records, not the kind of confident-sounding plausible advice that makes incident reviews miserable.

NIS2 quickscan, briefly

nis2_quickscan is the differentiator. Article 21.2 lists ten technical and organisational measures every essential and important entity has to implement. DNS/email is only one layer, but it's the layer that's observable from outside — any auditor with a resolver can grade it.

> /mcp__intodns__nis2_quickscan example.eu

NIS2 21.2 Readiness: 64/100

Per-measure status:
  a (risk policy)         — n/a (organisational)
  b (incident handling)   — n/a (organisational)
  c (business continuity) — n/a (organisational)
  d (supply chain)        — partial: 3rd-party mail provider observed
  e (acquisition/dev)     — n/a (process)
  f (effectiveness assess)— evidence: weak (no DMARC reports collected)
  g (basic cyber hygiene) — strong: SPF + DMARC enforced
  h (cryptography)        — strong: TLS 1.3, MTA-STS enforce
  i (HR security)         — n/a
  j (auth, MFA, …)        — partial: DNSSEC missing

Real compliance still needs the full audit (organisational measures, supply chain, training, incident response). But for the DNS/email layer, the model now has a concrete, citable answer — which is the part that previously took a security consultant two hours of dig commands to produce.

Why MCP, not "just call the API"

You could absolutely just curl the IntoDNS API. But once the model has the tools wired through MCP:

The agent picks the right tool for the question without you scripting it
Tool descriptions feed into the model's reasoning — it learns when check_mta_sts is the right call vs check_smtp_tls
Citation URLs come back with the data, so the model writes answers with links instead of vibes
Same server works in your editor, your terminal, your remote agent — install once

This is the bet of MCP in general, and DNS/email security turns out to be a near-perfect fit: deterministic backend, structured answers, well-bounded tool surface.

What's the catch

Honestly, the catch is the same as every backend-tools-over-MCP design: your agent only knows what your backend knows. IntoDNS.ai scans from one vantage point, so propagation tests are best-effort, not authoritative across every recursive resolver on Earth. For deep-scan cases (CDN edge issues, GeoDNS) you'll still want to combine with something like RIPE Atlas.

Everything else — SPF/DKIM/DMARC parsing, DNSSEC validation, MTA-STS, NIS2 mapping — is deterministic and reproducible. Citation-grade report snapshots are content-hashed so the same scan referenced in a ticket six months from now still resolves to the same evidence.

推荐订阅源

DEV Community