TamingDNS

npx add-mcp 'https://tamingdns.com/mcp'

TamingDNS MCP Server

This endpoint is a live Model Context Protocol server. Point an AI agent at it and the agent can run the same DNS and email-authentication checks you run on this site. It is the same engine code returning the same grades, as structured JSON instead of a web page. You don't need an account or an API key, and it costs nothing.

The short version

• Endpoint: https://tamingdns.com/mcp. Streamable HTTP, JSON-RPC 2.0 over POST, stateless.
• Auth: none. Rate limits apply per IP (see below).
• Tools: check_spf, check_dkim, discover_dkim, check_dmarc, check_dnssec, check_dane, check_mx, check_mta_sts, check_tls_rpt, check_bimi, check_m365, check_google_workspace, check_dns_propagation, check_txt, analyze_email_headers, decode_bounce, analyze_dmarc_report, check_website and check_mcp_keys. The rest of the TamingDNS diagnostics follow in later phases.
• Tool choice: the server sends its own guidance in the instructions field of its initialize reply, so the agent knows which tool fits the question.
• One prompt: audit_email_auth. It asks your agent to find the mail provider, run the Microsoft 365 or Google Workspace audit (or the SPF, DKIM, DMARC and BIMI checks for anyone else), and turn the findings into a fix list.
• Discovery: server card · llms.txt · finding-code registry.
• Listed in the official MCP Registry as com.tamingdns/mcp, in the Claude directory, and on Glama: and mcptry:

Connect your client

Any MCP client that speaks Streamable HTTP can attach. Add the server once; after that your agent calls the tools by name.

Want it in one click?

These links open the app, so they only work if it's installed on this computer.

Add to Cursor Add to VS Code Add to LM Studio Add to Goose

Claude Code?

claude mcp add --transport http tamingdns https://tamingdns.com/mcp

Claude Desktop or claude.ai?

Open the TamingDNS listing in the Claude directory and click Connect to Claude. You can still add it by hand: Customize → Connectors → Add custom connector, paste https://tamingdns.com/mcp as the URL, and leave authentication blank. The server doesn't use any.

Cursor?

Add this to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "tamingdns": { "url": "https://tamingdns.com/mcp" }
  }
}

VS Code?

Run MCP: Add Server, or add this to .mcp.json at the workspace root, or to ~/.copilot/mcp-config.json for every workspace:

{
  "mcpServers": {
    "tamingdns": {
      "type": "http",
      "url": "https://tamingdns.com/mcp",
      "tools": ["*"]
    }
  }
}

Windsurf?

In Cascade's MCP menu, choose Open MCP config file and add:

{
  "mcpServers": {
    "tamingdns": { "serverUrl": "https://tamingdns.com/mcp" }
  }
}

Zed?

Use Settings → AI → MCP Servers → Add Server → Add Remote Server, or add this to your settings file:

{
  "context_servers": {
    "tamingdns": { "url": "https://tamingdns.com/mcp" }
  }
}

LM Studio?

In the Program tab, choose Install → Edit mcp.json and add the same block as Cursor. LM Studio reads Cursor's format.

Goose?

Add this to ~/.config/goose/config.yaml:

extensions:
  tamingdns:
    name: TamingDNS
    type: streamable_http
    uri: https://tamingdns.com/mcp
    enabled: true
    timeout: 300

Raycast?

Open Raycast → search "Manage MCP Servers" → Add Server. Choose HTTP as the transport and paste the endpoint URL. Then ask Raycast AI something like "@tamingdns check the DMARC record for example.co.za". MCP servers in Raycast sit behind Raycast AI, which needs a Pro plan.

A client that only speaks stdio?

Bridge it with mcp-remote:

npx mcp-remote https://tamingdns.com/mcp

No MCP client? curl works

The server is plain JSON-RPC 2.0 over HTTPS POST, so anything that can make an HTTP request can use it. A weekly cron job that checks your clients' DMARC records is a one-liner. List the tools:

curl -sS -X POST https://tamingdns.com/mcp \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Run a check and pull out the grade and finding codes with jq:

curl -sS -X POST https://tamingdns.com/mcp \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":2,"method":"tools/call",
           "params":{"name":"check_spf","arguments":{"domain":"google.com"}}}' \
  | jq '.result.structuredContent | {grade, status, findings: [.findings[].code]}'

The same call shape works for check_dmarc, check_dnssec, check_dane, check_mx, check_mta_sts, check_tls_rpt, check_bimi, check_m365, check_google_workspace, check_txt, check_website, check_mcp_keys and discover_dkim. check_dkim also wants a selector argument, check_dns_propagation takes an optional type (A by default), analyze_email_headers takes a headers string instead of a domain, decode_bounce a bounce string, and analyze_dmarc_report a report string; see the table below.

The tools

Tool	Input	What it checks
check_spf	{ domain }	The SPF record, the expanded include/redirect tree, the RFC 7208 lookup count, and the terminal all qualifier resolved through any redirect= chain.
check_dkim	{ domain, selector }	One DKIM public key at <selector>._domainkey.<domain>: key type, length, revocation, test mode. For the 500-selector sweep, use discover_dkim or the /dkim page.
discover_dkim	{ domain }	Every key under the 500-selector database and the *._domainkey wildcard, each validated the way check_dkim does it. If the MX is Mimecast, it also tries Mimecast's date-stamped selectors, nine years back. The dated ones run in the background for about two minutes; the first call says when to call again, and the outcome is kept for 24 hours. Lookups that failed are counted, never reported as "no key". It has its own, lower rate limit.
check_dmarc	{ domain }	The DMARC policy via dual discovery: the RFC 7489 org-domain ladder receivers enforce today, and the RFC 9989 DNS Tree Walk. Emits a DISCOVERY_DIVERGENCE warning when the two pick different records. Parses DMARCbis tags (t=, np=, psd=) and checks external RUA/RUF authorisation.
check_tls_rpt	{ domain }	The TLS-RPT record at _smtp._tls.<domain> per RFC 8460 §3 (case-sensitive leading v=TLSRPTv1, multiple records mean receivers treat it as not implemented), every rua= destination's syntax, and whether MTA-STS or DANE gives senders anything to report against.
check_mta_sts	{ domain }	MTA-STS per RFC 8461: the _mta-sts TXT record (strict §3.1 selection), the policy file fetched without following redirects, the policy-host certificate (grade-bearing: a failed cert means senders fetch no policy), and live MX coverage against the mx: patterns.
check_bimi	{ domain }	The BIMI record at default._bimi.<domain>, SVG Tiny-PS logo validation, the full VMC certificate chain (expiry, EKU, SCT, issuer), and the DMARC enforcement prerequisite.
check_mx	{ domain }	The apex MX RRset (priority-sorted), and per host the A/AAAA addresses, PTR + forward-confirmed reverse DNS (FCrDNS), DANE TLSA, IP-literal (RFC 5321 §5) and CNAME (RFC 2181 §10.3) violations, and the mail provider. Detects the null MX (RFC 7505) and the implicit MX via the apex address. Probes the MTA-STS / TLS-RPT prerequisites.
check_dnssec	{ domain }	The DNSSEC chain of trust, walked zone by zone (root → TLD → domain): DS, DNSKEY and RRSIG over binary DoH, each DS digest recomputed against the published keys (RFC 4034 §5.1.4), and the AD bit cross-checked across Cloudflare, Google, Quad9 and OpenDNS. Unsigned is the common case and returns info, not a failure; a published-but-broken chain returns fail.
check_dane	{ domain }	SMTP DANE / TLSA records (RFC 7672): the TLSA record at _25._tcp.<mx-host> over binary DoH, each record classified by usage / selector / matching (RFC 7671 §2.1), and the DNSSEC AD bit confirmed, since an unsigned TLSA answer is the dominant failure mode. DNS-only: it never opens a port-25 handshake.
check_m365	{ domain }	A domain's DNS against what Microsoft 365 expects: the SPF include, DKIM selector1 and selector2, the DMARC policy, MX, MTA-STS, Autodiscover, TLS-RPT, BIMI and the Teams SIP SRV records. It is built from the same envelopes the single tools return, so it never disagrees with them. A domain with no sign of Microsoft 365 gets one M365_NOT_DETECTED finding. It has no grade; verdict is configured, configured_with_issues or not_detected.
check_google_workspace	{ domain }	A domain's DNS against what Google Workspace expects: MX to Google, the _spf.google.com include, a DKIM key at the default google selector, the DMARC policy, MTA-STS, TLS-RPT and BIMI. It is built from the same envelopes the single tools return, so it never disagrees with them. No key at google is a warning, because an admin can pick another prefix. A domain with no sign of Google Workspace gets one GWS_NOT_DETECTED finding. It has no grade; verdict is configured, configured_with_issues or not_detected.
check_txt	{ domain }	Every TXT record at the apex, labelled by vendor or purpose, plus 12 well-known names (_dmarc, _mta-sts, _smtp._tls, default._bimi, provider tokens). Flags more than one v=spf1 record (RFC 7208 §4.5 permerror), a DKIM key published at the apex, and duplicate vendor tokens. No grade; verdict is clean, warnings, misconfigured, incomplete or no_records.
check_dns_propagation	{ domain, type }	One record type at one name, asked of 14 public resolvers in North and South America, Europe and Asia. resolvers[] gives each one's answer and TTL, so you can compare them with the value you published. verdict is consistent, absent, rotating, split_short_ttl, split or incomplete; only an unexplained split or fewer than half answering raises a warning. A timeout never counts as "no record". Never cached, so you can poll it.
analyze_email_headers	{ headers }	A pasted block of raw email headers, judged for spoofing and phishing: SPF/DKIM/DMARC alignment, Microsoft compauth reason codes, ARC chain integrity, homoglyph From domains, duplicate singleton headers, display-name spoofing, backward Received timestamps, and link display-vs-href mismatches. Returns a phishing verdict; the echoed input is a digest only, so raw headers never come back.
decode_bounce	{ bounce }	A pasted bounce: an NDR email, an SMTP error line or a mail-log fragment. Returns the SMTP and enhanced status codes, the provider that sent it, whether the failure is permanent or temporary, and what the code means with fix steps. With no enhanced code, a known phrase in the wording picks the explanation, and a finding says so. The echoed input is a byte count only.
analyze_dmarc_report	{ report }	One DMARC aggregate (RUA) report, pasted as XML text. Returns who reported, the published policy, message totals split into DMARC capable, forwarded and unauthenticated, every source row, and the recommendations the viewer shows. Unauthenticated mail under p=none is an error finding. Never cached, and the echoed input is a byte count only.
check_website	{ domain }	One public hostname at the web layer: the HTTPS redirect chain, the TLS certificate and its trust, security headers, cookie flags, HTTP/2 and HTTP/3, whether plain http:// redirects, mixed content, security.txt and any CDN or WAF in front. verdict is the page's ok, warn or fail, with one finding per failing check. A name that resolves to a private address is refused. It has its own, lower rate limit.
check_mcp_keys	{ domain }	The v=MCPv1 TXT records at a domain, the keys the MCP Registry DNS login checks a signature against. Each record is judged the way the registry's own parser judges it: exact case and tag order, ed25519 or ecdsap384, padded base64, the right key length, and for P-384 a compressed point on the curve. verdict is not_configured, valid, some_invalid, invalid or misplaced (a record under _mcp-auth. or _mcp-registry., where the registry never looks), with a SHA-256 fingerprint per key.

Which tool should my agent call?

The server's initialize reply carries an instructions string, and clients that support it pass it to the model.

• The whole mail setup on Microsoft 365 or Google Workspace? check_m365 or check_google_workspace. One call covers SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT and BIMI. Not sure which provider? check_mx names it in analysis.hosts[].provider.name.
• One standard? The single tools: check_spf, check_dmarc, check_dkim (with a selector; google, selector1 and selector2 are the common ones; discover_dkim finds them when you don't know), check_mx, check_mta_sts, check_tls_rpt, check_bimi, check_dane, check_dnssec.
• What TXT records does a domain publish, and are any of them wrong? check_txt. It labels each record by vendor and flags duplicate SPF records, a DKIM key at the apex and stale tokens.
• Just changed a record? check_dns_propagation. Poll it and compare resolvers[].values with what you published.
• A message that looks wrong? analyze_email_headers with the raw headers.
• A bounce or SMTP error? decode_bounce with the pasted text.
• A DMARC aggregate report? analyze_dmarc_report with the XML (decompress the .xml.gz first).
• A website's certificate, headers or redirects? check_website with the hostname.
• Will the MCP Registry accept a domain's signing key? check_mcp_keys.

A result with retriable: true in its error did not finish. It says nothing about whether the record exists, so the instructions tell the agent to retry rather than report it missing.

For a one-shot audit there is the audit_email_auth prompt. It asks the agent to call check_mx first, then the Microsoft 365 or Google Workspace audit, or the SPF, DMARC, DKIM and BIMI checks when the domain is on neither, and to turn the findings into a fix list.

What comes back?

Every tool returns the same canonical envelope, in structuredContent and duplicated as a JSON text block:

• status: pass / warn / fail / info / error. The one-word answer. error means the check didn't finish, so it says nothing about the domain.
• verdict: the tool's own classification, such as enforced for DMARC or configured_with_issues for the Microsoft 365 audit.
• grade: A to F, with grade_reasons[] explaining each deduction in plain language. Only the single-standard tools grade. check_m365, check_google_workspace, check_dns_propagation, analyze_email_headers, decode_bounce, analyze_dmarc_report, check_website and check_mcp_keys return a verdict and no grade.
• findings[]: structured issues with stable codes (POLICY_NONE, NEAR_LOOKUP_LIMIT, TESTING_MODE, and so on), severity, and remediation text. The full registry lives at /mcp/resources/finding-codes and via MCP resources/read.
• records[]: the raw DNS records the verdict was computed from, so an agent can show its work. An empty array means the lookup finished and found nothing.
• provenance.queries[]: each DNS lookup behind the result, with the resolver, what it said (answer, nodata, nxdomain, servfail, timeout and so on), the rcode and how long it took.
• analysis: tool-specific detail such as the SPF include tree, the DMARC discovery ladder, or the VMC chain.
• error: present only when status is error. If the resolvers failed or timed out, the result carries a code (DOH_TIMEOUT, DKIM_LOOKUP_FAILED), a message and retriable: true, and no records, verdict or grade, so nothing in it reads as "no record". The MCP call result also sets isError. The tools only report a missing record from a confirmed DNS answer. When retriable is true, retry the call; errors are not cached. After a rate limit, wait the seconds given in retry_after (MCP) or the Retry-After header (REST).

The MCP server, the browser tools on this site, and the in-page WebMCP tools all run the same engine code. An agent calling check_dmarc gets byte-identical grading to a human using /dmarc. There is no "API version" that lags the website.

Practical details

What are the rate limits?

Per IP, a few dozen calls a minute, enough for interactive use and scheduled checks, not for bulk scanning. Results are cached for 60 seconds per input (check_dns_propagation is never cached, so you can poll it, no more often than every 10 seconds: it has its own, lower limit; analyze_dmarc_report is never cached either; check_website has its own, lower limit too). A repeat call inside that window returns the cached answer but still counts towards the limit. If you need more for a legitimate use case, talk to us.

Is there really no authentication?

None. Every tool is read-only and idempotent. It reads public DNS records, or the headers you send. The MTA-STS and BIMI checks also fetch the files a domain publishes: the policy file, the logo and the certificate. The website check fetches the homepage and security.txt, and reads the certificate. There is nothing an API key would protect.

Where is the machine-readable description?

The SEP-2127 server card is at /.well-known/mcp/server-card.json. Site-wide context for LLMs is in /llms.txt and /llms-full.txt.

Looking for the v=MCPv1 DNS-key checker?

The DNS signing-key checker that used to live at /mcp moved to /mcp-keys on 2026-06-07. Same tool, new home. This path now belongs to the MCP server itself.